Giter VIP home page Giter VIP logo

smlnj / legacy Goto Github PK

View Code? Open in Web Editor NEW
25.0 6.0 8.0 8.12 MB

This project is the old version of Standard ML of New Jersey that continues to support older systems (e.g., 32-bit machines).

License: BSD 3-Clause "New" or "Revised" License

Makefile 0.39% Perl 0.21% TeX 5.56% Standard ML 82.65% Lex 0.64% Batchfile 0.03% Shell 0.56% C 5.88% Assembly 1.08% Python 0.11% M4 0.18% C++ 0.19% HTML 2.11% C# 0.02% Roff 0.04% Yacc 0.08% Scala 0.01% GAP 0.17% Pascal 0.01% OpenEdge ABL 0.09%
standard-ml functional-programming sml

legacy'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 from the legacy system.

  1. Set VERSION to the version of SML/NJ that you want to build; for example

    VERSION=2024.2
  2. Clone the repository

    git clone --depth 1 --branch v$VERSION --recurse-submodules https://github.com/smlnj/smlnj.git

    The --depth option limits the download to just one commit (i.e., no history), the --branch option specifies the version of the source code that you are requesting, and the --recurse-submodules option is necessary to fetch the customized version of the LLVM library that we use.

  3. cd to the cloned repository and get the boot files

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

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

  4. 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

legacy's People

Contributors

atupone avatar barracuda156 avatar dmacqueen avatar johnreppy avatar p-ouellette avatar zbyrn 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

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

legacy's Issues

Difference between mlton/sml-nj in type generalization

Version

110.81

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Core system

Severity

Cosmetic

Description of the problem

In a silly example there is an observable difference between SML/NJ and MLton,
SML/NJ rejects the code, while MLTon accepts it,

I'm not quite sure though one or both may conform to the standard,
with differing interpretations of the value restriction context.

Additional comments:
Perhaps everything is conforming and this can be closed without change.
I just figured I would point it out.

Transcript

Standard ML of New Jersey v110.81 [built: Sun Jun 11 05:04:27 2017]
[opening silly.sml]
val id = fn : 'a -> 'a
val curry = fn : ('a * 'b -> 'c) -> 'a -> 'b -> 'c
val foo = fn : int * (bool * (unit * real)) -> unit
silly.sml:6.5-6.20 Warning: type vars not generalized because of
   value restriction are instantiated to dummy types (X1,X2,...)
silly.sml:7.11-7.19 Error: operator and operand don't agree [tycon mismatch]
  operator domain: 'Z * 'Y -> 'X
  operand:         ?.X1 -> int * ?.X1
  in expression:
    curry it

Expected Behavior

No response

Steps to Reproduce

fun id x = x
fun curry f x y = f (x, y)
fun foo (w : int, (x : bool, (y : unit, z : real))) = ();

val it = curry id 0
val it = (curry it) true
val it = (curry it) ()
val it = it 0.0
val _ = foo it;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 184

Submitted via web form by matt rice [email protected] on 2017-28-11 at 13:2800

comment by @JohnReppy on 2017-31-28 14:3100 +000 UTC

The Definition of Standard ML is ambiguous w.r.t. this question (also the scope of overload resolution).

Missing warning for nonexhaustive valbind patterns

Version

110.82 (trunk)

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

x86 (32-bit)

Component

Core system

Severity

Minor

Description of the problem

Hi all,

Currently, SMLNJ does not emit a warning for the following code:

val x = fn y => let
val nil = [1]
in
y
end

According to page 32, item number 3 in the definition of ML http://sml-family.org/sml97-defn.pdf, this must emit a warning informing the user that the match is invalid.

A further note to this matter is that MosML and PolyML both successfully report a warning in this case.

Jackson.

As a precise example of what I mean:
[15:50:24]
Poly/ML 5.6 Release

val x = fn y => let val nil = [1] in y end;;
poly: : warning: Pattern is not exhaustive. Found near val nil = [1]
val x = fn: 'a -> 'a
%

                                                                                                                                                                     [15:50:40]

Standard ML of New Jersey v110.79 [built: Wed Nov 2 06:06:36 2016]

  • val x = fn y => let val nil = [1] in y end;;
    val x = fn : 'a -> 'a

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 188

Submitted on 2017-52-19 at 14:5200

Keywords: Warning

comment by @JohnReppy on 2017-20-01 18:2000 +000 UTC

This bug appear to be related to 130.

comment by @dmacqueen on 2018-09-20 17:0900 +000 UTC

In 110.82 this bug is gone, and the "binding not exhaustive" warning is given. ~ However, when executed, this example should raise the Bind exception when [1] does not match the pattern nil. It looks like the let binding has been improperly optimized away so that it is not executed. So this reveals a different bug in the optimizer, which is changing the dynamic semantics of the code.

comment by @JohnReppy on 2019-02-16 14:0200 +000 UTC

This was presumably fixed when bug 130 was fixed (version 110.94)

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.

Bring command line help text into parity with man page.

Version

110.81

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Core system

Severity

Cosmetic

Description of the problem

The -h help text is missing some options present in the sml.1 manual page.
The attached adds the missing options,
and reorders an existing option to reflect the order presented in the manual page.
Additional comments:
Testing this out by running config/install.sh did not show new help text,
I went through the process here: http://www.smlnj.org/doc/CM/btcomp/node5.html
to check it, not sure if that is normal or not.

Fix:
Index: base/cm/main/cm-boot.sml

--- base/cm/main/cm-boot.sml (revision 4397)
+++ base/cm/main/cm-boot.sml (working copy)
@@ -730,10 +730,13 @@
\n
\ rtsargs:\n
\ @SMLload= (start specified heap image)\n\

  •        \    @SMLrun=<r>      (specify runtime system)\n\
    
  •        \    @SMLversion      (echo the version of SML/NJ then exit)\n\
    
  •        \    @SMLsuffix       (echo heap suffix for the system then exit)\n\
           \    @SMLalloc=<s>    (specify size of allocation area)\n\
           \    @SMLcmdname=<n>  (set command name)\n\
    
  •        \    @SMLverbose      (show heap image load progress)\n\
           \    @SMLquiet        (load heap image silently)\n\
    
  •        \    @SMLverbose      (show heap image load progress)\n\
           \    @SMLobjects      (show list of executable objects)\n\
           \    @SMLdebug=<f>    (write debugging info to file)\n\
           \\n\
    

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 185

Submitted via web form by matt rice [email protected] on 2017-31-27 at 22:3100

comment by @JohnReppy on 2017-28-28 14:2800 +000 UTC

Fixed for 110.82; also made some changes to the manual page.

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

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 @mathias-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?

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

heap2exec broken on 64-bit machines with default toolchains

Version

110.79

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

x86 (32-bit)

Component

Other

Severity

Minor

Description of the problem

This is probably not particularly urgent, especially with recent
ongoing work on Successor ML, but this might break some
old build setups.

heap2exec (the script itself) appears to be unusable by default
on 64bit machines with default toolchains. The reason is that most
64bit machines now compile (cc) and link (ld) targeting 64bit
architectures by default. Hence, additional flags must be added to
the $(CC) and $(LD) variable to the script to accomodate that.
Additional comments:
This is reproducable on 2 64bit machines:
one running linux and one running OSX.
Both have the standard developer toolchains installed. On linux
it triggers gcc, while on OSX it triggers clang. Both broke, with
somewhat similar messages. On OSX (HEAP-SUFFIX=x86-darwin),
it tried to link with the binary instead of the relocatable.

I believe that the updates in runtime, which now has the -m32
flags, forgot to update the heap2exec script as well?

Fix:
I actually don't know what the exact linker flags for ld should be,
but something like this linked properly on my machine:

gcc -m32 mltq.s runtime.x86-linux.a -lm -ldl -rdynamic

So for my own projects, I use my own build scripts (apparently
some folks really like linked binaries).

However, I'm extremely confused about what flags should be passed
to ld to make it link with the binary runtime. I've tried
something along the lines "ld -m elf_i386", but it still didn't
like it, but I do believe something to should be added to
EXEC_FLAGS, SO_FLAGS, and A_FLAGS in
config/_heap2exec (lines 77~85 declared, modified in if checks).

If it's any help, this is the output of gcc -v for the above command:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)
COLLECT_GCC_OPTIONS='-v' '-m32' '-rdynamic' '-mtune=generic' '-march=i586'
as -v --32 -o /tmp/cchsuADs.o mltc.s
GNU assembler version 2.25 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.25
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/32/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../i386-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib32/:/lib/i386-linux-gnu/:/lib/../lib32/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib32/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../i386-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../:/lib/i386-linux-gnu/:/lib/:/usr/lib/i386-linux-gnu/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-m32' '-rdynamic' '-mtune=generic' '-march=i586'
/usr/lib/gcc/x86_64-linux-gnu/4.9/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/4.9/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper -plugin-opt=-fresolution=/tmp/ccFy9PiM.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr -m elf_i386 --hash-style=gnu -export-dynamic -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib32/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib32/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.9/32/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.9/32 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../i386-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib32 -L/lib/i386-linux-gnu -L/lib/../lib32 -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib32 -L/usr/lib/gcc/x86_64-linux-gnu/4.9 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../i386-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -L/lib/i386-linux-gnu -L/usr/lib/i386-linux-gnu /tmp/cchsuADs.o ../run.x86-linux.a -ldl -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.9/32/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib32/crtn.o

I'm no good at this, so I'm not exactly sure which flags made it tick.

I'm also very much a n00b to the source code,
so I might be missing something really obvious, and I apologize
in advance if that's the case.

Transcript

This is the output of `heap2exec mltq.x86-linux mltq`.
I'm not particularly sure why it chose to link with
runtime.x86-linux.a (the static lib)
instead of runtime.x86-linux (the binary, it's present in objs/),
might be some misconfiguration or accidental fiddling on my
end, but that is irrelevant.

/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(main.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(c-libraries.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ml-options.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(boot.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(load-ml.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(run-ml.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(globals.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ml-state.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(error.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(timers.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(unix-timers.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(swap-bytes.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(unix-fault.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(signal-util.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(prim.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(posix-os-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tmpname.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(smlnj-runt-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(sysinfo.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(smlnj-sig-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(smlnj-prof-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(smlnj-sock-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(socket.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(socketpair.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(to-inetaddr.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(to-unixaddr.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(smlnj-time-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(timeofday.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(smlnj-date-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(strftime.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(smlnj-math-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(sqrt64.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(posix-process-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(sleep.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(waitpid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(posix-procenv-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(setgid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(setpgid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(setsid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(setuid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(sysconf.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(time.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(times.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ttyname.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(uname.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(posix-filesys-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(readdir.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(readlink.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(rename.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(rewinddir.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(rmdir.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(stat.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(stat_64.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(symlink.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(umask.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(unlink.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(utime.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(posix-io-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(read.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(readbuf.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(write.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(writebuf.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(posix-sysdb-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(posix-signal-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(posix-tty-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tcdrain.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tcflow.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tcflush.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tcgetattr.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tcgetpgrp.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tcsendbreak.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tcsetattr.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tcsetpgrp.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(posix-error-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(posix-name-val.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(big-objects.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(build-literals.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(c-globals-tbl.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(call-gc.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(gc-util.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(import-heap.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(init-gc.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(major-gc.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(minor-gc.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ml-objects.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(mem-mmap.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(unix-dynload-lib.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(unix-raise-syserr.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(qualify-name.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(poll.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(alloc-code.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(argv.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(blast-in.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(blast-out.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(cmd-name.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(debug.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(dummy.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(export-fun.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(export-heap.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(gc-ctl.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(itick.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(mkexec.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(mkliterals.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(raw-argv.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(record-concat.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(record1.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(setitimer.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(shift-argv.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getsigmask.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getsigstate.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(listsignals.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(pause.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(setsigmask.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(setsigstate.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getpquantum.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(setpref.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(setptimer.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(accept.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(bind.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(close.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(connect.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctlBROADCAST.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctlDEBUG.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctlDONTROUTE.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctlKEEPALIVE.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctlLINGER.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctlNODELAY.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctlOOBINLINE.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctlRCVBUF.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctlREUSEADDR.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctlSNDBUF.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(from-inetaddr.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(from-unixaddr.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getATMARK.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getERROR.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getNREAD.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getTYPE.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getaddrfamily.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(gethostbyaddr.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(gethostbyname.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(gethostname.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getnetbyaddr.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getnetbyname.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getpeername.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getprotbyname.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getprotbynum.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getservbyname.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getservbyport.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getsockname.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(inetany.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(list-addr-families.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(list-sock-types.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(listen.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(recv.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(recvbuf.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(recvbuffrom.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(recvfrom.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(sendbuf.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(sendbufto.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(setNBIO.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(shutdown.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tbl-addr-family.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tbl-sock-type.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(util-mkhostent.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(util-mknetent.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(util-mkservent.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(util-sockopt.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(gettime.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(asctime.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(gmtime.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(localoffset.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(localtime.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(mktime.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(atan64.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(cos64.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctlrndmode.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(exp64.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(log64.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(sin64.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(alarm.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(exec.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(exece.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(execp.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(exit.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(fork.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(kill.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(osval.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(pause.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ctermid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(environ.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getegid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getenv.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(geteuid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getgid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getgroups.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getlogin.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getpgrp.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getpid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getppid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getuid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(isatty.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(access.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(chdir.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(chmod.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(chown.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(closedir.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(fchmod.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(fchown.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ftruncate.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(ftruncate_64.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getcwd.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(link.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(mkdir.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(mkfifo.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(opendir.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(openf.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(osval.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(pathconf.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(close.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(dup.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(dup2.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(fcntl_d.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(fcntl_gfd.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(fcntl_gfl.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(fcntl_l.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(fcntl_l_64.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(fcntl_sfd.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(fcntl_sfl.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(fsync.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(lseek.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(lseek_64.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(osval.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(pipe.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getgrgid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getgrnam.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getpwnam.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(getpwuid.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(osval.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(osval.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(errmsg.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(geterror.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(listerrors.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(tbl-errno.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(addr-hash.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(blast-in.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(blast-out.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(export-heap.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(flip.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(heap-in-util.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(heap-out-util.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(mem-writer.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(obj-info.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(record-ops.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(writer.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(dlclose.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(dlerror.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(dlopen.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(dlsym.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(unix-signal.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(unix-prof.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(blast-gc.o)' is incompatible with i386:x86-64 output
/usr/bin/ld: mltq(.eh_frame): relocation ".text+0x0 (type R_386_PC32)" goes out of range
/usr/bin/ld: /home/haoxuany/projects/smlnj/bin/.run/run.x86-linux.a(swap-bytes.o): file class ELFCLASS32 incompatible with ELFCLASS64
/usr/bin/ld: final link failed: File in wrong format
collect2: error: ld returned 1 exit status

Expected Behavior

No response

Steps to Reproduce

Shouldn't be particularly relevant. Occurs on all projects. I've
chosen mltq as an example.

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 168

Submitted via web form by Haoxuan "Aaron" Yue [email protected] on 2016-38-19 at 14:3800

Keywords: heap2exec

comment by @JohnReppy on 2020-52-17 13:5200 +000 UTC

Should be working now (using the -64 flag)

Can't install SML/NJ in directories containing spaces

Version

v110.79

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

Ubuntu

Processor

No response

Component

Installation

Severity

Major

Description of the problem

Installation fails if the root directory contains spaces.
Fix:
diff -r smlnj-old/config/unpack smlnj/config/unpack
58c58
< for base in $2 $VERSION-$2 ; do

for base in "$2" "$VERSION-$2" ; do

290c290
< unpack "documentation" $ROOT doc doc

unpack "documentation" "$ROOT" doc doc
diff -r smlnj-old/nlffi/gen/build smlnj/nlffi/gen/build
42c42
< $BUILD ml-nlffigen.cm Main.main $HEAP_IMAGE


"$BUILD" ml-nlffigen.cm Main.main "$HEAP_IMAGE"

Transcript

/home/eush77/dir A/smlnj/config/unpack: Fetching documentation from http://smlnj.cs.uchicago.edu/dist/working/110.79/. Please stand by...
/home/eush77/dir A/smlnj/config/unpack: Trying A/smlnj.tgz ...
/home/eush77/dir A/smlnj/A/smlnj.tgz: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Trying A/smlnj.tar.gz ...
/home/eush77/dir A/smlnj/A/smlnj.tar.gz: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Trying A/smlnj.tar.Z ...
/home/eush77/dir A/smlnj/A/smlnj.tar.Z: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Trying A/smlnj.tz ...
/home/eush77/dir A/smlnj/A/smlnj.tz: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Trying A/smlnj.tar ...
/home/eush77/dir A/smlnj/A/smlnj.tar: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Trying A/smlnj.tar.bz2 ...
/home/eush77/dir A/smlnj/A/smlnj.tar.bz2: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Trying 110.79-A/smlnj.tgz ...
/home/eush77/dir A/smlnj/110.79-A/smlnj.tgz: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Trying 110.79-A/smlnj.tar.gz ...
/home/eush77/dir A/smlnj/110.79-A/smlnj.tar.gz: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Trying 110.79-A/smlnj.tar.Z ...
/home/eush77/dir A/smlnj/110.79-A/smlnj.tar.Z: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Trying 110.79-A/smlnj.tz ...
/home/eush77/dir A/smlnj/110.79-A/smlnj.tz: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Trying 110.79-A/smlnj.tar ...
/home/eush77/dir A/smlnj/110.79-A/smlnj.tar: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Trying 110.79-A/smlnj.tar.bz2 ...
/home/eush77/dir A/smlnj/110.79-A/smlnj.tar.bz2: No such file or directory
/home/eush77/dir A/smlnj/config/unpack: Fetching 110.79-A/smlnj.tar.bz2 was no success.
   You should try to do it manually now.
/home/eush77/dir A/smlnj/config/unpack: Please, fetch documentation archive
 (A/smlnj.* or 110.79-A/smlnj.*)
 from http://smlnj.cs.uchicago.edu/dist/working/110.79/
 and then re-run this script!
FAILURE: unpacking failed
./config/install.sh: !!! Installation of libraries and programs failed.

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 166

Submitted via web form by Eugene [email protected] on 2016-15-29 at 08:1500

Keywords: install, config, nlffi

comment by @JohnReppy on 2016-42-04 14:4200 +000 UTC

Fixed for 110.80 (needs to be tested).

@ 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.

Unexpected exception in SML/NJ with invalid list pattern match

Version

110.82 (trunk)

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Core system

Severity

Minor

Description of the problem

Hi all,

The following interactive session results in an error:

val [x] = [];;

I get the message

unexpected exception (bug?) in SML/NJ: Bind [nonexhaustive binding failure]
raised at: stdIn:1.6-4.1
../compiler/MiscUtil/print/ppobj.sml:396.20
../compiler/TopLevel/interact/evalloop.sml:45.54

This seems related, but not the same as http://smlnj-gforge.cs.uchicago.edu/tracker/index.php?func=detail&aid=130&group_id=33&atid=215

Jackson.

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 190

Submitted on 2017-03-19 at 15:0300

comment by @JohnReppy on 2017-21-01 18:2100 +000 UTC

This appears to be a duplicate of 130.

comment by @JohnReppy on 2018-31-19 14:3100 +000 UTC

May be related to bug #199

comment by @JohnReppy on 2020-47-13 18:4700 +000 UTC

This was fixed in 110.94 (when #130 was fixed).

smlnj installation: error in first cm file memory.cm from nlffi

Version

110.99

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

in 01.install.sh file

Processor

x86 (32-bit)

Component

Installation

Severity

Critical

Description of the problem

No response

Transcript

#####in 01.install.sh####

2021-04-13 21:03:49 +0300

config/install.sh
-default
64

config/install.sh: Using shell /bin/sh.
config/install.sh: SML root is /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME.
config/install.sh: Installation directory is /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME.
config/install.sh: Installing version 110.99.
config/install.sh: URL of source archive is http://smlnj.cs.uchicago.edu/dist/working/110.99/.
config/install.sh: installing /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME/bin/.arch-n-opsys
config/install.sh: Script /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME/bin/.arch-n-opsys reports ARCH=amd64; OPSYS=linux; HEAP_SUFFIX=amd64-linux.
config/install.sh: installing /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME/bin/.run-sml
config/install.sh: installing /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME/bin/.link-sml
config/install.sh: installing /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME/bin/ml-makedepend
config/install.sh: installing /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME/bin/heap2exec
/home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME/config/unpack: The run-time tree already exists.
config/install.sh: Compiling the run-time system.
(make CHECK_HEAP= RUNTIME="run.amd64-linux" VERSION="v-amd64-linux" AS="as --64" CC="gcc -std=gnu99 -Wall" CFLAGS="-O2 -m64" CPP="gcc -x assembler-with-cpp -E -P" TARGET=AMD64 DEFS="  -DARCH_AMD64 -DSIZE_64 -DOPSYS_UNIX -DOPSYS_LINUX -D_GNU_SOURCE -DGNU_ASSEMBLER -DDLOPEN -DINDIRECT_CFUNC" XOBJS="" XLIBS="../c-libs/dl/libunix-dynload.a" LD_LIBS="-lm -ldl" run.amd64-linux)
...
...

...
...
Here all was Ok!
...

[compiling $/(ckit-lib.cm):ast/(group.cm):parse-to-ast.sml]
[code: 2565, data: 21, env: 1084 bytes]
[stabilizing $/ckit-lib.cm]
[creating directory /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME/ckit/src/.cm/amd64-unix]
[code: 874749, data: 31637, inlinable: 0, env: 51839 bytes]
[scanning $c/memory/memory.cm]
[parsing $c/memory/(memory.cm):memaccess.sig]

...
And here error apears!
...

[creating directory /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME/nlffi/lib/memory/.cm/SKEL]
[parsing $c/memory/(memory.cm):memalloc.sig]
[parsing $c/memory/(memory.cm):memory.sig]
[parsing $c/memory/(memory.cm):linkage.sig]
[parsing $c/memory/(memory.cm):bitop-fn.sml]
[parsing $c/memory/(memory.cm):memaccess-64-little.sml]
/home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99/SMLNJ_HOME/nlffi/lib/memory/memory.cm:39.1-39.39 Error: architecture not supported yet
[parsing $c/memory/(memory.cm):main-lib-unix.sml]
[parsing $c/memory/(memory.cm):memalloc-a4-unix.sml]
[parsing $c/memory/(memory.cm):memory.sml]
[parsing $c/memory/(memory.cm):linkage-dlopen.sml]
[parsing $c/memory/(memory.cm):mlrep-i32f64.sml]
FAILURE: stabilization of libraries failed
config/install.sh: !!! Installation of libraries and programs failed.

HOMEBREW_VERSION: 3.1.1-22-g586d25a
ORIGIN: https://github.com/Homebrew/brew
HEAD: 586d25a5227ce565cd7e35fc5db935b245944601
Last commit: 5 hours ago
Core tap ORIGIN: https://github.com/Homebrew/linuxbrew-core
Core tap HEAD: 45ae5f7b53f0659af9f228648d9d1d8e4916d642
Core tap last commit: 17 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: :0
HOMEBREW_EDITOR: /home/linuxbrew/.linuxbrew/bin/nvim
Homebrew Ruby: 2.6.3 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/bin/ruby
CPU: quad-core 64-bit skylake
Clang: 11.1 build (parse error)
Git: 2.31.1 => /home/linuxbrew/.linuxbrew/bin/git
Curl: 7.76.0 => /home/linuxbrew/.linuxbrew/opt/curl/bin/curl
Kernel: Linux 5.4.0-70-generic x86_64 GNU/Linux
OS: elementary OS 5.1.7 Hera (hera)
Host glibc: 2.27
/usr/bin/gcc: 8.4.0
/usr/bin/ruby: 2.5.1
glibc: N/A
gcc@5: N/A
xorg: N/A

HOMEBREW_CC: gcc-10
HOMEBREW_CXX: g++-10
CMAKE_PREFIX_PATH: /home/linuxbrew/.linuxbrew
HOMEBREW_GIT: git
ACLOCAL_PATH: /home/linuxbrew/.linuxbrew/share/aclocal
PATH: /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/shims/linux/super:/home/linuxbrew/.linuxbrew/opt/binutils/bin:/usr/bin:/bin:/usr/sbin:/sbin:/home/linuxbrew/.linuxbrew/opt/gcc/bin

Expected Behavior

No response

Steps to Reproduce

/dist/working/110.99

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 283

Submitted via web form by Alek [email protected] on 2021-04-13 at 19:25:00

Keywords: architecture_not_supported

comment by Limon Lime on 2021-04-14 20:41:00 +000 UTC

Component:            Installer
                      Compilation of NLFFI
I also can repeat all steps (in MacOSX 10.15, if you need).

comment by Limon Lime on 2021-04-21 21:29:00 +000 UTC

====Linux uname -m x86_64 uname-r ====MACOSX===========
New 110.99.1:
aSame error while compiling NLFFI nlffi/lib/memory:
[parsing $c/memory/(memory.cm):mlrep-i32f64.sml]
FAILURE: stabilization of libraries failed
[[[[[[parsing $c/memory/(memory.cm):memaccess-64-little.sml]
/home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99.1/SMLNJ_HOME/nlffi/lib/memory/memory.cm:39.1-39.39 Error: architecture not supported yet
]]]]]]

Maybe you need full logs ( 00.options.out 01.install.sh.cc 01.install.sh)

/gist.github.com/d8cd35fafea51560db1cab047682042f
/gist.github.com/097fe5bcf4236871b89275127aabef70
/gist.github.com/ad845584109f5d51c6ecf6b1433ac1ec
====MACOSX (opsys DARWIN uname -r 19 uname -p i386======

I don't need that, but I repeated same steps on MacOSX10.15 and result is the same.

I don't understand the bottom line of this error, all tested platforms must be supportable,
install.sh should run without SIZE in patrameters, inspected config/_arch-n-opsys and nlffi/lib/memory/memory.cm should work fine.

comment by Limon Lime on 2021-04-21 21:33:00 +000 UTC

FIX: on the first line not the MACOSX!
uname -r 5.4.0-72-generic!

comment by Limon Lime on 2021-04-22 20:33:00 +000 UTC

I made inline replace on the line of memory.cm:
but dont know which is better LINE 39:

1st variant :(* error bla
2nd variant 
Now it fails when my little-endian system run this line of memory.cm:
memaccess-64-little.sml         (lambdasplit:infinity)

I can't go ahead here, please help with installation because it too complex for me:

[scanning $c/memory/memory.cm]
[parsing $c/memory/(memory.cm):memaccess.sig]
[creating directory /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99.1/SMLNJ_HOME/nlffi/lib/memory/.cm/SKEL]
[parsing $c/memory/(memory.cm):memalloc.sig]
[parsing $c/memory/(memory.cm):memory.sig]
[parsing $c/memory/(memory.cm):linkage.sig]
[parsing $c/memory/(memory.cm):bitop-fn.sml]
[parsing $c/memory/(memory.cm):memaccess-64-little.sml]
[parsing $c/memory/(memory.cm):memaccess-a4s2i4l4f4d8.sml]
[parsing $c/memory/(memory.cm):main-lib-unix.sml]
[parsing $c/memory/(memory.cm):memalloc-a4-unix.sml]
[parsing $c/memory/(memory.cm):memory.sml]
[parsing $c/memory/(memory.cm):linkage-dlopen.sml]
[parsing $c/memory/(memory.cm):mlrep-i32f64.sml]
[compiling $c/memory/(memory.cm):bitop-fn.sml]
[creating directory /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99.1/SMLNJ_HOME/nlffi/lib/memory/.cm/GUID]
[creating directory /home/linuxbrew/.linuxbrew/Cellar/smlnj/110.99.1/SMLNJ_HOME/nlffi/lib/memory/.cm/amd64-unix]
[code: 6057, data: 1, env: 669, inlinable: 1529 bytes]
[compiling $c/memory/(memory.cm):mlrep-i32f64.sml]
[code: 3173, data: 21, env: 3678, inlinable: 2138 bytes]
[compiling $c/memory/(memory.cm):memaccess.sig]
[code: 81, data: 1, env: 2820 bytes]
[compiling $c/memory/(memory.cm):memalloc.sig]
[code: 81, data: 1, env: 214 bytes]
[compiling $c/memory/(memory.cm):memory.sig]
[code: 81, data: 1, env: 2975 bytes]
[compiling $c/memory/(memory.cm):memaccess-64-little.sml]
nlffi/lib/memory/memaccess-64-little.sml:3.48-3.66 Error: unbound structure: RawMemInlineT in path RawMemInlineT.w32l
nlffi/lib/memory/memaccess-64-little.sml:3.20-3.38 Error: unbound structure: RawMemInlineT in path RawMemInlineT.w32l
nlffi/lib/memory/memaccess-64-little.sml:5.35-5.53 Error: unbound structure: RawMemInlineT in path RawMemInlineT.w32s
nlffi/lib/memory/memaccess-64-little.sml:5.3-5.21 Error: unbound structure: RawMemInlineT in path RawMemInlineT.w32s
FAILURE: stabilization of libraries failed

Linux Mac user who uses Homebrew you will see this error if you run brew install juplutonic/homebrew-tap/smlnj

comment by Limon Lime on 2021-04-22 20:40:00 +000 UTC

FIX: the first paragraph should be:
I made inline replacement on the line 39 of memory.cm file:
but Idont know which is better(will not fail) :
1st variant: memaccess-a4s2i4l4f4d8.sml      (lambdasplit:infinity)
2nd variant: (*# error architecture not supported yet*)

*And last paragraph should be Linux or Mac users

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.

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)

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 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 @mathias-blume on 2009-33-05 01:3300 +000 UTC

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

Build failure on macOS 10.13

Version

110.81

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

10.13

Processor

x86 (32-bit)

Component

Installation

Severity

Critical

Description of the problem

Build fails when running config/install.sh because script config/_arch-n-opsys does not recognise the macOS version 10.13 (i.e. Darwin 17).

Given that all macOS versions yield the same values of OPSYS, and given that building on macOS 10.13 works flawlessly once that obstacle is removed, I suggest the pattern matching for uname -r be remove entirely.
Fix:
Given that all macOS versions yield the same values of OPSYS, and given that building on macOS 10.13 works flawlessly once that obstacle is removed, I suggest the pattern matching for uname -r be remove entirely.

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 187

Submitted via web form by FX Coudert [email protected] on 2017-56-02 at 08:5600

Keywords: build

comment by @JohnReppy on 2017-26-01 18:2600 +000 UTC

Fixed in 110.82

SMLNJ Incompatibility with macOS 12 Beta

Version

110.9.1

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

12 beta

Processor

x86 (32-bit)

Component

Installation

Severity

Critical

Description of the problem

Hello there,

Iโ€™m in a computer science class at UNC-Chapel Hill, and we are studying SMLNJ. I am running the macOS 12 (Monterey) beta and it seems as if it is incompatible with SMLNJ. I have tried both the Homebrew installation and downloading the file directly from the website, and neither work.

I thought Iโ€™d reach out since macOS 12 will likely be released to the public in the next month or two, and you might get a number of support requests and/or many people who are unable to install SMLNJ.

Thanks so much!

Transcript

I get the following output message in the Homebrew installation:

~ % brew install smlnj
==> Caveats
To use smlnj, you may need to add the /usr/local/smlnj/bin directory
to your PATH environment variable, e.g. (for Bash shell):
  export PATH=/usr/local/smlnj/bin:"$PATH"

==> Downloading http://smlnj.cs.uchicago.edu/dist/working/110.99.1/smlnj-amd64-1
Already downloaded: /Users/hawkeyeshi/Library/Caches/Homebrew/downloads/a3dc852e914d06f4b7b60f302e266759e1434370060882a472353962236da819--smlnj-amd64-110.99.1.pkg
==> Installing Cask smlnj
==> Running installer for smlnj; your password may be necessary.
Package installers may write to any location; options such as `--appdir` are ignored.
Password:
installer: Package name is SML/NJ Version 110.99.1
installer: Installing at base path /
installer: The install failed. (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance. An error occurred while running scripts from the package โ€œsmlnj-amd64-110.99.1.pkgโ€.)
==> Purging files for version 110.99.1 of Cask smlnj
Error: Failure while executing; `/usr/bin/sudo -E -- /usr/bin/env LOGNAME=hawkeyeshi USER=hawkeyeshi USERNAME=hawkeyeshi /usr/sbin/installer -pkg /usr/local/Caskroom/smlnj/110.99.1/smlnj-amd64-110.99.1.pkg -target /` exited with 1. Here's the output:
installer: Package name is SML/NJ Version 110.99.1
installer: Installing at base path /
installer: The install failed. (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance. An error occurred while running scripts from the package โ€œsmlnj-amd64-110.99.1.pkgโ€.)

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 293

Submitted via web form by Sam Shi [email protected] on 2021-30-14 at 16:3000

Keywords: installation error

comment by @JohnReppy on 2021-40-23 00:4000 +000 UTC

Fixed for 110.99.2 (and 2021.1).

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. ~

Compile functions with redundant patterns

Version

110.82 (trunk)

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Core system

Severity

No response

Description of the problem

Hi all,

Currently, we emit an error when compling a function like this:

val x = fn x => x
| y => y

The same issue arises with top level functions.

fun f x = x
| f y = y

The ML definition states that an implementation "must" emit a warning for these (which we do, to the extent of an error). However, it also states that we "should" still compile the pattern. (See page 32, item 3, http://sml-family.org/sml97-defn.pdf)

Was it a concious design decision to reject these?

Thanks,

Jackson.

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 189

Submitted on 2017-58-19 at 14:5800

comment by @JohnReppy on 2017-26-01 18:2600 +000 UTC

The default behavior of rejecting redundant patterns as bugs can be turned off by setting the Control.MC.matchRedundantError flag to false.

Types structure from SML/NJ compiler is visible in REPL

Version

110.80

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Core system

Severity

Minor

Description of the problem

For some reason, the Types structure is visible
in the REPL environment.

Transcript

<jhr@valhalla> sml
Standard ML of New Jersey v110.80 [built: Fri Aug 19 07:49:58 2016]
- open Types;
[autoloading]
[library $smlnj/compiler/current.cm is stable]
[library $smlnj/compiler/x86.cm is stable]
[library $smlnj/viscomp/elabdata.cm is stable]
[library $smlnj/viscomp/basics.cm is stable]
[library $SMLNJ-LIB/Util/smlnj-lib.cm is stable]
[autoloading done]
opening Types
  type label = Symbol.symbol
  type polysign = bool list
  datatype eqprop = ABS | DATA | IND | NO | OBJ | UNDEF | YES
  datatype litKind = CHAR | INT | REAL | STRING | WORD
  datatype openTvKind = FLEX of (label * ty) list | META
  datatype ovldSource
    = OLIT of litKind * IntInf.int * SourceMap.region
    | OVAR of Symbol.symbol * SourceMap.region
  datatype tvKind
    = INSTANTIATED of ty
    | LBOUND of {depth:int, eq:bool, index:int}
    | OPEN of {depth:int, eq:bool, kind:openTvKind}
    | OVLD of {options:ty list, sources:ovldSource list}
    | UBOUND of {depth:int, eq:bool, name:Symbol.symbol}
  datatype tycpath
    = TP_APP of tycpath * tycpath list
    | TP_FCT of tycpath list * tycpath list
    | TP_SEL of tycpath * int
    | TP_TYC of tycon
    | TP_VAR of exn
  datatype tyckind
    = ABSTRACT of tycon
    | DATATYPE of {family:dtypeFamily, freetycs:tycon list, index:int,
                   root:Stamps.stamp option, stamps:Stamps.stamp vector}
    | FLEXTYC of tycpath
    | FORMAL
    | PRIMITIVE of int
    | TEMP
  datatype tycon
    = DEFtyc of {path:?.InvPath.path, stamp:Stamps.stamp, strict:bool list,
                 tyfun:tyfun}
    | ERRORtyc
    | FREEtyc of int
    | GENtyc of gtrec
    | PATHtyc of {arity:int, entPath:?.EntPath.entPath, path:?.InvPath.path}
    | RECORDtyc of label list
    | RECtyc of int
  datatype ty
    = CONty of tycon * ty list
    | IBOUND of int
    | MARKty of ty * SourceMap.region
    | POLYty of {sign:polysign, tyfun:tyfun}
    | UNDEFty
    | VARty of tyvar
    | WILDCARDty
  datatype tyfun = TYFUN of {arity:int, body:ty}
  type dconDesc =
    {domain:Types.ty option, name:Symbol.symbol, rep:Access.conrep}
  type dtmember =
    {arity:int, dcons:Types.dconDesc list, eq:Types.eqprop ref, lazyp:bool,
     sign:Access.consig, tycname:Symbol.symbol}
  type dtypeFamily =
    {members:Types.dtmember vector, mkey:Stamps.stamp,
     properties:PropList.holder}
  type stubinfo = {lib:bool, owner:PersStamps.persstamp}
  type gtrec =
    {arity:int, eq:Types.eqprop ref, kind:Types.tyckind, path:?.InvPath.path,
     stamp:Stamps.stamp, stub:stubinfo option}
  type tyvar = Types.tvKind ref
  val infinity : int
  val mkTyvar : tvKind -> tyvar
  val copyTyvar : tyvar -> tyvar
  datatype datacon
    = DATACON of {const:bool, lazyp:bool, name:Symbol.symbol,
                  rep:Access.conrep, sign:Access.consig, typ:ty}
-

Expected Behavior

No response

Steps to Reproduce

from REPL

  open Types;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 171

Submitted via web form by John Reppy [email protected] on 2016-10-24 at 01:00:00

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 handling large reals

Version

110.82 (trunk)

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

x86 (32-bit)

Component

Core system

Severity

Minor

Description of the problem

Hi all,

Currently, on input of reals out of the accepted range, SMLNJ crashes:

val x = 1e1000;;

Produces:

unexpected exception (bug?) in SML/NJ: BadReal [BadReal]
raised at: ../compiler/MiscUtil/bignums/realconst.sml:237.54-237.63
../compiler/Basics/stats/stats.sml:198.40
../compiler/Basics/stats/stats.sml:198.40
../compiler/TopLevel/interact/evalloop.sml:45.54

This happens in interactive sessions. When opening files, the assignments are ignored.

Thanks,

Jackson.

Transcript

No response

Expected Behavior

No response

Steps to Reproduce

val x = 1e1000000

Additional Information

No response

Email address

No response

Comments from smlnj-gforge

Original smlnj-gforge bug number 191

Submitted on 2017-39-01 at 20:3900

comment by @JohnReppy on 2017-15-01 21:1500 +000 UTC

We can fix this problem as part of the literal-representation overhaul. Currently, real literals are being represented as strings until code generation, which is too late to gracefully catch and handle this problem.

comment by @JohnReppy on 2018-31-20 15:3100 +000 UTC

Fixed for 110.83.

Executable Stack on Linux

Version

110.80

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Installation

Severity

Minor

Description of the problem

Hi,

bin/.run/run.x86-linux and bin/.run/run.x86-linux.so currently have the stack set to executable.

A number of Linux distributions (Fedora, Ubuntu, Gentoo) are trying to reduce the use of executable stack for security reasons. Here is a good summary: https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart

I do not believe that smlnj needs the stack to be executable, but I may be wrong. Editing the binary by hand to make the stack unexecutable (by calling execstack -c bin/.run/run.x86-linux*) produced no regressions in the tests/ directory of SVN trunk.

I am not an expert in these matters, and so it's not totally clear to me what is causing the stack to be marked executable. So there may be a reason for it that doesn't come up in the tests or that I didn't notice in glancing through the code.
Fix:
If executable stack is in fact not needed and is the result of unmarked assembly code, there are two ways to fix it: https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart#How_to_fix_the_stack_.28in_practice.29

The first is to add the appropriate stack markings (see previous link).

The second is to compile with -Wa,--noexecstack

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 175

Submitted via web form by Daniel Moerner [email protected] on 2017-46-08 at 21:4600

comment by @JohnReppy on 2017-53-09 17:5300 +000 UTC

Fixed for 110.81 on x86 and PPC architectures (those are the only Linux targets that we currently support).

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

Signals are not delivered for corresponding events

Version

110.85/110.98.1

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

other Windows 10

Processor

x86 (32-bit)

Component

Other

Severity

Major

Description of the problem

No sigALRM nor sigGC will be delivered to installed handlers,
when an interval timer is set by "setIntTimer" or
garbage collection is enforced by "doGC".

The behavior is the same in 110.85 for Windows 10 (pasted as
atranscript), 110.98.1 (both the 32/64 version) for Linux.
Additional comments:
As for sigGC, it has been reported in #81 (gforge bug 65).

Transcript

Standard ML of New Jersey v110.85 [built: Fri Dec 21 20:19:39 2018]
- open Signals
= open SMLofNJ.IntervalTimer
= open SMLofNJ.Internals.GC;
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[library $SMLNJ-BASIS/(basis.cm):basis-common.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
opening SMLofNJ.IntervalTimer
  val tick : unit -> Time.time
  val setIntTimer : Time.time option -> unit
opening SMLofNJ.Internals.GC
  val doGC : int -> unit
  val messages : bool -> unit
-
- fun laterSec x = let open Time in now() + fromSeconds x end ;
val laterSec = fn : IntInf.int -> Time.time
- fun prt x = (TextIO.output(TextIO.stdOut,x); TextIO.flushOut TextIO.stdOut);
[autoloading]
[autoloading done]
val prt = fn : TextIO.vector -> unit
-
- val _ = setHandler (sigALRM, HANDLER(fn z => (prt "tm";#3 z)  )) ;
- val _ = setHandler (sigGC  , HANDLER(fn z => (prt "gc";#3 z)  )) ;
-
- unmaskSignals (MASK [sigALRM, sigGC]);
val it = () : unit
-
- val _ = setIntTimer (SOME (laterSec 10));  (* nothing will happen *)
- val _ = doGC 10; (* also nothing happens *)
tm-
-

Expected Behavior

No response

Steps to Reproduce

open Signals
open SMLofNJ.IntervalTimer
open SMLofNJ.Internals.GC;

fun laterSec x = let open Time in now() + fromSeconds x end ;
fun prt x = (TextIO.output(TextIO.stdOut,x); TextIO.flushOut TextIO.stdOut);

val _ = setHandler (sigALRM, HANDLER(fn z => (prt "tm";#3 z)  )) ;
val _ = setHandler (sigGC  , HANDLER(fn z => (prt "gc";#3 z)  )) ;

unmaskSignals (MASK [sigALRM, sigGC]);

val _ = setIntTimer (SOME (laterSec 10));  (* nothing will happen *)
val _ = doGC 10; (* also nothing happens *)

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 291

Submitted via web form by Masaya Saito [email protected] on 2021-08-15 at 11:18:00

Keywords: structure Signals

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

Also see issue #81 (gforge bug 65)

comment by @JohnReppy on 2022-06-27 15:44:00 +000 UTC

I was not able to reproduce the problem with sigALRM (it works for me), but support for sigGC has been added in 110.99.3 and 2022.1.

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

ml-ulex writing debug messages to stdOut

Version

110.79

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

Hi, my makefiles are a bit wacky,

as i've been both
a) automatic depenency generation,
b) generation of mlton mlb files from sources.cm

this tends to work ok, but when using
c) generated sources

we need to c -> b -> a to generate the dependency graph...
with ml-ulex debug output has been ending up in the mlb file.
Additional comments:
fix refers to the file ml-ulex/main.sml
changing the debug function to write to stderr

Sorry I don't have a minimal reproducer at the moment,
I'm guessing it should reproduce by running the Mlton cm2mlb
on lex using project

Fix:
fun debug s =
let val fd = TextIO.stdErr;
(* Flush probably unecessary *)
fun printerr s = (TextIO.output (fd, s); TextIO.output (fd, "\n"); TextIO.flushOut fd);
in printerr s end

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 179

Submitted via web form by matt rice [email protected] on 2017-13-16 at 05:1300

comment by @JohnReppy on 2017-48-07 17:4800 +000 UTC

Fixed for 110.81

Word8.toLargeInt is broken

Version

110.96

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

other Windows 10

Processor

x86 (32-bit)

Component

Basis Library

Severity

Major

Description of the problem

Word8.toLargeInt produces badly incorrect answers.

Transcript

- Word8.toLargeInt 0w0;
val it = 128321952 : IntInf.int

Expected Behavior

No response

Steps to Reproduce

Word8.toLargeInt 0w0;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 285

Submitted via web form by Karl Crary [email protected] on 2021-53-07 at 14:5300

Keywords: IntInf

comment by @JohnReppy on 2021-37-01 19:3700 +000 UTC

Fixed in more recent versions.

OS.Process.sleep only works with whole numbers

Version

110.80

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

10.12.2

Processor

No response

Component

Basis Library

Severity

Major

Description of the problem

val dt = Time.fromReal(1.5);
OS.Process.sleep(dt)
Is supposed to sleep for 1.5 seconds, whereas it only does so for 1.

In general, all real-valued times supplied to sleep are floored to the smaller integer.

Transcript

Standard ML of New Jersey v110.80 [built: Fri Aug 19 07:49:58 2016]
- [autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[library $SMLNJ-BASIS/(basis.cm):basis-common.cm is stable]
[autoloading done]
val dt = TIME {usec=1750000} : Time.time
[autoloading]
[autoloading done]
1484257107.91
1484257108.92
1484257109.92
1484257110.92
1484257111.92
1484257112.92
1484257113.93
1484257114.93
^C
Interrupt
-

Expected Behavior

No response

Steps to Reproduce

val dt = Time.fromReal(1.6);
while true do (
print (Real.toString(Time.toReal(Time.now())) ^ "\n");
OS.Process.sleep(dt)
);

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 173

Submitted via web form by Leonid Zlotnikov [email protected] on 2017-39-12 at 21:3900

Keywords: OS Process sleep real int

comment by @JohnReppy on 2017-00-12 22:0000 +000 UTC

OS.Process.sleep is just a wrapper around Posix.Process.sleep, which maps onto the sleep(3) function that only sleeps integral units of time. Since the POSIX standard now has functions like usleep and nano-sleep, we should probably be using those in the Posix.Process implementation. ~ ~ I'm not sure what the story for Windows is. ~

comment by @JohnReppy on 2017-39-18 17:3900 +000 UTC

We've decided to fix this bug by changing the semantics of Posix.Process.sleep() to use the most precise version of sleep/usleep/nanosleep that is available. This change will require changing the runtime-system API for sleep (which currently expects an integer number of seconds as the argument to sleep). ~ ~ Also, the Posix.Process.alarm() function should receive a similar treatment, since recent versions os Posix also have ualarm().

comment by @JohnReppy on 2019-43-24 14:4300 +000 UTC

For systems that have the nanosleep(2) system call (and Windows), the sleep function supports sub-second resolution in 110.93.

Install errors with `request asdl`

Version

110.99.1

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Installation

Severity

Minor

Description of the problem

When request asdl is enabled (which is the default for a UNIX
platform), install fails during the asdl build step due to not
being able to find ml-ulex and ml-antlr.
Additional comments:
I encountered the error on a fresh Fedora Linux machine which
had not previous SML/NJ versions installed (and, in particular,
had no ml-ulex or ml-antlr on PATH).

It seems that the freshly built ml-ulex and ml-antlr tools are
not added to PATH for the asdlgen build.

Using #request asdl in config/targets allows the install to
complete successfully.

Transcript

Building asdlgen.
/home/matthew/devel/smlnj/smlnj-110.99.1/asdl/src/gen/fragments/mkmk.sh back-end/sml
/home/matthew/devel/smlnj/smlnj-110.99.1/asdl/src/gen/fragments/mkfrags.sh back-end/sml
touch .depend
/home/matthew/devel/smlnj/smlnj-110.99.1/bin/ml-makedepend -64 -n -f .depend driver/sources.cm /home/matthew/devel/smlnj/smlnj-110.99.1/asdl/src/asdlgen/asdlgen.amd64-linux || rm -f .depend
Standard ML of New Jersey (64-bit) v110.99.1 [built: Wed Jun 30 09:32:37 2021]
[opening 17466-mlscript.sml]
[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]
[library $SMLNJ-BASIS/(basis.cm):basis-common.cm is stable]
[autoloading done]
[scanning driver/sources.cm]
[scanning driver/(sources.cm):../common/sources.cm]
[scanning driver/(sources.cm):../common/(sources.cm):../ast/sources.cm]
[parsing driver/(sources.cm):../common/(sources.cm):../ast/(sources.cm):ast.sml]
[creating directory ast/.cm/SKEL]
[parsing driver/(sources.cm):../common/(sources.cm):../ast/(sources.cm):ident-fn.sml]
[parsing driver/(sources.cm):../common/(sources.cm):../ast/(sources.cm):prim-types.sml]
[library $SMLNJ-LIB/Util/smlnj-lib.cm is stable]
[parsing driver/(sources.cm):../common/(sources.cm):config.sml]
[creating directory common/.cm/SKEL]
[parsing driver/(sources.cm):../common/(sources.cm):options.sml]
[scanning driver/(sources.cm):../front-end/sources.cm]
[library $/pp-lib.cm is stable]
[scanning driver/(sources.cm):../front-end/(sources.cm):common/sources.cm]
[library $/ml-lpt-lib.cm is stable]
[parsing driver/(sources.cm):../front-end/(sources.cm):common/(sources.cm):error.sml]
[creating directory front-end/common/.cm/SKEL]
[scanning driver/(sources.cm):../front-end/(sources.cm):parser/sources.cm]
[parsing driver/(sources.cm):../front-end/(sources.cm):parser/(sources.cm):parse-tree.sml]
[creating directory front-end/parser/.cm/SKEL]
[parsing driver/(sources.cm):../front-end/(sources.cm):parser/(sources.cm):parser.sml]
[attempting to load plugin $/ml-antlr-tool.cm]
[library $/ml-antlr-tool.cm is stable]
[library $smlnj/cm/tools.cm is stable]
[library $smlnj/internal/cm-lib.cm is stable]
[plugin $/ml-antlr-tool.cm loaded successfully]
["ml-antlr"  "asdl.grm"]
sh: line 1: ml-antlr: command not found
front-end/parser/sources.cm:23.3-23.11 Error: tool "ML-Antlr" failed: "ml-antlr"  "asdl.grm"
[attempting to load plugin $/ml-ulex-tool.cm]
[library $/ml-ulex-tool.cm is stable]
[plugin $/ml-ulex-tool.cm loaded successfully]
["ml-ulex"  "asdl.lex"]
sh: line 1: ml-ulex: command not found
front-end/parser/sources.cm:24.3-24.11 Error: tool "ML-ULex" failed: "ml-ulex"  "asdl.lex"
[parsing driver/(sources.cm):../front-end/(sources.cm):front-end.sml]
[creating directory front-end/.cm/SKEL]
[parsing driver/(sources.cm):main.sml]
[creating directory driver/.cm/SKEL]
/home/matthew/devel/smlnj/smlnj-110.99.1/bin/ml-makedepend: CM dependency analysis failed
touch .depend
/home/matthew/devel/smlnj/smlnj-110.99.1/bin/ml-makedepend -64 -n -f .depend driver/sources.cm /home/matthew/devel/smlnj/smlnj-110.99.1/asdl/src/asdlgen/asdlgen.amd64-linux || rm -f .depend
Standard ML of New Jersey (64-bit) v110.99.1 [built: Wed Jun 30 09:32:37 2021]
[opening 17489-mlscript.sml]
[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]
[library $SMLNJ-BASIS/(basis.cm):basis-common.cm is stable]
[autoloading done]
[scanning driver/sources.cm]
[scanning driver/(sources.cm):../common/sources.cm]
[scanning driver/(sources.cm):../common/(sources.cm):../ast/sources.cm]
[library $SMLNJ-LIB/Util/smlnj-lib.cm is stable]
[scanning driver/(sources.cm):../front-end/sources.cm]
[library $/pp-lib.cm is stable]
[scanning driver/(sources.cm):../front-end/(sources.cm):common/sources.cm]
[library $/ml-lpt-lib.cm is stable]
[scanning driver/(sources.cm):../front-end/(sources.cm):parser/sources.cm]
[attempting to load plugin $/ml-antlr-tool.cm]
[library $/ml-antlr-tool.cm is stable]
[library $smlnj/cm/tools.cm is stable]
[library $smlnj/internal/cm-lib.cm is stable]
[plugin $/ml-antlr-tool.cm loaded successfully]
["ml-antlr"  "asdl.grm"]
sh: line 1: ml-antlr: command not found
front-end/parser/sources.cm:23.3-23.11 Error: tool "ML-Antlr" failed: "ml-antlr"  "asdl.grm"
[attempting to load plugin $/ml-ulex-tool.cm]
[library $/ml-ulex-tool.cm is stable]
[plugin $/ml-ulex-tool.cm loaded successfully]
["ml-ulex"  "asdl.lex"]
sh: line 1: ml-ulex: command not found
front-end/parser/sources.cm:24.3-24.11 Error: tool "ML-ULex" failed: "ml-ulex"  "asdl.lex"
/home/matthew/devel/smlnj/smlnj-110.99.1/bin/ml-makedepend: CM dependency analysis failed
/home/matthew/devel/smlnj/smlnj-110.99.1/bin/ml-build -64 driver/sources.cm Main.main asdlgen
Standard ML of New Jersey (64-bit) v110.99.1 [built: Wed Jun 30 09:32:37 2021]
[scanning driver/sources.cm]
[scanning driver/(sources.cm):../common/sources.cm]
[scanning driver/(sources.cm):../common/(sources.cm):../ast/sources.cm]
[library $SMLNJ-BASIS/basis.cm is stable]
[library $SMLNJ-BASIS/(basis.cm):basis-common.cm is stable]
[library $SMLNJ-LIB/Util/smlnj-lib.cm is stable]
[scanning driver/(sources.cm):../front-end/sources.cm]
[library $/pp-lib.cm is stable]
[scanning driver/(sources.cm):../front-end/(sources.cm):common/sources.cm]
[library $/ml-lpt-lib.cm is stable]
[scanning driver/(sources.cm):../front-end/(sources.cm):parser/sources.cm]
[attempting to load plugin $/ml-antlr-tool.cm]
[library $/ml-antlr-tool.cm is stable]
[library $smlnj/cm/tools.cm is stable]
[library $smlnj/internal/cm-lib.cm is stable]
[plugin $/ml-antlr-tool.cm loaded successfully]
["ml-antlr"  "asdl.grm"]
sh: line 1: ml-antlr: command not found
front-end/parser/sources.cm:23.3-23.11 Error: tool "ML-Antlr" failed: "ml-antlr"  "asdl.grm"
[attempting to load plugin $/ml-ulex-tool.cm]
[library $/ml-ulex-tool.cm is stable]
[plugin $/ml-ulex-tool.cm loaded successfully]
["ml-ulex"  "asdl.lex"]
sh: line 1: ml-ulex: command not found
front-end/parser/sources.cm:24.3-24.11 Error: tool "ML-ULex" failed: "ml-ulex"  "asdl.lex"
Compilation failed.
make: *** [Makefile:84: /home/matthew/devel/smlnj/smlnj-110.99.1/asdl/src/asdlgen/asdlgen.amd64-linux] Error 1
FAILURE: Building asdlgen failed.
./config/install.sh: !!! Installation of libraries and programs failed.

Expected Behavior

No response

Steps to Reproduce

$ ./config/install.sh -default 64

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 287

Submitted via web form by Matthew Fluet [email protected] on 2021-58-30 at 13:5800

comment by @JohnReppy on 2021-42-23 00:4200 +000 UTC

This bug has been fixed for 110.99.2 (and 1021.1) by adding the generated SML files for the scanner and parser to the repository.

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)

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

Bogus "Left recursion" error message from ML-Antlr

Version

110.80

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Command-line tool

Severity

Major

Description of the problem

ML-Antlr reports a left recursion, where there is no such
problem. There is a problem that the grammar is not LL(k)
and it appears that the generated parser may not work on
valid input.
Additional comments:
It looks like the generated parser would fail on the input

if X then skip

because the function for the E nonterminal fails if the
first token is not "else".

Transcript

<jhr@dhcp-10-135-11-128> ml-antlr dangling-else.grm
[ml-antlr: parsing dangling-else.grm]
[ml-antlr: checking grammar]
 2 nonterminals
 4 productions
Left recursion detected: E -> E ...

Expected Behavior

No response

Steps to Reproduce

%token
  : IF		("if")
  | THEN	("then")
  | ELSE	("else")
  | SKIP	("skip")
  | ID
  ;

%start S;

S	: "if" ID "then" S E
	| "skip"
	;

E	: "else" S
	| (* empty *)
	;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 170

Submitted via web form by John Reppy [email protected] on 2016-10-13 at 17:48:00

Keywords: ml-lpt

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)

Manpages

Version

110.80

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Installation

Severity

Cosmetic

Description of the problem

Hi,

smlnj is missing a number of man pages for its binaries. Several have been in Debian for a long time, and I just wrote brief ones for heap2asm and heap2exec. There are now manpages for all executables shipped by smlnj.

https://pagure.io/smlnj-packaging/raw/master/f/heap2asm.1
https://pagure.io/smlnj-packaging/raw/master/f/heap2exec.1
https://pagure.io/smlnj-packaging/raw/master/f/ml-burg.1
https://pagure.io/smlnj-packaging/raw/master/f/ml-lex.1
https://pagure.io/smlnj-packaging/raw/master/f/ml-nlffigen.1
https://pagure.io/smlnj-packaging/raw/master/f/ml-yacc.1
https://pagure.io/smlnj-packaging/raw/master/f/nowhere.1

I wanted to share them in case you wanted to add them to the doc tarball.

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 176

Submitted via web form by Daniel Moerner [email protected] on 2017-01-08 at 22:0100

Keywords: doc

comment by @JohnReppy on 2017-34-28 14:3400 +000 UTC

Manpages exist as part of the "doc" tree, although some of the commands are missing manpages (e.g., nowhere, ml-nlffigen).

comment by @JohnReppy on 2020-48-02 17:4800 +000 UTC

I've added manual pages to the doc/src/man directory for ml-burg, ml-lex, ml-nlffigen, and ml-yacc. The other programs are currently not part of the standard install, so they are omitted for now.

Error in register allocation

Version

v110.99

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

5.10.11-arch1-1

Processor

x86 (32-bit)

Component

Core system

Severity

Major

Description of the problem

The following code causes an issue in, I believe, register allocation, manifesting as a uncaught exception and the message "Error: MLRisc bug: RegisterAllocator.chooseVictim".
Additional comments:
I wasn't able to find severity guidelines, so sorry if this is mislabeled.

Transcript

Standard ML of New Jersey (64-bit) v110.99 [built: Thu Dec 31 00:05:14 2020]
fun foo ([], []) = foo ([], []) ^ "A"
  | foo (_, _) = foo ([], []) ^ "A";
=========== K=12 ===========
1[1] <-->
2[2] <-->
3[3] <-->
5[5] <-->
6[6] <-->
8[8] <-->
9[9] <-->
10[10] <-->
512r <--> 10[10] 9[9] 8[8] 6[6] 5[5] 3[3] 2[2] 1[1]
513a => 514r
514r <--> 10[10] 9[9] 8[8] 6[6] 5[5] 3[3] 2[2] 1[1]
515r <--> 10[10] 6[6] 5[5] 516r 517r 518r 519r 520r 521r 3[3] 2[2] 1[1]
516r <--> 10[10] 5[5] 517r 518r 519r 520r 521r 523r 531 530 515r 3[3] 2[2] 1[1]
517r <--> 10[10] 518r 519r 520r 521r 523r 531 530 524 5[5] 516r 515r 2[2] 1[1]
518r <--> 10[10] 519r 520r 521r 523r 531 530 524 525 517r 5[5] 516r 515r 2[2]
519r <--> 10[10] 520r 521r 523r 531 530 524 525 526 518r 517r 5[5] 516r 515r
520r <--> 10[10] 521r 523r 531 530 524 525 526 527 519r 518r 517r 516r 515r
521r <--> 523r 531 530 524 525 526 527 528 520r 519r 518r 517r 516r 515r
523r <--> 531 521r 520r 519r 518r 517r 516r
524 <--> 557r 525 526 527 528 529a 530 531 521r 9[9] 8[8] 520r 519r 518r 6[6] 517r 5[5] 3[3] 2[2]
525 <--> 540r 539r 536r 535r 544r 546r 545r 549r 551r 550r 554r 556r 555r 526 527 528 529a 530 531 533r 524 521r 9[9] 8[8] 520r 519r 518r 6[6] 5[5] 3[3] 2[2]
526 <--> 540r 539r 536r 558a 1[1] 544r 546r 545r 549r 551r 550r 554r 556r 555r 527 528 529a 530 531 533r 534r 525 524 521r 9[9] 8[8] 520r 519r 6[6] 5[5] 3[3]
527 <--> 540r 539r 558a 1[1] 2[2] 544r 546r 545r 549r 551r 550r 554r 556r 555r 528 529a 530 531 533r 534r 535r 526 525 524 521r 9[9] 8[8] 520r 6[6] 5[5]
528 <--> 558a 1[1] 2[2] 3[3] 544r 546r 545r 549r 551r 550r 554r 556r 555r 529a 530 531 533r 534r 535r 536r 527 526 525 524 521r 9[9] 8[8] 6[6]
529a => 6[6]
530 <--> 540r 558a 1[1] 2[2] 3[3] 5[5] 6[6] 544r 546r 545r 549r 551r 550r 554r 556r 555r 531 533r 534r 535r 536r 537r 538r 529a 528 527 526 525 524 521r 9[9] 520r 519r 518r 517r 516r
531 <--> 558a 1[1] 2[2] 3[3] 5[5] 6[6] 8[8] 544r 546r 545r 549r 551r 550r 554r 556r 555r 533r 534r 535r 536r 537r 538r 539r 530 529a 528 527 526 525 524 523r 521r 520r 519r 518r 517r 516r
533r <--> 6[6] 534r 535r 536r 537r 538r 539r 540r 531 530 529a 528 527 526 525
534r <--> 535r 536r 537r 538r 539r 540r 533r 531 530 529a 528 527 526
535r <--> 6[6] 552r 547r 536r 537r 538r 539r 540r 542r 525 534r 533r 531 530 529a 528 527
536r <--> 6[6] 552r 547r 537r 538r 539r 540r 542r 525 526 535r 534r 533r 531 530 529a 528
537r <--> 538r 539r 540r 536r 535r 534r 533r 531 530 529a
538r <--> 539r 540r 537r 536r 535r 534r 533r 531 530
539r <--> 552r 547r 540r 542r 525 526 527 538r 537r 536r 535r 534r 533r 531
540r <--> 552r 547r 542r 525 526 527 530 539r 538r 537r 536r 535r 534r 533r
542r <--> 540r 539r 536r 535r
544r <--> 546r 545r 531 530 529a 528 527 526 525
545r <--> 544r 531 530 529a 528 527 526 525
546r <--> 544r 531 530 529a 528 527 526 525
547r <--> 540r 539r 536r 535r
549r <--> 551r 550r 531 530 529a 528 527 526 525
550r <--> 549r 531 530 529a 528 527 526 525
551r <--> 549r 531 530 529a 528 527 526 525
552r <--> 540r 539r 536r 535r
554r <--> 556r 555r 531 530 529a 528 527 526 525
555r <--> 554r 531 530 529a 528 527 526 525
556r <--> 554r 531 530 529a 528 527 526 525
557r <--> 524 9[9] 8[8] 6[6] 5[5] 3[3] 2[2]
558a => 1[1]
560r <--> 9[9] 8[8] 6[6] 5[5] 3[3] 2[2] 1[1]
561r <--> 563r 562a 9[9] 8[8] 6[6] 5[5] 3[3] 2[2] 1[1]
562a => 563r
563r <--> 561r 9[9] 8[8] 6[6] 5[5] 3[3] 2[2] 1[1]
Spill candidates:
515r 516r 517r 518r 519r 520r 531 524 525 526 527 528 530
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/TopLevel/interact/evalloop.sml:45.54
-

Expected Behavior

No response

Steps to Reproduce

fun foo ([], []) = foo ([], []) ^ "A"
| foo (_, _) = foo ([], []) ^ "A"

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 282

Submitted via web form by Cooper Pierce [email protected] on 2021-11-28 at 07:1100

comment by @JohnReppy on 2022-08-01 23:0800 +000 UTC

Given that the MLRisc code generator will be going away, it is not worth the effort to diagnose and fix this problem. The example does compile under 2021.1.

Compiler bug: Contract: UsageMap on 132

Version

110.99

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

10.15.7

Processor

x86 (32-bit)

Component

Core system

Severity

Major

Description of the problem

The following code snippet produces:
Compiler bug: Contract: UsageMap on 132.

Transcript

$ cat > valia.sml << EOF
fun g (l, a, b, x, y, d0, d1 : real, d2 : real, d3 : real) = (
    x - Real.fromInt(Array.sub(l, a));
    y - Real.fromInt(Array.sub(l, b))
)
EOF

$ sml valia.sml
Standard ML of New Jersey (64-bit) v110.99 [built: Thu Dec 24 11:47:23 2020]
[opening valia.sml]
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[library $SMLNJ-BASIS/(basis.cm):basis-common.cm is stable]
[autoloading done]
Error: Compiler bug: Contract: UsageMap on 132
****** pass1 ******
 v129(v130[PV]) =
    v129("bogus")
 v101(v131[PV]) =
    v129("bogus")
 v91.1 -> v93[PV]
 v12(v103[C],v96[PR1]) =
    v1(v104[C],v80[PV],v81[I],v82[I],v83[R64],v84[R64],v86[R64],v87[R64],v133[PR2]) =
       v132.0 -> v88[R64]
       v133.0 -> v132[PF1]
       v133.1 -> v85[PV]
       length(v80) -> v46[I]
       v118(v105[I]) =
          real63_64(v105) -> v43[R64]
          length(v80) -> v59[I]
          v107(v106[I]) =
             real63_64(v106) -> v56[R64]
             subf64(v84,v56) -> v55[R64]
             v104(v55)
          if u63<(v82,v59) [v108] then
             subscript(v80,v82) -> v60[I]
             v107(v60)
          else
             {v93,(I63t)0,(I63t)0} -> v98
             v98.0 -> v110[PV]
             v98.1 -> v111[PV]
             v98.2 -> v112[PV]
             {"valia.sml:3.22-3.31",v112} -> v114
             {v110,v111,v114} -> v113
             gethdlr() -> v117[FN]
             v117(v101,v113)
       if u63<(v81,v46) [v119] then
          subscript(v80,v81) -> v47[I]
          v118(v47)
       else
          {v93,(I63t)0,(I63t)0} -> v97
          v97.0 -> v121[PV]
          v97.1 -> v122[PV]
          v97.2 -> v123[PV]
          {"valia.sml:2.22-2.31",v123} -> v125
          {v121,v122,v125} -> v124
          gethdlr() -> v128[FN]
          v128(v101,v124)
    v103(v1)
 {v12} -> v89
 v102(v89)

Expected Behavior

No response

Steps to Reproduce

fun g (l, a, b, x, y, d0, d1 : real, d2 : real, d3 : real) = (
    x - Real.fromInt(Array.sub(l, a));
    y - Real.fromInt(Array.sub(l, b))
)

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 284

Submitted via web form by Nikolaos S. Papaspyrou [email protected] on 2021-04-18 at 19:22:00

comment by @JohnReppy on 2022-05-31 17:04:00 +000 UTC

It looks like this bug is in the CPSTrans module (CPS/convert/cpstrans.sml), which is producing bogus CPS IR.

comment by @JohnReppy on 2022-06-01 15:58:00 +000 UTC

Fixed for 110.99.3 and 2022.1

[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)

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.

Bug in handling of long options in GetOpt

Version

110.79

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

SML/NJ Library

Severity

Minor

Description of the problem

The GetOpt module does not support long options, where one flag
is a prefix of another (e.g., "--log" and "--log-x").

Transcript

- opts();

uncaught exception Fail [Fail: option `--log' is ambiguous; could be one of:
    --log
    --log-x
]
  raised at: stdIn:21.31-21.37

Expected Behavior

No response

Steps to Reproduce

val opts = GetOpt.getOpt {
argOrder = GetOpt.RequireOrder,
options = [
{short = "", long = ["log"], desc = GetOpt.NoArg(fn () => print "log\n"), help = ""},
{short = "", long = ["log-x"], desc = GetOpt.NoArg(fn () => print "logx\n"), help = ""}
],
errFn = fn s => raise Fail s
} ["--log", "foo"];

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 167

Submitted via web form by John Reppy [email protected] on 2016-44-03 at 13:4400

comment by @JohnReppy on 2016-52-03 13:5200 +000 UTC

Fixed in 110.80

Incorrect implementation of pattern matching for exceptions

Version

110.99.1

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

Any

Component

Core system

Severity

Minor

Description of the problem

The example comes from the coresml regression tests (test d001a-ac.sml).

With FLINT printing on, we see the source of the problem is that the order of cases has changed (B appears before A): For exception constructors, which can be aliases, this change results in incorrect behavior.

[After Translate ...]

FN(v85:
STR([TYC(TCAP(PRIM(ETG), [{}])),TYC(TCAP(PRIM(ETG), [{}])),
TYC(TCAP(PRIM(ETG), [{}]))]),
v73 = v85[0]
v72 = v85[1]
v74 = v85[2]
v70 =
v71 =
CON((B,EXNLVAR(72),TYC(AR[rr]([{}], [PRIM(EXN)]))), [],
RCD())
v75 = FN(v76: TYC({}),(I63)1)
v77 = FN(v78: TYC({}),(I63)2)
v79 = FN(v80: TYC({}),(I63)3)
v81 =
FN(v82:
TYC({}),
RAISE(TYC(PRIM(I63)),
APP(PRM(markexn,
TYC(AR[rr]([PRIM(EXN),PRIM(STR)],
[PRIM(EXN)])), []),
RCD(CON((Match,EXNLVAR(74),TYC(AR[rr]([{}],
[PRIM(EXN)]))), [], RCD()),
"stdIn:4.36"))))
SWIv71
of B.v83 => APP(v77, RCD())
A.v84 => APP(v75, RCD())
_ => APP(v79, RCD())
SRCD(v70))

Transcript

<jhr@Froh> sml
Standard ML of New Jersey (64-bit) v110.99.1 [built: Mon Apr 12 18:45:14 2021]
- exception A;
exception A
- exception B = A;
exception B = A
- (case B of A => 1 | B => 2 | _ => 3);
val it = 2 : int

Expected Behavior

No response

Steps to Reproduce

exception A;
exception B = A;
(case B of A => 1 | B => 2 | _ => 3);

Additional Information

No response

Email address

No response

Comments from smlnj-gforge

Original smlnj-gforge bug number 290

Submitted on 2021-57-10 at 20:5700

Keywords: pattern matching, exceptions

comment by @dmacqueen on 2021-06-10 03:0600 +000 UTC

A spurious "rev" operation in the SWITCHexp case of Translate.mkExp was removed, which restored the proper order of rules in the example (the A => rule ~ now comes first. However, this was not enough to fix the bug. Deeper analysis of the issues around identity exception declarations will be required.

comment by @dmacqueen on 2022-23-17 19:2300 +000 UTC

The mkExp rule transposition problem still applies the the legacy branch, but with the new match compiler, the bug persisted. The fix is to suppress the SWITCH contraction (FLINT/opt/lcontract.sml: swiInfo; FLINT/opt/fcontract.sml: fcSwitch) when the subject is an exception constructor, because these functions use equality of conreps to identify the exception constructor, which is not correct when one of the exceptions is defined by an exception identity declaration as in the bug test case. The bug remains open in the legacy branch.

Broken link to tutorial on web page

Version

No response

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Other

Severity

Major

Description of the problem

The first link on the web page listing SML tutorials is now a 404.
From the web archive it looks like this happened in 2016.

I'm referring to the link on this page to Robert Harper's book:

http://www.smlnj.org/doc/literature.html#tutorials

Looks like it should be changed to point here instead of /smlbook/:

http://www.cs.cmu.edu/~rwh/isml/

Setting severity 'Major', because this is the first thing I found
when considering relearning SML, which isn't ideal :-)

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 172

Submitted via web form by Geoff Richards [email protected] on 2017-36-10 at 17:3600

Keywords: documentation

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)

status code returned by sml REPL

Version

110.81

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 status code returned by the sml REPL changed between 110.79 and
110.81. Previously, if I gave a filename on the command line and it
had a compilation error, sml would return a non-zero status code.

Now, in 110.81, it just issues the error and prints another prompt. If
I specify </dev/null on the command line then sml exits, but the
status code is zero despite the error.

This is causing a problem in the build scripts for my qcheck library,
which aims to be usable with every implementation of SML. Its build
script tries to check which basis libraries are available, and it
relied on the status code described above.

The bug report to qcheck is at
league/qcheck#5 (comment)

If this change in behavior is intentional with a meaningful rationale,
then fine -- I can work around it. But if it was inadvertent I thought
I'd notify you and maybe it can be fixed to work the previous way.
Thanks.

Transcript

https://github.com/league/qcheck/issues/5#issuecomment-307125426

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 183

Submitted via web form by Christopher League [email protected] on 2017-10-08 at 15:1000

comment by @JohnReppy on 2017-18-18 20:1800 +000 UTC

Fixed for 110.82

Inaccurate install instructions, ia32-libs have been deprecated

Version

110.79

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Installation

Severity

Cosmetic

Description of the problem

As of Debian Wheezy, 'ia32-libs' have been deprecated in favor of using multiarch support.
https://wiki.debian.org/Multiarch
https://wiki.ubuntu.com/MultiarchSpec

Fix:
Replace the instructions to install 'ia32-libs' with the following:

You will probably need to do the following to achieve the same goal:
dpkg --add-architecture i386 # enable multi-arch
apt-get update
apt-get install libc6:i386 # install base 32bit libraries

This seems to be true for CentOS as well.

On CentOS I was able to install the following to install smlnj successfully:
yum groupinstall "Development tools" # ~= 'build-essential'
yum install libgcc.i686
yum install glibc-devel.i686

Presumably Fedora is further along than CentOS so I would assume the above instructions work there as well.

I would like my extra credit in the form of beer, delivered to the techstaff office. :P

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 164

Submitted via web form by Phil Kauffman [email protected] on 2016-31-15 at 15:3100

comment by @JohnReppy on 2016-43-15 16:4300 +000 UTC

This issue has been fixed for 110.80

comment by @JohnReppy on 2016-23-16 19:2300 +000 UTC

This is the same issue as bug #146.

REPL deletes prompt

Version

110.99.1

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

x86 (32-bit)

Component

Other

Severity

Cosmetic

Description of the problem

The REPL appears to delete the prompt when executing declarations;
see transcript below. Lines 3 and 5 of each session are typed by
me. Notice that the "-" prompt has been deleted in 110.99.1, but
not in 110.98.

This is cosmetic, but does make it difficult to show what had been
typed and what is a response from the REPL.

Transcript

$ /opt/smlnj-110.99.1/bin/sml
Standard ML of New Jersey (64-bit) v110.99.1 [built: Fri Jul 30 15:24:13 2021]
val x = 5 ;
val x = 5 : int
use "area.sml" ;
[opening area.sml]
structure A : sig
  val pi : real
  val area : real -> real
end
val it = () : unit

$ /opt/smlnj-110.98/bin/sml
Standard ML of New Jersey (64-bit) v110.98 [built: Mon Aug 10 14:08:31 2020]
- val x = 5 ;
val x = 5 : int
- use "area.sml" ;
[opening area.sml]
structure A :
  sig
    val pi : real
    val area : real -> real
  end
val it = () : unit

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 292

Submitted via web form by Norman Danner [email protected] on 2021-54-01 at 18:5400

comment by @JohnReppy on 2021-33-01 19:3300 +000 UTC

It turns out that the problem was with the "rlwrap" program and not with SML/NJ.

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. ~

Inlining for Word8 arithmetic operations is broken

Version

110.81

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

No response

Component

Core system

Severity

Minor

Description of the problem

Word8.+, Word8.-, Word8.*, and Word8.~ are not inline expanded.

Additional comments:
The problem is the w8adapt function in
base/system/smlnj/init/pervasive.sml.

To fix, the w8adapt function needs to be merged into the
actual primitive implementations.

Transcript

[After convert ...]

v12(v25[C],v17[PR2]) =
   v28(v29[PV]) =
      v28("bogus")
   v24(v30[PV]) =
      v28("bogus")
   v17.0 -> v18[F]
   v1(v26[C],v5[I]) =
      v18(v26,v5,(I)1)
   {v1} -> v16
   v25(v16)

Expected Behavior

No response

Steps to Reproduce

(* to demonstrate *)
Control.CG.printit := true;
fun f (x : Word8.word) = x + 0w1;

Additional Information

No response

Email address

[email protected]

Comments from smlnj-gforge

Original smlnj-gforge bug number 186

Submitted via web form by John Reppy [email protected] on 2017-09-21 at 18:49:00

Redundant error messages for when a constructor name is misspelled

Version

110.99

Operating System

  • All
  • Linux
  • macOS
  • Windows
  • Other Unix

OS Version

No response

Processor

Any

Component

Core system

Severity

Cosmetic

Description of the problem

If a qualified constructor name is misspelled, we get two or three error messages, instead of just one. In particular, the "variable found where constructor is required" is bogus, since qualified variables can never appear in a pattern.

Transcript

<jhr@Froh> sml
Standard ML of New Jersey (64-bit) v110.99 [built: Thu Dec 24 11:47:23 2020]
- structure A = struct datatype t = Foo | Bar end;
structure A : sig
  datatype t = Bar | Foo
end
- fun f x = (case x of A.Baz => 1 | _ => 2);
stdIn:2.22-2.27 Error: unbound variable or constructor: Baz in path A.Baz
stdIn:2.22-2.27 Error: variable found where constructor is required: A.Baz
- fun g x = (case x of A.Baz _ => 1 | _ => 2);
stdIn:1.23-1.28 Error: unbound variable or constructor: Baz in path A.Baz
stdIn:1.23-1.28 Error: variable found where constructor is required: A.Baz
stdIn:1.23-1.30 Error: constant constructor applied to argument in pattern:bogus

Expected Behavior

No response

Steps to Reproduce

structure A = struct datatype t = Foo | Bar end;
fun f x = (case x of A.Baz => 1 | _ => 2);
fun g x = (case x of A.Baz _ => 1 | _ => 2);

Additional Information

No response

Email address

No response

Comments from smlnj-gforge

Original smlnj-gforge bug number 281

Submitted on 2021-55-16 at 16:5500

Keywords: error messages

comment by @dmacqueen on 2021-03-10 03:0300 +000 UTC

Bug closed on 2021.11.9. ~ Fix required rewriting substantial portions of elabPat (albacore.sml) to deal more correctly with constructors vs variables in patterns. This required revision of the Absyn.value type (adding an ERRORid constructor) and modifying and adding several functions in ElabData/staticenv/lookup.sml. The function ElabUtil.makeAPPpat was eliminated, and ElabUtil.pat_id was cleaned up. Portions of elabPat in ElabCore dealing with variables, constant data constructors and constructor applications were revised to improve error handling and reporting. ~

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.