- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ConfigurationOfGlamour not connected to repository

by Tudor Girba

Hi Stephan, Indeed, these are not needed. Those groups are not maintainable and make tool building a nightmare. We will remove them from all Moose configurations eventually :). Doru On Fri, Nov 21, 2014 at 1:41 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hmm, there are also other configurations still loaded that should have > been removed > ConfigurationOfGTInspector > ConfigurationOfGTPlayground. > > Though I'd prefer to see them as groups in a ConfigurationOfGToolkit > > Stephan > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 21, 2014

Re: [Pharo-dev] VM fixes to review

by Ben Coman

Ben Coman wrote: > Marcus Denker wrote: >>> On 21 Nov 2014, at 13:21, stepharo <stepharo(a)free.fr> wrote: >>> >>> can you mark them as 4.0 >>> >> >> The problem is that they now show up in the integrator app and the >> monkey will try to run them with a non-existing slice, failing them all. > > I checked they are all tagged NoMonkey. > Sorry I didn't consider the Integrator app. Maybe the integrator app should only show issues tagged "Fix To Include" ? -ben

Nov. 21, 2014

Re: [Pharo-dev] VM fixes to review

by Ben Coman

Marcus Denker wrote: >> On 21 Nov 2014, at 13:21, stepharo <stepharo(a)free.fr> wrote: >> >> can you mark them as 4.0 >> > > The problem is that they now show up in the integrator app and the monkey will try to run them with a non-existing slice, failing them all. I checked they are all tagged NoMonkey. Sorry I didn't consider the Integrator app. -ben > >> Stef >> >> Le 16/11/14 01:52, Ben Coman a Ã©crit : >>> I notice several VM fixes [1] submitted by Nicolas 6 months ago. They >>> are categorized as Milestone=Later, so I'm bumping them here just in case these slipped through the cracks to get them into Pharo 4. >>> >>> [1] https://pharo.fogbugz.com/default.asp?pgx=LF&ixFilter=36 >>> >>> But then I think I remember that early in Pharo 4 cycle, the Pharo VM was aligned more closely with with Eliot's - so maybe some of these are already included? >>> >>> cheers -ben >>> >>> >>> >> > > >

Nov. 21, 2014

Re: [Pharo-dev] ConfigurationOfGlamour not connected to repository

by Stephan Eggermont

Hmm, there are also other configurations still loaded that should have been removed ConfigurationOfGTInspector ConfigurationOfGTPlayground. Though I'd prefer to see them as groups in a ConfigurationOfGToolkit Stephan

Nov. 21, 2014

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

by Ben Coman

Bert Freudenberg wrote: > > > > ------------------------------------------------------------------------ > > > On 21.11.2014, at 04:19, David T. Lewis <lewis(a)mail.msen.com> wrote: > >> On Thu, Nov 20, 2014 at 05:51:42PM -0800, Eliot Miranda wrote: >>> 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. >>> >>> Thoughts? >> 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 >> 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 > > I'd suggest BoxedDouble and ImmediateDouble as names for the concrete subclasses (*). Names do mean something. (**) > This is a nice idea, except we have the legacy of SmallInteger and LargeInteger, and I don't like the inconsistency of Float not following the same rule. The boxing/unboxing can be covered in the class comment. Unless you want to change to BoxedInteger and ImmediateInteger ? cheers -ben > 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? >

Nov. 21, 2014

Re: [Pharo-dev] About the Playground cache

by Tudor Girba

Thanks. Doru On Fri, Nov 21, 2014 at 10:54 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 14513 <https://pharo.fogbugz.com/default.asp?14513> > GTPlayground cache does not truncate the current cache file > > 14512 <https://pharo.fogbugz.com/default.asp?14512> > GTPlayground duplicate the number of cache files on image start/stop > > > 2014-11-21 9:42 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > >> Hi Doru, >> >> You might want to try it on a machine with a HD instead of SSD >> Your machine is a few orders of magnitude faster in opening multiple >> small files >> >> Stephan >> > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 21, 2014

Re: [Pharo-dev] VM fixes to review

by Marcus Denker

> On 21 Nov 2014, at 13:21, stepharo <stepharo(a)free.fr> wrote: > > can you mark them as 4.0 > The problem is that they now show up in the integrator app and the monkey will try to run them with a non-existing slice, failing them all. > Stef > > Le 16/11/14 01:52, Ben Coman a Ã©crit : >> >> I notice several VM fixes [1] submitted by Nicolas 6 months ago. They >> are categorized as Milestone=Later, so I'm bumping them here just in case these slipped through the cracks to get them into Pharo 4. >> >> [1] https://pharo.fogbugz.com/default.asp?pgx=LF&ixFilter=36 >> >> But then I think I remember that early in Pharo 4 cycle, the Pharo VM was aligned more closely with with Eliot's - so maybe some of these are already included? >> >> cheers -ben >> >> >> > >

Nov. 21, 2014

Re: [Pharo-dev] VM fixes to review

by Ben Coman

stepharo wrote: > can you mark them as 4.0 > > Stef > > Le 16/11/14 01:52, Ben Coman a Ã©crit : >> >> I notice several VM fixes [1] submitted by Nicolas 6 months ago. They >> are categorized as Milestone=Later, so I'm bumping them here just in >> case these slipped through the cracks to get them into Pharo 4. >> >> [1] https://pharo.fogbugz.com/default.asp?pgx=LF&ixFilter=36 >> >> But then I think I remember that early in Pharo 4 cycle, the Pharo VM >> was aligned more closely with with Eliot's - so maybe some of these >> are already included? >> >> cheers -ben >> >> >> > > > done

Nov. 21, 2014

Re: [Pharo-dev] VM fixes to review

by Esteban Lorenzano

the problem was that everything changed a lot since then because for the time he submitted them I was making a HUGE synchronisation with Eliot sources. so I want those changes, a lotâ¦ but I asked him to review his fixes in the new context (because some changes could be already there due the sync, etc.) and reconfirm the pull request. and thatâs the status of those fixes so far :) Esteban > On 21 Nov 2014, at 13:21, stepharo <stepharo(a)free.fr> wrote: > > can you mark them as 4.0 > > Stef > > Le 16/11/14 01:52, Ben Coman a Ã©crit : >> >> I notice several VM fixes [1] submitted by Nicolas 6 months ago. They >> are categorized as Milestone=Later, so I'm bumping them here just in case these slipped through the cracks to get them into Pharo 4. >> >> [1] https://pharo.fogbugz.com/default.asp?pgx=LF&ixFilter=36 >> >> But then I think I remember that early in Pharo 4 cycle, the Pharo VM was aligned more closely with with Eliot's - so maybe some of these are already included? >> >> cheers -ben >> >> >> > >

Nov. 21, 2014

Re: [Pharo-dev] VM fixes to review

by stepharo

can you mark them as 4.0 Stef Le 16/11/14 01:52, Ben Coman a Ã©crit : > > I notice several VM fixes [1] submitted by Nicolas 6 months ago. They > are categorized as Milestone=Later, so I'm bumping them here just in > case these slipped through the cracks to get them into Pharo 4. > > [1] https://pharo.fogbugz.com/default.asp?pgx=LF&ixFilter=36 > > But then I think I remember that early in Pharo 4 cycle, the Pharo VM > was aligned more closely with with Eliot's - so maybe some of these > are already included? > > cheers -ben > > >

Nov. 21, 2014