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

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

Re: [MIT-Scheme-devel] scheme/edwin build problem?


From: Huston Bokinsky
Subject: Re: [MIT-Scheme-devel] scheme/edwin build problem?
Date: Tue, 8 Nov 2011 11:46:39 -0500

Chris,

That worked.  Many thanks.  As a note, building Scheme according to these last instructions makes it open in a separate window.  To get it to run on my server in a terminal window, I configured it with the "--without-x" option.

Huston

On Tue, Nov 8, 2011 at 4:02 AM, Chris Hanson <address@hidden> wrote:
Huston,

Do the following to get this working (only the rm and
etc/build-bands.sh are different from the standard instructions).
Unfortunately I didn't notice because I only tested the 64-bit
versions carefully, and this particular problem doesn't seem to occur
with them.

Sorry for the trouble.

tar xzf mit-scheme-9.1-i386.tar.gz
cd mit-scheme-9.1/src
./configure
make compile-microcode
rm lib/*.com
etc/build-bands.sh
sudo make install

On Mon, Nov 7, 2011 at 5:57 PM, Matt Birkholz
<address@hidden> wrote:
>> From: Taylor R Campbell <address@hidden>
>> Date: Tue, 8 Nov 2011 01:04:39 +0000
>>
>> [...]
>>
>> Chris recently changed Scheme to preserve the floating-point
>> environment across band save/restore, but floating-point environment
>> objects are OS-dependent.
>
> They are stored in every suspended thread's floating-point-
> environment slot.  We cannot restore a band with suspended threads
> anymore?  Not unless an fenv_t is identical (in size AND meaning) on
> both host (dumper) and target (restorer)?
>
> Actually, I can roll with that.  If we ship runtime/*.com, the
> installer can spin up an all.com optimized for the hardware on which
> it is installed.  Despite the lost portabimini, many machines will
> still be able to swap bands... no?
>


reply via email to

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