- Pharo-dev - lists.pharo.org

[ANN] Hubcap - a SmalltalkHub API and browser for Pharo

by Stephan Eggermont

Nice! I like being able to quickly search for someone and see their projects. Useful extensions would be: - Teams and their projects - My teams - Sorting mczs I think I'd prefer the menu location to be with Configuration Browser When I type moose<enter> there is an exception. There is an empty Array somewhere where you expect an OrderdCollection. I don't understand why the delay in the response from smalltalkhub is always so large. Stephan

Nov. 21, 2014

Re: [Pharo-dev] About the Playground cache

by Stephan Eggermont

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

Nov. 21, 2014

Re: [Pharo-dev] [Pharo-users] [ANN] Hubcap - a SmalltalkHub API and browser for Pharo

by Sven Van Caekenberghe

Yes, very nice. > On 21 Nov 2014, at 08:35, Hilaire <hilaire(a)drgeo.eu> wrote: > > Le 21/11/2014 08:32, Torsten Bergmann a Ã©crit : >> as I wanted to browse the SmalltalkHub contents directly from within Pharo image >> I wrote a simple browser: > > > Cool! > > Thanks > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > >

Nov. 21, 2014

[ANN] Hubcap - a SmalltalkHub API and browser for Pharo

by Torsten Bergmann

Hi, as I wanted to browse the SmalltalkHub contents directly from within Pharo image I wrote a simple browser: Gofer it url: 'http://www.smalltalkhub.com/mc/TorstenBergmann/Hubcap/main'; configurationOf: 'Hubcap'; loadDevelopment. Attached is a screenshot. Works on Pharo 4.0. Still not finished but maybe it is already useful to others as well. One can access the tool from the world menu, implementation lives in "Hubcap-Tools" package. The UI shows and allows to filter users, shows their projects and packages. Special icons display the state (loaded, modified, public writable, ...). One can load from the UI or open Monticello tools. The "Hubcap-Core" package includes an API to query STHub and write expressions like: HubClient new allProjectsForUserNamed: 'TorstenBergmann' HubClient new hasUserNamed: 'TorstenBergmann' So "Hubcap-Core" may be usefull to people who want to build other tools that depend on STHub infos. Basic documentation lives on http://www.smalltalkhub.com/#!/~TorstenBergmann/Hubcap and as class comment on ConfigurationOfHubcap. Beware: the tool is sill not optimized, any clicking involves a query to STHub (hope STHub will not crash when many people use it). API may still undergo changes in the future. Also teams are not yet supported as STHub still returns an MNU error in the REST interface: http://www.smalltalkhub.com/hub/teams?term=Pharo Anyone able to fix that? Thanks to Stephan Eggermonts who gave me the initial idea with some code I've found in "Deprecation finder" and to Sven for the easy to use NeoJSON package. Contributors can just commit, the project is public. Bye T.

Nov. 21, 2014

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

by Ben Coman

Ben Coman wrote: > > Eliot Miranda wrote: >> >> Hi Ben, >> >> On Nov 20, 2014, at 8:42 PM, Ben Coman <btc(a)openInWorld.com> wrote: >> >>> Eliot Miranda wrote: >>>> On Thu, Nov 20, 2014 at 7:00 PM, Ben Coman <btc(a)openinworld.com >>>> <mailto:btc@openinworld.com>> wrote: >>>> Eliot Miranda wrote: >>>> Hi All, >>>> 64-bit Spur can usefully provide an immediate float, a >>>> 61-bit subset of the ieee double precision float. I >>>> wonder if class SmallDouble would be more intention revealing? >>>> In practice 61 bits will be "more than enough"(tm) for anyone. But I >>>> can envisage in a business environment environment software needing >>>> to comply with (sometimes irrelevant) feature checklists, with one >>>> of those likely being full 64 bit compliant IEEE Doubles. Can we >>>> have such a class, to which 61 bit floats are auto-promoted as >>>> required? >>>> Just as SmallInteger is seamless with the large integers, so >>>> SmallFloat is seamless with boxed Float. The SmallFloat >>>> representation is used where ever possible, since it is faster both >>>> to decode (no memory fetch) and to encode (no allocation). But >>>> operations overflow into the boxed representation if outside the >>>> SmallFloat range. >>> (btw, rather than SmallFloat and BoxedFloat, I think SmallFloat and >>> LargeFloat would align better with the Integer hierarchy.) >>> >>> So I understand that immediate types will overflow to boxes types :) >>> >>> To try to be more clear, integers don't have a well defined >>> size/format. It varies with architecture word size. So SmallInteger >>> and LargeInteger are reasonable descriptions. But floats have a well >>> defined format defined by IEEE. Since you are pivoting around the >>> IEEE Double format (you define it as "61-bit subset of the ieee >>> double precision float"), rather than generic SmallFloat and >>> LargeFloat, use SmallDouble and LargeDouble. (anyway, maybe I'm off >>> track. Its not a big deal). >> >> Ah, I like this. Thanks. a random thought on implementation of LargeDouble... is it worth considering a performance versus space tradeoff... rather than boxing LargeDouble so that access through a pointer reduces performance(?), could the value be stored in a second 64bits adjacent to the first? Or does being 128 bits in total complicate things too much? cheers -ben

Nov. 21, 2014

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

by Ben Coman

Eliot Miranda wrote: > > Hi Ben, > > On Nov 20, 2014, at 8:42 PM, Ben Coman <btc(a)openInWorld.com> wrote: > >> Eliot Miranda wrote: >>> On Thu, Nov 20, 2014 at 7:00 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>> Eliot Miranda wrote: >>> Hi All, >>> 64-bit Spur can usefully provide an immediate float, a >>> 61-bit subset of the ieee double precision float. I wonder if class SmallDouble would be more intention revealing? >>> In practice 61 bits will be "more than enough"(tm) for anyone. But I >>> can envisage in a business environment environment software needing >>> to comply with (sometimes irrelevant) feature checklists, with one >>> of those likely being full 64 bit compliant IEEE Doubles. Can we >>> have such a class, to which 61 bit floats are auto-promoted as required? >>> Just as SmallInteger is seamless with the large integers, so SmallFloat is seamless with boxed Float. The SmallFloat representation is used where ever possible, since it is faster both to decode (no memory fetch) and to encode (no allocation). But operations overflow into the boxed representation if outside the SmallFloat range. >> (btw, rather than SmallFloat and BoxedFloat, I think SmallFloat and LargeFloat would align better with the Integer hierarchy.) >> >> So I understand that immediate types will overflow to boxes types :) >> >> To try to be more clear, integers don't have a well defined size/format. It varies with architecture word size. So SmallInteger and LargeInteger are reasonable descriptions. But floats have a well defined format defined by IEEE. Since you are pivoting around the IEEE Double format (you define it as "61-bit subset of the ieee double precision float"), rather than generic SmallFloat and LargeFloat, use SmallDouble and LargeDouble. (anyway, maybe I'm off track. Its not a big deal). > > Ah, I like this. Thanks. Cool. :) David T. Lewis wrote: > > 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. You also might also have Single subclassed from abstract Float. cheers -ben

Nov. 21, 2014

New Cog VMs available

by Eliot Miranda

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3143. CogVM binaries as per VMMaker.oscog-tpr.949/r3143 Spur: Fix regression in primitiveNewWithArg from VMMaker.oscog-eem.859 which caused basicNew: on fixed classes to raise OutOfMemory instead of the relevant error. Have checkForAndFollowForwardedPrimitiveState follow other references in the frame if a forwarder is found on the stack. All: Add a first cut at the primitiveSlotAt[Put] primitives. Reimplement primitiveBitShift for 64-bits. Define areIntegers:and: for 64-bit Spur, and move it into the ObjectMemory hierarchies. Add maxSmallInteger and minSmallInteger and matching manifest constants. Use these in LargeIntegersPlugin and Matrix2x3Plugin. Use numBytesOf: instead of lengthOf: in the 64-bit integer conversion routines. Reorder cases in Spur's numBytesOf: to put common case first. -- best, Eliot

Nov. 21, 2014

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

by Eliot Miranda

Hi Ben, On Nov 20, 2014, at 8:42 PM, Ben Coman <btc(a)openInWorld.com> wrote: > Eliot Miranda wrote: >> On Thu, Nov 20, 2014 at 7:00 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> Eliot Miranda wrote: >> Hi All, >> 64-bit Spur can usefully provide an immediate float, a >> 61-bit subset of the ieee double precision float. I wonder if class SmallDouble would be more intention revealing? >> In practice 61 bits will be "more than enough"(tm) for anyone. But I >> can envisage in a business environment environment software needing >> to comply with (sometimes irrelevant) feature checklists, with one >> of those likely being full 64 bit compliant IEEE Doubles. Can we >> have such a class, to which 61 bit floats are auto-promoted as required? >> Just as SmallInteger is seamless with the large integers, so SmallFloat is seamless with boxed Float. The SmallFloat representation is used where ever possible, since it is faster both to decode (no memory fetch) and to encode (no allocation). But operations overflow into the boxed representation if outside the SmallFloat range. > > (btw, rather than SmallFloat and BoxedFloat, I think SmallFloat and LargeFloat would align better with the Integer hierarchy.) > > So I understand that immediate types will overflow to boxes types :) > > To try to be more clear, integers don't have a well defined size/format. It varies with architecture word size. So SmallInteger and LargeInteger are reasonable descriptions. But floats have a well defined format defined by IEEE. Since you are pivoting around the IEEE Double format (you define it as "61-bit subset of the ieee double precision float"), rather than generic SmallFloat and LargeFloat, use SmallDouble and LargeDouble. (anyway, maybe I'm off track. Its not a big deal). Ah, I like this. Thanks. >> My first few pages of search results lead to a few references in >> conversation, but nothing that described what a boxed float is. Can >> someone explain? >> Boxed datatypes are those where the data is held in a structure (e.g. an object) and accessed throguh a pointer. So most Smalltalk objects are "boxed", for example, large integers, points, etc. But some datatypes (immediate SmallIntegers, and in Spur, the Characters, and in languages like C, all basic numeric types) are represented as pure values. > > Thanks. > > cheers -ben Eliot (phone)

Nov. 21, 2014

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

by Ben Coman

Eliot Miranda wrote: > > On Thu, Nov 20, 2014 at 7:00 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > > Eliot Miranda wrote: > > Hi All, > > 64-bit Spur can usefully provide an immediate float, a > 61-bit subset of the ieee double precision float. > > > I wonder if class SmallDouble would be more intention revealing? > > In practice 61 bits will be "more than enough"(tm) for anyone. But I > can envisage in a business environment environment software needing > to comply with (sometimes irrelevant) feature checklists, with one > of those likely being full 64 bit compliant IEEE Doubles. Can we > have such a class, to which 61 bit floats are auto-promoted as required? > > > > Just as SmallInteger is seamless with the large integers, so SmallFloat > is seamless with boxed Float. The SmallFloat representation is used > where ever possible, since it is faster both to decode (no memory fetch) > and to encode (no allocation). But operations overflow into the boxed > representation if outside the SmallFloat range. > > (btw, rather than SmallFloat and BoxedFloat, I think SmallFloat and LargeFloat would align better with the Integer hierarchy.) So I understand that immediate types will overflow to boxes types :) To try to be more clear, integers don't have a well defined size/format. It varies with architecture word size. So SmallInteger and LargeInteger are reasonable descriptions. But floats have a well defined format defined by IEEE. Since you are pivoting around the IEEE Double format (you define it as "61-bit subset of the ieee double precision float"), rather than generic SmallFloat and LargeFloat, use SmallDouble and LargeDouble. (anyway, maybe I'm off track. Its not a big deal). > > > My first few pages of search results lead to a few references in > conversation, but nothing that described what a boxed float is. Can > someone explain? > > > Boxed datatypes are those where the data is held in a structure (e.g. an > object) and accessed throguh a pointer. So most Smalltalk objects are > "boxed", for example, large integers, points, etc. But some datatypes > (immediate SmallIntegers, and in Spur, the Characters, and in languages > like C, all basic numeric types) are represented as pure values. > Thanks. cheers -ben

Nov. 21, 2014

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

by Eliot Miranda

Hi Ben, On Thu, Nov 20, 2014 at 7:00 PM, Ben Coman <btc(a)openinworld.com> wrote: > > (sorry, I didn't notice the cross-post) Thanks, Ben. Eliot Miranda wrote: > >> Hi All, >> >> 64-bit Spur can usefully provide an immediate float, a 61-bit subset >> of the ieee double precision float. >> > > I wonder if class SmallDouble would be more intention revealing? > > In practice 61 bits will be "more than enough"(tm) for anyone. But I can > envisage in a business environment environment software needing to comply > with (sometimes irrelevant) feature checklists, with one of those likely > being full 64 bit compliant IEEE Doubles. Can we have such a class, to > which 61 bit floats are auto-promoted as required? Just as SmallInteger is seamless with the large integers, so SmallFloat is seamless with boxed Float. The SmallFloat representation is used where ever possible, since it is faster both to decode (no memory fetch) and to encode (no allocation). But operations overflow into the boxed representation if outside the SmallFloat range. 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. >> >> > My first few pages of search results lead to a few references in > conversation, but nothing that described what a boxed float is. Can > someone explain? > Boxed datatypes are those where the data is held in a structure (e.g. an object) and accessed throguh a pointer. So most Smalltalk objects are "boxed", for example, large integers, points, etc. But some datatypes (immediate SmallIntegers, and in Spur, the Characters, and in languages like C, all basic numeric types) are represented as pure values. > btw, http://www.ctan.org/pkg/float > also mentioned boxed float, ruled float and plainÂtop float > Anyone familiar with those? > Hmmm, never heard of ruled and plaintop floats. I'd like to know too. 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". >> > > This is probably a good change anyway. > > >> - 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. >> > > ** do you mean the current Float, or after Float become abstract? The former. If Float stays unchanged and one tries to add SmallFloat as a subclass then one hits the primitive failure problem. If SmallFloat doesn't inherit from BoxedFloat (when Float is abstract with BoxedFloat and SmallFloat as subclasses), or if SmallFloat doesn't inherit from Float (when LimitedPrecisionReal is abstract, and BoxedFloat and SmallFloat inherit from it) then there's no such problem. > > > >> >> 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. >> >> > A Float is defined as a limited precision real [1] having several types > of precision, so I like the first option. > > [1] http://en.wikipedia.org/wiki/Floating_point > > cheers -ben > OK, thanks! -- best, Eliot

Nov. 21, 2014