mit-scheme-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: painter implementation for picture language in SICP


From: Taylor R Campbell
Subject: Re: painter implementation for picture language in SICP
Date: Thu, 26 Dec 2019 16:52:47 +0000

> Date: Thu, 26 Dec 2019 11:30:46 -0500
> From: David Liu <address@hidden>
> 
> Thanks; I managed to get a lot farther in loading book's painter files [1]
> using those instructions for loading the 6001 package (also, I noticed that
> when building from the x86_64 binary tarball, there's a --with-6001 option
> that can be passed to ./configure, but that option seems to have no effect
> besides generating a seemingly useless src/6001/Makefile). I had to copy
> the 6001 dir to the mit-scheme lib dir (and also use the binary
> installation from the GNU site rather than the Debian package) in order to
> get it to work.

For testing you can also just work in the source directory -- just do
(cd "mit-scheme-10.1.whatever/src/6001") (load "6001.sf") &c.

The 6001 directory was unhooked from the build last year but it may be
possible to just put it back into SUBDIRS in src/Makefile.in (and then
run config.status to regenerate src/Makefile, or just start over) if
you reallly want it installed systemwide.  Of course, it should really
be an add-on that can be built and installed separately, not something
baked in.

> Anyway, to get a bit further, I made some other minor obvious changes
> (mostly just filename path fixes, no actual logic changes) to the ".scm"
> files at [1]. Then, I tried loading "psgo.scm" managed to get past a few
> other choke points, but ran into some kind of UTF error [2] while loading
> the "fovnder.pgm" picture. I'm pretty sure this error was not caused by any
> of the minor changes I made. Any idea how I can get past this? I would be
> happy to provide more detailed repro instructions if necessary.

Try the attached patch -- this code was written long before MIT Scheme
made it into the modern world of Unicode, and ports by default read
text in UTF-8; the patch changes to reading them in `binary', meaning
ISO-8859-1, a historical pun that enables you to interpret the octets
as `characters' whose Unicode code points correspond to the octets you
would have gotten in real binary I/O.

(There is also a way to use real binary I/O but that may require more
changes to the code.)

Attachment: patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]