Code Monkey home page Code Monkey logo

smlnj's Introduction

Standard ML of New Jersey

This is the main development repository for SML/NJ. We are currently reworking many components of the system, so it is not very stable. For most uses, we recommend the legacy version of the system.

As of the 2023.1 release, this version is known to work on AMD64 (a.k.a. x86-64) hardware running Linux or macOS.


Contents


Building From Source

The process for building the system from source code has changed.

  1. clone the repository

    git clone [email protected]:smlnj/smlnj.git
  2. cd to the cloned repository and get the boot files

    cd smlnj
    curl -O https://smlnj.org/dist/working/$VERSION/boot.amd64-unix.tgz

    where $VERSION is the version that you are building (e.g., 2023.1).

    We plan to incorporate this step into the build.sh script in the near future.

  3. build the installation

    ./build.sh

    Use build.sh -h to see the list of options accepted by the build script.

    As before, you can modify the config/targets file to add/remove components from the build.

After successful running of the build.sh script, bin/sml will be the interactive system.

Recompiling the System

The process of recompiling the system from source code is fairly similar to before.

  1. Switch to the system directory and run the cmb-make command:

    cd system
    ./cmb-make ../bin/sml

    The "../bin/sml" argument is optional; if omitted, then the sml command in the user's PATH will be used. Once can also specify a different path to an sml command, when appropriate.

  2. Bootstrap the system

    ./makeml
  3. Install the system

    ./installml -clean -boot

    The -boot option is new (and optional); it causes the existing boot files in the root directory (e.g., boot.amd64-unix.tgz) to be replaced by the files generated by the cmb-make command.

  4. Rebuild the libraries and tools

    cd ..
    ./build.sh

smlnj's People

Contributors

cr2007 avatar darinm223 avatar dmacqueen avatar johnreppy avatar p-ouellette avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

smlnj's Issues

regalloc broken

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

2.6.31-23-generic

Processor

No response

Component

Core system

Severity

Major

Description of the problem

The code below raises an exception in register allocation

Additional comments:
Sadly, I don know enough about the SMLNJ compiler internals to fix

Transcript

[22:35]rpearl@silverhold:~$ sml break.sml
Standard ML of New Jersey v110.72 [built: Wed Feb  3 11:03:59 2010]
[opening break.sml]
=========== K=6 ===========
1[1] --
2[2] --
3[3] --
5[5] --
6[6] --
8m{%8} --
9m{%9} --
10m{%10} --
11m{%11} --
12m{%12} --
13m{%13} --
14m{%14} --
15m{%15} --
16m{%16} --
17m{%17} --
18m{%18} --
19m{%19} --
20m{%20} --
21m{%21} --
22m{%22} --
23m{%23} --
24m{%24} --
25m{%25} --
26m{%26} --
27m{%27} --
28m{%28} --
29m{%29} --
30m{%30} --
31m{%31} --
514s{1} --
515a = 6[6]
516a = 3[3]
517a = 1[1]
518a = 2[2]
519s{2} --
521a = 5[5]
524r -- 6[6] 5[5] 3[3] 2[2] 1[1]
525 -- 526 6[6] 5[5] 3[3] 2[2] 1[1]
526 -- 525 6[6] 5[5] 3[3] 2[2] 1[1]
527r -- 6[6] 5[5] 3[3] 2[2] 1[1]
Spill candidates:
526 525
Error: MLRisc bug: RegisterAllocator.chooseVictim

unexpected exception (bug?) in SML/NJ: Error [Error]
  raised at: ../../MLRISC/control/mlriscErrormsg.sml:21.14-21.19
             ../compiler/Basics/stats/stats.sml:198.40
             ../compiler/Basics/stats/stats.sml:198.40
             ../compiler/Basics/stats/stats.sml:198.40
             ../compiler/Basics/stats/stats.sml:198.40
             ../compiler/TopLevel/interact/evalloop.sml:44.55
             ../compiler/TopLevel/interact/evalloop.sml:296.17-296.20
/Users/rpearl/bin/sml: Fatal error -- Uncaught exception Error with 0
 raised at ../../MLRISC/control/mlriscErrormsg.sml:21.14-21.19

Expected Behavior

No response

Steps to Reproduce

fun break n j =
let val k = j + 1
in
(k, if j = n then j else k)
end

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 72

Submitted via web form by Ryan Pearl [email protected] on 2011-37-26 at 05:3700

comment by @JohnReppy on 2022-15-30 13:1500 +000 UTC

This bug is fixed with the switch to the LLVM back end. At this point, I do not think that we will try to fix it in the legacy version, so I am closing it.

String.scan function missing from basis library

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Basis Library

Severity

Minor

Description of the problem

The scan function is missing from both the STRING signature and
the String structure in the SMLNJ implementation of the Standard
ML Basis library.

Transcript

$ sml string_scan.sml
Standard ML of New Jersey v110.72 [built: Sun May 16 15:16:12 2010]
[opening string_scan.sml]
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]
string_scan.sml:1.27-1.38 Error: unbound variable or constructor: scan in path String.scan
/usr/lib/smlnj/bin/sml: Fatal error -- Uncaught exception Error with 0
 raised at ../compiler/TopLevel/interact/evalloop.sml:66.19-66.27

Expected Behavior

No response

Steps to Reproduce

$ cat string_scan.sml
case StringCvt.scanString String.scan \ test \ of
SOME s = print (\s = \\\ ^ s ^ \\\\n)
| NONE = print \No string in there\n;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 69

Submitted via web form by James Bostock [email protected] on 2011-16-05 at 18:1600

comment by @JohnReppy on 2011-37-09 21:3700 +000 UTC

Fixed for 110.73

Compiler bug in specialize phase

Version

v110.71

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

Any

Component

Core system

Severity

Minor

Description of the problem

The compiler crashes with the message

Recover.get: 334
Error: Compiler bug: Recover: Recover.recover.get

while in specialize phase

unexpected exception (bug?) in SML/NJ: Io [Io: openAppend failed on "flint.core", Win32TextPrimIO:openApp: failed]
raised at: Basis/Implementation/IO/text-io-fn.sml:792.25-792.75
../compiler/Basics/stats/stats.sml:198.40
../compiler/TopLevel/interact/evalloop.sml:44.55

when entering the expression shown below. (It also crashes when
loading a file containing that expression via use, or when using
compilation manager to compile the file.)

Transcript

Standard ML of New Jersey v110.71 [built: Thu Sep 17 08:50:14 2009]
- let fun split_ST3_SK3_SK1_ST3 (x55, x56, x57, x58, x59) = split_ST2_SK3_SK1_ST3 (op + (x55, 1), x56, x57, x58, x59)
      and yield_SK2_ST3_SK1_ST3 (x50, x51, x52, x53, x54) = split_ST3_SK3_SK1_ST3 (x50, x51, x52, x53, x54)
      and split_ST2_SK2_ST3_SK1 (x46, x47, x48, x49) = if op > (x46, x47) then [] else yield_SK2_ST3_SK1_ST3 (x48, x49, x46, x46, x47)
      and split_ST3_SK2_ST3_SK1 (x42, x43, x44, x45) = split_ST2_SK2_ST3_SK1 (op + (x42, 1), x43, x44, x45)
      and split_ST1_ST3_ST3_SK1 (x38, x39, x40, x41) = split_ST3_SK2_ST3_SK1 (x38, x39, x40, x41)
      and yield_SK1_ST1_ST3_ST3 (x33, x34, x35, x36, x37) = op :: (x33, split_ST1_ST3_ST3_SK1 (x34, x35, x36, x37))
      and yield_SK3_SK1_ST3_ST3 (x27, x28, x29, x30, x31, x32) = yield_SK1_ST1_ST3_ST3 ((x27, x30), x28, x29, x31, x32)
      and split_ST2_SK3_SK1_ST3 (x22, x23, x24, x25, x26) = if op > (x22, x23) then [] else yield_SK3_SK1_ST3_ST3 (x24, x25, x26, x22, x22, x23)
      and split_ST4_SK3_SK1_ST3 (x17, x18, x19, x20, x21) = split_ST2_SK3_SK1_ST3 (x17, x18, x19, x20, x21)
      and yield_SK2_ST4_SK1_ST3 (x12, x13, x14, x15, x16) = split_ST4_SK3_SK1_ST3 (x12, x13, x14, x15, x16)
      and split_ST2_SK2_ST4_SK1 (x8, x9, x10, x11) = if op > (x8, x9) then [] else yield_SK2_ST4_SK1_ST3 (x10, x11, x8, x8, x9)
      and split_ST4_SK2_ST4_SK1 (x4, x5, x6, x7) = split_ST2_SK2_ST4_SK1 (x4, x5, x6, x7)
      and split_ST5_ST4_ST4_SK1 (x0, x1, x2, x3) = split_ST4_SK2_ST4_SK1 (x0, x1, x2, x3)
  in split_ST5_ST4_ST4_SK1 (0, 10, 20, 30)
  end;
Recover.get: 4
Error: Compiler bug: Recover: Recover.recover.get

while in specialize phase

unexpected exception (bug?) in SML/NJ: Io [Io: openAppend failed on \"flint.core\", Win32TextPrimIO:openApp: failed]
  raised at: Basis/Implementation/IO/text-io-fn.sml:792.25-792.75
             ../compiler/Basics/stats/stats.sml:198.40
             ../compiler/TopLevel/interact/evalloop.sml:44.55
-

Expected Behavior

No response

Steps to Reproduce

let fun split_ST3_SK3_SK1_ST3 (x55, x56, x57, x58, x59) = split_ST2_SK3_SK1_ST3 (op + (x55, 1), x56, x57, x58, x59)
and yield_SK2_ST3_SK1_ST3 (x50, x51, x52, x53, x54) = split_ST3_SK3_SK1_ST3 (x50, x51, x52, x53, x54)
and split_ST2_SK2_ST3_SK1 (x46, x47, x48, x49) = if op > (x46, x47) then [] else yield_SK2_ST3_SK1_ST3 (x48, x49, x46, x46, x47)
and split_ST3_SK2_ST3_SK1 (x42, x43, x44, x45) = split_ST2_SK2_ST3_SK1 (op + (x42, 1), x43, x44, x45)
and split_ST1_ST3_ST3_SK1 (x38, x39, x40, x41) = split_ST3_SK2_ST3_SK1 (x38, x39, x40, x41)
and yield_SK1_ST1_ST3_ST3 (x33, x34, x35, x36, x37) = op :: (x33, split_ST1_ST3_ST3_SK1 (x34, x35, x36, x37))
and yield_SK3_SK1_ST3_ST3 (x27, x28, x29, x30, x31, x32) = yield_SK1_ST1_ST3_ST3 ((x27, x30), x28, x29, x31, x32)
and split_ST2_SK3_SK1_ST3 (x22, x23, x24, x25, x26) = if op > (x22, x23) then [] else yield_SK3_SK1_ST3_ST3 (x24, x25, x26, x22, x22, x23)
and split_ST4_SK3_SK1_ST3 (x17, x18, x19, x20, x21) = split_ST2_SK3_SK1_ST3 (x17, x18, x19, x20, x21)
and yield_SK2_ST4_SK1_ST3 (x12, x13, x14, x15, x16) = split_ST4_SK3_SK1_ST3 (x12, x13, x14, x15, x16)
and split_ST2_SK2_ST4_SK1 (x8, x9, x10, x11) = if op > (x8, x9) then [] else yield_SK2_ST4_SK1_ST3 (x10, x11, x8, x8, x9)
and split_ST4_SK2_ST4_SK1 (x4, x5, x6, x7) = split_ST2_SK2_ST4_SK1 (x4, x5, x6, x7)
and split_ST5_ST4_ST4_SK1 (x0, x1, x2, x3) = split_ST4_SK2_ST4_SK1 (x0, x1, x2, x3)
in split_ST5_ST4_ST4_SK1 (0, 10, 20, 30)
end

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 45

Submitted via web form by Morten Rhiger [email protected] on 2009-11-02 at 14:1100

Keywords: flint.core, Win32TextPrimIO, openApp

comment by @larsbergstrom on 2009-13-12 03:1300 +000 UTC

Not Windows-specific - reproduces on OSX too: ~ Standard ML of New Jersey v110.71 [built: Sat Nov 21 16:40:08 2009] ~ - use "/Users/larsberg/Desktop/foo.txt"; ~ [opening /Users/larsberg/Desktop/foo.txt] ~ Recover.get: 4 ~ Error: Compiler bug: Recover: Recover.recover.get ~ ~ while in specialize phase ~ raised at: ../compiler/Basics/errormsg/errormsg.sml:52.14-52.19 ~ ../compiler/FLINT/opt/recover.sml:123.44 ~ ../compiler/Basics/stats/stats.sml:198.40 ~ ~ uncaught exception Error ~ raised at: ../compiler/Basics/errormsg/errormsg.sml:52.14-52.19 ~ ../compiler/FLINT/opt/recover.sml:123.44 ~ ../compiler/Basics/stats/stats.sml:198.40 ~ ../compiler/FLINT/main/flintcomp.sml:183.13 ~ ../compiler/Basics/stats/stats.sml:198.40 ~ ../compiler/TopLevel/interact/evalloop.sml:44.55 ~ ../compiler/TopLevel/interact/evalloop.sml:296.17-296.20 ~ -

comment by @JohnReppy on 2015-01-23 22:0100 +000 UTC

This bug still exists in 110.78 on Mac OS X. The final message is a bit different: ~ ~ Recover.get: 4 ~ Error: Compiler bug: Recover: Recover.recover.get ~ ~ while in specialize phase ~ raised at: ../compiler/Basics/errormsg/errormsg.sml:52.14-52.19 ~ ../compiler/FLINT/opt/recover.sml:123.44 ~ ../compiler/Basics/stats/stats.sml:198.40 ~

comment by @JohnReppy on 2015-51-23 22:5100 +000 UTC

The bug is because of an attempt to lookup a variable that isn't bound. Turning on Control.FLINT.print shows that the problem is in contraction. Specifically, after contraction, we have the following residual code ~ ~ ==================== ~ [After fcontract ...] ~ ~ v424{1} : (FCT) = ~ FN([v612{0} : ???], ~ FIX(v197{2,2} : (RFUN rr) = ~ FN([v539{3} : I, ~ v540{2} : I, ~ v541{1} : I, ~ v542{1} : I, ~ v543{2} : I], ~ IF PRIMOP(>, <I,I> -rr-> , []) [v539,v540] ~ THEN ~ v526{1} = RECORD [] ~ v525{1} = CON(nil, [TT<I,I>], v526) ~ RETURN [v525] ~ ELSE ~ v508{1} = RECORD [v541,v539] ~ v470{3} = PRIMOP(+, <I,I> -rr-> , []) [v542,(I)1] ~ [v493{1}] = APP(v192,[v470,v543,v539,v540]) ~ v364{1} = RECORD [v508,v493] ~ v494{1} = CON(::, [TT<I,I>], v364) ~ RETURN [v494])) ~ [v189{1}] = IF PRIMOP(>, <I,I> -rr-> , []) [(I)0,(I)10] ~ THEN ~ v572{1} = RECORD [] ~ v571{1} = CON(nil, [TT<I,I>], v572) ~ RETURN [v571] ~ ELSE ~ APP(v197,[(I)20,(I)30,(I)0,(I)0,(I)10]) ~ v611{1} = STRUCT [v189] ~ RETURN [v611]) ~ ~ Recover.get: 192 ~ Error: Compiler bug: Recover: Recover.recover.get ~ ==================== ~ ~ Notice that the function v192 is applied, but not bound anywhere. Its binding has been removed by the contraction phase. I think that v192 corresponds to split_ST2_SK3_SK1_ST3 in the source. ~

comment by @JohnReppy on 2015-29-24 00:2900 +000 UTC

I have reduced the example by hand-eta reducing all but one of the available eta reductions. Eliminating the remaining eta reduction will cause the bug to disappear. The reduced version of the bug is loaded as an attachment, as is a transcript of the debug output.

comment by @JohnReppy on 2015-29-24 20:2900 +000 UTC

Fixed for 110.79. ~ ~ The problem turns out to be a bad interaction between eta contraction and simple inlining. The situation is that we have a function v5 (split_4 in the source) that is mapped by eta contraction to a function v4 (split_3). The function v4 contains a call to v3, while another function, v6, contains a non-tail application of v5. During inlining, we first contract v4 and inline the call to v3; we then contract v6 and inline the call to v5, but it is mapped to the old definition of v4! The result is a residual program that contains a call to v3, but where v3 has been deleted as unused. ~ ~ To fix this problem, I modified the fcApp function so that when it maps its argument function f to Fun(g, ...) and g is a different LVar than f, then I recursively call fcApp on g with the same argument list.

@ is very slow (quadratic?)

Version

110.71

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

Any

Component

Basis Library

Severity

Minor

Description of the problem

Append operator @ loses with long lists (test takes 1 minute).
A hand-crafted equivalent wins (test2 takes 13 seconds).
I could not find definition of @, so I am unable to investigate
the problem myself. The problem could be in GC
(there were crazy page fault counts due to very frequent
mappings/unmappings).
(BTW SBCL does the same list-power thing in 6 sec,
GHC in 2 sec, on my machine :)

Transcript

measure time of test and test2
on Core2 2.2 Ghz, 2GB RAM, i got 60 and 13 wall-clock seconds.

Expected Behavior

No response

Steps to Reproduce

fun append l r =
let fun app l r =
case l of
[] => r
| (l::ls) => app ls (l::r)
in app (rev l) r
end
;;

fun pow l n =
if n>0 then pow (l@l) (n-1)
else length l
;;

fun pow2 l n =
if n>0 then pow2 (append l l) (n-1)
else length l
;;

fun test () = pow [1] 24
;;

fun test2 () = pow2 [1] 24
;;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 51

Submitted via web form by Denis [email protected] on 2009-27-20 at 17:2700

Keywords: performance append runtime GC

comment by @JohnReppy on 2009-00-21 18:0000 +000 UTC

Fixed for 110.72.

strange error message for syntax error

Version

110.73

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

any

Processor

Any

Component

Core system

Severity

Minor

Description of the problem

A syntax error results in a strange type error message.

Transcript

- structure S = struct
=   datatype foo = A | B of bar
=   and bar = Bar of int
= end;
structure S :
  sig
    datatype foo = A | B of bar
    datatype bar = Bar of int
  end
- datatype foo = datatype S.foo
= and bar = datatype S.bar;
stdIn:14.1-15.25 Error: argument type variables in datatype replication

Expected Behavior

No response

Steps to Reproduce

structure S = struct
datatype foo = A | B of bar
and bar = Bar of int
end;

datatype foo = datatype S.foo
and bar = datatype S.bar; (* using and here is incorrect *)

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 77

Submitted via web form by John Reppy [email protected] on 2011-01-19 at 19:0100

Keywords: datatype replication syntax

comment by @dmacqueen on 2012-02-17 05:0200 +000 UTC

Fixed by changing ml.grm so that this example causes a syntax error instead, as it should. Changes required revising art, with follow-up changes to elaborator, cm, etc. ~

HashCons equality test doesn't work because tags aren't incremented

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

SML/NJ Library

Severity

Critical

Description of the problem

The HashCons library doesn't work.
Actually the way it looks probably never did.
The tags that are used for equality testing are never
incremented, so equality testing fails (well actually
always succeeds), resulting in, well, major nonsense.
The fix is one line, marked in source code below with
#added#

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

In file hash-cons.sml

fun insert (Tbl{eq, nextTag, tbl}, h, term) = let
  val tbl' = !tbl
  val i = Word.toIntX(Word.mod(h, Word.fromInt(Array.length tbl')))
  val bucket = Array.sub(tbl', i)
  fun find [] = let
	val id = !nextTag
   #added#	val _ = nextTag := (!nextTag + 0wx1)
	val obj = {nd = term, hash = h, tag = id}
	in
	  Array.update(tbl', i, obj::bucket);

(* check for table resize *)
obj
end
| find ((obj as {nd, hash, ...})::r) =
if (h = hash) andalso eq(term, nd)
then obj
else find r
in
find bucket
end

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 55

Submitted via web form by Jakob Uecker [email protected] on 2010-51-09 at 17:5100

Keywords: HashCons

comment by @JohnReppy on 2011-38-22 13:3800 +000 UTC

Fixed for 110.73 (r3517)

No shebang support

Version

No response

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

No response

Severity

Minor

Description of the problem

Its useful to begin scripts in other programming languages with a shebang.

hello.py:

#!/usr/bin/env python
print Hello World!

This allows a script to be run with dot slash notation in Unix, Linux, and Mac OS X.

In other words, while you can already do this:

$ python hello.py
Hello World!

It is useful to treat a script as if it were a binary:

$ ./hello.py
Hello World!

We can come close to this behavior in SML:

hello.sml:

print Hello World!\n;
OS.Process.exit(OS.Process.success);

$ sml hello.sml
Hello World!

However, when we add the proper shebang, SML/NJ borks.

hello.sml:

#!/usr/bin/env sml
print Hello World!\n;
OS.Process.exit(OS.Process.success);

Example:

$ ./hello.sml
Standard ML of New Jersey v110.72 [built: Mon Nov 14 17:30:10 2011]
[opening ./hello.sml]
./hello.sml:1.12-1.15 Error: unbound variable or constructor: env
./hello.sml:1.16-1.19 Error: unbound variable or constructor: sml
./hello.sml:1.8-1.11 Error: unbound variable or constructor: bin
./hello.sml:1.1-1.4 Error: unbound variable or constructor: #!/
./hello.sml:1.4-1.7 Error: unbound variable or constructor: usr
/opt/local/share/smlnj/bin/sml: Fatal error -- Uncaught exception Error with 0
raised at ../compiler/TopLevel/interact/evalloop.sml:66.19-66.27

The solution is for SML to treat #!...\n as a comment. This is already being discussed in Successive ML.

Futhermore, I lied. When you submit the following code to SML:

hello.sml:

print Hello World!\n;
OS.Process.exit(OS.Process.success);

SML spits out a bunch of spurious warnings and statements.

$ sml hello.sml
Standard ML of New Jersey v110.72 [built: Mon Nov 14 17:30:10 2011]
[opening hello.sml]
Hello World!
val it = () : unit
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]
hello.sml:2.1-2.36 Warning: type vars not generalized because of
value restriction are instantiated to dummy types (X1,X2,...)

These really get in the way of scripting, because they gum up command line interfaces. Can some of these be turned off by default? Or, could SML/NJ add a special -script flag that disables such warnings?
Fix:
Consider #!...\n a comment.

Disable some warnings by default, or add a -script option.

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 84

Submitted via web form by Andrew Pennebaker [email protected] on 2011-56-14 at 22:5600

comment by @JohnReppy on 2011-55-25 19:5500 +000 UTC

Probably the right way to address this request is to implement a wrapper program for running scripts. The wrapper could strip off the "#!" line and submit the rest of the code to the sml program. ~

Buildling SML/NJ on WIndows fails if there is a number in the path

Version

No response

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

xp

Processor

x86 (32-bit)

Component

Other

Severity

Minor

Description of the problem

Just try to run config\install.bat from a directory with a number in the path. If you do, it will fail shortly after it enters the "bin\sml.bat -m $smlnj/installer.cm" command, as it will fail to copy ml-antlr.bat to the bin directory and the HTML4 package will fail to build and error out.

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

No response

Comments from smlnj-gforge

Original smlnj-gforge bug number 87

Submitted on 2012-13-28 at 00:1300

comment by @larsbergstrom on 2012-32-03 22:3200 +000 UTC

This does not reproduce. I believe it was an issue with directory permissions on the machine where it happened.

CM anchors for CML need rationalization

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

Any

Component

Compilation manager (CM)

Severity

Major

Description of the problem

The naming convention for CML's CM files needs to be rationalized.
The proposed convention is:

$cml/basis.cm -- the CML version of $/basis.cm
$cml/cml.cm -- core CML features
$cml/cml-lib.cm -- CML library code (currently merged
into $cml/cml-lib/smlnj-lib.cm)
$cml/trace-cml.cm -- TraceCML library for debugging
$cml/smlnj-lib.cm -- CML version of the $/smlnj-lib.cm

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

No response

Comments from smlnj-gforge

Original smlnj-gforge bug number 68

Submitted on 2011-50-08 at 16:5000

Keywords: CML, CM

Building on OS X Lion

Version

110.74

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

OS X Lion

Processor

x86 (32-bit)

Component

Other

Severity

Cosmetic

Description of the problem

When building on my Mac, I get errors due to the build script trying to load include files from /Developer/SDKs/MacOSX10.5.sdk. As I am using Lion and has a fairly recent clean installation of the developer tools, I do not have this directory. Symlinking /Developer/SDKs/MacOSX10.7.sdk to the location fixes the problem, but it would probably be nicer to go with the newer SDK or auto-detect the newest one in the build process).

Transcript

echo v-x86-darwin  v-x86-darwin
cc -m32 -ansi -c -g -O2 -D_DARWIN_C_SOURCE -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -I../config -I../objs -I../include ../config/gen-common.c
../config/gen-common.c:8:19: error: stdio.h: No such file or directory
../config/gen-common.c:9:20: error: stdlib.h: No such file or directory
In file included from ../config/gen-common.c:10:
../config/gen.h:11: error: expected �=�, �,�, �;�, �asm� or �__attribute__� before �*� token
../config/gen.h:12: error: expected �)� before �*� token
../config/gen-common.c:16: error: expected �=�, �,�, �;�, �asm� or �__attribute__� before �*� token
../config/gen-common.c:47: error: expected �)� before �*� token
make[1]: *** [gen-common.o] Error 1
make: *** [all] Error 2

Expected Behavior

No response

Steps to Reproduce

N/A

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 89

Submitted via web form by Michael Westergaard [email protected] on 2012-59-02 at 12:5900

Keywords: osx, building

comment by @JohnReppy on 2012-36-05 12:3600 +000 UTC

Known issue, but we need to automate the handling of it in config/install.sh.

comment by @JohnReppy on 2012-36-02 17:3600 +000 UTC

Fixed for 110.75

Please ship manpages for binaries

Version

110.71

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

Debian

Processor

No response

Component

Other

Severity

Cosmetic

Description of the problem

Hi, it would be nice to provide at least minimal manpages for all shipped binaries. There is excellent documentation for SML/NJ, and I don't think it's worth the time to document all of this in a manpage. However, it would be nice to have some basic information about usage.

Debian already ships skeletal manpages for all the binaries. I thought I'd file a feature request here with links to the manpages in case you're ever interested in developing them more.

ml-antlr:
http://git.debian.org/?p=collab-maint/smlnj.git;a=blob;f=debian/ml-antlr.1;h=115ae716fd92e50c00b50b89ec954498bd4214ea;hb=HEAD

ml-build:
http://git.debian.org/?p=collab-maint/smlnj.git;a=blob;f=debian/ml-build.1;h=4553d2c2a0b9bde9d16f1dae249ea10e33d604e8;hb=HEAD

ml-burg:
http://git.debian.org/?p=collab-maint/smlnj.git;a=blob;f=debian/ml-burg.1;h=add9d70bde75fd5cf12433c0cb3a05bf7035335e;hb=HEAD

ml-lex:
http://git.debian.org/?p=collab-maint/smlnj.git;a=blob;f=debian/ml-lex.1;h=31dbc9d7bdc7237543b774d76d070b36958f5ac0;hb=HEAD

ml-makedepend:
http://git.debian.org/?p=collab-maint/smlnj.git;a=blob;f=debian/ml-makedepend.1;h=03a8f3034f1a1630b4f8bf21dc18d75e8c86a640;hb=HEAD

ml-nlffigen:
http://git.debian.org/?p=collab-maint/smlnj.git;a=blob;f=debian/ml-nlffigen.1;h=7147aa0203074a0902c3a47aae605260bc6bc673;hb=HEAD

ml-ulex:
http://git.debian.org/?p=collab-maint/smlnj.git;a=blob;f=debian/ml-ulex.1;h=77a2a097dabb5d02f04e15b03d7aef9785973ffb;hb=HEAD

ml-yacc:
http://git.debian.org/?p=collab-maint/smlnj.git;a=blob;f=debian/ml-yacc.1;h=b55e06c0210fcf4cdb955384ae5bbb0ce1c641d6;hb=HEAD

nowhere:
http://git.debian.org/?p=collab-maint/smlnj.git;a=blob;f=debian/nowhere.1;h=c1fe33042e8b0c24aec295eb5edea485e9b487c4;hb=HEAD

sml:
http://git.debian.org/?p=collab-maint/smlnj.git;a=blob;f=debian/sml.1;h=e7649b69ce1c694b6ab4842b0c23fe7fae78ff2c;hb=HEAD

Regards,
Daniel

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 35

Submitted via web form by Daniel Moerner [email protected] on 2009-20-16 at 08:2000

Keywords: documentation

comment by @JohnReppy on 2014-31-23 15:3100 +000 UTC

As of 110.77 the doc.tgz file in the distribution includes manual pages for the command-line tools. On Mac OS X, these are installed in /usr/local/man.

sml/nj does not work with Linux 3.0

Version

110.73

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

3.0

Processor

No response

Component

Other

Severity

Critical

Description of the problem

Due to an operating system version check sml/nj will
neither install (using install.sh) nor run
(if already installed before the kernel upgrade).

(I suspect this is the reason for the removal of smlnj
from the Ubuntu repositories as it no longer works on the
newest version of Ubuntu.)
Additional comments:
I did not include the transcript as the bug occurred on a
friends machine.

Fix:
Add 3.0.* or 3.* to the switch in .arch-n-opsys

After line 95 adding:

3.0.*) ;;

or

3.*) ;;

Fixes the problem.

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

Attempt to install smlnj on top of Linux 3.0.

(Ubuntu 11.10 ships with a 3.0 kernel.)

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 81

Submitted via web form by Kaida [email protected] on 2011-43-16 at 21:4300

Keywords: kernel, linux, ubuntu

comment by @JohnReppy on 2011-08-24 18:0800 +000 UTC

Same as bug #80

comment by @larsbergstrom on 2011-06-26 02:0600 +000 UTC

Fixed. We now support all 3.x kernels.

Slight syntactic difference between ml-lex and ml-ulex in backward compatibility mode.

Version

110.71

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Command-line tool

Severity

Minor

Description of the problem

The ml-ulex tool appears to not correctly recognize the character class "[-]" as being just the hyphen. The transcript shows running ml-lex and ml-ulex on the attached input (both appear to generate a SML file, but I have not checked to see if they work).

The original submitter (Roger Price, via smlnj-list) noted a work around for this problem was to just remove the brackets for the hyphen (changing "({alpha}|[-])" to "({alpha}|-)".

Transcript

$ ml-lex test.lex

Number of states = 14
Number of distinct rows = 5
Approx. memory size of trans. table = 645 bytes
$ ml-ulex --ml-lex-mode test.lex
[ml-ulex: parsing]
14: syntax error: deleting  BAR LB RBD
[ml-ulex: DFA gen]
 12 states in full DFA
[ml-ulex: SML gen]

Expected Behavior

No response

Steps to Reproduce

(See attached file.)

Additional Information

No response

Email address

No response

Comments from smlnj-gforge

Original smlnj-gforge bug number 49

Submitted on 2009-40-08 at 23:4000

comment by @JohnReppy on 2011-23-31 16:2300 +000 UTC

Fixe in r174 of ml-lpt

CM still can't invoke ml-yacc on Windows

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

xp

Processor

x86 (32-bit)

Component

Compilation manager (CM)

Severity

Minor

Description of the problem

The compilation manager still cannot invoke ml-yacc, as I reported
in bug report #50. The error message is different now, indicating
that something was done, but it still doesn't work.

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 56

Submitted via web form by Karl Crary [email protected] on 2010-56-18 at 20:5600

Implementations of PACK_REAL missing

Description of the problem

There are no implementations of the PACK_REAL signatures in SML/NJ.
Fix:
I wrote a somewhat hacky implementation that might be of use: https://github.com/msullivan/sml-util/blob/master/libs/pack-real.sml

Comments from smlnj-gforge

Original smlnj-gforge bug number 82

Submitted via web form by Michael Sullivan on 2011-36-24 at 17:3600

comment by @JohnReppy on 2011-29-28 17:2900 +000 UTC

Note that the implementation of PackReal is an optional part of the Basis Library, which is why this ticket is a "feature request."

comment by @JohnReppy on 2015-59-23 22:5900 +000 UTC

Reclassified as feature request.

comment by @JohnReppy on 2015-59-23 22:5900 +000 UTC

Moved from Bugs to Feature Requests

comment by @JohnReppy on 2015-34-25 13:3400 +000 UTC

Added for 110.79.

No support for Kernel 3.x

Version

110.72-1

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

Ubuntu 11.10

Processor

x86 (32-bit)

Component

Other

Severity

Critical

Description of the problem

It is not possible to start sml/nj on an x686 machine running a
kernel newer than 2.6, due to the immensely ugly .arch-n-opsys
script that apparently is run when you start sml/nj.

Ubuntu 11.10 ships with kernel 3.0.0-11-generic, and is thus not
supported. Someone seems to have made a temporary fix [1], however
that script seriously ought to be fixed. As far as I can see, then
the only reason why kernel versions are being explicitly checked,
is because kernel 2.2.x and below is not supported (as no extra
flags are set in the specific cases).

x86_64 seems to just fall back on x86, without having this check
for kernel 2.2. Maybe this entire script ought to have an audit
as it seems like hack upon hack upon hack...

[1] : https://answers.launchpad.net/ubuntu/+source/smlnj/+question/174447

Transcript

$ sml
sml: unable to determine architecture/operating system
$ uname -r
3.0.0-11-generic
$ uname -m
i686

Expected Behavior

No response

Steps to Reproduce

Try to start sml/nj on an x686 machine with a kernel newer than 2.6.

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 83

Submitted via web form by Jesper Reenberg [email protected] on 2011-39-26 at 01:3900

Keywords: .arch-n-opsys

comment by @larsbergstrom on 2011-06-26 02:0600 +000 UTC

Fixed. We now support all 3.x kernels.

Errors in ml-lpt manual

Version

110.73

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

N/A

Processor

No response

Component

Command-line tool

Severity

Cosmetic

Description of the problem

There appear to be some errors in the ml-lpt manual:

The type given for the lex function at the start of chapter 2 should be:

val lex : AntlrStreamPos.sourcemap - strm -
lex_result * AntlrStreamPos.span * strm

In the sample CM file (fig 5.1), \\CalcLex\\ should be \\CalcLexer\\ and
\\CalcParse\\ should be \\CalcParseFn\.

In the sample ml-ulex file (fig 5.2), the \\T.\\ prefix should be
dropped from the token values.

In the sample ml-antlr file (fig 5.3), the expressions multExp::SR
and prefixExp::SR need to be parenthesised.

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

No response

Comments from smlnj-gforge

Original smlnj-gforge bug number 74

Submitted via web form by James Bostock on 2011-06-05 at 21:0600

comment by @JohnReppy on 2011-07-05 22:0700 +000 UTC

Fixed for 110.74

blastWrite crashes

Version

110.71

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

other Windows 7

Processor

x86 (32-bit)

Component

Other

Severity

Minor

Description of the problem

I encounter a crash of the SML/NJ environment, if I try to
call Unsafe.blastRead to read a byte stream marshalled by
Unsafe.blastWrite.

Both Windows and Linux yeild the problem.
Windows: A pop-up menu appears.

Linux: I get the following messages:
Fatal error -- bogus fault not in ML: sig = 11, code = 0x46cafc, pc = 0x46cafc)

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

val y0 = {a=1,b=2.0,c=(5.3,4.5)}: {a:int, b:real, c:realreal};
val z = Unsafe.blastWrite y0;
val y = Unsafe.blastRead z: {a:int, b:real, c:real
real};

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 76

Submitted via web form by Masaya Saito [email protected] on 2011-03-04 at 06:0300

Keywords: Unsafe operations

comment by @JohnReppy on 2011-29-25 18:2900 +000 UTC

Committed a fix for the segmentation fault, but the underlying problem with blastWrite remains. ~ [2011-11-25]

comment by @JohnReppy on 2011-51-25 19:5100 +000 UTC

Fixed for 110.74. ~ [2011-11-25]

Very slow compilation with a large statically-defined list

Version

110.70

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Core system

Severity

Minor

Description of the problem

The attached program takes a very long or possibly infinite time to compile. The problem seems to be in the building of the "runs" list. We noticed that, by shortening the list, compilation would complete quickly. We are able to compile and execute our program in MLton.

Transcript

Standard ML of New Jersey v110.70 [built: Tue Sep 15 20:12:50 2009]
- [opening /Users/mrainey/Downloads/smlnj-bug/smlnj-bug.sml]
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]

Expected Behavior

No response

Steps to Reproduce

We attach a compressed version of the source file, as the raw source is too large to put here.

Additional Information

No response

Email address

No response

Comments from smlnj-gforge

Original smlnj-gforge bug number 40

Submitted on 2009-43-01 at 19:4300

comment by George Kuan on 2009-27-03 02:2700 +000 UTC

At least from a quick and dirty measurement, the bottleneck appears to be in CPS closure. This problem occurs for any test program that conses a large list in one fell swoop.

comment by George Kuan on 2009-29-03 02:2900 +000 UTC

That said, the above explanation only addresses the compilation bottleneck. The generated code may also have issues.

comment by @matthias-blume on 2009-30-05 01:3000 +000 UTC

This is a well-known problem caused by the way the SML :: operator works. Since it is right-associative but evaluation is strictly left-to-right, long lists can create tremendous register pressure because so many intermediate values have to be held in temporary variables. (In certain cases the compiler could avoid this outright, and in others there are ways of avoiding compile-time blowup at the expense of an extra list reversal or some such, but SML/NJ does not do that in general.) ~ ~ There is a simple trick for programmers to use (especially if the programmer is a program!): ~ ~ Define a "reverse cons" operator that is left-associative and takes its arguments in opposite order from ordinary cons. Then generate the source code in reverse order, starting from nil. This will greatly reduce compile time and also be more efficient at runtime.

comment by @dmacqueen on 2019-44-04 20:4400 +000 UTC

DBM, 2019:10:4. Appears to be fixed in 110.93. Compiles in about 3 seconds on a 2015 high-end iMac. Apparently the CPS closure algorithm was improved?

Incorrect type inference with functor taking/producing polymorphic type

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Core system

Severity

Major

Description of the problem

In the problem code, SMLNJ fails to infer the correct type of the `demo function.

When a type annotation is added to the function then the code compiles:

fun demo bd =
(Data (bd, 1), Data (bd:string Bad.bad_poly, ))
Additional comments:
This bug appeared in SMLNJ 110.63.1 - 110.63 does not have the problem.

It was found in the wild in AliceML (http://www.ps.uni-saarland.de/pipermail/alice-users/2009/000977.html)

Transcript

- use �ug.ml;
[opening bug.ml]
bug.ml:16.4-16.33 Error: operator and operand don	 agree [literal]
  operator domain: int Bad.bad_poly * int
  operand:         int Bad.bad_poly * string
  in expression:
    Data (bd,\)

uncaught exception Error
  raised at: ../compiler/TopLevel/interact/evalloop.sml:66.19-66.27
             ../compiler/TopLevel/interact/evalloop.sml:44.55
             ../compiler/TopLevel/interact/evalloop.sml:296.17-296.20

Expected Behavior

No response

Steps to Reproduce

functor MkBad (type 'a bad_poly) =
struct
    type 'a bad_poly = 'a bad_poly
end

structure Bad = MkBad (type 'a bad_poly = unit)

datatype 'a bad_data = Data of 'a Bad.bad_poly * 'a

fun demo bd =
   (Data (bd, 1), Data (bd, true))

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 60

Submitted via web form by Gareth [email protected] on 2010-30-19 at 21:3000

Keywords: types

comment by @dmacqueen on 2012-56-18 22:5600 +000 UTC

DBM: Fixed by calling ElabUtil.calc_strictness on the body of a DEFtyc instantiated by a functor application in evalTyc in EvalEntityFct. (Elaborator/modules/evalent.sml). ~

print() crashes with large strings on Win32 build

Version

110.71

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

other Windows 7 - 6.1.7100

Processor

Other

Component

Basis Library

Severity

Major

Description of the problem

When calling print() with a string of size >= 62734 the runtime
crashes with the message:

C:\Program Files (x86)\SMLNJ\\bin\.run\run.x86-win32.exe: Fatal error -- Uncaught exception Io with raised at Basis/Implementation/IO/text-io-fn.sml:443.14-443.56

This error does not occur on an older Unix build.
Additional comments:
I thought this might be a buffering issue but I tried setting
stdOut to IO.NO_BUF, IO.LINE_BUF, and IO.BLOCK_BUF and it still
occurs. I suspect an issue in low-level IO routines.

Fix:
I tried but SML is too hard to debug. This will require
someone with experience in the code.

Transcript

Standard ML of New Jersey v110.71 [built: Thu Sep 17 08:50:14 2009]
[opening bug.sml]
val bigString = fn : int -> string
C:\\Program Files (x86)\\SMLNJ\\\\bin\\.run\\run.x86-win32.exe: Fatal error -- Uncaught exception Io with <unknown> raised at Basis/Implementation/IO/text-io-fn.sml:443.14-443.56

or if I uncomment the working print line:
uncaught exception Io [Io: output failed on \"<stdOut>\", <win32 error code 8>]
  raised at: Basis/Implementation/IO/text-io-fn.sml:443.14-443.56

Expected Behavior

No response

Steps to Reproduce

(* repro code for Win32 SML output(stdOut, s) bug *)

fun bigString(0) = ""
| bigString(n) =
let fun buildString(0) = []
| buildString(n) = #"*"::buildString(n-1)
in
implode(buildString(n))
end;

(* this works )
(
print(bigString(62733)); *)

(* this fails *)
print(bigString(62734));

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 37

Submitted via web form by Jason Mackay [email protected] on 2009-25-24 at 18:2500

Keywords: IO print

comment by @larsbergstrom on 2009-07-12 03:0700 +000 UTC

Fixed. Changelist #3468, should be in 110.72.

Fails to bootstrap on ppc: unexpected fault, signal = 5, code = 0x8000

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

Debian Sid

Processor

PowerPC

Component

Installation

Severity

Cosmetic

Description of the problem

Hi, smlnj is failing to build on powerpc Linux. For reference, see. [0]

I'll see if I can find the problem in the next couple of days but I am not confident in my abilities here.

[0] https://buildd.debian.org/fetch.cgi?&pkg=smlnj&ver=110.72-1&arch=powerpc&stamp=1267719699&file=log

Transcript

./config/install.sh: Installation complete.
cd base/system && echo "CMB.make();" | /home/user/smlnj-110.72/bootstrap/bin/sml "\$smlnj/cmb.cm";
Standard ML of New Jersey v110.72 [built: Fri Mar  5 08:07:16 2010]
[library $smlnj/cmb.cm is stable]
- [autoloading]
[library $smlnj/cmb/current.cm is stable]
[library $smlnj/internal/cm-sig-lib.cm is stable]
[library $smlnj/cmb/ppc-unix.cm is stable]
[autoloading done]
[reading init spec from $smlnj/init/init.cmi]
[compiling $smlnj/init/(init.cmi):order.sml]
[creating directory /home/user/smlnj-110.72/base/system/smlnj/init/.cm/GUID]
[creating directory sml.bin.ppc-unix/smlnj/init/.cm/ppc-unix]
[code: 104, env: 188 bytes]
[compiling $smlnj/init/(init.cmi):assembly.sig]
[code: 88, env: 1649 bytes]
[compiling $smlnj/init/(init.cmi):dummy.sml]
[code: 860, data: 56, env: 448 bytes]
[compiling $smlnj/init/(init.cmi):core-intinf.sml]
*** WARNING: no access to exn Div
*** WARNING: no access to exn Div
*** WARNING: no access to exn Div
*** WARNING: no access to exn Div
*** WARNING: no access to exn Div
*** WARNING: no access to exn Div
*** WARNING: no access to exn Div
/home/user/smlnj-110.72/bootstrap/bin/sml: Fatal error -- unexpected fault, signal = 5, code = 0x8000
make[2]: *** [boot.ppc-unix.tgz] Error 1
make[2]: Leaving directory `/home/user/smlnj-110.72'
make[1]: *** [boot] Error 2
make[1]: Leaving directory `/home/user/smlnj-110.72'

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 54

Submitted via web form by Daniel Moerner [email protected] on 2010-45-05 at 08:4500

comment by @dmacqueen on 2012-18-24 06:1800 +000 UTC

DBM: 110.74 builds to a fixpoint on ppc-darwin. Don't have ppc Linux to test on. ~

Users Guide refers to Compiler structure

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Other

Severity

Minor

Description of the problem

The Users Guide in several places refers to the structure
Compiler, which (according to the revision history) was
removed in 2001 and replaced with a stub.
Additional comments:
Are there more cases of changes that are not reflected in the
documentation?

Transcript

Standard ML of New Jersey v110.72 [built: Wed Feb  3 11:03:59 2010]
- Compiler.Control.Print.printLength := 50;
[autoloading]
[autoloading done]
stdIn:1.1-1.35 Error: unbound structure: Control in path Compiler.Control.Print.printLength

Expected Behavior

No response

Steps to Reproduce

Compiler.Control.Print.printLength := 50;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 62

Submitted via web form by Lars-Henrik Eriksson [email protected] on 2011-02-18 at 18:0200

Keywords: Compiler documentation

comment by @larsbergstrom on 2011-55-19 01:5500 +000 UTC

I believe that those pages are unfortunately out of date. All of the structures within the Compiler structure have been lifted to top level. ~ ~ For example, print depth is now at: ~ Control.Print.printDepth ~ instead of the old: ~ Compiler.Control.Print.printDepth ~ ~ Sorry! I should get this cleaned up. I'll talk to the Powers about where that content lives.

comment by @larsbergstrom on 2011-24-11 22:2400 +000 UTC

This issue is now fixed. I can't claim that all of the Users' Guide is corrected, but the shift in the Compilers structure has been updated and pushed to the website.

basis library documentation out of sych with implementation

Version

110.71

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

10.6.8

Processor

x86 (32-bit)

Component

Basis Library

Severity

Minor

Description of the problem

The documentation for at least one structure in the Basis library
is out of sync with the code distributed in my version of SML/NJ.
Specifically, smlnj.org offers this documentation for the Array
structure:

http://www.smlnj.org/doc/basis/pages/array.html

but standardml.org has this version

http://www.standardml.org/Basis/array.html
http://www.standardml.org/Basis/array-slice.html

The distribution of SML/NJ appears to follow the documentation
from standardml.org, not smlnj.org. Examples of this are shown
in the sections below.
Fix:
Update the html documentation, at least for the Array structure, to reflect the version of the SML standard thats currently implemented.

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

Standard ML of New Jersey v110.71 [built: Thu Sep 17 16:48:42 2009]

  • Array.collate (* this shouldn exist, according to smlnj.org *);
    [autoloading]
    [library $SMLNJ-BASIS/basis.cm is stable]
    [autoloading done]
    val it = fn : (a * a - order) - a array * a array - order
  • Array.modifyi
    (* should have type ((int * a) - a) - (a array * int * int option) - unit *);
    val it = fn : (int * a - a) - a array - unit
  • Array.modifyi (fn _ = 1) (Array.fromList [0], 0, NONE);
    stdIn:5.1-5.56 Error: operator and operand don agree [tycon mismatch]
    operator domain: int array
    operand: int array * int * Z option
    in expression:
    (Array.modifyi (fn _ = 1)) (Array.fromList (0 :: nil),0,NONE)
  • ArraySlice.length (* shouldn exist, according to smlnj.org *);
    [autoloading]
    [autoloading done]
    val it = fn : a ArraySlice.slice - int

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 75

Submitted via web form by Ian Voysey [email protected] on 2011-51-19 at 21:5100

comment by @JohnReppy on 2011-15-19 22:1500 +000 UTC

The issue is that Ian found an old version of the Basis specification that was before the addition of the Slice structures.

Installation fails on Linux 3.0

Version

110.73

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

3.0

Processor

x86 (32-bit)

Component

Installation

Severity

Minor

Description of the problem

Installation fails on Linux 3.0 because of missing
�.*-entry in config/_arch-n-opsys.

Additional comments:
With the following fix everything seems to work again.

Fix:
Please add the following line in config/_arch-n-opsys
between �.6.*) ;; and *) exit 1 ;;:

      3.*) ;;

Transcript

$ uname -m
i686
$ uname -r
3.0-ARCH

$ config/install.sh n
config/install.sh: Using shell /bin/sh.
config/install.sh: SML root is /tmp/smlnj.
config/install.sh: Installation directory is /tmp/smlnj.
config/install.sh: Installing version 110.73.
config/install.sh: URL of source archive is http://smlnj.cs.uchicago.edu/dist/working/110.73/.
config/install.sh: !!! Script /tmp/smlnj/bin/.arch-n-opsys fails on this machine.
config/install.sh: !!! You must patch this by hand and repeat the installation.

Expected Behavior

No response

Steps to Reproduce

config/_arch-n-opsys

...
Linux)
OPSYS=linux
case uname -m in
86)
ARCH=x86
# we no longer support Linux before the 2.2 kernel.
case uname -r in
2.2.
) ;;
2.3.) ;;
2.4.
) ;;
2.5.) ;;
2.6.
) ;;
*) exit 1 ;;
esac
;;
...

Additional Information

No response

Email address

No response

Comments from smlnj-gforge

Original smlnj-gforge bug number 80

Submitted via web form by CaB on 2011-21-12 at 08:2100

comment by @larsbergstrom on 2011-55-08 19:5500 +000 UTC

I think we should probably match 3.0., not just 3.. I will try to track down a Linux machine with a 3.x kernel over the next few weeks.

comment by @larsbergstrom on 2011-06-26 02:0600 +000 UTC

Fixed. We now support all 3.x kernels.

psfig.sty is deprecated, use epsfig.sty wrapper or graphicx.sty

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

Debian Sid

Processor

No response

Component

Other

Severity

Minor

Description of the problem

Hi,

TeXLive 2009 no longer ships psfig.sty. It has been deprecated. However, four files in MLRISC/Doc/latex still use it:

dmr@skynet .../itps/smlnj/smlnj-old/MLRISC/Doc/latex (git)-[master] % grep -ri psfig .
./mlrisc-ir.tex: \psfig{figure=../pictures/eps/mlrisc-IR.eps,width=4.5in}
./mlrisc-ir.tex:\cpsfig{figure=../pictures/eps/tail-duplication.eps,width=3in}
./mltex.sty:\usepackage{psfig}
./mltex.sty:\newcommand{\cpsfig}[1]{\centerline{\psfig{#1}}}
./mltex.tex: \psfig
./graphs.tex: \psfig{figure=../pictures/eps/trace.eps,width=2.8in}
./graphs.tex: \psfig{figure=../pictures/eps/subgraph.eps,width=2.8in}

See:

http://osdir.com/ml/debian-tex-maint-debian/2010-01/msg00066.html

See section 2.2.2 of this document:

http://ftp.dante.de/tex-archive/info/l2tabu/english/l2tabuen.pdf

One solution is to use the epsfig.sty wrapper. Another is to port it properly to use graphicx directly.

The fix using epsfig.sty is trivial and is attached.

The more general fix would require changing the \newcommand wrapper in MLRISC/Doc/latex/mltex.sty. I know basically no Latex so I can't help with this.

Regards,
Daniel
Fix:
diff --git a/MLRISC/Doc/latex/graphs.tex b/MLRISC/Doc/latex/graphs.tex
index 01e626d..992f64a 100644
--- a/MLRISC/Doc/latex/graphs.tex
+++ b/MLRISC/Doc/latex/graphs.tex
@@ -877,7 +877,7 @@ with sources and targets in $S$. $S$ must be a subset of $V$.

\begin{wrapfigure}{r}{3in}
\begin{Boxit}

  • \psfig{figure=../pictures/eps/trace.eps,width=2.8in}
  • \epsfig{figure=../pictures/eps/trace.eps,width=2.8in}
    \end{Boxit}
    \label{fig:trace-view}
    \caption{A trace view}
    @@ -910,7 +910,7 @@ be both since it exits from \sml{G} and enters into \sml{A}.
    \end{SML}
    \begin{wrapfigure}{r}{3in}
    \begin{Boxit}
  • \psfig{figure=../pictures/eps/subgraph.eps,width=2.8in}
  • \epsfig{figure=../pictures/eps/subgraph.eps,width=2.8in}
    \end{Boxit}
    \label{fig:acyclic-subgraph-view}
    \caption{An acyclic subgraph}
    diff --git a/MLRISC/Doc/latex/mlrisc-ir.tex b/MLRISC/Doc/latex/mlrisc-ir.tex
    index c346baa..f437e22 100644
    --- a/MLRISC/Doc/latex/mlrisc-ir.tex
    +++ b/MLRISC/Doc/latex/mlrisc-ir.tex
    @@ -187,7 +187,7 @@ operate on more complex representations which use this
    representation as the base layer.
    \begin{wrapfigure}{r}{4.5in}
    \begin{Boxit}
  • \psfig{figure=../pictures/eps/mlrisc-IR.eps,width=4.5in}
  • \epsfig{figure=../pictures/eps/mlrisc-IR.eps,width=4.5in}
    \end{Boxit}
    \caption{The MLRISC IR}
    \end{wrapfigure}
    @@ -514,7 +514,7 @@ These functions have the following meanings:
    \end{SML}
    \begin{Figure}
    \begin{boxit}
    -\cpsfig{figure=../pictures/eps/tail-duplication.eps,width=3in}
    +\cepsfig{figure=../pictures/eps/tail-duplication.eps,width=3in}
    \end{boxit}
    \label{fig:tail-duplication}
    \caption{Tail-duplication}
    diff --git a/MLRISC/Doc/latex/mltex.sty b/MLRISC/Doc/latex/mltex.sty
    index 04d3477..8a30680 100644
    --- a/MLRISC/Doc/latex/mltex.sty
    +++ b/MLRISC/Doc/latex/mltex.sty
    @@ -5,7 +5,7 @@
    \ProvidesPackage{mltex}[2000/2/12 defines mltex environment]

\usepackage{latexsym}
-\usepackage{psfig}
+\usepackage{epsfig}
\usepackage{fancyheadings}
\usepackage{sml}
\usepackage{color}
@@ -34,7 +34,7 @@

% Images and Figures
\newcommand{\image}[3]{}
-\newcommand{\cpsfig}[1]{\centerline{\psfig{#1}}}
+\newcommand{\cepsfig}[1]{\centerline{\epsfig{#1}}}

% Formatting
\newenvironment{Bold}{\begingroup\bf}{\endgroup}
diff --git a/MLRISC/Doc/latex/mltex.tex b/MLRISC/Doc/latex/mltex.tex
index c9cbdbb..343d6fe 100644
--- a/MLRISC/Doc/latex/mltex.tex
+++ b/MLRISC/Doc/latex/mltex.tex
@@ -104,7 +104,7 @@ environments and macros, and will translate them into HTML equivalents.
\section \subsection \subsubsection \paragraph
\ref \label
\noindent \linebreak

  • \psfig
  • \epsfig
    \end{verbatim}

\subsection{Bugs and Shortcomings}

Transcript

dmr@skynet ...bian/itps/smlnj/smlnj/MLRISC/Doc/latex (git)-[master] % make
(cd ../pictures; make)
make[1]: Entering directory `/home/dmr/debian/itps/smlnj/smlnj/MLRISC/Doc/pictures'
fig2dev -L ps fig/big-pict.fig eps/big-pict.eps
fig2dev -L ps fig/big-pict2.fig eps/big-pict2.eps
fig2dev -L ps fig/cfg-rev.fig eps/cfg-rev.eps
fig2dev -L ps fig/cfg.fig eps/cfg.eps
fig2dev -L ps fig/compiler-2.fig eps/compiler-2.eps
fig2dev -L ps fig/compiler.fig eps/compiler.eps
fig2dev -L ps fig/compiler2.fig eps/compiler2.eps
fig2dev -L ps fig/hyperblock-formation.fig eps/hyperblock-formation.eps
fig2dev -L ps fig/if-conversion.fig eps/if-conversion.eps
fig2dev -L ps fig/layers.fig eps/layers.eps
fig2dev -L ps fig/mlrisc-ir-archive.fig eps/mlrisc-ir-archive.eps
fig2dev -L ps fig/mlrisc-IR.fig eps/mlrisc-IR.eps
fig2dev -L ps fig/phg.fig eps/phg.eps
fig2dev -L ps fig/region-builder.fig eps/region-builder.eps
fig2dev -L ps fig/subgraph.fig eps/subgraph.eps
fig2dev -L ps fig/tail-dupl.fig eps/tail-dupl.eps
fig2dev -L ps fig/tail-duplication.fig eps/tail-duplication.eps
fig2dev -L ps fig/trace.fig eps/trace.eps
fig2dev -L ps fig/uncol.fig eps/uncol.eps
fig2dev -L ps fig/viewer.fig eps/viewer.eps
fig2dev -L png fig/compiler-1.fig png/compiler-1.png
fig2dev -L png fig/compiler-2.fig png/compiler-2.png
fig2dev -L png fig/hof-1.fig png/hof-1.png
fig2dev -L png fig/hof-2.fig png/hof-2.png
fig2dev -L png fig/mlrisc-ir-archive.fig png/mlrisc-ir-archive.png
fig2dev -L png fig/optimization.fig png/optimization.png
fig2dev -L png fig/sharing1.fig png/sharing1.png
fig2dev -L png fig/sharing2.fig png/sharing2.png
fig2dev -L png fig/sharing3.fig png/sharing3.png
fig2dev -L png fig/uncol.fig png/uncol.png
fig2dev -L png fig/uncol1.fig png/uncol1.png
fig2dev -L png fig/uncol2.fig png/uncol2.png
make[1]: Leaving directory `/home/dmr/debian/itps/smlnj/smlnj/MLRISC/Doc/pictures'
latex sml.tex
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)
 restricted \write18 enabled.
entering extended mode
(./sml.tex
LaTeX2e <2009/09/24>
Babel <v3.8l> and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, loaded.
(/usr/share/texmf-texlive/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texmf-texlive/tex/latex/base/size10.clo)) (./sml.sty)
No file sml.aux.
[1]
Overfull \hbox (43.49661pt too wide) in paragraph at lines 67--67
[]     \OT1/cmtt/m/n/10 | flatten(NODE(x,children)) = [x] @ List.concat(map fla
tten children)[]

Overfull \hbox (43.49661pt too wide) in paragraph at lines 76--76
[]     \OT1/cmtt/m/n/10 | flatten(NODE(x,children)) = [x] @ List.concat(map fla
tten children)[]

Overfull \hbox (38.24666pt too wide) in paragraph at lines 90--90
[] \OT1/cmtt/m/n/10 \newcommand{\BeginSmlComment}{\begingroup\smlCommentSize\sm
lCommentFont}[]
[2]
Overfull \hbox (1.49698pt too wide) in paragraph at lines 138--138
[]   \OT1/cmtt/m/n/10 The datatype \sml{'a tree} implements a polymorphic n-ary
 tree.[]

Overfull \hbox (53.99652pt too wide) in paragraph at lines 138--138
[]\OT1/cmtt/m/n/10 The function \sml{val rev : 'a tree -> 'a list} flattens a t
ree into a list.[]

Overfull \hbox (1.49698pt too wide) in paragraph at lines 154--154
[]   \OT1/cmtt/m/n/10 The datatype \Sml{'a tree} implements a polymorphic n-ary
 tree.[]

Overfull \hbox (53.99652pt too wide) in paragraph at lines 154--154
[]\OT1/cmtt/m/n/10 The function \Sml{val rev : 'a tree -> 'a list} flattens a t
ree into a list.[]
[3] [4]

LaTeX Font Warning: Font shape `OMS/cmtt/m/n' undefined
(Font)              using `OMS/cmsy/m/n' instead
(Font)              for symbol `textbraceleft' on input line 244.

[5] (./sml.aux)

LaTeX Font Warning: Some font shapes were not available, defaults substituted.

 )
(see the transcript file for additional information)
Output written on sml.dvi (5 pages, 11392 bytes).
Transcript written on sml.log.
latex mlrisc.tex
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian)
 restricted \write18 enabled.
entering extended mode
(./mlrisc.tex
LaTeX2e <2009/09/24>
Babel <v3.8l> and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, loaded.
(/usr/share/texmf-texlive/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texmf-texlive/tex/latex/base/size10.clo)) (./mltex.sty
(/usr/share/texmf-texlive/tex/latex/base/latexsym.sty)

! LaTeX Error: File `psfig.sty' not found.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)

Enter file name:
! Emergency stop.
<read *>

l.9 \usepackage
               {fancyheadings}^^M
No pages of output.
Transcript written on mlrisc.log.
make: *** [mlrisc.dvi] Error 1

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 53

Submitted via web form by Daniel Moerner [email protected] on 2010-44-08 at 01:4400

Keywords: doc

comment by James McCoy on 2015-24-08 14:2400 +000 UTC

Debian continues to carry this patch. Is there a chance the patch will be accepted?

comment by @JohnReppy on 2015-28-09 08:2800 +000 UTC

Replaced eps files with pdf files and switched to use the graphicx package.

comment by @JohnReppy on 2015-55-09 08:5500 +000 UTC

Fixed for 110.79

SML/NJ 110.70 doesn't build under Mac OS/X Snow Leopard

Version

110.70

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

10.6

Processor

x86 (32-bit)

Component

Core system

Severity

Critical

Description of the problem

SML/NJ trunk doesn't compile under Mac OS/X 10.6 "Snow Leopard".

The makefile in base/runtime/objs/mk.x86-darwin defines _NONSTD_SOURCE.
The default gcc code generation for 10.6 is x86_64, which is incompatible with the _NONSTD_SOURCE define,
but even when setting the code generation to 32-bit (via adding -m32 flag to makefile),
the build fails somewhat later in the build process stating that:
cc -ansi -c -g -O2 -D_NONSTD_SOURCE -m32 -DHOST_X86 -DTARGET_X86 -DOPSYS_UNIX -DOPSYS_DARWIN -DOPSYS_MACOS_10_2 -DGNU_ASSEMBLER -DDLOPEN -DINDIRECT_CFUNC -I../objs -I../include ../mach-dep/unix-fault.c
/usr/include/ucontext.h:42:2: error: #error ucontext routines are deprecated, and require _XOPEN_SOURCE to be defined

Transcript

[11:25:59] Air:StandardML$ ./config/install.sh
./config/install.sh: Using shell /bin/sh.
./config/install.sh: SML root is /Users/pclark/Projects/StandardML.
./config/install.sh: Installation directory is /Users/pclark/Projects/StandardML.
./config/install.sh: Installing version 110.70.
./config/install.sh: URL of source archive is http://smlnj.cs.uchicago.edu/dist/working/110.70/.
./config/install.sh: Script /Users/pclark/Projects/StandardML/bin/.arch-n-opsys reports ARCH=x86; OPSYS=darwin; HEAP_SUFFIX=x86-darwin.
/Users/pclark/Projects/StandardML/config/unpack: The run-time tree already exists.
./config/install.sh: Compiling the run-time system.
(make RUNTIME="run.x86-darwin" VERSION="v-x86-darwin" CC="cc -ansi" CFLAGS="-g -O2 -D_NONSTD_SOURCE" CPP="cc -x assembler-with-cpp -E -P -ansi" AS="/usr/bin/as" TARGET=X86 DEFS="  -DHOST_X86 -DTARGET_X86 -DOPSYS_UNIX -DOPSYS_DARWIN -DOPSYS_MACOS_10_2 -DGNU_ASSEMBLER -DDLOPEN -DINDIRECT_CFUNC" XOBJS="" XLIBS="../c-libs/dl/libunix-dynload.a" LD_LIBS="-ldl" run.x86-darwin)
cc -ansi -c -g -O2 -D_NONSTD_SOURCE -I../config -I../objs -I../include ../config/gen-common.c
In file included from /usr/include/sys/_types.h:32,
                 from /usr/include/_types.h:27,
                 from /usr/include/stdio.h:64,
                 from ../config/gen-common.c:8:
/usr/include/sys/cdefs.h:289:8: error: #error "Can't define _NONSTD_SOURCE when only UNIX conformance is available."
make[1]: *** [gen-common.o] Error 1
make: *** [all] Error 2
./config/install.sh: !!! Run-time system build failed for some reason.

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 31

Submitted via web form by Peter Clark [email protected] on 2009-29-10 at 16:2900

Keywords: darwin10, snow leopard

comment by @JohnReppy on 2009-20-14 19:2000 +000 UTC

Fixed for 110.71 (September 13, 2009)

Structure C does not exist in Windows binary of 110.72 and 73.

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

vista

Processor

x86 (32-bit)

Component

Foreign-Function Interface (FFI)

Severity

Minor

Description of the problem

I tried to update from 110.71 to 110.72 and 110.73
using Windows installer, smlnj.msi.
Then, I found that both of versions 110.72 and 110.73 do not
have lib/c.
Is structure C ($c/c.cm) no longer included in Windows binary of
110.72 and later?

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 86

Submitted via web form by Masaya Saito [email protected] on 2011-43-09 at 13:4300

comment by @larsbergstrom on 2011-50-21 15:5000 +000 UTC

This observation is correct. I failed to uncomment ml-nlffi-lib in config/targets when I last built SML/NJ. Next release, I will bring this file in line with the one we ship for OSX.

comment by @larsbergstrom on 2012-38-21 22:3800 +000 UTC

I fixed this for the 110.74 release. Also, the config/targets file has now been updated so that this will not be missed again.

ml-makedepend trashes dependency file on error

Version

110.73

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Compilation manager (CM)

Severity

Major

Description of the problem

The ml-makedepend tool will generate an empty file that overwrites
the existing dependency file, when there is an error in the
compilation (e.g., ml-antlr fails). This means that subsequent
attempts to run make will not have any dependency information.
Additional comments:
ml-mkdepend should only generate a new dependency file when there
are no errors.

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 71

Submitted via web form by John Reppy [email protected] on 2011-00-19 at 00:0000

Keywords: CM

CM can't invoke ml-yacc or ml-lex on Windows

Version

110.70

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

xp

Processor

x86 (32-bit)

Component

Compilation manager (CM)

Severity

Major

Description of the problem

On Windows, the configuration manager is unable to invoke
ml-yacc or ml-lex. When it attempts to do so, I receive this
error message:

[scanning sources.cm]
["C:\smlnj\bin\ml-yacc" "" "mlc.grm"]
'C:\smlnj\bin\ml-yacc" "" "mlc.grm' is not recognized as an internal or external command,
operable program or batch file.
sources.cm:74.2-74.9 Error: tool "ML-Yacc" failed: "C:\smlnj\bin\ml-yacc" "" "mlc.grm"
["C:\smlnj\bin\ml-ulex" "--ml-lex-mode" "mlc.lex"]
'C:\smlnj\bin\ml-ulex" "--ml-lex-mode" "mlc.lex' is not recognized as an internal or external command,
operable program or batch file.
sources.cm:75.2-75.9 Error: tool "ULex-ML-Lex" failed: "C:\smlnj\bin\ml-ulex" "--ml-lex-mode" "mlc.lex"
val it = () : unit

I suspect that CM is sending an ill-formed command string to the
shell. The bug appeared in version 110.69, probably as a result
of this change:

  • Fixed problem with CM tools when paths contain spaces.

Additional comments:
I think this is the same bug as #38.

Transcript

as above

Expected Behavior

No response

Steps to Reproduce

No SML code necessary. Just put "foo.grm" into your sources.cm
to see it happen.

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 50

Submitted via web form by Karl Crary [email protected] on 2009-32-12 at 21:3200

[diff] SML/NJ doesn\'t build on NetBSD out of the box

Version

110.71

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

netbsd 5.0

Processor

x86 (32-bit)

Component

Installation

Severity

Major

Description of the problem

You cannot install SML/NJ on NetBSD without patchwork.
Fix:
NetBSD versions older than 4.0 are desupported.

--- config/_arch-n-opsys.orig 2008-08-13 22:37:59.000000000 +0400
+++ config/_arch-n-opsys 2009-01-27 17:24:34.000000000 +0300
@@ -118,13 +118,15 @@
;;
NetBSD)
case uname -r in

  •  2*) OPSYS=netbsd2;;
    
  •  3*) OPSYS=netbsd;;
    
  •  *) exit 1;;
    
  •  1.*)  exit 1;;
    
  •  2.*) OPSYS=netbsd2;;
    
  •  *) OPSYS=netbsd;;
    
    esac
    HEAP_OPSYS=bsd
  • case uname -m in
  • case uname -p in
    *86) ARCH=x86;;
  •  powerpc) ARCH=ppc;;
    
  •  sparc) ARCH=sparc;;
     *) exit 1;;
    
    esac
    ;;

NetBSD has POSIX signals since 2.0 at least.

--- src/runtime/include/ml-unixdep.h.orig 2008-12-05 20:57:39.000000000 +0300
+++ src/runtime/include/ml-unixdep.h 2009-03-19 00:14:35.000000000 +0300
@@ -323,7 +323,7 @@
#elif defined(OPSYS_NETBSD) /* version 3.x */

define OS_NAME "BSD"

define HAS_POSIX_LIBRARIES

-# define HAS_BSD_SIGS
+# define HAS_POSIX_SIGS

define HAS_GETRUSAGE

define HAS_SETITIMER

define HAS_MMAP

NetBSD has POSIX signals since 2.0 at least.

--- base/runtime/include/ml-unixdep.h.orig 2008-12-05 20:57:39.000000000 +0300
+++ base/runtime/include/ml-unixdep.h 2009-03-19 00:16:29.000000000 +0300
@@ -323,7 +323,7 @@
#elif defined(OPSYS_NETBSD) /* version 3.x */

define OS_NAME "BSD"

define HAS_POSIX_LIBRARIES

-# define HAS_BSD_SIGS
+# define HAS_POSIX_SIGS

define HAS_GETRUSAGE

define HAS_SETITIMER

define HAS_MMAP

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 39

Submitted via web form by Aleksej Saushev [email protected] on 2009-45-01 at 14:4500

comment by @JohnReppy on 2011-30-10 22:3000 +000 UTC

Fixed by Jon Riehl (r3492)

Comments not lexed correctly in mlyacc grammar files

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Command-line tool

Severity

Cosmetic

Description of the problem

Comments are not permitted in code snippets:

e.g.,

nonterminal : TOK1 nonterminal2 TOK2 (some code (* comment *))

fails.

Comments are not really lexed as such in the prefix. The following both fail:

(*
this is comment where the comment start is immediate followed by a newline
*)
open foo
%%

as well as

(* lets put a special string in my comment %% *)
maniacal laughter
Fix:
changeset: 7714:9a0d5c89f1e4
user: Michael Norrish [email protected]
date: Wed Jan 12 16:02:09 2011 +1100
files: c-parser/tools/mlyacc/src/yacc.lex
description:
Fix bug in comment-handling in lexer for mlyaccs input language.

In particular, if a comment was successfully lexed, it returned a BOGUS_VALUE
token, which then messed up the higher-level parsing. This was due to
the use of the idiom

continue() before YYBEGIN SOMESTATE

making the return value of the continue the return value for the lexer at
that point.

This bug prevented the use of comments in code sections entirely.

It was somewhat masked in the prefix section by the fact that most
supposed comments there were never lexed as such anyway. This could
be observed by a file that included %% in a comment in the prefix
section.

diff --git a/c-parser/tools/mlyacc/src/yacc.lex b/c-parser/tools/mlyacc/src/yacc.lex
--- a/c-parser/tools/mlyacc/src/yacc.lex
+++ b/c-parser/tools/mlyacc/src/yacc.lex
@@ -71,11 +71,11 @@
qualid ={id}.;
%%
INITIAL(* = (Add yytext; YYBEGIN COMMENT; commentLevel := 1;

  •       continue() before YYBEGIN INITIAL);
    
  •       continue(); YYBEGIN INITIAL; continue());
    

A(* = (YYBEGIN EMPTYCOMMENT; commentLevel := 1; continue());
CODE(* = (Add yytext; YYBEGIN COMMENT; commentLevel := 1;

  •       continue() before YYBEGIN CODE);
    

-INITIAL[^%\n]+ = (Add yytext; continue());

  •       continue(); YYBEGIN CODE; continue());
    

+INITIAL[^(%\n]+ = (Add yytext; continue());
INITIAL%% = (YYBEGIN A; HEADER (concat (rev (!text)),!lineno,!lineno));
INITIAL,CODE,COMMENT,F,EMPTYCOMMENT\n = (Add yytext; inc lineno; continue());
INITIAL. = (Add yytext; continue());

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

As above.

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 63

Submitted via web form by Michael Norrish [email protected] on 2011-46-19 at 00:4600

Keywords: mlyacc lexing

comment by @JohnReppy on 2011-04-08 17:0400 +000 UTC

Added suggested fix for 110.73. ~

Real.toLargeInt hangs when rounding mode has been previously set to TO_ZERO

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

other Windows 7 x64

Processor

x86 (32-bit)

Component

SML/NJ Library

Severity

Major

Description of the problem

Real.toLargeInt hangs if the global rounding mode has been set to
TO_ZERO.

Fix:
(* Sorry *)

Transcript

Standard ML of New Jersey v110.72 [built: Fri Feb 05 10:57:49 2010]
- IEEEReal.setRoundingMode IEEEReal.TO_ZERO ;
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]
val it = () : unit
- Real.toLargeInt IEEEReal.TO_ZERO 10.0 ;
[autoloading]
[autoloading done]

Interrupt
-

Expected Behavior

No response

Steps to Reproduce

IEEEReal.setRoundingMode IEEEReal.TO_ZERO;
Real.toLargeInt IEEEReal.TO_ZERO 10.0;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 66

Submitted via web form by Dan DuVarney [email protected] on 2011-33-08 at 23:3300

Keywords: reals, basis library

comment by @JohnReppy on 2011-02-22 15:0200 +000 UTC

It looks like the problem is in the function Real64.toLargeInt

comment by @JohnReppy on 2022-18-30 13:1800 +000 UTC

This was fixed at some point (at least in the 64-bit branch).

Problem with quoting, CM, and Windows

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

other Windows 7

Processor

x86 (32-bit)

Component

Compilation manager (CM)

Severity

Major

Description of the problem

When running CM.make, some of the commands for MS-DOS are provided
in quotes. When passed to the MS-DOS prompt, the quotes from the
beginning and end of the line are stripped, but not the ones in
the middle, causing the command to fail.

Ex:

[C:\Path\To\Command CmdArg]

Goes to the command line as:

C:\Current\Working\DirC:\Path\To\Command CmdArg
Fix:
Im pretty sure this can be fixed by enveloping the entire
command in another layer of quotes. (Yay, windows!)

Transcript

C:\Program Files (x86)\MLton\home\pkrajcev\sml3d\gen\gen-gl-gluesml
 Standard ML of New Jersey v110.72 [built: Fri Feb 05 10:57:49 2010]
 - CM.make sources.cm;
 [autoloading]
 ...
 [C:\SMLNJ\bin\ml-ulex  gl-spec.lex]
 C:\SMLNJ\bin\ml-ulex  gl-spec.lex is not recognized as an internal or extern
 al command,
 operable program or batch file.
 sources.cm:19.5-19.16 Error: tool MLULex failed: C:\SMLNJ\bin\ml-ulex  gl-s
 pec.lex
 [attempting to load plugin $/ml-antlr-tool.cm]
 [library $/ml-antlr-tool.cm is stable]
 [plugin $/ml-antlr-tool.cm loaded successfully]
 [C:\SMLNJ\bin\ml-antlr  gl-spec.grm]
 C:\SMLNJ\bin\ml-antlr  gl-spec.grm is not recognized as an internal or exter
 nal command,
 operable program or batch file.
 sources.cm:20.5-20.16 Error: tool MLAntlr failed: C:\SMLNJ\bin\ml-antlr  gl
 -spec.grm
 [parsing (sources.cm):expand-file.sml]

Expected Behavior

No response

Steps to Reproduce

Im not actually familiar with the SML/NJ source, so I don know
where this happens?

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 61

Submitted via web form by Pavel Krajcevski [email protected] on 2011-43-13 at 21:4300

Keywords: CM, Windows, Quotes, MSDOS

comment by @larsbergstrom on 2011-45-19 01:4500 +000 UTC

Just tested -- this is fixed in the latest sources: ~ ~ c:\Users\larsberg\sml3d\gen\gen-gl-glue>......\smlnj\bin\sml.bat ~ Standard ML of New Jersey v110.72 [built: Tue Jan 18 19:40:50 2011] ~ - CM.make sources.cm; ~ [autoloading] ~ [library $smlnj/cm/cm.cm is stable] ~ [library $smlnj/internal/cm-sig-lib.cm is stable] ~ [library $/pgraph.cm is stable] ~ [library $smlnj/internal/srcpath-lib.cm is stable] ~ [library $SMLNJ-BASIS/basis.cm is stable] ~ [autoloading done] ~ stdIn:1.9-1.19 Error: unbound structure: sources in path sources.cm ~ - CM.make "sources.cm"; ~ [scanning sources.cm] ~ [library $/regexp-lib.cm is stable] ~ [library $/json-lib.cm is stable] ~ [library $/ml-lpt-lib.cm is stable] ~ [attempting to load plugin $/ml-ulex-tool.cm] ~ [library $/ml-ulex-tool.cm is stable] ~ [library $smlnj/cm/tools.cm is stable] ~ [library $smlnj/internal/cm-lib.cm is stable] ~ [plugin $/ml-ulex-tool.cm loaded successfully] ~ ["c:\users\larsberg\smlnj\bin\ml-ulex" "gl-spec.lex"] ~ [ml-ulex: parsing] ~ [ml-ulex: DFA gen] ~ 100 states in full DFA ~ [ml-ulex: SML gen] ~ [parsing (sources.cm):gl-spec.lex.sml] ~ [creating directory .cm\SKEL] ~ [attempting to load plugin $/ml-antlr-tool.cm] ~ [library $/ml-antlr-tool.cm is stable] ~ [plugin $/ml-antlr-tool.cm loaded successfully] ~ ["c:\users\larsberg\smlnj\bin\ml-antlr" "gl-spec.grm"] ~ [ml-antlr: parsing gl-spec.grm] ~ [ml-antlr: checking grammar] ~ 22 nonterminals ~ 29 productions ~ [parsing (sources.cm):gl-spec.grm.sml] ~ [parsing (sources.cm):expand-file.sml] ~ [parsing (sources.cm):extensions.sml] ~ [parsing (sources.cm):gen.sml] ~ [parsing (sources.cm):gen-func-util.sml] ~ [parsing (sources.cm):gen-glee.sml] ~ [parsing (sources.cm):gen-std.sml] ~ [parsing (sources.cm):gl-types.sml] ~ [parsing (sources.cm):parser.sml] ~ [library $SMLNJ-LIB/Util/smlnj-lib.cm is stable] ~ [compiling (sources.cm):extensions.sml] ~ [creating directory .cm\GUID] ~ [creating directory .cm\x86-win32] ~ [code: 72, env: 846 bytes] ~ [compiling (sources.cm):gl-spec.grm.sml] ~ [code: 32931, data: 283, env: 3771 bytes] ~ [compiling (sources.cm):gl-spec.lex.sml] ~ [code: 26080, data: 188, env: 1331 bytes] ~ [compiling (sources.cm):parser.sml] ~ [code: 3125, data: 101, env: 141 bytes] ~ [compiling (sources.cm):gl-types.sml] ~ gl-types.sml:40.27-42.46 Warning: match nonexhaustive ~ NONE => ... ~ SOME (#"*",ss) => ... ~ ~ [code: 6067, data: 1291, env: 375 bytes] ~ [compiling (sources.cm):gen-func-util.sml] ~ [code: 2201, data: 77, env: 326 bytes] ~ [compiling (sources.cm):gen-glee.sml] ~ [code: 911, data: 319, env: 286 bytes] ~ [compiling (sources.cm):gen-std.sml] ~ [code: 658, data: 106, env: 285 bytes] ~ [compiling (sources.cm):expand-file.sml] ~ [code: 8026, data: 706, env: 215 bytes] ~ [compiling (sources.cm):gen.sml] ~ gen.sml:28.7-41.12 Warning: match nonexhaustive ~ STRING f => ... ~ ~ gen.sml:20.8-44.6 Warning: match nonexhaustive ~ OBJECT flds => ... ~ ~ [code: 5233, data: 473, env: 188 bytes] ~ [New bindings added.] ~ val it = true : bool ~ -

Garbage collection does not trigger sigGC

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

OS X 10.6.6

Processor

x86 (32-bit)

Component

Other

Severity

Minor

Description of the problem

A signal handler set to run when sigGC is triggered does not appear to run when forcing GC.

Transcript

rlwrap sml
Standard ML of New Jersey v110.72 [built: Wed Jan 26 00:56:21 2011]
- open Signals;
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]
opening Signals
  eqtype signal
  datatype sig_action
    = DEFAULT
    | HANDLER of signal * int * unit ?.Cont.cont - unit ?.Cont.cont
    | IGNORE
  val listSignals : unit - signal list
  val toString : signal - string
  val fromString : string - signal option
  val setHandler : signal * sig_action - sig_action
  val overrideHandler : signal * sig_action - sig_action
  val inqHandler : signal - sig_action
  datatype sigmask = MASK of signal list | MASKALL
  val maskSignals : sigmask - unit
  val unmaskSignals : sigmask - unit
  val masked : unit - sigmask
  val pause : unit - unit
  val sigINT : signal
  val sigALRM : signal
  val sigTERM : signal
  val sigGC : signal
- setHandler (sigGC, HANDLER (fn (_, _, k) = (print **** GC ****\n; k)));
val it = IGNORE : sig_action
- SMLofNJ.Internals.GC.doGC 100000;
[autoloading]
[autoloading done]
val it = () : unit

Expected Behavior

No response

Steps to Reproduce

(* From the REPL *)
open Signals;
setHandler (sigGC, HANDLER (fn (_, _, k) => (print "**** GC ****\n"; k)));
SMLofNJ.Internals.GC.doGC 100000;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 65

Submitted via web form by Ivan Tomac [email protected] on 2011-07-02 at 23:0700

Keywords: GC, Signals

comment by @JohnReppy on 2022-04-01 23:0400 +000 UTC

Also see #291

comment by @JohnReppy on 2022-19-27 15:1900 +000 UTC

Fixed for 110.99.3 and 2022.1.

Floating point exceptions are not handled correctly on Solaris x86.

Version

110.73

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

solaris 5.10

Processor

x86 (32-bit)

Component

Core system

Severity

Minor

Description of the problem

Floating point exceptions are not handled correctly (or at all) under Solaris x86.

This makes sml/nj only handle integer values up to 2^29 correctly.

The problem is present in 110.59, 110.72 and 110.73.
The problem is NOT present in 110.0.7.
I have not tested other versions.

Additional comments:
I only copied some defines for from the Solaris sparc parts and that
seem to have fixed the problem.

% sml-test
Standard ML of New Jersey v110.73 [built: Mon Sep 5 17:40:30 2011]

  • 536870910+1;
    val it = 536870911 : int
  • 536870910*2;
    val it = 1073741820 : int
  • 536870910*4;

uncaught exception Overflow [overflow]
raised at: file stdIn

Fix:
--- ./runtime/mach-dep/signal-sysdep.h~ 2009-09-13 19:50:53.000000000 +0200
+++ ./runtime/mach-dep/signal-sysdep.h 2011-09-05 17:32:03.031470000 +0200
@@ -499,6 +499,12 @@

elif defined(OPSYS_SOLARIS)

  /** x86, Solaris */

+# define SIG_FAULT1 SIGFPE
+# define INT_DIVZERO(s, c) (((s) == SIGFPE) ((c) == FPE_INTDIV))
+# define INT_OVFLW(s, c) (((s) == SIGFPE) ((c) == FPE_INTOVF))
+
+# define SIG_GetCode(info,scp) ((info)-si_code)
+

define SIG_GetPC(scp) ((scp)-uc_mcontext.gregs[EIP])

define SIG_SetPC(scp, addr) { (scp)-uc_mcontext.gregs[EIP] = (int)(addr); }

define SIG_ZeroLimitPtr(scp) { ML_X86Frame[LIMITPTR_X86OFFSET] = 0; }

Transcript

% sml
Standard ML of New Jersey v110.72 [built: Wed Oct 13 15:17:13 2010]
- 536870909+1;
val it = 536870910 : int
- 536870910+1;
Arithmetic Exception
%

Expected Behavior

No response

Steps to Reproduce

536870910+1;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 78

Submitted via web form by Joel Fredrikson [email protected] on 2011-21-05 at 16:2100

Keywords: FPE, Arithmetic Exception, Solaris, x86

comment by @JohnReppy on 2019-42-18 15:4200 +000 UTC

This bug appears to have been fixed some time ago.

Installation fails on mac OSX (10.7, Lion)

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

10.7

Processor

x86 (32-bit)

Component

Installation

Severity

Major

Description of the problem

Installation using PKG installer fails on Mac OSX (10.7, Lion).

This is a simple fix, please add the following line to smlnj-110.72/config/_arch-n-opsys between lines 66 and 67

11*) OPSYS=darwin; HEAP_OPSYS=darwin ;; # MacOS X 10.7

This fixes the problem. OSX Lion uses Kernal release version 11.
Thanks guys!

Fix:
Add the following line to smlnj-110.72/config/_arch-n-opsys between lines 66 and 67

11*) OPSYS=darwin; HEAP_OPSYS=darwin ;; # MacOS X 10.7

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 67

Submitted via web form by Scott [email protected] on 2011-49-14 at 20:4900

Keywords: osx, install, postinstall, script

comment by @JohnReppy on 2011-33-22 13:3300 +000 UTC

Fixed for 110.73 (r3578)

Can't open very large file

Version

110.70

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Basis Library

Severity

Major

Description of the problem

TextIO.openIn can't open very large files.

Transcript

kzhu@tucson:~/tmp$ uncaught exception Io [Io: openIn failed on "../ypc/20061214_ irvpiv1", File too large]
  raised at Basis/Implementation/IO/text-io-fn.sml:783.25-783.71

Expected Behavior

No response

Steps to Reproduce

(* ../ypc/20061214_ irvpiv1 is a very large file over 2GB *)

TextIO.openIn "../ypc/20061214_ irvpiv1"

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 36

Submitted via web form by Kenny Zhu [email protected] on 2009-06-17 at 08:0600

Keywords: IO, openIn

comment by @JohnReppy on 2011-43-08 16:4300 +000 UTC

This bug is essentially the same as #33

comment by @JohnReppy on 2019-23-02 05:2300 +000 UTC

Fixed in 110.89 (Position.int is now a 64-bit type)

sml/nj 110.70 pre-built executable does not run under OX X 10.6 Snow Leopard

Version

110.70

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

OS X 10.6

Processor

Other

Component

Other

Severity

Critical

Description of the problem

When sml is started from the command line, it prints
"sml: unable to determine architecture/operating system"
... and exits.

This same binary worked under OS X 10.5

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 30

Submitted via web form by Roy Lowrance [email protected] on 2009-45-01 at 02:4500

comment by @dmacqueen on 2009-50-14 17:5000 +000 UTC

In the file config/_arch-n-opsys (and the generated file bin/.arch-n-opsys) the line ~ ~ 10*) OPSYS=darwin; HEAP_OPSYS=darwin ;; # MacOS X 10.6 ~ ~ needs to be inserted after line 65. This adds a case under darwin/x86 for Snow Leopard, for which uname -r returns "10.0.0".

comment by @dmacqueen on 2009-36-14 19:3600 +000 UTC

Fixed in 110.71. ~

SML/NJ crashes when CML is used together with foreign code

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

OS X 10.6.6

Processor

x86 (32-bit)

Component

SML/NJ Library

Severity

Minor

Description of the problem

When using CML together with FFI, SML/NJ crashes with:

Fatal error -- Uncaught exception Fail with inconsistent state DEFAULT for signal 20 raised at Basis/Implementation/NJ/internal-signals.sml:346.16-346.24
Additional comments:
Problem only occurs when using CML and FFI code in the same
session. CML alone works fine as does FFI.

I found a workaround and that is to mask sigALRM before running
CML code - so far that appears to fix the problem though Im not
yet sure if it breaks anything else.

structure RunCML = struct

open RunCML

local
    open Signals

    val doit = doit
in
    fun doit args =
      ( maskSignals (MASK [sigALRM])
      ; doit args
      ; unmaskSignals (MASK [sigALRM])
      )
end

end

Fix:
Workaround mentioned in comments, though its not an actual fix.

Transcript

Ivan-MacBook:test ivan$ gcc -m32 -O2 -std=c99 -Wall -Wextra -pedantic -c ctest.c
Ivan-MacBook:test ivan$ libtool -dynamic -o ctest.so ctest.o -lc
Ivan-MacBook:test ivan$ ml-nlffigen -dir FFI -cmfile test.cm -include ../library.sml ctest.c
Ivan-MacBook:test ivan$ sml
Standard ML of New Jersey v110.72 [built: Wed Jan 26 00:56:21 2011]
- CM.make 	est.cm;
[autoloading]
[library $smlnj/cm/cm.cm is stable]
[library $smlnj/internal/cm-sig-lib.cm is stable]
[library $/pgraph.cm is stable]
[library $smlnj/internal/srcpath-lib.cm is stable]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]
[scanning test.cm]
[library $c/c.cm is stable]
[library $cml/cml.cm is stable]
[scanning (test.cm):FFI/test.cm]
[library $c/internals/c-int.cm is stable]
[parsing (test.cm):FFI/(test.cm):f-init.sml]
[creating directory FFI/.cm/SKEL]
[parsing (test.cm):FFI/(test.cm):callop-0.sml]
[parsing (test.cm):FFI/(test.cm):fptr-rtti-0.sml]
[parsing (test.cm):FFI/(test.cm):../library.sml]
[creating directory .cm/SKEL]
[library $c/memory/memory.cm is stable]
[parsing (test.cm):test.sml]
[library $cml/cml-internal.cm is stable]
[library $cml/core-cml.cm is stable]
[compiling (test.cm):FFI/(test.cm):../library.sml]
[creating directory .cm/GUID]
[creating directory .cm/x86-unix]
[code: 559, data: 39, env: 210 bytes]
[compiling (test.cm):FFI/(test.cm):callop-0.sml]
[creating directory FFI/.cm/x86-unix]
[code: 284, env: 261 bytes]
[compiling (test.cm):FFI/(test.cm):fptr-rtti-0.sml]
[code: 528, env: 277 bytes]
[compiling (test.cm):FFI/(test.cm):f-init.sml]
[code: 949, data: 33, env: 189 bytes]
[compiling (test.cm):test.sml]
[code: 540, env: 262 bytes]
$Execute: required privileges are:
  c-int
  primitive
[New bindings added.]
val it = true : bool
- Main.doit ();
/opt/local/share/smlnj/bin/sml: Fatal error -- Uncaught exception Fail with inconsistent state DEFAULT for signal 20 raised at Basis/Implementation/NJ/internal-signals.sml:346.16-346.24

Expected Behavior

No response

Steps to Reproduce

---- ctest.c ----

void init(void) { }

---- test.sml ----

structure Main = struct
fun loop () = loop () : unit
fun main () = (F_init.f (); loop ())
fun doit () = RunCML.doit (main, NONE)
end

---- library.sml ----

(* Helper module to load the object code *)

structure Library = struct
local
val lh = DynLinkage.open_lib
{ name = ./ctest.so, global = true, lazy = true }
in
fun libh s = let
val sh = DynLinkage.lib_symbol (lh, s)
in
fn () = DynLinkage.addr sh
end
end
end

---- test.cm ----

group
is
$/basis.cm
$c/c.cm
$cml/cml.cm
FFI/test.cm
test.sml

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 64

Submitted via web form by Ivan Tomac [email protected] on 2011-12-01 at 00:1200

Keywords: CML, FFI

Non-blocking socket functions broken

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

Debian lenny

Processor

No response

Component

Basis Library

Severity

Critical

Description of the problem

Non-blocking receive and send functions will block when called
on sockets that have been created by calls to acceptNB. This makes
it impossible to implement a server that uses nonblocking network
I/O functions.
Additional comments:
The problem is found in system/Basis/Implementation/Sockets/socket.sml.

The acceptNB function calls accept(), and once a socket is returned,
it invokes sockNB to wrap it in a Socket.SOCK with {nb = true}. This
is not correct. When accept() is called on a nonblocking listen socket,
the new connection socket it returns does not inherit the nonblockingness
of the listen socket. This causes future calls to recvVecNB and so on
to think that the socket is already nonblocking, when it actually isn .

Fix:
Here is a patch, to which I release all copyright interest:

Index: socket.sml

--- socket.sml (revision 3552)
+++ socket.sml (working copy)
@@ -163,9 +163,6 @@
val wrapNB_o = OpsysDetails.wrapNB_o
val wrapNB_b = OpsysDetails.wrapNB_b

  • fun sockB fd = SOCK { fd = fd, nb = ref false }

  • fun sockNB fd = SOCK { fd = fd, nb = ref true }

  • (* socket address operations )
    fun sameAddr (ADDR a1, ADDR a2) = (a1 = a2)
    local
    @@ -187,13 +184,13 @@
    (
    * Should do some range checking on backLog *)
    fun listen (SOCK { fd, ... }, backLog) = listen (fd, backLog)

  • fun accept0 (sock, getfd) s = let

  • fun accept0 getfd s = let
    val (newFD, addr) = accept (getfd s)
    in
  • (sock newFD, ADDR addr)
  • (SOCK { fd = newFD, nb = ref false }, ADDR addr)
    end
  • fun accept s = accept0 (sockB, fdB) s
  • fun acceptNB s = wrapNB_o (accept0 (sockNB, fdNB)) s
  • fun accept s = accept0 fdB s

  • fun acceptNB s = wrapNB_o (accept0 fdNB) s

    fun connect0 getfd (s, ADDR addr) = connect (getfd s, addr)
    fun connect arg = connect0 fdB arg

Transcript

I run strace sml test.sml. After startup messages, I get:

socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(4, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr(

Expected Behavior

No response

Steps to Reproduce

fun test () = let
val listener = INetSock.TCP.socket ()
val _ = Socket.Ctl.setREUSEADDR (listener, true)
val _ = Socket.bind (listener, INetSock.any 1234)
val _ = Socket.listen (listener, 50)
fun getConnection () = case Socket.acceptNB listener of
NONE = getConnection ()
| SOME (conn, addr) = conn

val conn = getConnection ()

in
Socket.recvVecNB (conn, 1)
end

val _ = test ()

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 59

Submitted via web form by Jacob Potter [email protected] on 2010-32-31 at 00:3200

Keywords: IO

comment by @JohnReppy on 2011-36-08 16:3600 +000 UTC

The bug was the way that Socket.acceptNB created new sockets. They ~ were marked as non-blocking, when they are not, which meant that ~ subsequent attempts to use them in non-blocking I/O would block. ~ ~ Fixed for 110.73

Compiler crash when compiling Manticore+MLton in one tree

Version

110.73

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

x86 (32-bit)

Component

Core system

Severity

Critical

Description of the problem

The compiler crashes with an error Uncaught exception Option with 0. From the line it occurs on, this appears to be a call to valOf on NONE somewhere in the compiler.
Additional comments:
Sorry for the calls to ml-lex before the make. MLton source code uses their own version of the basis, which does not contain all types mentioned in the output from ml-ulex --ml-lex-mode.

Transcript

[scanning (55161-export.cm):driver/(x86_64-darwin.cm):(sources.cm):../mlton/(sources.cm):front-end/(sources.cm):(ml-yacc-lib-proxy.cm):../../../../lib/mlyacc-lib/ml-yacc-lib.cm]
[parsing (55161-export.cm):55161-export.sml]
[compiling (55161-export.cm):55161-export.sml]
[code: 958, data: 78, env: 40 bytes]
/Users/larsberg/smlnj/bin/.run/run.x86-darwin: Fatal error -- Uncaught exception Option with 0
 raised at smlnj/init/pre-perv.sml:21.28-21.34

make[2]: *** [pmlc.x86-darwin] Error 1
make[1]: *** [build] Error 2
make: *** [build] Error 2
[larsberg@boot mlton-frontend]$

Expected Behavior

No response

Steps to Reproduce

  1. make sure you have an SML/NJ installation in the path.

  2. Enlist in the Manticore MLton-frontend branch

svn co --username anonsvn https://smlnj-gforge.cs.uchicago.edu/svn/manticore/branches/mlton-frontend

password: anonsvn (two times, once for the benchmarks tree)

  1. Configure and do a first build of the tree
    cd mlton-frontend
    autoheader -Iconfig
    autoconf -Iconfig
    ./configure
    pushd src/tools/mc/mlton/front-end
    ml-lex ml.lex
    ml-lex mlb.lex
    popd
    make local-install

  2. To remake with just the crash:
    cd src/tools/mc
    sml
    CM.make sources.cm;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 73

Submitted via web form by Lars Bergstrom [email protected] on 2011-57-08 at 19:5700

comment by @larsbergstrom on 2011-03-08 20:0300 +000 UTC

Nevermind, managed to track it down myself.

CM bug in calling ML-Lex/Yacc in Windows

Version

110.58-->now

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

xp

Processor

x86 (32-bit)

Component

Compilation manager (CM)

Severity

Major

Description of the problem

When calling ML-Lex and ML-Yacc, CM generates
a "file not found" error in the generation of
the lexer and parser files. (More correct to
say that ML-Lex and ML-Yacc are generating the
error message.) We speculate that the reason is
that they are not getting passed the right value
of $CWD (or whatever it is on Windows).

Hand invocation of ML-Lex/Yacc works just fine
from the Windows DOS prompt.

Fix:
See above.

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

Sorry, the above should give enough info to quickly
find the bug. If not, we can construct a small lexer
and show the problem.

Additional Information

No response

Email address

[email protected],[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 38

Submitted via web form by Konrad Slind and Mike Whalen <[email protected], [email protected]> on 2009-42-28 at 16:4200

comment by @matthias-blume on 2009-33-05 01:3300 +000 UTC

It would be nice to have sample code that illustrates the problem.

Support for UTF8 path names

Version

110.74

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

other Tested on OS/X Lion and Windows XP (using the Cygwin-compiled compiler)

Processor

No response

Component

Basis Library

Severity

Major

Description of the problem

Some of the OS.Path functions use the checkArc function to check the validity of arcs of paths. This does not play well with UTF8-encoded paths (which otherwise more or less work).

For example, if I have a directory ��� and I do
OS.FileSys.openDir ���
I get no problems, whereas
OS.Path.concat (���, abc)
I do.
Additional comments:
I see that validArc in Basis/Implementation/Unix/os-path.sml uses Char.isPrint, which is strictly speaking not correct for Unix paths (which allow anything but / and \0), and also the root of the problem. The Windows implementation in Basis/Implementation/Win32/os-path.sml seems more sane.

Transcript

- OS.FileSys.openDir /Users/michael;
val it = DS {dirStrm=-,isOpen=ref true} : ?.OS_FileSys.dirstream
- val d = it;
val d = DS {dirStrm=-,isOpen=ref true} : ?.OS_FileSys.dirstream
- OS.FileSys.readDir d;
val it = SOME .abbot.properties : string option

and so on, until

- OS.FileSys.readDir d;
val it = SOME \�95\134\195\152A\204\138 : string option
- val s =
Option.valOf it;
val s = \�95\134\195\152A\204\138 : string
- val m = String.concat [/Users/michael/, s];

- OS.FileSys.openDir m;
val it = DS {dirStrm=-,isOpen=ref true} : ?.OS_FileSys.dirstream
- OS.Path.concat (m, abc);

uncaught exception InvalidArc
  raised at: Basis/Implementation/OS/os-path-fn.sml:47.62-47.72
- OS.Path.concat (���, abc);

uncaught exception InvalidArc
  raised at: Basis/Implementation/OS/os-path-fn.sml:47.62-47.72

Expected Behavior

No response

Steps to Reproduce

For example, if I have a directory ��� and I do
OS.FileSys.openDir ���
I get no problems, whereas
OS.Path.concat (���, abc)
I do.

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 88

Submitted via web form by Michael Westergaard [email protected] on 2012-15-02 at 12:1500

Keywords: UTF8, OS.Path

comment by @JohnReppy on 2012-58-05 12:5800 +000 UTC

Fixed for 110.75. We now accept any character except slash or null.

nonsensical type error message

Version

110.71

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Core system

Severity

Minor

Description of the problem

Type checker issues nonsensical error message when operator +
(or any overloaded operator?) is used at the wrong type.
Additional comments:
The problem seems to be caused by having the boolean argument
appear first. If "3 + true" is entered instead, the error message
is correct.

Transcript

- true + 3;
stdIn:1.1-1.9 Error: operator and operand don't agree [literal]
  operator domain: bool * bool
  operand:         bool * int
  in expression:
    true + 3
stdIn:1.6 Error: overloaded variable not defined at type
  symbol: +
  type: bool
-

Expected Behavior

No response

Steps to Reproduce

true + 3;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 52

Submitted via web form by Matthias Blume [email protected] on 2009-37-28 at 05:3700

Keywords: types error messages

comment by @JohnReppy on 2014-36-20 16:3600 +000 UTC

Fixed for 110.78

top-level identfiers in generated code clash with legacy code

Version

110.xy

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

x86 (32-bit)

Component

Command-line tool

Severity

Minor

Description of the problem

This is a feature which is a critical bug for me!

ml-yacc (and to a lesser extent ml-lex) generated parsers exploit
assumptions about the top-level identifiers in the standard basis,
as per http://www.standardml.org/Basis/top-level-chapter.html

While porting some ancient (njsml 0.93 compilable) legacy software,
I encountered MANY hard-to-debug (until I figured out the global
problem) type errors/incompatibilities arising from use of
top-level identifiers (esp. for List primitives) and those in the
legacy code.

I agree with the principle regarding convenience which governs
top-level visibility, but for code-generators such as ml-yacc,
it seems much safer to adhere to signature-closed code in the
generated parsers (not least because the code generating sections
are fixed once and for all, so it only involves a one-time
change to the ml-yacc, ml-lex code base).
Additional comments:
I don know if this counts as a bug report, or merely a gripe,
but it certainly means I won be re-releasing this legacy code
in a hurry, given the extra work necessary to get it to compile.

It counts as critical for me, but maybe only of philosophical
interest to others!

There is a tension between the design principle articulated in the
Standard Basis document regarding pragmatics/convenience of having
top-level non-module identifiers visible, and the discipline
(originally Dave MacQueens?) of writing signature-closed code.

Theres a separate comment/bug report to file about how the type
signatures (and semantics!) of Standard Basis functions changed,
and the consequences for legacy code, but hey!
One source of knock-on viscosity is enough.

Fix:
Simple examples can easily be repaired by systematic renaming of
identifiers in legacy code, but thats the whole point! I was
lucky, and had access to source, but others may not be.

My solution was entirely ad-hoc: to hack the sources of ml-yacc
locally, and import base.sig etc. by hand into the source tree,
until such time as I could systematically eliminate all type
incompatibilities.

A better solution is as indicated above: write code generators
in a signature-closed way, as if your (defensive programmers)
expectation is that code will be deployed in a (type-)hostile
environment...

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

Too involved to deal with here.

Simple examples can easily be repaired by systematic renaming of
identifiers in legacy code, but thats the whole point!

But: List.rev is a (the?) major offender here.
(alternatively, be careful if you should rebind
ev in your
own code, and want ml-yacc generated parsers to work)

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 85

Submitted via web form by James McKinna [email protected] on 2011-59-16 at 11:5900

Keywords: legacy software, portability, ml-yacc, ml-lex

comment by @larsbergstrom on 2011-03-16 18:0300 +000 UTC

Without commenting on the signature-closed code issue, I can provide a fairly straightforward workaround. This issue is something we run into frequently in the context of generated code and the MLton compiler, which internally uses a modified Basis library built on top of the normal one. The trick that we use is to wrap the generated files in a CM file that provides the environment they expect. For example: ~ ~ Library ~ structure Parser ~ is ~ $/basis.cm ~ $/smlnj-lib.cm ~ parser.sml ~ ~ This does, unfortunately, mean that any SML code in productions has to use newspeak-List. But, it should hopefully be easier to adapt just the .lex/.grm files than the entire source codebase. In case it helps, I also attached a very small example .tgz that shows how to do this wrapping for simple SML files and a trivial change to the List structure (making app take its arguments tupled instead of curried).

comment by @JohnReppy on 2011-39-26 16:3900 +000 UTC

Fixed two unqualified IDs, but waiting for submitter response before closing the bug. ~ [2011-11-26] ~

comment by @JohnReppy on 2014-22-20 13:2200 +000 UTC

We have fixed the examples that we can detect by hand and also for the ml-opt tools. No response from the original bug submitter, so we'll assume that it is fixed.

Overflow exception with inputLine function

Version

110.70

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

2.6.18-164.el5 #1 SMP (64-bit)

Processor

x86 (32-bit)

Component

Basis Library

Severity

Critical

Description of the problem

We are processing a large file, and get the following exception:

uncaught exception Io [Io: inputLine failed on "../20061214_irvpiv1.1st"
with exception overflow]
raised at Basis/Implementation/IO/text-io-fn.sml:119.14-119.56

The exception occurs after we have processed more than 2 million lines.

Transcript

kzhu@tucson:~/tmp$ sml test.sml
Standard ML of New Jersey v110.70 [built: Thu Aug 13 10:36:44 2009]
[opening test.sml]
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]

uncaught exception Io [Io: inputLine failed on "abc" with exception overflow]
  raised at: Basis/Implementation/IO/text-io-fn.sml:119.14-119.56
/home/kfisher/sml-110.70/bin/sml: Fatal error -- Uncaught exception Io with <unk
nown> raised at Basis/Implementation/IO/text-io-fn.sml:119.14-119.56

Expected Behavior

No response

Steps to Reproduce

let
val eof = ref false
(* the file "abc" has 2.6M lines *)
val strm = TextIO.openIn "abc"
val _ = while not (!eof) do
(
case TextIO.inputLine strm of
SOME x => ()
| NONE => eof:=true
)
val _ = TextIO.closeIn strm
in ()
end

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 33

Submitted via web form by Kenny Zhu [email protected] on 2009-16-15 at 08:1600

Keywords: IO, exception

comment by @JohnReppy on 2011-41-08 16:4100 +000 UTC

To fix this bug will require switching to 64-bit integers for file positions. ~ Until we have an efficient implementation of 64-bit ints, this fix will probably ~ hurt general I/O performance too much to implement. [JHR: 2010-04-08]

comment by @JohnReppy on 2019-22-02 05:2200 +000 UTC

Fixed in 110.89 (Position.int is now a 64-bit type)

confusing error message when trying to install on 64-bit Linux without 32-bit support

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

x86 (32-bit)

Component

Installation

Severity

Minor

Description of the problem

SML/NJ is a 32-bit system, which means that it cannot be installed on 64-bit Linux, unless the 32-bit emulation libraries are available. The error messages that are produced during installation in this case are confusing. E.g.,

% gcc -m32 x.c
In file included from /usr/include/features.h:354,
from /usr/include/stdio.h:28,
from x.c:3:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

No response

Comments from smlnj-gforge

Original smlnj-gforge bug number 70

Submitted on 2011-01-13 at 18:0100

comment by @JohnReppy on 2011-14-13 21:1400 +000 UTC

As of version 110.73, the install script tests for this situation and prints a message.

ml-lpt: inconsistent treatment of %defs directive between ml-antlr and ml-ulex

Version

110.72

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Command-line tool

Severity

Cosmetic

Description of the problem

Both ml-antlr and ml-ulex provide a %defs directive to
include user provided code in the parser or lexer.

Ml-antlr puts this code in a UserCode structure, hidden within a
local block making it inaccessible outside of the parser
functor.

Ml-ulex, on the other hand, puts the user provide code in a
UserDeclarations structure that is accessible outside of the
lexer structure.

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

No response

Comments from smlnj-gforge

Original smlnj-gforge bug number 79

Submitted via web form by James Bostock on 2011-51-09 at 21:5100

comment by @JohnReppy on 2014-08-20 13:0800 +000 UTC

Changed ml-ulex to hide the UserDeclarations structure inside a local (like ml-antlr does).

Fix bashism in base/smlnj-lib/Doc/config.sh

Version

110.71

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

Any

Component

SML/NJ Library

Severity

Minor

Description of the problem

Hi, "function" is not POSIX-compliant, and thus is not implemented by all shells that provide /bin/sh.

Please see attached patch which will be applied in the next upload to Debian.

I hope the patch formatting doesn't get mangled, you can find it at:

http://git.debian.org/?p=collab-maint/smlnj.git;a=blob;f=debian/patches/01_fix-bashism.patch;h=a50f3751898bc101aef2cc237d953e68393a6d63;hb=HEAD
Fix:
--- smlnj.orig/base/smlnj-lib/Doc/config.sh 2007-05-10 14:39:48.000000000 -0700
+++ smlnj/base/smlnj-lib/Doc/config.sh 2009-09-03 23:39:05.000000000 -0700
@@ -6,7 +6,7 @@

find ML-Doc -name "*.mldoc" -print | mk-mldoc-makefile

-function mkDirTree {
+mkDirTree () {
base=$1
if test ! -d $base ; then
mkdir $base || (echo "unable to create $base"; exit 1)

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

No response

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 34

Submitted via web form by Daniel Moerner [email protected] on 2009-13-16 at 08:1300

Keywords: POSIX

comment by @JohnReppy on 2009-06-19 00:0600 +000 UTC

Fixed for 110.72

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.