Hi Ben,
On Wed, Nov 26, 2014 at 2:27 PM, Ben Coman <[hidden email]> wrote: --
No; there is no automatic conversion between 32-bit and 64-bit images. 64-bit Spur images will only be runnable on 64-bit machines. There are scripts that convert 32-bit non-Spur images to 32-bit Spur images and from 32-bit Spur images to 64-bit Spur images, and it would be easy to add a script that converted from a 64-bit Spur image to a 32-bit Spur image. But none of these conversions will be provided "automatically" (e.g. as a side-effect of starting up an image), although they may be wrapped up in tools. Currently the conversion time from 32-bit non-Spur to 32-bit Spur on a fast laptop is 5 minutes, and IIRC conversion from 32-bit Spur to 64-bit Spur takes a couple of minutes. So I don't think one will ever want this to happen automatically. Further, I hope and expect that we're moving to/have already moved to a construction-oriented image build process where one will take a pre-prepared base image of the appropriate pointer width and run scripts to load packages into them. So I expect the main use of the Spur 32-bit to 64-bit bootstrap is in preparing base release images. btw, Does that comment need updating... didn't you go with SmallDouble, BoxedDouble? No. Bert suggested (IIRC) ImmediateFloat64 and BoxedFloat64 and I went with SmallFloat64 and BoxedFloat64 for two reasons. SmallFloat64 because I like the symmetry with SmallInteger, and because this name scheme gracefully admits SmallFloat32, BoxedFloat32 and BoxedFloat80 if ever there was the energy to add them. best,
Eliot |
On 26.11.2014, at 23:42, Eliot Miranda <[hidden email]> wrote:
Here’s my message (sent private to Eliot to not prolong the bikeshedding):
- Bert - smime.p7s (5K) Download Attachment |
Free forum by Nabble | Edit this page |