November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Listening for shift key pressed

by Aliaksei Syrel

Hi Stef, cool, looking forward to seeing it works :) Because we really need shift event Cheers, Alex On Fri, Nov 21, 2014 at 11:13 PM, stepharo <stepharo(a)free.fr> wrote: > Hi alex > > the way these low level events are managed sucks. This is why we started > to reify them. Now with OSWindow (we should review the code) > and I hope it will get better. Also the VM was not generating event for > shift and I hope that OSwindow will support that :) > Le 21/11/14 17:36, Aliaksei Syrel a Ã©crit : > > Hi Ben, > > If at the end of InputEventFetcher>>waitForInput >> you put "Transcript crShow: Time now" >> and I think you'll be looking at as raw an event aas you can get. > > > Now this exhibits some strange behaviour? Pushing <shift> on its own >> does not produce an event, however pushing <shift> fast multiple times does >> generate events. ??? > > It's maybe because you move mouse, or randomly touch touchpad. > > After some investigations and digging lower and lower till primitive > methods, I realized that VM itself doesn't queue an event after user > presses Shift. It's just a modifier bit, that is applied on a real events, > such as mouse moves or normal keyboard events. > > Cheers, > Alex > > > >

Nov. 21, 2014

Re: [Pharo-dev] Listening for shift key pressed

by stepharo

Hi alex the way these low level events are managed sucks. This is why we started to reify them. Now with OSWindow (we should review the code) and I hope it will get better. Also the VM was not generating event for shift and I hope that OSwindow will support that :) Le 21/11/14 17:36, Aliaksei Syrel a Ã©crit : > Hi Ben, > > If at the end of InputEventFetcher>>waitForInput > you put "Transcript crShow: Time now" > and I think you'll be looking at as raw an event aas you can get. > > > Now this exhibits some strange behaviour? Pushing <shift> on its > own does not produce an event, however pushing <shift> fast > multiple times does generate events. ??? > > It's maybe because you move mouse, or randomly touch touchpad. > > After some investigations and digging lower and lower till primitive > methods, I realized that VM itself doesn't queue an event after user > presses Shift. It's just a modifier bit, that is applied on a real > events, such as mouse moves or normal keyboard events. > > Cheers, > Alex

Nov. 21, 2014

Re: [Pharo-dev] Listening for shift key pressed

by Aliaksei Syrel

Hi, Nicolai Thanks for suggestion. I'm using Mac 10.10 and it doesn't show any notifications for shift.. I'll open an issue for this. Cheers, Alex On Fri, Nov 21, 2014 at 10:20 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > If you look at KeyPrinterMorph you'll see that it indeed handles a single > shift key down. > > 2014-11-21 17:36 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > >> Hi Ben, >> >> If at the end of InputEventFetcher>>waitForInput >>> you put "Transcript crShow: Time now" >>> and I think you'll be looking at as raw an event aas you can get. >> >> >> Now this exhibits some strange behaviour? Pushing <shift> on its own >>> does not produce an event, however pushing <shift> fast multiple times does >>> generate events. ??? >> >> It's maybe because you move mouse, or randomly touch touchpad. >> >> After some investigations and digging lower and lower till primitive >> methods, I realized that VM itself doesn't queue an event after user >> presses Shift. It's just a modifier bit, that is applied on a real events, >> such as mouse moves or normal keyboard events. >> >> Cheers, >> Alex >> >> > >

Nov. 21, 2014

Re: [Pharo-dev] Listening for shift key pressed

by Nicolai Hess

If you look at KeyPrinterMorph you'll see that it indeed handles a single shift key down. 2014-11-21 17:36 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Hi Ben, > > If at the end of InputEventFetcher>>waitForInput >> you put "Transcript crShow: Time now" >> and I think you'll be looking at as raw an event aas you can get. > > > Now this exhibits some strange behaviour? Pushing <shift> on its own does >> not produce an event, however pushing <shift> fast multiple times does >> generate events. ??? > > It's maybe because you move mouse, or randomly touch touchpad. > > After some investigations and digging lower and lower till primitive > methods, I realized that VM itself doesn't queue an event after user > presses Shift. It's just a modifier bit, that is applied on a real events, > such as mouse moves or normal keyboard events. > > Cheers, > Alex > >

Nov. 21, 2014

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Float hierarchy for 64-bit Spur

by Chris Muller

> I have always felt that the mapping of Float to 64-bit double and FloatArray > to 32-bit float is awkward. It may be that 32-bit floats are becoming less > relevant nowadays, but if short float values are still important, then it >From the sense that a lot of computing is addressing fuzzy pattern matching, 32-bit speed and space are actually becoming more relevant. > would be nice to be able to represent them directly. I like the idea of having > a Float class and a Double class to represent the two most common representations. > A class hierarchy that could potentially support this sounds like a good idea to me. > > I have no experience with VW, but a LimitedPrecisionReal hierachy sounds like a > reasonable approach. > > Dave >

Nov. 21, 2014

Re: [Pharo-dev] Float hierarchy for 64-bit Spur

by stepharo

Le 21/11/14 02:51, Eliot Miranda a Ã©crit : > Hi All, > > 64-bit Spur can usefully provide an immediate float, a 61-bit > subset of the ieee double precision float. The scheme steals bits > from the mantissa to use for the immediate's 3-bit tag pattern. So > values have the same precision as ieee doubles, but can only represent > the subset with exponents between 10^-38 and 10^38, the > single-precision range. The issue here is how to organize the class > hierarchy. > > The approach that looks best to me is to modify class Float to be an > abstract class, and add two subclasses, BoxedFloat and SmallFloat, > such that existing boxed instances of Float outside the SmallFloat > range will become instances of BoxedFloat and instances within that > range will be replaced by references to the relevant SmallFloat. > > With this approach ... > > - Float pi etc can still be used, even though they will answer > instances of SmallFloat. But tests such as "self assert: result class > == Float." will need to be rewritten to e.g. "self assert: result > isFloat". > > - BoxedFloat and SmallFloat will not be mentioned much at all since > floats print themselves literally, and so the fact that the classes > have changed won't be obvious. > > - the boxed Float primitives (receiver is a boxed float) live in > BoxedFloat and the immediate ones live in SmallFloat. Making > SmallFloat a subclass of Float poses problems for all the primitives > that do a super send to retry, since the boxed Float prims will be > above the unboxed ones and so the boxed ones would have to test for an > immediate receiver. > > > An alternative, that VW took (because it has both Float and Double) is > to add a superclass, e.g. LimitedPrecisionReal, move most of the > methods into it, and keep Float as Float, and add SmallFloat as a > subclass of LimitedPrecisionReal. Then while class-side methods such > as pi would likely be implemented in LimitedPrecisionReal class, sends > to Float to access them find them via inheritance. An automatic > reorganization which moves only primitives out of LimitedPrecisionReal > is easy to write. Eliot the solution proposed by VM is nice in the sense that we can continue to use Float pi... On the other hand, I like the design used on objective-c when the superclass act as a factory for its subclass hidding concrete implementation classes. Now I do not know if his would make sense for Float. Another point, I do not really like Boxed because this is the first time we use it. May be SmallFloat would be in the same spirit than SmallInteger. > > Thoughts? > -- > best, > Eliot

Nov. 21, 2014

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Float hierarchy for 64-bit Spur

by Tobias Pape

Hi Eliot On 21.11.2014, at 19:56, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Tobias, > > On Fri, Nov 21, 2014 at 10:52 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Hi Eliot > > On 21.11.2014, at 19:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Tobias, > > > > On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > > > > Hi, > > > > > > On 21.11.2014, at 13:44, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > > > > > > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) < > > > juanlists(a)jvuletich.org> wrote: > > > > > > > >> Quoting Bert Freudenberg <bert(a)freudenbergs.de>: > > > >>> > > > >>> I'd suggest BoxedDouble and ImmediateDouble as names for the concrete > > > subclasses (*). Names do mean something. (**) > > > >>> > > > >>> You're right about the FloatArray confusion. However, note that the > > > IEEE standard calls it single and double. It's only C using "float" to mean > > > "single precision". > > > >>> > > > >>> I'd name the abstract superclass Float, for readability, and the > > > isFloat test etc. Also: "Float pi" reads a lot nicer than anything else. I > > > don't see the need for having a deep LimitedPrecisionReal - Float - > > > BoxedDouble/ImmediateDouble deep hierarchy now. > > > >>> > > > >>> If we ever add single-precision floats, we should name them > > > BoxedSingle and ImmediateSingle. At that point we might want a Single > > > superclass and a LimitedPrecisionReal supersuperclass, but we can cross > > > that bridge when we get there. > > > >>> > > > >>> - Bert - > > > >>> > > > >>> (*) Since we're not going to see the class names often, we could even > > > spell it out as BoxedDoublePrecisionFloat and > > > ImmediateDoublePrecisionFloat. Only half joking. It would make the relation > > > to the abstract Float very clear. > > > >>> > > > >>> (**) We could also try to make the names googleable. I was surprised > > > to not get a good hit for "boxed immediate". Only "boxed unboxed" finds it. > > > Maybe there are two better words? > > > >> > > > >> I very much agree with Bert. But I'd suggest SmallDouble instead of > > > ImmediateDouble for consistency with SmallInteger. > > > > > > > > Then it would have to be LargeDouble for consistency with LargeInteger, > > > too. Which I don't find compelling. > > > > > > > > Also, with the 64 bit format we get many more immediate objects. There > > > already are immediate integers and characters, floats will be the third, > > > there could be more, like immediate points. For those, the small/large > > > distinction does not make sense. > > > > > > > > Maybe Eliot's idea of keeping "Float" in the name was best, but instead > > > of "small" use "immediate": > > > > > > > > Float - BoxedFloat - ImmediateFloat > > > > > > > > A Float is either a BoxedFloat or an ImmediateFloat, depending on > > > the magnitude of its exponent. > > > > > > I don't like the idea of putting a VM/Storage detail into the Class name. > > > The running system itself does not care about whether Floats or Integers > > > are > > > boxed or immediate. > > > > > > > I disagree. I think at least Smalltalk-80 has a philosophy of lifting as > > much out of the VM into the system, and hiding it from clients via > > encapsulation. So unlike many other VMs the compiler is in the system, the > > system explicitly separates SmallInteger, LargePositiveInteger and > > LargeNegativeInteger and implements large integer arithmetic with Smalltalk > > code that uses SmallIntegers. Note that the primitives are an optional > > extra optimization that the VM does not need to implement. So for me it is > > in keeping with the current system to use BoxedFloat and SmallFloat or > > BoxedDouble and SmallDouble. > > > > This lifting things up provides us with an extremely malleable system. > > Pushing things down into the VM does the opposite. > > >> >> I can understand. It is however a tradeoff between abstraction and malleability. >> I'd rather see everything done in Smalltalk. Yet primitives not exposing its >> innards. >> >> I think I just can't have the cake and have it, too. >> > yes, alas it is all about tradeoffs :-). But that's great. The more varieties the merrier. > > > > > > For example in RSqueakVM (aka SPy) there is no immediate > > > Integer whatsoever. Yes, tagged ints are read during image startup but they > > > aren't subsequently represented as immediates or tagged ints after that. > > > > > > > Well because it's implemented above RPython I guess it is using Python's > > bignum code directly. That's fine but its a bit of a cheat. >> >> I was talking of SmallInts here. There is no bignum code involved. >> On the RPython side, SmallIntegers are just objects that have a field >> that is not accessible from Smalltalk but keeps a machine-word integer. >> > Hmmm, somewhere there's got to be a discrimination between SmallIntegers and other objects, right? It is done. They are just objects but object identity is delegated to value identity [1]. All primitives know about this and they unwrap and rewrap the boxed machine int. It's just a straight-forward boxed implementation of integers. Where have I confused you? > > > > Just as input, in the Racket language and other Schemes, > > > the equivalent to our SmallInterger/LargeInteger is fixnum/bignum > > > and for floats they have flonums and "extflonums" (80bit). > > > > > > Best > > > -Tobias Best -Tobias [1]: https://bitbucket.org/pypy/lang-smalltalk/src/2a99a4827c84352bbd8344a327937…

Nov. 21, 2014

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Float hierarchy for 64-bit Spur

by Eliot Miranda

Hi Tobias, On Fri, Nov 21, 2014 at 10:52 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Hi Eliot > > On 21.11.2014, at 19:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Tobias, > > > > On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > > > > Hi, > > > > > > On 21.11.2014, at 13:44, Bert Freudenberg <bert(a)freudenbergs.de> > wrote: > > > > > > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) < > > > juanlists(a)jvuletich.org> wrote: > > > > > > > >> Quoting Bert Freudenberg <bert(a)freudenbergs.de>: > > > >>> > > > >>> I'd suggest BoxedDouble and ImmediateDouble as names for the > concrete > > > subclasses (*). Names do mean something. (**) > > > >>> > > > >>> You're right about the FloatArray confusion. However, note that the > > > IEEE standard calls it single and double. It's only C using "float" to > mean > > > "single precision". > > > >>> > > > >>> I'd name the abstract superclass Float, for readability, and the > > > isFloat test etc. Also: "Float pi" reads a lot nicer than anything > else. I > > > don't see the need for having a deep LimitedPrecisionReal - Float - > > > BoxedDouble/ImmediateDouble deep hierarchy now. > > > >>> > > > >>> If we ever add single-precision floats, we should name them > > > BoxedSingle and ImmediateSingle. At that point we might want a Single > > > superclass and a LimitedPrecisionReal supersuperclass, but we can cross > > > that bridge when we get there. > > > >>> > > > >>> - Bert - > > > >>> > > > >>> (*) Since we're not going to see the class names often, we could > even > > > spell it out as BoxedDoublePrecisionFloat and > > > ImmediateDoublePrecisionFloat. Only half joking. It would make the > relation > > > to the abstract Float very clear. > > > >>> > > > >>> (**) We could also try to make the names googleable. I was > surprised > > > to not get a good hit for "boxed immediate". Only "boxed unboxed" > finds it. > > > Maybe there are two better words? > > > >> > > > >> I very much agree with Bert. But I'd suggest SmallDouble instead of > > > ImmediateDouble for consistency with SmallInteger. > > > > > > > > Then it would have to be LargeDouble for consistency with > LargeInteger, > > > too. Which I don't find compelling. > > > > > > > > Also, with the 64 bit format we get many more immediate objects. > There > > > already are immediate integers and characters, floats will be the > third, > > > there could be more, like immediate points. For those, the small/large > > > distinction does not make sense. > > > > > > > > Maybe Eliot's idea of keeping "Float" in the name was best, but > instead > > > of "small" use "immediate": > > > > > > > > Float - BoxedFloat - ImmediateFloat > > > > > > > > A Float is either a BoxedFloat or an ImmediateFloat, depending > on > > > the magnitude of its exponent. > > > > > > I don't like the idea of putting a VM/Storage detail into the Class > name. > > > The running system itself does not care about whether Floats or > Integers > > > are > > > boxed or immediate. > > > > > > > I disagree. I think at least Smalltalk-80 has a philosophy of lifting as > > much out of the VM into the system, and hiding it from clients via > > encapsulation. So unlike many other VMs the compiler is in the system, > the > > system explicitly separates SmallInteger, LargePositiveInteger and > > LargeNegativeInteger and implements large integer arithmetic with > Smalltalk > > code that uses SmallIntegers. Note that the primitives are an optional > > extra optimization that the VM does not need to implement. So for me it > is > > in keeping with the current system to use BoxedFloat and SmallFloat or > > BoxedDouble and SmallDouble. > > > > This lifting things up provides us with an extremely malleable system. > > Pushing things down into the VM does the opposite. > > > > I can understand. It is however a tradeoff between abstraction and > malleability. > I'd rather see everything done in Smalltalk. Yet primitives not exposing > its > innards. > > I think I just can't have the cake and have it, too. > yes, alas it is all about tradeoffs :-). But that's great. The more varieties the merrier. > > > > > For example in RSqueakVM (aka SPy) there is no immediate > > > Integer whatsoever. Yes, tagged ints are read during image startup but > they > > > aren't subsequently represented as immediates or tagged ints after > that. > > > > > > > Well because it's implemented above RPython I guess it is using Python's > > bignum code directly. That's fine but its a bit of a cheat. > > I was talking of SmallInts here. There is no bignum code involved. > On the RPython side, SmallIntegers are just objects that have a field > that is not accessible from Smalltalk but keeps a machine-word integer. > Hmmm, somewhere there's got to be a discrimination between SmallIntegers and other objects, right? > > Just as input, in the Racket language and other Schemes, > > > the equivalent to our SmallInterger/LargeInteger is fixnum/bignum > > > and for floats they have flonums and "extflonums" (80bit). > > > > > > Best > > > -Tobias > -- best, Eliot

Nov. 21, 2014

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Float hierarchy for 64-bit Spur

by Tobias Pape

Hi Eliot On 21.11.2014, at 19:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Tobias, > > On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > > Hi, > > > > On 21.11.2014, at 13:44, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > > > > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) < > > juanlists(a)jvuletich.org> wrote: > > > > > >> Quoting Bert Freudenberg <bert(a)freudenbergs.de>: > > >>> > > >>> I'd suggest BoxedDouble and ImmediateDouble as names for the concrete > > subclasses (*). Names do mean something. (**) > > >>> > > >>> You're right about the FloatArray confusion. However, note that the > > IEEE standard calls it single and double. It's only C using "float" to mean > > "single precision". > > >>> > > >>> I'd name the abstract superclass Float, for readability, and the > > isFloat test etc. Also: "Float pi" reads a lot nicer than anything else. I > > don't see the need for having a deep LimitedPrecisionReal - Float - > > BoxedDouble/ImmediateDouble deep hierarchy now. > > >>> > > >>> If we ever add single-precision floats, we should name them > > BoxedSingle and ImmediateSingle. At that point we might want a Single > > superclass and a LimitedPrecisionReal supersuperclass, but we can cross > > that bridge when we get there. > > >>> > > >>> - Bert - > > >>> > > >>> (*) Since we're not going to see the class names often, we could even > > spell it out as BoxedDoublePrecisionFloat and > > ImmediateDoublePrecisionFloat. Only half joking. It would make the relation > > to the abstract Float very clear. > > >>> > > >>> (**) We could also try to make the names googleable. I was surprised > > to not get a good hit for "boxed immediate". Only "boxed unboxed" finds it. > > Maybe there are two better words? > > >> > > >> I very much agree with Bert. But I'd suggest SmallDouble instead of > > ImmediateDouble for consistency with SmallInteger. > > > > > > Then it would have to be LargeDouble for consistency with LargeInteger, > > too. Which I don't find compelling. > > > > > > Also, with the 64 bit format we get many more immediate objects. There > > already are immediate integers and characters, floats will be the third, > > there could be more, like immediate points. For those, the small/large > > distinction does not make sense. > > > > > > Maybe Eliot's idea of keeping "Float" in the name was best, but instead > > of "small" use "immediate": > > > > > > Float - BoxedFloat - ImmediateFloat > > > > > > A Float is either a BoxedFloat or an ImmediateFloat, depending on > > the magnitude of its exponent. > > > > I don't like the idea of putting a VM/Storage detail into the Class name. > > The running system itself does not care about whether Floats or Integers > > are > > boxed or immediate. > > > > I disagree. I think at least Smalltalk-80 has a philosophy of lifting as > much out of the VM into the system, and hiding it from clients via > encapsulation. So unlike many other VMs the compiler is in the system, the > system explicitly separates SmallInteger, LargePositiveInteger and > LargeNegativeInteger and implements large integer arithmetic with Smalltalk > code that uses SmallIntegers. Note that the primitives are an optional > extra optimization that the VM does not need to implement. So for me it is > in keeping with the current system to use BoxedFloat and SmallFloat or > BoxedDouble and SmallDouble. > > This lifting things up provides us with an extremely malleable system. > Pushing things down into the VM does the opposite. > I can understand. It is however a tradeoff between abstraction and malleability. I'd rather see everything done in Smalltalk. Yet primitives not exposing its innards. I think I just can't have the cake and have it, too. > > For example in RSqueakVM (aka SPy) there is no immediate > > Integer whatsoever. Yes, tagged ints are read during image startup but they > > aren't subsequently represented as immediates or tagged ints after that. > > > > Well because it's implemented above RPython I guess it is using Python's > bignum code directly. That's fine but its a bit of a cheat. I was talking of SmallInts here. There is no bignum code involved. On the RPython side, SmallIntegers are just objects that have a field that is not accessible from Smalltalk but keeps a machine-word integer. > > > > > > Just as input, in the Racket language and other Schemes, > > the equivalent to our SmallInterger/LargeInteger is fixnum/bignum > > and for floats they have flonums and "extflonums" (80bit). > > > > Best > > -Tobias > >

Nov. 21, 2014

Re: [Pharo-dev] [squeak-dev] Float hierarchy for 64-bit Spur

by Eliot Miranda

Hi Tobias, On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Hi, > > On 21.11.2014, at 13:44, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) < > juanlists(a)jvuletich.org> wrote: > > > >> Quoting Bert Freudenberg <bert(a)freudenbergs.de>: > >>> > >>> I'd suggest BoxedDouble and ImmediateDouble as names for the concrete > subclasses (*). Names do mean something. (**) > >>> > >>> You're right about the FloatArray confusion. However, note that the > IEEE standard calls it single and double. It's only C using "float" to mean > "single precision". > >>> > >>> I'd name the abstract superclass Float, for readability, and the > isFloat test etc. Also: "Float pi" reads a lot nicer than anything else. I > don't see the need for having a deep LimitedPrecisionReal - Float - > BoxedDouble/ImmediateDouble deep hierarchy now. > >>> > >>> If we ever add single-precision floats, we should name them > BoxedSingle and ImmediateSingle. At that point we might want a Single > superclass and a LimitedPrecisionReal supersuperclass, but we can cross > that bridge when we get there. > >>> > >>> - Bert - > >>> > >>> (*) Since we're not going to see the class names often, we could even > spell it out as BoxedDoublePrecisionFloat and > ImmediateDoublePrecisionFloat. Only half joking. It would make the relation > to the abstract Float very clear. > >>> > >>> (**) We could also try to make the names googleable. I was surprised > to not get a good hit for "boxed immediate". Only "boxed unboxed" finds it. > Maybe there are two better words? > >> > >> I very much agree with Bert. But I'd suggest SmallDouble instead of > ImmediateDouble for consistency with SmallInteger. > > > > Then it would have to be LargeDouble for consistency with LargeInteger, > too. Which I don't find compelling. > > > > Also, with the 64 bit format we get many more immediate objects. There > already are immediate integers and characters, floats will be the third, > there could be more, like immediate points. For those, the small/large > distinction does not make sense. > > > > Maybe Eliot's idea of keeping "Float" in the name was best, but instead > of "small" use "immediate": > > > > Float - BoxedFloat - ImmediateFloat > > > > A Float is either a BoxedFloat or an ImmediateFloat, depending on > the magnitude of its exponent. > > I don't like the idea of putting a VM/Storage detail into the Class name. > The running system itself does not care about whether Floats or Integers > are > boxed or immediate. > I disagree. I think at least Smalltalk-80 has a philosophy of lifting as much out of the VM into the system, and hiding it from clients via encapsulation. So unlike many other VMs the compiler is in the system, the system explicitly separates SmallInteger, LargePositiveInteger and LargeNegativeInteger and implements large integer arithmetic with Smalltalk code that uses SmallIntegers. Note that the primitives are an optional extra optimization that the VM does not need to implement. So for me it is in keeping with the current system to use BoxedFloat and SmallFloat or BoxedDouble and SmallDouble. This lifting things up provides us with an extremely malleable system. Pushing things down into the VM does the opposite. For example in RSqueakVM (aka SPy) there is no immediate > Integer whatsoever. Yes, tagged ints are read during image startup but they > aren't subsequently represented as immediates or tagged ints after that. > Well because it's implemented above RPython I guess it is using Python's bignum code directly. That's fine but its a bit of a cheat. > > Just as input, in the Racket language and other Schemes, > the equivalent to our SmallInterger/LargeInteger is fixnum/bignum > and for floats they have flonums and "extflonums" (80bit). > > Best > -Tobias thanks -- best, Eliot

Nov. 21, 2014