Re: [MIT-Scheme-devel] intel macs

On Mar 31, 2006, at 5:50 AM, Dan Starr wrote: Will be getting a new Intel-based Macintosh. Have checked web-page for building MIT/Scheme on "other Unix" platforms. Has this been done yet? Since other Unix and x86 platforms are already used, this should be relatively easy. Willing to do

[MIT-Scheme-devel] "Unknown directive name" while compiling "turtle.scm"

Even after doing , I'm consistently getting the error "Unknown directive name" while compiling "turtle.scm" as part of . Has anyone else seen this? Thanks. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/li

Re: [MIT-Scheme-devel] "Unknown directive name" while compiling "turtle.scm"

On Aug 7, 2006, at 10:56 PM, Arthur A. Gleckler wrote: Even after doing , I'm consistently getting the error "Unknown directive name" while compiling "turtle.scm" as part of . Has anyone else seen this? Aha! I found Chris's 29 Jun 2006 answer to another ques

Re: [MIT-Scheme-devel] git?

> CVS may be crusty, but personally I'm still not remotely comfortable > using Git after some three-odd attempts to learn to use it.  However, > if I'm the only one to whom it is nearly as unusably opaque as Arch, > then it is probably not worth stalling for my sake alone. I'm not a fan of git, ei

Re: [MIT-Scheme-devel] savannah problems

> Savannah crashed a couple of days due to hardware problems.  We lost > the git repository because it wasn't backed up (apparently there was > some issue with backups in the time leading up to the failure -- what > do you want for a free service, anyway).  The CVS repository is not at > issue beca

Re: [MIT-Scheme-devel] savannah problems

> No, the two are independent, except for the project web pages, which > are managed by CVS on savannah.  But I'm not very excited about moving > at the moment, although Google Code does have some nice features. Yeah, I understand. I thought I should mention it since this would be the easiest tim

[MIT-Scheme-devel] compiling for OS X

I just bought a new Mac Mini to replace my aging iMac G5. Now that I have an x86, I'd love to run the prebuilt binary, but it doesn't include some bug fixes I made recently that I need for a project. Unfortunately, I can't get MIT Scheme to compile using either the x86 back end or the C back end a

Re: [MIT-Scheme-devel] compiling for OS X

> Nothing special is required to compile 32-bit native binary.  From a > fresh git checkout: > > ./Setup.sh > ./configure > make > make install Yeah, that's what I did. I'll send along the transcript when I get home tonight. > You've installed Xcode?  We haven't tested other compilers. Yes. >

Re: [MIT-Scheme-devel] compiling for OS X

> OK, send me the transcript and I'll try to figure it out.  I have the > Snow Leopard upgrade, but haven't installed it because it breaks > ToonTown, and that would be *very bad* for the rest of my family.  And > I'm not touching the Google machine until it's officially supported. > So at the mome

Re: [MIT-Scheme-devel] compiling for OS X

> I'll send you the transcript tonight. I've attached the transcript. The build fails here in "microcode/confshared.h": #ifndef PC_ZERO_BITS # ifdef CC_IS_NATIVE #include "Error: confshared.h: Unknown PC alignment." # else #define PC_ZERO_BITS 0 # endif #endif My guess

Re: [MIT-Scheme-devel] compiling for OS X

> 1. Test whether the directory "/Developer/SDKs/MacOSX10.4u.sdk" exists > in your installation. Aha! I don't have that directory. > 2b. If not, change microcode/configure.ac to refer to a different sdk > that _is_ present.  This would explain why the liarc binary wouldn't > work. I change that

Re: [MIT-Scheme-devel] compiling for OS X

> OK, add -arch i386 too. By editing "configure.ac" somehow or as an argument to "configure"? > Did you try a liarc build with this? Not this time. But when I tried yesterday, it failed. I don't have the transcript for that any more. ___ MIT-Scheme

Re: [MIT-Scheme-devel] compiling for OS X

> OK, good.  Now add a binding AS_FLAGS="-arch i386" to that same part > of configure.ac that sets MACOSX_CFLAGS. Hurrah! It's compiling the compiler now, so we're definitely past those problems. I'm not yet a Git Achiever, so I've attached the changed section of "configure.ac". I will get up t

Re: [MIT-Scheme-devel] compiling for OS X

> OK, I've made some changes to "configure.ac".  It should automatically > adapt to the correct SDK.  Please "git pull" and try again to test. I'm getting this again: cmpaux-i386.s:166:suffix or operands invalid for `push' I tried both with and without the <--with-macosx-version=10.6> argument

Re: [MIT-Scheme-devel] compiling for OS X

> I'll look into this further tonight. Oh, I see. This doesn't include the change to add <-arch i386>. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] compiling for OS X

> Thanks.  I've fixed that in git. Thank you, thank you! I pulled that down and have now successfully built on Snow Leopard. By the way, I consistently get this error the first time I do : bash-3.2$ git pull remote: Counting objects: 9, done. remote: Compressing objects: 100% (5/5), done.

Re: [MIT-Scheme-devel] compiling for OS X

> The second time I try that in any directory where I've done clone> earlier, it works fine.  Is this normal? Oh, I bet I know what's going on. I did in a directory which was a copy of the directory I had pulled down. It must be comparing the hash of the enclosing directory's name with the has

Re: [MIT-Scheme-devel] MIT Scheme on the AMD x86-64

> My guess is that you have a stale configure script for the microcode > which doesn't know about x86-64 native code. Rerun autoconf in the > `microcode/' directory, or run `make maintainer-clean' and then start > over. Also, run `git pull' again -- I have just pushed a fix to an > unrelated prob

Re: [MIT-Scheme-devel] MIT Scheme on the AMD x86-64

Very nice! I'm able to make some awfully large heaps. Thanks for doing this, Taylor. This is going to make a lot of people happy. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] MIT Scheme on the AMD x86-64

> It seems to lack all floating point: > > 1 ]=> (/ 3.0 1.2) That expression works for me -- even when included in a compiled procedure. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] problems with the x86-64 build on OS X 10.5

I'm re-sending this message with an abbreviated transcript because the first attempt bounced from . On Mon, Nov 9, 2009 at 5:50 PM, Arthur A. Gleckler wrote: > Has anyone tried the x86-64 build on OS X 10.5?  I've built from an > up-to-date, clean repository on a machine with

[MIT-Scheme-devel] Re: problems with the x86-64 build on OS X 10.5

> I haven't tried building it on OS X at all, but did you build the C > distribution as i386 or as x86-64?  If i386, that will cause make.bin > to be a 32-bit fasl, which the 64-bit microcode won't know how to > read.  You may need to build the C distribution with > > sh etc/make-liarc.sh 'CFLAGS=-

[MIT-Scheme-devel] Re: problems with the x86-64 build on OS X 10.5

> Thank you!  I didn't do that, but will try it now. Alas, I didn't get far. (See attached.) It appears that on OS X expects , or as the value of <-arch>. But that doesn't seem to be what this error is complaining about. I have machines running 10.6 at home. I'll see whether this works the

[MIT-Scheme-devel] Re: problems with the x86-64 build on OS X 10.5

> There may be other lurking space-sensitive `pathname' arguments among > the scripts -- you could also try renaming the directory from `MIT > Scheme' to `mit-scheme' or something without any spaces in it. Gee whiz. Sorry to bother you with such a trivial problem. I had built successfully earlie

[MIT-Scheme-devel] Re: problems with the x86-64 build on OS X 10.5

>    CFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" etc/make-liarc.sh Hurrah! That did it. Once that built, I was able to build the native x64-64 version. Thanks again to you both. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://list

Re: [MIT-Scheme-devel] Recent Win32 microcode?

> I believe Chris is referring to microcode/cmpauxmd/i386-ntw.asm, which > is generated when you run Setup.sh. Here's mine, which is from 9 Nov. Is that recent enough? i386-ntw.asm Description: Binary data ___ MIT-Scheme-devel mailing list MIT-Scheme-

[MIT-Scheme-devel] missing "runtime-unx.c"

I'm trying to build the latest MIT Scheme on an OS X 10.6 system and running into a new problem. I've run: ./Setup.sh ./configure sh etc/make-liarc.sh The third command fails with: gcc -DHAVE_CONFIG_H -DMIT_SCHEME -DDEFAULT_LIBRARY_PATH=\"/Users/arthur/mit-scheme/src/boot-root/lib/mit-s

[MIT-Scheme-devel] Re: missing "runtime-unx.c"

Is it actually possible to build starting with only an installed 20090107 binary and an up-to-date Git repository? Or does one have to build from a ".tgz" file for the 20090107 C release, then proceed? I thought that I had built on my Mac Pro without downloading the C release, but neither "make-n

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

> Hmm, I'm afraid I can't reproduce this -- but I don't have any > machines running Snow Leopard to test on.  Can anyone who does > reproduce this (using the 20090107 snapshot, which is what I have > been using to bootstrap the x86-64 port)? Yes, I was just able to reproduce this: ;non-pointer

Re: [MIT-Scheme-devel] Re: missing "runtime-unx.c"

> If you have Scheme with the C back end installed, and you want to > build Scheme with a native back end, run make-native.sh. Alas, that doesn't work right now (";non-pointer datum out of range 288230376151711743"). > If you have Scheme with a native back end installed, and you want to > build S

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

> Just to clarify: do you mean that you had the 20090107 snapshot with > the C back end installed, and you fetched a clean Git repository, in > which you ran Setup.sh and etc/make-native.sh? And did it fail at the > same time as for Derrell Piper as shown in his transcript? Here are the steps I f

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

> And just to confirm one last detail, can you start up the 20090107 > version of Scheme with the C back end (i.e. the one you're using to > buil the x86-64 version), and tell me the value of the following > expression? > > (vector-ref (gc-space-status) 0) No problem. I'll check that tonight when

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

> (vector-ref (gc-space-status) 0) Result: 8. (See attached transcript.) So, alas, that looks right. bash-3.2$ mit-scheme-c MIT/GNU Scheme running under MacOSX Type `^C' (control-C) followed by `H' to obtain information about interrupts. Copyright (C) 1986, 1987, 1988, 1989, 1990, 1991, 1992, 1

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

> By the way, if your goal is just to build the latest Scheme, you can > start with > > > > by untarring it in $prefix and then running `./configure && make && > make install' in the microcode alone, without needing any p

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

> The last line overrides the default code generator which is i386 -- > incorrect for snow leopard, and perhaps the source of the problems > here. Yes, that did it for me. Thanks. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists

Re: [MIT-Scheme-devel] make-eq-hash-table

> Comments? I agree with your recommendation. On a related note, in a recent build, I noticed some of my code failing sporadically to find certain values in EQ hash tables. Depending on the order in which the code was loaded, one particular symbol value would be missing from one such table, which

Re: [MIT-Scheme-devel] make-eq-hash-table

> OK? That's an excellent plan. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] specifying hash table weakness

> (MAKE-x-HASH-TABLE* #!OPTIONAL ), >  x \in {EQ, EQV, EQUAL, STRING} I wonder whether it makes sense to make X a parameter, too. That wouldn't prevent special treatment of EQ. The other obvious possibility is to make a hash table constructor maker, i.e. to curry the construction of hash tables

Re: [MIT-Scheme-devel] MIT-Scheme 9.0.1 performance problem. (cont.)

> > Hmm, it's a mess, I agree. > Loading definer.scm before execution of (cf "luser.scm") does not > help. I load the definer.scm, then compile the luser.scm and get the > error. I read somewhere that the compiler uses only the predefined > macros from the Scheme build (let's say included in all.co

Re: [MIT-Scheme-devel] MIT-Scheme 9.0.1 performance problem. (cont.)

> I am waiting for your notes then. Every hint is valuable for me. Here's what I wrote in my notes: (load "~/tmp/macro-definition.scm") (fluid-let ((sf/default-syntax-table (->environment '(user (cf "~/tmp/macro-user.scm")) This will make sure that the macros defined in "macro-defi

Re: [MIT-Scheme-devel] GTk+ in MIT-Scheme?

> > Bless me, like-minded entities, for I have Schemed. > Two highly worthy hacks, I must say! No sin at all! ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] named parameters

> > Any comments? I don't plan to integrate it into the system any time > soon, but it might be nice to do some day when we have less broken > macros and modules, like Racket. > This would be great. I've only skimmed your code so far, but I plan to come back to it after I've had a chance to read

Re: [MIT-Scheme-devel] primitives, interrupts, allocation, and robustness

> > (a) If a primitive performs a permanent side effect, it may not use > any system call afterward that could ever conceivably block. This > means eliminating (or at least deprecating) complex primitives such as > FILE-TOUCH and replacing them by Scheme code. > This is my favorite suggestion. I

Re: [MIT-Scheme-devel] Faster ports.

> > > `Byte' won't make any sense when we get the PDP-10 port working again. > > That very old joke is why you can't say "byte"? You can't be serious. > Yes, we should stop worrying about that. "Byte" means eight bits except in history books, and that's that. English evolves. __

Re: [MIT-Scheme-devel] bookkeeping memory allocated per primitive

> > Any objections to committing this? > None from me. This is a clean, simple solution to what initially sounded like a complicated problem. My only suggestion is to initialize to zero explicitly. That makes it clearer how this test works: if (Free_primitive < heap_start) Otherwise, if so

Re: [MIT-Scheme-devel] symbol names

> > I don't have a particular suggestion for what to do, but this seems > wrong. > I propose fixing these cases one by one as they are encountered. I can't see a systematic way to address them all that doesn't reduce our Unicode support. My biggest concern is that whatever we do doesn't break th

Re: [MIT-Scheme-devel] bookkeeping memory allocated per primitive

> > It's not semantically necessary, since Free_primitive is defined with > static storage, but I agree that it's clearer that way; I'll do that. > Exactly. It makes your intent clear. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://l

Re: [MIT-Scheme-devel] bookkeeping memory allocated per primitive

> > Rather than wait longer for any objections, I've just committed this > together with a change to the i386 and x86-64 back ends to improve > overall system performance by 20%, using the same unscientific tests. > (Do a two-stage build to get the effect.) > 20%?! That's a lot. What do you attr

Re: [MIT-Scheme-devel] bookkeeping memory allocated per primitive

> > The branch direction change. Before, on pretty much every entry to a > non-leaf procedure, the CPU would see a backward branch and predict it > taken by default, if there were no dynamic profile data to inform the > branch predictor. But almost all of the time, that branch -- to > handle inte

Re: [MIT-Scheme-devel] named parameters

Thanks. I just read the Racket paper. It's quite a nice system, and now I see the advantages of their approach, e.g. #%app. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] History of MIT Scheme Through 27 Aug 2011 Visualized Using Gource

I've just put up a video of the history of MIT Scheme created using Gource : http://www.youtube.com/watch?v=3czU5kBFhNI It covers 1987 through today. It's amazing to see the complete history animated in this way. Make sure to watch at 720p and full screen. __

Re: [MIT-Scheme-devel] Bottlenecks

> > Fluid-let seems to be rather expensive, and this one is called a lot. > Would it be better to create an object to contain all those variables and then pass it around instead? ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gn

Re: [MIT-Scheme-devel] A tellurion for the faithful.

On Mon, Apr 15, 2013 at 2:37 PM, Matt Birkholz wrote: > Thanks to Brother Arthur I was able to complete a simple hymn -- a > tellurion: > > http://birkholz.chandler.az.us/tellurion.png > Beautiful! All glory be to Scheme! ___ MIT-Scheme-devel mai

[MIT-Scheme-devel] non-recursive mutexes

Hi, Taylor. Long time, no see. I hope all is well. I'm just upgrading to MIT Scheme 9.2, and my code is breaking in several places because of your change to Remove support for recursion in WITH-THREAD-MUTEX-LOCKED

[MIT-Scheme-devel] non-recursive mutexes

On Monday, June 8, 2015, Taylor R Campbell > wrote: > Hi, Arthur! I asked the list last year whether anyone relied on it: > > https://lists.gnu.org/archive/html/mit-scheme-devel/2014-11/msg5.html > > Nobody replied that they relied on it, and since the thread system is > undocumented I expec

Re: [MIT-Scheme-devel] non-recursive mutexes

On Monday, June 8, 2015, Alexey Radul wrote: > Respectfully, in general, users who rely on subtleties of the detailed > semantics of undocumented procedures [*] should expect occasional > incompatible changes. And what communication channel do we have > except postings on the devel mailing list

Re: [MIT-Scheme-devel] non-recursive mutexes

On Monday, June 8, 2015, Taylor R Campbell wrote: > It sounds like you would be better served by having two locks: the web > server's data structure lock, and the logging lock. The logging lock > can be internal to the logging routines, and need not be exposed > elsewhere in the web server at a

Re: [MIT-Scheme-devel] non-recursive mutexes

On Monday, June 8, 2015, Alexey Radul wrote: > As to ecosystem stewardship, do we as a community have the need and > resources to maintain a package repository, such as > hackage.haskell.org, planet.racket-lang.org, or even interoperate with > snow.iro.umontreal.ca ? That seems a more basic ste

Re: [MIT-Scheme-devel] non-recursive mutexes

On Monday, June 8, 2015, Taylor R Campbell wrote: >Saying "don't rely on it, it's not documented" in reference to an >essential service is basically saying "our system is an unfinished >toy, we're sorry you decided to use it". > > That is basically true of the thread system at least.

Re: [MIT-Scheme-devel] non-recursive mutexes

On Monday, June 8, 2015, Taylor R Campbell wrote: >The log file is specific to the particular web server instance, so the > lock >that controls the log file belongs in the web server data structure. >Having two locks opens the possibility of ordering problems. Having > just >one

Re: [MIT-Scheme-devel] non-recursive mutexes

On Jun 8, 2015 10:04 PM, "Arthur A. Gleckler" wrote: > Still, when logging is used in the web server, the lock needs to reside somewhere. It shouldn't have to be passed around separately from the web server, so I just incorporated it into the web server. Okay, I know what to

Re: [MIT-Scheme-devel] non-recursive mutexes

On Tuesday, June 9, 2015, Taylor R Campbell wrote: > There is an implementation of Concurrent ML for MIT Scheme and others > at > > http://mumble.net/~campbell/darcs/scheme-cml > > which includes multiplexed waits on synchronous channels. If any of > you are interested in using it, feel free to

Re: [MIT-Scheme-devel] non-recursive mutexes

On Monday, June 8, 2015, Arthur A. Gleckler wrote: > > Okay, I know what to do now --basically what you said, but now I have > figured out the details. It should help me with another refactoring I was > already planning, too. I'll report back with the results. > Okay,

[MIT-Scheme-devel] removal of top-level "TAGS" file

Hi, Chris. In change e0429c04, "TAGS shouldn't be in commit," you removed the top-level "TAGS" file. Unlike other "TAGS" files, that file was not a generated file. Having it made it possible to do tags searches across the whole source code tree at once, not just one directory at a time. May I pl

[MIT-Scheme-devel] reduce-right

Hi, Chris. In change de2cb85c, "Put reduce-right back," you restored the implementation of `reduce-left' (not `reduce-right'). However, that change didn't restore the documentation for `reduce-left', which was removed in 5410eb4b. Shall I restore that, too?

Re: [MIT-Scheme-devel] reduce-right

Chris Hanson writes: | Yes thanks. Done. ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] removal of top-level "TAGS" file

Chris Hanson writes: | Oops. I had generated my own TAGS file there and was | surprised when it tried to check it in. I should have | looked at the original contents. > | Go ahead and put it back. Done. ___ MIT-Scheme-devel mailing list MIT-Scheme-de

Re: [MIT-Scheme-devel] Fixes pushed

Chris Hanson writes: | Note that I haven't yet updated the documentation to | reflect these changes. I'll get around to that soon. I'm embarrassed to say that I can't figure out how to build the documentation. I've been following these steps to build and install the system: make maintainer-

Re: [MIT-Scheme-devel] Fixes pushed

Chris Hanson writes: | The documentation is in a separate subdirectory from src/, so it's | built differently: > | cd doc/ | autoconf | ./configure | make Thanks. I can't believe I didn't think of . ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@

Re: [MIT-Scheme-devel] Blowfish, MD5, mcrypt, mhash

I like the idea, but isn't it generally accepted that writing one's own crypto is risky? ___ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] Blowfish, MD5, mcrypt, mhash

On Thu, Nov 2, 2017 at 10:35 PM, Taylor R Campbell wrote: > Merely _using_ MD5 or Blowfish in a protocol is risky! > Yes, of course. > That said, I am pretty well acquainted with what goes into crypto > implementation. > It sounds like you do. Thank you in advance for doing the work. I hav

dropped syntactic closure in 10.90

I've been trying to debug a macro that worked under 9.2.1 but fails under 10.90 (76bb84eaa). I've narrowed the problem down to the following reproducible test case: (define-syntax bar (sc-macro-transformer (lambda (exp env) (let ((bindings (let ((sc (close-syntax (cadr exp) env)))

Re: Macro bug

On Wed, Feb 12, 2020 at 5:26 AM Joe Marshall wrote: > Macros don't seem to be hygienic in Release 10.1.10 > (define (quux) (display "quux") 'quux) > (define (foo) (display "foo") #f) > > (define-syntax or2 > (syntax-rules () > ((or2 form1 form2) > (let ((temp form1)) >(if temp

*.bci missing

*.bci files aren't installed when I do make install (sudo make install, in fact). I see bug 33898 , which reports that they aren't installed, but in my case, they don't even seem to have been generated, at least not in the directories where install expects them

Re: *.bci missing

On Thu, Apr 30, 2020 at 12:12 AM Taylor R Campbell wrote: > git pull and try again? > Thank you so much! That worked. Debugging is so much harder when almost every stack frame looks like this: ... 17 ;compiled code 18 ;compiled code 19

installing Info documentation

What's the standard way to install Info documentation these days? I see doc/Makefile.in, but no Makefile nor .info files. Thanks.

Re: installing Info documentation

On Thu, Apr 30, 2020 at 7:14 PM Taylor R Campbell wrote: > cd mit-scheme/doc > autoconf > ./configure > make > make install > Thanks! Amazingly, after all these years, I don't think I had ever run autoconf, at least not manually.

`read' is now >200x slower than under 9.2 and 10.1.10.

I haven't tracked down the cause, but in a trivial test case, read is more than 200x slower under 10.1.90 than under 9.2 and 10.1.10: Executing this form: (show-time (lambda () (do ((i 0 (1+ i))) ((= i 1000)) (with-input-from-string "foo" read here is the time under 9.2: ;process time: 30 (

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

On Fri, May 1, 2020 at 1:56 PM Arthur A. Gleckler wrote: > and under 10.1.90 at HEAD: > > ;process time: 8150 (8150 RUN + 0 GC); real time: 8149 > > > Does anyone have a clue what might have caused this decline? > Naturally, once I sent my message to the list, the numb

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

Interestingly, the more times I run my now-slow code, the slower it gets, and the slower the trivial test expression I sent earlier gets, too. And threads-list is now broken: 1 ]=> (threads-list) ;The object #[weak-cons 32], passed as the first argument to set-cdr!, is not the correct type. ;To

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

On Fri, May 1, 2020 at 4:59 PM Taylor R Campbell wrote: > > ;The object #[weak-cons 32], passed as the first argument to set-cdr!, is > > not the correct type. > > Sounds like fallout from the weak pair #f -> #!reclaimed changes. > That's what I was thinking. Unfortunately, I haven't been able

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

On Fri, May 1, 2020 at 7:30 PM Chris Hanson wrote: > If you’re running a 10.90 cross-compiled by 10.1.10, you should do a > native compilation from 10.90 to 10.90. Otherwise gc-renamed-object? won’t > be open-coded, which could affect performance. > Thanks for the idea. I'm doing that now on al

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

On Fri, May 1, 2020 at 9:33 PM Arthur A. Gleckler wrote: > The error I get is: > > ;Unable to find file "edwin.bld" because: File does not exist. > > Removing src/edwin/stamp-scheme fixed the problem. Should that have been removed automatically by make distclean? It

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

On Fri, May 1, 2020 at 9:57 PM Taylor R Campbell wrote: > I don't trust maintainer-clean, because the makefiles aren't very good > at being around at all the right times; I always use `git clean -dxn' > (and review what it will delete to make sure it's nothing important) > and then `git clean -d

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

On Fri, May 1, 2020 at 10:02 PM Arthur A. Gleckler wrote: > Now back to the performance problems. > I'm consistently finding that code that calls read gets slower and slower until I call gc-flip, when it suddenly becomes faster again, but only for a while. Setting *parser-associat

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

On Fri, May 1, 2020 at 11:30 PM Arthur A. Gleckler wrote: > I'm not sure how to proceed. Suggestions welcome. > Oh, the solution is obvious: I'll create that hash table lazily. Sorry for the flood of email.

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

On Sat, May 2, 2020 at 12:07 AM Chris Hanson wrote: > Interesting. Every time the reader is called it creates a hash table, but > inserting it into the population of address-hash tables requires scanning > the population to determine if it’s already there. > Aha! > I’ll generate an alternative

Re: fix:lsh signedness

On Fri, Oct 30, 2020 at 4:59 PM Taylor R Campbell < campbell+mit-sch...@mumble.net> wrote: > - When Arthur originally documented the fix:lsh procedure in 1991 > (bbc428a9), he documented arithmetic right shift semantics. > I'm pretty sure I don't deserve credit for that. If you look at the re

blog post "MIT Scheme on Apple Silicon (M1 Mac)"

I thought you might be interested in this detailed blog post on running MIT Scheme on the Apple M1: https://www.kennethfriedman.org/thoughts/2021/mit-scheme-on-apple-silicon/

[CFP] Scheme 2022, 23rd Scheme and Functional Programming Workshop

held as part of this year's International Conference on Functional Programming. Here is the ICFP site <https://icfp22.sigplan.org/home/scheme-2022> for the workshop. Sincerely, Andy Keep, General Co-chair Arthur A. Gleckler, General Co-chair

Re: Latin Phrases on exit

On Thu, Feb 16, 2023 at 8:21 AM Patrick Heil wrote: > My name is Patrick. I'm a college student who worked with the MIT Scheme > Interpreter in a Comparative Programming Languages course. I noticed the > interpreter would exit with latin phrases such as "Fortitudine vincimus." > I wanted to lear

Re: Latin Phrases on exit

On Thu, Feb 16, 2023 at 11:51 AM Clive Tovero wrote: > "Cogito, ergo sum, cogito." (For fun, someone with access to ChatGPT > might ask it to translate this.) > Here is ChatGPT's reply: The phrase "Cogito, ergo sum, cogito" is originally in Latin and is famously attributed to the French philos

Re: Swiss AI FTP site

On Mon, May 22, 2023 at 12:04 AM Lassi Kortela wrote: > Is there a live instance or an archive of ftp.swiss.ai.mit.edu aka > ftp-swiss.ai.mit.edu remaining somewhere? Neither of those two hostnames > serves HTTP or FTP anymore. > I'm not sure. What was there before? MIT Scheme releases are ser

Re: (run-shell-command ) with output

See the subprocess options documented here: https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-ref/Subprocess-Options.html I hope that helps.