From J Wiki
< System‎ | Interpreter‎ | Bugs
Jump to: navigation, search
Requests: Interpreter   Bugs: Interpreter

Please restrict the headings to just two levels, with the actual bug reports placed at the top level; sign your submission using ~~~~; register the entry in the comment field below.

These reports/requests have been closed for the reason cited.

evoke local names

Evoke on verb arguments to explicit conjunctions and adverbs don't refer to local names; refer to global names.

   useU    =.  2 : ' ''u.''~ ''n.''~'
   evokeU  =.  1 : ' ''u.''~ '

   +: useU 12    NB.  Correct
   +: evokeU     NB.  Bug
|value error: u.

   u. =. -:
   +: useU 12    NB.  Correct
   +: evokeU     NB.  Bug

-- Dan Bron <<DateTime(2005-11-09T21:14:49Z)>>

  • I'm not sure that this is a bug. I think this behavior fits what the dictionary says about resolution for verbs: verbs are resolved as names, and the name is used at evaluation time to determine the context for execution. Here's a definition of evokeU that does what I think you want:

evokeU=:1 :'(5!:1<''u.'')5!:0'
-- ["Raul Miller"] DateTime(2006-05-22T19:39:30Z)

  • I considered that interpretation. But I don't buy it (
    Information.png pendantry ahead
    Information.png ).
    -- Dan Bron <<DateTime(2006-05-22T21:15:36Z)>>
  • Related :
  • Related :
   ({.;:'z') 1 : 'sum__m'
|value error: m
Of course, there's a work around `({.;:'z') 1 : ' (''sum_'',(;m),''_'')~ '` .
  • You're stacking the explicit arguments names by value, aren't you? According to Section E of the Dictionary, which says "...their values except in the case of proverbs..." (3208 50 qdoj 'dicte'), this is a bug:
   + 1 : 0
   	u1 =. u /
   	u  =. *
   	u2 =. u /
   	(u1, u2) f.
+/ , */
I don't want you to change this, but I wouldn't mind if the Dictionary were changed s.t. [wiki:JForum:beta/2006-April/000840 all local names were stacked by value].

Status: closed, documented in NuVoc. The original evokeU is not an error; 'u'~ evokes the name u which is returned as the result of the modifier; that gets a value error when used in the caller.

The special treatment of the local names x y u v m n is documented in the details of : .

value errors with special names

The special names, which denote arguments to explicit definitions, are still treated differently from other names.

   3 : '  ".  ''q'' ' 0  NB.  Fine

   3 : '  ".  ''n'' ' 0  NB.  Bug
|value error: n
|       n

   3 : ' q"_ :: 0: y' 0   NB.  Fine

   3 : ' u"_ :: 0: y' 0   NB.  Bug
|value error: u
|       u"_ ::0:y

   foo =: 3 : 0
	4!:55 {. ;: 'z'
	name_z =. + z     NB.  Fine (when verb executed)

	4!:55 {. ;: 'y'
	name_y =. + y     NB.  Bug  (when verb executed)

   foo ''
|value error: y
|   name_y=.+    y

A similar error occurs for the analogous cases of x m n u v where no such exception would be expected.

Note that this can cause unexpected problems when loading (or loadding or requireing) files which expect y to be a normal undefined name. Vide:

   'foo =: + y' fwrite jpath '~temp\y.ijs'
   load '~temp\y.ijs'
|value error: y
|   foo=:+    y
|[-0] c:\app\j\current\temp\y.ijs

I thought this particular (loading) problem might be restricted to the name y, due to the phrase 4!:55<''y'' in the library definitions script and scriptd, but all the special names are so effected.

-- Dan Bron <<DateTime(2006-09-21T19:07:34Z)>>

Status: Closed, documented in NuVoc in the details of : .

display of bonded conjunctions buggy

Similar to the sequence adverbs bug, certain typing adverbs raise errors when displayed:

|domain error
|spelling error
}}} while the diplay of others is incorrect (misleading, ambiguous):


and others have no display at all:

   (((a=.<3)++)`)  ("_) (`a)
   NB.  No display

   e=. (((a=.<3)++)`)  ("_) (`a)
|domain error
|       5!:5{.;:'e'
    NB.  Explicit request for display results in error
    NB.  (like earlier examples).

I suggest that the display of the form `(abn=.arbitrary boxed noun) should be '`(',')',~5!:5<'abn' except when abn happens to be the same as an atomic rep of a verb, in which case the display should be '`(',')',~]2 :'5!:5{.;:''v''' abn 5!:0, as now. If abn is the atomic rep of a primitive or named verb, the parentheses may be elided. Similar strategies apply to abn` and other conjunctions in place of ` .

-- Dan Bron <<DateTime(2006-12-30T18:22:14Z)

Status: Closed, documented in NuVoc. The error seems to be that gerund modifiers ` and `: cannot create a display when they have a boxed operand that is not a valid gerund.

zero-length infix discrepancy

As asked in the Infix thread in the Forums: Is this right?

   0 (<\ ,&# <;._3) i. 5
6 5

Look at the pattern:

   inf   =:  2 : '(i. ->: n) #@u"0 _ i. <:n'
   inf5  =:  inf 5
   <\ inf5 ,: <;._3 inf5
0 1 2 3 4 5
0 1 2 3 4 4

I'm pretty sure that \ is right and ;._3 is wrong, but not positive. Just as \ is a sliding window across one dimension, so ;._3 is a sliding window across any number of dimensions. But when that number is 1, its results should agree with \ . No?

Status: closed, documented in NuVoc

-- Dan Bron <<DateTime(2007-01-06T04:23:27Z)>>

final sentence of f. specification incorrect

The sentence x f. will not fix any part of x that contains $: from the Vocabulary page for f. (1770 100 qdoj 'f.'), added in J5, should be removed for J6. It is now incorrect:

   z =. $:@:<:^:*
   x =. 10 + z
   x f.
10 + 3 : '$:@:<:^:* y' :(4 : 'x $:@:<:^:* y')

Also, the notation x for an adverb's argument is outdated. The notation is now u, which can be a noun or verb (as x, above, may be noun or verb).

Status: closed, documented in NuVoc

-- Dan Bron <<DateTime(2007-04-03T16:03:52Z)>>

dyads #. and #: sensitive to type of empty RHA

Even though ''-:i.0, the dyads #. and #: treat them differently:

   0 #. i.0
   0 #. ''
|domain error
|   0    #.''

   $ (,0) #: ''
   $ (,0) #: i. 0
0 1

Also, given that r&#: is defined in terms of r&#., and (,0)&#. i.0 signals error (fundamentally, because (,1) * i.0 signals error), perhaps (,0)&#: i.0 should too? Or maybe the other way around: maybe (,0)&#. i.0 should produce a result?

Status: closed, no problem. The behavior of #. is admissible (and now documented in NuVoc). The behavior of #: follows the rules for errors in fill-cells.

-- Dan Bron <<DateTime(2007-04-03T16:04:29Z)>>

cannot exclude index from scalar

Even though it is possible to select indices from a scalar, as in 0{9 and _1{9, it is not possible to except (suppress) indices from a scalar:

   (<<<0) { 9
|length error
|   (<<<0)    {9

   (<<<_1) { 9
|length error
|   (<<<_1)    {9

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- Dan Bron <<DateTime(2007-10-26T18:33:15Z)>>

It seems you also cannot index a scalar (in its first dimension) if you use a boxed left argument: (<0) { 2 gives length error to me in j602/2008-03-03/16:45 amd64 linux.

Status: closed. { is not indexing an array, but conforming to the fact that an atom is considered to have one item.

-- User:B Jonas <<DateTime(2009-12-02T23:54:40+0200)>>

fsm corrupts memory

As reported by User:RE Boss in the Forums, the following sentences, adapted from HenryRich's [[JDic:../jforc/loopless_code_vii_sequential.htm#_Toc141158112|JfC]], crash J:

   m =. a. e. '0x123456789abcdefABCDEF'
   m =. m + a. e. '0x'
   m =. m + a. e. '0'

   s =. 1 4 2 $ 0 0 0 0 0 0 1 1
   s =. s , 4 2 $ 0 0 0 0 2 0 0 0
   s =. s , 4 2 $ 0 0 3 0 0 0 3 0
   s =. s , 4 2 $ 0 3 3 0 0 3 3 0

   1!:2&2 (5;s;m;0 _1 0 0) ;: 'qqq0x30x30x40x0x34a'

However, the problem is more complex; you may see the details in my Forum message.

Since this code is highlighted in book popular with J neophytes, it might be given some priority (lest they give up on J when they execute it and the interpreter crashes).

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

Status: closed, fixed in J8

-- Dan Bron <<DateTime(2007-11-07T13:47:42Z)>>

rank with more than three numbers

The following gives a length error:

   0"0 0 0 0 ] 0

I belive it should just give 0 just like 0"0 0 0 ] 0, because according to the dictionary definition of m"n, "The rank used is 3 $&.|. n ." (It might be better to change the dictionary definition to reflect this.)

The same is true for ranking a verb: ]"0 0 0 0 ] 0 gives a length error, while it should return 0.

I'm using j601/2006-09-04/09:20 on i686-linux. -- User:B Jonas <<DateTime(2007-11-08T11:01:08Z)>>

The full form of the levels used is 3$&.|.n. (1)

To be fair, the same page also says: It may have three elements, specifying levels for the monadic, left, and right cases (2)

But if that doesn't prohibit the case that 2-:#n then it cannot prohibit the case that 4-:#n. 1. 1500 63 qdoj 'L:' 1. 1408 86 qdoj 'L:'

Status: closed, documented in NuVoc

-- Dan Bron <<DateTime(2007-11-19T22:27:06Z)>>

define is permissive

The adverb 5!:0 is permissive; it will accept arguments encoded in a non-5!:1 format. Specifically, it permits excessive boxing:

   (< (,'3') ; < (;:'--') ,<^:1 (,'3'); <;:'---')5!:0
- - - - -
   (< (,'3') ; < (;:'--') ,<^:2 (,'3'); <;:'---')5!:0
- - - - -
   (< (,'3') ; < (;:'--') ,<^:3 (,'3'); <;:'---')5!:0
- - - - -

The definition of 5!:1 does not allow for this extra depth (1565 194 qdojH 'dx005'):

The result is a single box containing a character list of the symbol (if primitive) or a two-element boxed list of the symbol and atomic representation of the arguments (if not primitive).

Though I suppose that since 5!:0 is defined (ibid) as the inverse of 5!:1, and not the other way around (1280 78 qdoj 'dx005'):

That is, (5!:1 <'f') 5!:0 equals f for all f.

the definition of 5!:0 could be considered incomplete rather than incorrect.

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

-- Dan Bron <<DateTime(2007-11-15T21:34:43Z)>>

    • There are other kinds of boxed nouns not returned by 5!:1 which 5!:0 accepts. Namely, you can use uv-style explicit adverbs in verbs, while 5!:1 only produces xyuv-style explicit adverbs, because uv-style explicit adverbs are already called by the time you run 5!:1. Try this for example (the 5!:0 produces a side-effect):
   v =: [
   a =: 1 :('1!:2&2''hello''';']')
   vv =: 5!:1 <'v'
   aa =: 5!:1 <'a'
   ss =: <aa,<vv
   s =: ss 5!:0
   5!:1 <'s'
 -- User:B Jonas <<DateTime(2007-11-16T14:37:16Z)>>
    • I have probably misunderstood you, but I am not sure your example demonstrates what you think it does. In your code, ss is the internal representation of the train v a, not the internal representation of the gerund < aa,<vv. That is, (< aa,<vv) 5!:0 is identical to v a, which indeed produces the effects you note.

If you want 5!:0 to produce the gerund < aa,<vv you must pass it the atomic representation of that noun. To wit: (5!:1 {.;: 'ss') 5!:0.

You are correct that there are other kinds of nouns that 5!:1 will not produce, but 5!:0 will accept, and your ss is one of them. But I think trying the effect of evoking (invoking?) executable trains is "obvious". What I am concerned about in this bug report is the "unobvious" forms acceptable to 5!:0. Here's another example:

   hi   =. 'hello'
   ars  =. <   '0' ; hi
   arv  =. < (,'0'); hi

   ir   =. 5!:1{.;:'hi'

   ir -: arv
   ir -: ars

   arv 5!:0 -: ars 5!:0
 But perhaps you're right; maybe "define" should not invoke trains, merely "single gerunds" (things producible with 5!:1) .  Trains can already be invoked with `:6.

-- Dan Bron <<DateTime(2007-11-16T15:45:33Z)>>

    • Further, despite the description of 5!:1 (quoted above), I know I've seen a case where the left-hand box was neither a single box nor two boxes where the left is a character list of a primitive or a code for a symbol-less entity. I've seen cases where the left hand box itself contains an atomic representation. I believe, but am less sure, I've also seen cases where the number of boxes was three. I cannot now think of examples, but will try to create some if requested (otherwise I'll just post them if I run across them).

Status: closed, left as undocumented feature

-- Dan Bron <<DateTime(2007-11-16T15:57:30Z)>>

dictionary defn for floor does not handle tolerance

The dictionary definition of monad <. (Floor) claims:

For a complex argument, the definition of <. is modelled by:

   floor=: j./@(ip+(c2>c1),c1+:c2)
   '`c1 c2 fp ip'=:(1:>+/@fp)`(>:/@fp)`(+.-ip)`(<.@+.)

However, when tolerance comes in, floor doesn't always return the same as <.. Here's an example with the default tolerance:

      9!:18 ''
      floor=: j./@(ip+(c2>c1),c1+:c2)
      '`c1 c2 fp ip'=:(1:>+/@fp)`(>:/@fp)`(+.-ip)`(<.@+.)
      t =: 2j2 - 1e_13
      ($ ; <. ; floor) t

This is j601/2006-09-04/09:20 on linux-i686.

-- User:B Jonas <<DateTime(2007-11-18T15:59:20Z)>>

Extending the above, the value of floor sometimes depends on the internal type of a number.

   <.x0 =: _1e_14
   <.x1 =: _1e_14 j. 0
   x0 =!.0 x1

I request that you document the precise behaviour of tolerant floor on complex numbers, and implement it consistently.

Status: closed, documented in NuVoc

-- User:B Jonas <<DateTime(2010-02-10T00:04:26+0200)>>

local/global nameclass confusion

Due to the situation described in an earlier bug report, explicit operators can return "confused" entities. For example:

   z =. 'some noun'
   +1 :('z =. some verb or other';'z')
'some noun'
   NB.  Note the quotes around the display

   e =. +1 :('z =. some verb or other';'z')
   4!:0 {.;:'e'
   NB.  The result is a _verb_

   e f.
|domain error
|       e f.
   e 4

|domain error: z
|       e 4
   NB.  But not really.

These confused names take their nameclass from their local context, but their value (later) from the global context.

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

Status: closed, no problem. Any verb v can refer to other names, which were either defined as verbs or undefined when v was assigned. If these names are later redefined as non-verbs, the verb v becomes unusable, and an attempt to evaluate it creates a domain error.

-- Dan Bron <<DateTime(2007-11-19T20:25:35Z)>>

equalty too tolerant for complex numbers

The verb = seems to use a wrong tolerance for complex numbers as for real numbers. This results in real and complex numbers being compared for equalty differently:

   tc =: 1+9e_14j1e_14-0j1e_14
   tr =: 1+9e_14
   tr =!.0 tc
   1 = tr
   1 = tc

The last result is agains the dict definition of =:

If x or y is a finite floating-point or complex number, the comparison is made with a tolerance t , normally 2 to the power _44 but also controlled by the fit conjunction !. , as in x=!.0 y . Formally, x=y is 1 if the magnitude of x-y does not exceed t times the larger of the magnitudes of x and y .

For a graphical demonstration, try


Using j601/2006-09-04/09:20 on i686-linux.

-- User:B Jonas <<DateTime(2007-11-20T13:03:13Z)>>

The bug doesn't seem to happen with j602/2008-03-03/16:45 i686-linux.

Status: closed, fixed in J6.02

-- User:B Jonas <<DateTime(2008-03-20T11:06:03Z)>>

specification of verbal amend incomplete

The specification for verbal amend, u}, is incomplete (or misleading, or incorrect). The wording:

u} is defined in terms of the noun case m}

implies that x u y} and x (x u y)} y are equivalent. They are not; the former amends indices of the ravel of y. For example:

   '*' 1 } 2 2 $'x'
   '*' 1:} 2 2 $'x'

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

Status: closed. x u} y is deprecated.

Secondary problem

   Ei=: i.@(+*+0&=)  NB.Extended integers
   CPA=: (@])%.i.@#@]^/Ei@[  NB.Coeffs of poly approx (adverb)
|syntax error

Status: closed, no problem. A V V V V V is not valid syntax.

-- User:Raul Miller <<DateTime(2008-08-20T23:05:20Z)>>

-- Dan Bron <<DateTime(2008-01-23T00:23:52Z)>>

nan won't do

The phrase _. ". 'r' crashes J. Neither _. ". 'q' nor _. ". 's' crashed J.

Status: closed, fixed in J8

-- Dan Bron <<DateTime(2009-08-16T23:47:07-0300)>>

stacking the proverbial deck

As previously reported by Henry Rich, If "proverb" means "a name that stands for a verb", then this behavior

	   deck =. /
	   deck deck
	deck deck

disagrees with Dictionary §II.E:

   Parsing proceeds by moving successive elements (or
   their values except in the case of proverbs and names
   immediately to the left of a copula)

because named adverbs should be stacked (passed) by value.

AFAICT, §II requires proverbs to refer to verbs:

    The name "area" thus assigned is a /pronoun/ and, as in
    English, it plays the role of a noun. Similar remarks
    apply to names assigned to verbs, adverbs, and conjunctions.

For a longer discussion of this topic, see "stacked by name" thread in the Forums. In particular, see the linked references.

If proverbs must be verbs, then the discrepancy can be resolved emending the DoJ (to say something like "except in the case of names to the left of copulae or which don't refer to nouns") or the implementation (by making pro-advs and pro-conjs stack by value, which I don't think would hurt many existing J users). I posted a fuller proposal in the Forums.

If this is not a bug, I'd like to know why.

Status: closed, documented in NuVoc. Only nouns are passed by reference, others by name.

-- Dan Bron <<DateTime(2009-08-17T00:09:00-0300)>>

128!:5] 0j_.

As mentioned in this mailing list thread, 128!:5] 0j_. gives 0 whereas I think it should return 1. The dictionary definition does not mention complex numbers, but I think any complex number whose real part or imaginary part is a nan should count as containing a nan. I could reproduce this bug in j602/2008-03-03/16:45 x86 linux, and also the 64-bit j602/2008-03-03/16:45 on amd64 linux. -- User:B Jonas <<DateTime(2009-12-02T01:30:32+0200)>>

Apparently the 128!:5 verb can even crash J in some cases if used on complex numbers. This might be related. -- User:B Jonas <<DateTime(2009-12-02T23:04:41+0200)>>

I cannot reproduce this bug in j64-701. -- User:B Jonas <<DateTime(2011-02-04T15:04:53+0200)>>

Status: closed, fixed in J8

Dictionary 6!:8 (Query Clock Frequency)

The dictionary for j602 claims that 6!:8 y ignores its argument y, whereas actually it does not. The call 6!:8 $0 returns the clock divisor as claimed, whereas for example 6!:8 ]0 gives a rank error. The description of 6!:9, 6!:13 has the same problem. This applies to at least 64-bit j602/2008-03-03/16:45 on linux-amd64.

Status: closed, documented in NuVoc

-- User:B Jonas <<DateTime(2010-02-05T23:21:31+0200)>>

Strange evoke of invalid gerund with fit

Evoking an atomic form of an errornous application of the fit conjunction seems to return a strange bonded conj adverb that is in no apparent relation with what we're intending to evoke.

   a =: (<'!.';<'-';<'0';0)@.0
   1 <a 1+1e_14

I believe that (<'!.';<'-';<'0';0)@.0 should either raise a domain error like -!.0 does, or give some other error, or possibly even return a verb of form -!.0 that always raises a domain error when called, but it definitely should not return an adverb.

This applies to at least 64-bit j602/2008-03-03/16:45 on linux-amd64.

-- User:B Jonas <<DateTime(2010-02-22T01:43:26+0200)>>

It seems that this bug is still present in j64-701. -- User:B Jonas <<DateTime(2011-02-04T15:04:53+0200)>>

Status: closed, no problem. It is good design for users of ARs to assume that they are well-formed, which puts the onus of the creator not to produce one that, as here, could not have been created using ` .

In Dictionary page for monad-dyad conj, example output wrong

On the j602 Dictionary page for the monad-dyad conjunction u :v (d310v), there is an example command where the output shown is a valence error error message, whereas currently that example gives domain error instead. Please fix the output so it corresponds to what the interpreter actually does. (Sorry for nitpicking.)

-- User:B Jonas <<DateTime(2010-08-26T01:03:12+0200)>>

Status: closed, documented in NuVoc

q: gives up for no good reason

12323 151819363
   9!:14 ''

-- Andrew Nikitin <<DateTime(2011-06-24T15:06:30-0400)>>

Status: closed, fixed in J8

conjunction (and adverb) defined in locale is not always executed within that locales context

bug exists in J7 and J8 64 bit windows. Most likely the error occurs when a modifier definition accesses y. This cannot be intentional design because one locale's definition cannot possibly rely on another locale's state, and the primary reason for defining a modifier in a specific locale is to use that locale's environment.

cocurrent 'myl'
a=: 4
c =: 2 : 0  NB. will execute wrong (callers) locale
smoutput 18!:5 ''
u a v y
cp =: 2 : 0  NB. will execute right (this) locale
smoutput 18!:5 ''

cocurrent 'newl'

c2_myl_ =: 2 : 0
smoutput 18!:5 ''
u a v y

test =: 3 : 0
a=: 14
smoutput >: c_myl_ + 1
smoutput >: c2_myl_ + 1
c =: conew 'myl'
>: c2__c + 1

in session:

   test_newl_ '' NB. results should be 6 (and <'myl') for all 3.

conjunction that does not access y in session (or script):
   conj_myl_=: 2 :'v@:u^:a'
   >: conj_myl_ ] 1 NB. result for both should be 5
   >: cp_myl_ ] 1

Status: closed, no problem, the result of executing a modifier is not a locative

Release notes should mention NVV forks

The dictionary documents NVV forks, that is, trains of the form (n v w) where n is a noun, and v and w are verbs. However, these are a new feature and so should be mentioned in the release notes as well. -- User:B Jonas <<DateTime(2013-11-23T23:21:08+0200)>>

Status: closed, obsolete

too many digits from base representation

Similar to a bug Raul reported previously, the dyad #.^:_1 can produce leading zeros. For example:

   10 #.^:_1 <:1e12
0 9 9 9 9 9 9 9 9 9 9 9 9

This boils down to a tolerance issue in monad <. which User:B Jonas reported in the Forums. I am too ignorant of tolerance to know whether that behavior is itself a bug, but you may find some details in my followup message.

Applies to ( 'j602/beta/2007-09-19/23:00';6;'jwin32' ) -: (9!:14'') ; (9!:12'') ; wd 'qwd' (This does not mean that the bug is restricted to this environment, only that it is the one I tested.)

Status: Closed, no fix. The number of digits is calculated as <. x ^. y, and with tolerance this can leave an extra digit. There is no way to make the logarithm accurate enough to get the number of digits right, so the only solution would be to try converting the maximum value and seeing how many digits are needed. Rather than incurring this overhead for every use, it will be left for the user to polish.

-- Dan Bron <<DateTime(2007-11-30T15:17:43Z)>>

In Dictionary page for tie, example verb `ar` wrong

On the j602 Dictionary page for the tie conjunction (d610), there's an example monadic verb called ar defined, that claims to give the atomic representation from a noun. The definition is wrong, it doesn't work for boxed nouns. Please fix this example or remove it. -- User:B Jonas <<DateTime(2010-08-26T01:03:12+0200)>>

Status: Documented in NuVoc page.

Expand 15!: in the Dictionary

The dictionary page for the 15!: foreign (native function call interface) is currently only a list that names the first few 15!: functions. It links to a User page that gives some more information. Even if the 15!: foreign isn't documented in the dictionary as completely as most other foreigns, it would be nice if at least all of its subfunctions would be listed. Specifically 15!:10 (get error code) is documented in User, and the module gives names to other verbs as well: 15!:5 (unload shared libary), 15!:6, 15!:7, 15!:8, 15!:9, 15!:11, 15!:13. -- User:B Jonas <<DateTime(2008-08-06T13:55:57Z)>>

(I forgot to add this was dictionary for j602 on x86 linux system.

-- User:B Jonas <<DateTime(2008-08-06T14:01:52Z)>>)

Status: closed. Foreigns page has been updated in NuVoc