Thanks David, that's useful to know. I haven't been able to build Scheme using gcc (Homebrew, gcc-14): the configure script craps out, and I haven't had time to figure out what goes wrong. I'm traveling now but will try again when I get home. -Kevin
-----Original Message----- From: David Gray <dg...@iesl.forth.gr> Cc: mit-scheme-users@gnu.org For what it's worth, it is a problem with the apple compiler. I managed to get a butchered version working by using gcc13 with macports. I just chopped out the lines with errors in the source, copied the all.com from the previous version. Unlikely as it seems this compiles scheme code correctly even with the usual-integrations. However I’m not expert enough to go anywhere further with this information. > On 10 Dec 2024, at 6:23 AM, Kevin Lin <kky...@alum.mit.edu> wrote: > > Thanks David. I've been doing something similar to > you, but using a version of the work-around in my > first msg (despite my own disclaimers). So far it > seems to work fine and I can get by with it. > -Kevin > > > -----Original Message----- > From: David Gray <dg...@iesl.forth.gr> > Cc: mit-scheme-users@gnu.org > > I think you are correct in that it is saving that is the > problem. I really just want a couple of slow functions to be > compiled, so after digging around in the source I found > compile-procedure which does what I need for the > moment. Just load up the function, compile-procedure, then > run it. > > > > >> On 4 Dec 2024, at 10:43 PM, Kevin Lin <kky...@alum.mit.edu> wrote: >> >> Sorry, two things I forgot to say: >> >> - If scode that's been directly compiled (as in my >> example, and as opposed to loading it from a .bin >> file generated by SF) is then compiled into native >> code via say compile-scode, it does seem to run just >> fine. But saving to file (via fasdump) and >> reloading leads to the same problems. >> >> - Not necessarily recommending these kludges as a >> work-around for anyone else having similar issues -- >> I don't know MIT Scheme internals and haven't tested >> these things; the kludges came about as an effort to >> isolate the issue. >> >> Kevin >> >> -----Original Message----- >> To: mit-scheme-users@gnu.org >> >> Hi all, >> >> I'm trying to build and run MIT/GNU Scheme 12.1 on an Intel >> Mac running Sequoia (15.1). I've had similar issues as >> described on this thread: >> >> https://lists.gnu.org/archive/html/mit-scheme-users/2023-10/msg00004.html >> >> I've been digging around this for a bit, so this is long. >> I've broken this into sections. Details on how I built >> Scheme on my machine come at the end. Any insights or just >> knowing that someone has managed to get 12.1 running on a >> recent macOS would be great. >> >> Thanks! >> >> Kevin <kky...@alum.mit.edu> >> >> *MAIN SYMPTOMS* >> >> Here is a little transcript of what I get: >> >> #| >> (cf "fact.scm") >> >> ;Generating SCode for file: "fact.scm" => "fact.bin"... done >> ;Compiling file: "fact.bin" => "fact.com"... done >> ;Unspecified return value >> >> 1 ]=> (load "fact.com") >> >> ;Loading "fact.com"... >> ;The object fact, passed as an argument to >> return-address->stack-frame-type, is not in the correct >> range. >> ;To continue, call RESTART with an option number: >> ; (RESTART 1) => Return to read-eval-print level 1. >> |# >> >> The file "fact.scm" is something more or less straight from >> SICP: >> >> #| >> (declare (usual-integrations)) >> >> (define (fact n) >> (if (> n 1) >> (* n (fact (- n 1))) >> 1)) >> |# >> >> Moreover, there appear to be issues affecting SF as well: >> >> #| >> 1 ]=> (sf "fact.scm") >> >> ;Generating SCode for file: "fact.scm" => "fact.bin"... done >> ;Unspecified return value >> >> 1 ]=> (pp (fasload "fact.bin")) >> >> ;Loading "fact.bin"... done >> (define (fact n) >> (if (%record n 1) >> (%record n (fact (%record n))) >> 1)) >> ;Unspecified return value >> |# >> >> If I remove (declare (usual-integrations)) then it seems to >> be ok: >> >> #| >> 1 ]=> (sf/system "fact.scm") >> >> ;Generating SCode for file: "fact.scm" => "fact.bin"... >> ; This program does not have a USUAL-INTEGRATIONS declaration. >> ; Without this declaration, the compiler will be unable to perform >> ; many optimizations, and as a result the compiled program will be >> ; slower and perhaps larger than it could be. Please read the MIT >> ; Scheme User's Guide for more information about USUAL-INTEGRATIONS. >> ;... done >> ;Unspecified return value >> >> 1 ]=> (pp (fasload "fact.bin")) >> >> ;Loading "fact.bin"... done >> (define (fact n) >> (if (> n 1) >> (* n (fact (- n 1))) >> 1)) >> ;Unspecified return value >> |# >> >> but CF continues to fail: >> >> #| >> 1 ]=> (cf/system "fact.scm") >> >> ;Generating SCode for file: "fact.scm" => "fact.bin"... >> ; This program does not have a USUAL-INTEGRATIONS declaration. >> ; Without this declaration, the compiler will be unable to perform >> ; many optimizations, and as a result the compiled program will be >> ; slower and perhaps larger than it could be. Please read the MIT >> ; Scheme User's Guide for more information about USUAL-INTEGRATIONS. >> ;... done >> ;Compiling file: "fact.bin" => "fact.com"... done >> ;Unspecified return value >> >> 1 ]=> (load "fact.com") >> >> ;Loading "fact.com"... >> ;The object fact, passed as an argument to >> return-address->stack-frame-type, is not in the correct >> range. >> ;To continue, call RESTART with an option number: >> ; (RESTART 1) => Return to read-eval-print level 1. >> |# >> >> *IS FASDUMP THE PROBLEM?* >> >> One thing I noticed is that if I took a .bin or .com file >> compiled on my Linux box and loaded it on my Intel Mac, it >> works just fine: this code (and more complicated programs) >> runs without a hiccup, and pretty-printing the .bin file >> looks fine to me. It suggests the issue *might* be centered >> around saving binary files. Digging around more, I found >> that if I bypass the FASDUMP defined in fasdump.c, SF >> appears to be ok again. Here's a little kludge that does >> that. >> >> (define *target-fasl-format* >> (eval '(target-fasl-format) (->environment cbf))) >> >> (define (fasdump-kludge obj file) >> (portable-fasdump obj file *target-fasl-format*)) >> >> and what we find is this: >> >> #| >> 1 ]=> (define fact-scode >> ;; compile SCode without saving to file >> (eval '(sf/file->scode "fact.scm" "" #f '()) >> (package/environment >> (find-package '(scode-optimizer top-level))))) >> ;Value: fact-scode >> >> 1 ]=> (pp fact-scode) ;; looks ok to me >> (define (fact n) >> (if (&> n 1) >> (&* n (fact (-1+ n))) >> 1)) >> ;Unspecified return value >> >> 1 ]=> (fasdump-kludge fact-scode "fact.bin") ;; now save to file >> >> ;Unspecified return value >> >> 1 ]=> (pp (fasload "fact.bin")) ;; reload and look >> >> ;Loading "fact.bin"... done >> (define (fact n) >> (if (&> n 1) >> (&* n (fact (-1+ n))) >> 1)) >> ;Unspecified return value >> >> |# >> The kludge doesn't work for compiled expressions and I >> didn't test it on a .com file. I've also dug around >> fasdump.c but I don't understand the microcode and don't >> know where to start tracking down the issue. >> >> Anecdotally, the native code compiler worked just fine in >> Monterey and earlier versions of macOS. >> >> *MORE SYMPTOMS* >> >> 1. One can get different errors by (i) adding more >> definitions to fact.scm, and (ii) selecting which >> primitives (+, *, >) get integrated. I didn't include >> all the cases. >> >> 2. DISK-SAVE also fails, but bands saved on working >> installations (e.g., ScmUtils) work just fine. >> >> *HOW I BUILT SCHEME* >> >> I use Apple's "gcc", which (I think) is just an alias for >> clang. I massage various env vars (happy to share >> config.log), but none of that seems super important. What >> *is* important is to set SDKROOT to >> >> `xcrun --sdk macosx --show-sdk-path` >> >> or clang won't compile the microcode. This may have >> something to do with my having GCC installed (via Homebrew). >> Incidentally, I haven't tried uninstalling gcc as that would >> break too many things, but I did try unlinking gcc and it >> didn't make a difference to the behavior above. >> >> In case it matters, all this is on a 2015 Intel MBP. I get >> the same behavior on an M2 Mac via Rosetta, and on older >> Intel Macs on Sequoia + OCLP. >> >> -- >> >> -- >> > > -- --
