This is an ebuild for the newest SML/NJ. SML is a (mostly) functional language. SML/NJ is one of the most popular implimitations of SML. Most funcional languages are very different from imperitive languages(C, C++, java, fortran). There is no compiler per se in SML/NJ. SML/NJ is an interactive shell, where you can type your functions and check them easily at the prompt, without recompiling. SML is also type safe, so you can't get seg faults, or class cast errors. The nature of SML makes it easy to prove the correctness of programs(imagine if you could do that for gcc or the kernel). sml/nj is currently in dev-lang/sml-nj. As of 110-58, sml/nj supports x86-64 processors, ppc, and sparc. I've enabled all of them in the ebuild, however, I don't feel that good about anything except the x86. I currently support X and compile as USE flags. X enables eXene, an interface to X from sml/nj. "compile" enables heap2asm, which takes a smlnj heap, and produces assembly. --Marty
Created attachment 91015 [details] smlnj-110.59.ebuild oh yes, I don't know how to make sure that this correctly downloads the sources. for the time being, you can get whatever you need from: http://www.contrib.andrew.cmu.edu/~mjrosenb/gentoo/ anyone knows how to do that correctly, let me know.
Works fine on amd64 with multilib (the compiler remains a 32 bit executable, and it still generates 32 bit code, but that is a step up from any other sml compiler at this point).
Works flawless on amd64 here, too. Someone should fix the file downloading thing and add this to upstream portage asap.
A new version of Sml/NJ is available: 110.60 http://www.smlnj.org/dist/working/110.60/index.html
110.65 is out, same ebuild is still working
Created attachment 134184 [details] smlnj-110.65.ebuild New ebuild for version 110.65. - fetch of sources should work fine; - heap2asm is installed via USE="heap2asm"; - fixed DEPEND; - added ~amd64 keyword (smlnj works on that arch too); - also install ml-antlr and heap2exec; - code cleanups.
Davide, the problem with you ebuild is that it will put unversioned files into distfiles/ which will become a problem on the next version bump. Marty, one solution is if I put the files into the gentoo mirroring system manually (a bit like you have done), but that is a maintenance nightmare and definately not something I am willing to do more than maybe once. So maybe for now you should point the SRC_URI to <http://www.contrib.andrew.cmu.edu/~mjrosenb/gentoo/distfiles/>. A real solution involves ebuild specification being extended to allow custom src_fetch. I'm not sure if I can make that happen and if I can if it will be in a reasonable timeframe. Therefore I am interested in any hacks you might have. I'd also like to invite you to the brand new #gentoo-ml
update: 110.67 is just out. I also wrote a small script to download and version the files. I'll be using it to add the files to the mirrors too as soon as I get the ebuild working to my liking.
Created attachment 135978 [details] fetch-files.sh usage example: ./fetch-files.sh 110.67 /usr/portage/distfiles
There's a typo in the script: heap2asm.tgz
Alright, you'll be happy to know 110.67 has been committed and files mirrored. Would like to hear of at least one succesful fetch/emerge.
(In reply to comment #11) I just emerge --sync'd and the current Manifest lists the size of config.tgz as 1006149 bytes. However, the file at http://smlnj.cs.uchicago.edu/dist/working/110.67/config.tgz and on the mirrors is only 501550 bytes.
Thanks Daniel for reporting this. I'm not sure why the files I had locally were the wrong size. Anyway I think it should be fixed now.
(In reply to comment #13) OK, the Manifest looks good. Next issue: bootstrapping fails on my machine. Snip from build.log is below, but I suspect something like the following. 1. install.sh line 381 calls .../work/bin/.link-sml 2. .link-sml checks $SMLNJ_HOME and sets BIN_DIR and RUN_DIR based on it 3. .link-sml runs a binary from /usr/lib/smlnj/bin 4. I am upgrading from 110.45 so this binary is incompatible with the image generated in .../work SMLNJ_HOME is set by profile.env to point to /usr/lib/smlnj. But there is a comment in the ebuild that sets it to the WORKDIR... perhaps that should be uncommented? While I am looking at this, I notice the 110.45 ebuild populates /etc/env.d/10smlnj while the 110.67 ebuild populates /etc/env.d/50smlnj. Any reason for this change? Keeping both seems crufty. Should the old file be removed (or the user warned)? from build.log: /var/tmp/portage/dev-lang/smlnj-110.67/work/config/unpack: Un-GZIP-ing and un-TAR-ing bootfiles archive. ./config/install.sh: CM metadata directory name is ".cm" /usr/lib/smlnj/bin/.run/run.x86-linux: Fatal error -- unable to find PerID [5c1335271e850f70e576f44c3fcf352a] ./config/install.sh !!! Boot code failed, no heap image (sml.x86-linux). * * ERROR: dev-lang/smlnj-110.67 failed. * Call stack: * ebuild.sh, line 1701: Called dyn_compile * ebuild.sh, line 1039: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * smlnj-110.67.ebuild, line 105: Called die * The specific snippet of code: * ./config/install.sh || die "compilation failed" * The die message: * compilation failed
(In reply to comment #14) > SMLNJ_HOME is set by profile.env to point to /usr/lib/smlnj. But there is a > comment in the ebuild that sets it to the WORKDIR... perhaps that should be > uncommented? Please test that. But first try unsetting SMLNJ_HOME with the current ebuild. > While I am looking at this, I notice the 110.45 ebuild populates > /etc/env.d/10smlnj while the 110.67 ebuild populates /etc/env.d/50smlnj. Any > reason for this change? Keeping both seems crufty. Should the old file be > removed (or the user warned)? 50 is the default and I saw no need for the deviation, but this function is not used anymore. The old file should be recycled automatically as usual. > from build.log: > /usr/lib/smlnj/bin/.run/run.x86-linux: Fatal error -- unable to find PerID this is the same as bug 199320.
(In reply to comment #15) > > SMLNJ_HOME is set by profile.env to point to /usr/lib/smlnj. But there is a > > comment in the ebuild that sets it to the WORKDIR... perhaps that should be > > uncommented? > > Please test that. But first try unsetting SMLNJ_HOME with the current ebuild. Unsetting SMLNJ_HOME in the shell has no effect with the current ebuild. Unsetting it in the ebuild works -- at least the emerge succeeds, but the resulting installation is broken. The following should complain that "nofile" doesn't exist, and not get an unexpected exception. $ sml Standard ML of New Jersey v110.67 [built: Fri Nov 16 12:09:36 2007] - CM.make "nofile"; [autoloading] unexpected exception (bug?) in SML/NJ: Io [Io: openIn failed on "/var/tmp/portage/dev-lang/smlnj-110.67/work/sml.boot.x86-unix/smlnj/.cm/x86-unix/cm.cm", No such file or directory] raised at: Basis/Implementation/IO/bin-io-fn.sml:617.25-617.71 ../cm/util/safeio.sml:30.11 ../compiler/TopLevel/interact/evalloop.sml:44.55 -
is that in a shell with or without SMLNJ_HOME? here: $ sml Standard ML of New Jersey v110.67 [built: Thu Nov 15 23:18:39 2007] - CM.make "nofile"; [autoloading] [library $smlnj/cm/cm.cm is stable] [library $smlnj/internal/cm-sig-lib.cm is stable] [library $/pgraph.cm is stable] [library $smlnj/internal/srcpath-lib.cm is stable] [library $SMLNJ-BASIS/basis.cm is stable] [autoloading done] [scanning nofile] uncaught exception Io [Io: openIn failed on "nofile", No such file or directory] raised at: Basis/Implementation/IO/text-io-fn.sml:783.25-783.71 ../cm/util/safeio.sml:30.11 ../cm/parse/parse.sml:502.47 Is that the correct output?
(In reply to comment #17) > is that in a shell with or without SMLNJ_HOME? Without. I don't seem to have any SMLNJ related files in /etc/env.d. > uncaught exception Io [Io: openIn failed on "nofile", No such file or > directory] > ... > Is that the correct output? That is correct. If I set SMLNJ_HOME to /usr then everything is fine. Is that what it should be set to?
(In reply to comment #18) > If I set SMLNJ_HOME to /usr then everything is fine. Is that what it should > be set to? It works here without SMLNJ_HOME being set at all, so I am a bit skeptical whether you actually unset it.
(In reply to comment #19) > It works here without SMLNJ_HOME being set at all, so I am a bit skeptical > whether you actually unset it. $ unset SMLNJ_HOME $ sml Standard ML of New Jersey v110.67 [built: Fri Nov 16 12:09:36 2007] - CM.make "nofile"; [autoloading] unexpected exception (bug?) in SML/NJ: Io [Io: openIn failed on "/var/tmp/portage/dev-lang/smlnj-110.67/work/sml.boot.x86-unix/smlnj/.cm/x86-unix/cm.cm", No such file or directory] raised at: Basis/Implementation/IO/bin-io-fn.sml:617.25-617.71 ../cm/util/safeio.sml:30.11 ../compiler/TopLevel/interact/evalloop.sml:44.55 - $ export SMLNJ_HOME=/usr $ sml Standard ML of New Jersey v110.67 [built: Fri Nov 16 12:09:36 2007] - CM.make "nofile"; [autoloading] [library $smlnj/cm/cm.cm is stable] [library $smlnj/internal/cm-sig-lib.cm is stable] [library $/pgraph.cm is stable] [library $smlnj/internal/srcpath-lib.cm is stable] [library $SMLNJ-BASIS/basis.cm is stable] [autoloading done] [scanning nofile] uncaught exception Io [Io: openIn failed on "nofile", No such file or directory] raised at: Basis/Implementation/IO/text-io-fn.sml:783.25-783.71 ../cm/util/safeio.sml:30.11 ../cm/parse/parse.sml:502.47 - My sml script still has a portage build path in it: $ grep -n /var/tmp/portage /usr/bin/sml 35: BIN_DIR="/var/tmp/portage/dev-lang/smlnj-110.67/work/bin" That line isn't used if SMLNJ_HOME is set, and I can't see where else that path would be coming from.
(In reply to comment #20) > My sml script still has a portage build path in it: > $ grep -n /var/tmp/portage /usr/bin/sml > 35: BIN_DIR="/var/tmp/portage/dev-lang/smlnj-110.67/work/bin" > > That line isn't used if SMLNJ_HOME is set, and I can't see where else that > path would be coming from. Okay, you're right. It seems that temp build directory is still hanging around on my system which is why it works even with faulty BIN_DIR. I expect it works if you change that line to BIN_DIR="/usr/bin".
revision1 should now work regardless of any previously installed smlnj's and regardless of any lingering SMLNJ-HOME settings. Please test.
(In reply to comment #22) > revision1 should now work regardless of any previously installed smlnj's and > regardless of any lingering SMLNJ-HOME settings. Please test. works on x86
