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

Re: [Pharo-dev] Update Fuel documentation

by Max Leske

Thanks Nicolas. Weâll update the docs and fix the configuration. Has 4.5 been released? We had decided to wait with support for 4.5 until it was released to prevent repetitive work. If 4.5 has indeed been released weâll of course add support for 4.5. Cheers, Max On 01.11.2013, at 21:37, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > This page http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation/… has obsolete information, at least for Squeak installation. > > This is because ConfigurationOfFuel-MaxLeske.178 still points to old repository http://ss3.gemstone.com/ss/Fuel.html which has been drained... > ConfigurationOfFuel-MartinDias.209 should be a better starting point. > > In latest Squeak trunk there is another problem: lack of squeak4.5.x support both in ConfigurationOfFuel and MetacelloSqueakPlatform>>defaultPlatformAttributes. > But it's another problem, not related to documentation

Nov. 2, 2013

smalltalkhub is down

by Tudor Girba

smalltalkhub is down: http://www.downforeveryoneorjustme.com/smalltalkhub.com Doru -- www.tudorgirba.com "Every thing has its own flow"

Nov. 2, 2013

Re: [Pharo-dev] how to set another inspector/explorer

by Marcus Denker

On 02 Nov 2013, at 07:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> > It should not. I thought I removed it. ObjectExplorer should be removed eventually (it is now only used for the PointerExplorer, which is a subclass). > >> Anyway, I added #inspect: and #explore: to GTInspector class, and I registered it as the #inspector. It seems fine, but the problem now is that the default Spec-based debugger relies on a #inspectorSpec method in the inspector class. >> I think this can be easily fixed: somewhere in the Debugger, it calls Smalltalk tools inspector where it should hard-code EyeInspector, as the Debugger require this specific implementation. Now finding that placeâ¦ I will check Marcus

Nov. 2, 2013

Re: [Pharo-dev] how to set another inspector/explorer

by Marcus Denker

On 01 Nov 2013, at 22:49, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am trying to set the GTInspector as the default explorer. > > However, I see that the inspector registration has changed. It seems to me that registering to #objectExplorer has no effect. Instead, we are now sending #inspect: and #explore to the #inspector: > > Object>>explore > ^Smalltalk tools inspector explore: self > > I do not quite see the rationale behind the current design. With the new inspector, the inspector and explorer are the same tool. If you open a normal inspector, you can even turn it into an explorer with a keyboard shortcut. Therefore it makes conceptually no sense to have a #objectExplorer tool. There was a basicInspector in the tools, too, which is now gone. Explorers are just special inspectors, like the special inspectors for CompiledMethod or Dictionary, just available for all classes. > Furthermore, Smalltalk tools still has an entry for #objectExplorer: > (Smalltalk tools instVarNamed: #tools) at: #objectExplorer ==> ObjectExplorer > It should not. I thought I removed it. ObjectExplorer should be removed eventually (it is now only used for the PointerExplorer, which is a subclass). > Anyway, I added #inspect: and #explore: to GTInspector class, and I registered it as the #inspector. It seems fine, but the problem now is that the default Spec-based debugger relies on a #inspectorSpec method in the inspector class. > > This is highly problematic and I am stuck. I think we should not introduce Spec-specific requirements at such a basic level. > It should normally not âleakâ that the inspector is implemented with Spec, you should be able to replace the inspector (via Smalltalk tools) with another one. So this should be checked and fixed. But it is clear that we can not have all the tools âin a crap version in the kernelâ and âthat version that everyone usesâ. This Philosophy is *wrong* just the same for tools as it is for libraries. Marcus

Nov. 2, 2013

Re: [Pharo-dev] Proposal for a Topic for the bachelor/master list [safe-image for teaching]

by btc＠openinworld.com

Nov. 2, 2013

Re: [Pharo-dev] flatCollect:

by Sebastian Tleye

Hi, flatCollect: is called by Collection>>gather: instead of renaming gather: what we did is add "flatCollect:" to keep compatibility. Take into account that if you change what flatCollect: returns it will affect all the methods that use "gather:" 2013/11/1 Gabriel Cotelli <g.cotelli(a)gmail.com> > I don't have a Pharo at hand now,but if species returns the class of the > collection, be carefull with SortedCollection because in that case the > sortBlock could not work with the collected objects. > > > On Fri, Nov 1, 2013 at 7:55 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> I see that Pharo 3.0 has a Collection>>flatCollect:. This is great as the >> method proved to be very valuable in the context of Moose. >> >> However, the current Pharo implementation is less ideal: >> >> Collection>>flatCollect: aBlock >> ^ Array streamContents: >> [:stream | >> self do: [:ea | stream nextPutAll: (aBlock value: ea)]] >> >> The Moose one is: >> Collection>>flatCollect: aBlock >> "Evaluate aBlock for each of the receiver's elements and answer the >> list of all resulting values flatten one level. Assumes that aBlock >> returns some kind >> of collection for each element. Equivalent to the lisp's mapcan" >> "original written by a. Kuhn and released under MIT" >> | stream | >> self isEmpty ifTrue: [ ^ self copy ]. >> stream := (self species new: 0) writeStream. >> self do: [ :each | stream nextPutAll: (aBlock value: each) ]. >> ^ stream contents >> >> The difference is in the type returned. The Pharo one always returns >> Array, while the Moose one returns a collection of the same species as the >> receiver. >> >> Does anyone have anything against the Moose implementation? >> >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

Nov. 1, 2013

Re: [Pharo-dev] flatCollect:

by Gabriel Cotelli

I don't have a Pharo at hand now,but if species returns the class of the collection, be carefull with SortedCollection because in that case the sortBlock could not work with the collected objects. On Fri, Nov 1, 2013 at 7:55 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I see that Pharo 3.0 has a Collection>>flatCollect:. This is great as the > method proved to be very valuable in the context of Moose. > > However, the current Pharo implementation is less ideal: > > Collection>>flatCollect: aBlock > ^ Array streamContents: > [:stream | > self do: [:ea | stream nextPutAll: (aBlock value: ea)]] > > The Moose one is: > Collection>>flatCollect: aBlock > "Evaluate aBlock for each of the receiver's elements and answer the > list of all resulting values flatten one level. Assumes that aBlock > returns some kind > of collection for each element. Equivalent to the lisp's mapcan" > "original written by a. Kuhn and released under MIT" > | stream | > self isEmpty ifTrue: [ ^ self copy ]. > stream := (self species new: 0) writeStream. > self do: [ :each | stream nextPutAll: (aBlock value: each) ]. > ^ stream contents > > The difference is in the type returned. The Pharo one always returns > Array, while the Moose one returns a collection of the same species as the > receiver. > > Does anyone have anything against the Moose implementation? > > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 1, 2013

flatCollect:

by Tudor Girba

Hi, I see that Pharo 3.0 has a Collection>>flatCollect:. This is great as the method proved to be very valuable in the context of Moose. However, the current Pharo implementation is less ideal: Collection>>flatCollect: aBlock ^ Array streamContents: [:stream | self do: [:ea | stream nextPutAll: (aBlock value: ea)]] The Moose one is: Collection>>flatCollect: aBlock "Evaluate aBlock for each of the receiver's elements and answer the list of all resulting values flatten one level. Assumes that aBlock returns some kind of collection for each element. Equivalent to the lisp's mapcan" "original written by a. Kuhn and released under MIT" | stream | self isEmpty ifTrue: [ ^ self copy ]. stream := (self species new: 0) writeStream. self do: [ :each | stream nextPutAll: (aBlock value: each) ]. ^ stream contents The difference is in the type returned. The Pharo one always returns Array, while the Moose one returns a collection of the same species as the receiver. Does anyone have anything against the Moose implementation? Doru -- www.tudorgirba.com "Every thing has its own flow"

Nov. 1, 2013

Re: [Pharo-dev] Strange primitive failure

by Eliot Miranda

Hi Ben, On Fri, Nov 1, 2013 at 7:01 AM, Benjamin < Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Hello guys, > > is it expected that > > 1 perform: #gcd: withArguments: {2} > works > > while > > 1 perform: #gcd: withArguments: {2} asOrderedCollection > fails ? > As Alexandre explained it's because the VM insists on an Array. But there is a neat way to solve this. e.g. if the method is defined as Object>>perform: selector withArguments: argArray "Send the selector, aSymbol, to the receiver with arguments in argArray. Fail if the number of arguments expected by the selector does not match the size of argArray. Primitive. Optional. See Object documentation whatIsAPrimitive." <primitive: 84> ^ self perform: selector withArguments: argArray inSuperclass: self class and Object>>perform: selector withArguments: argArray inSuperclass: lookupClass "NOTE: This is just like perform:withArguments:, except that the message lookup process begins, not with the receivers's class, but with the supplied superclass instead. It will fail if lookupClass cannot be found among the receiver's superclasses. Primitive. Essential. See Object documentation whatIsAPrimitive." <primitive: 100> (selector isSymbol) ifFalse: [^ self error: 'selector argument must be a Symbol']. (selector numArgs = argArray size) ifFalse: [^ self error: 'incorrect number of arguments']. (self class == lookupClass or: [self class inheritsFrom: lookupClass]) ifFalse: [^ self error: 'lookupClass is not in my inheritance chain']. self primitiveFailed then redefine perform:withArguments:inSuperclass: to read something like: Object>>perform: selector withArguments: argArray inSuperclass: lookupClass "NOTE: This is just like perform:withArguments:, except that the message lookup process begins, not with the receivers's class, but with the supplied superclass instead. It will fail if lookupClass cannot be found among the receiver's superclasses. Primitive. Essential. See Object documentation whatIsAPrimitive." <primitive: 100> (argArray isCollection and: [argArray isSequenceable and: [argArray class ~~ Array]]) ifTrue: [^self perform: selector withArguments: argArray asArray inSuperclass: lookupClass]. selector isSymbol ifFalse: [^ self error: 'selector argument must be a Symbol']. selector numArgs = argArray size ifFalse: [^ self error: 'incorrect number of arguments']. (self class == lookupClass or: [self class inheritsFrom: lookupClass]) ifFalse: [^ self error: 'lookupClass is not in my inheritance chain']. self primitiveFailed c.f. e.g. the asInteger send in Object>>at: index "Primitive. Assumes receiver is indexable. Answer the value of an indexable element in the receiver. Fail if the argument index is not an Integer or is out of bounds. Essential. See Object documentation whatIsAPrimitive." <primitive: 60> index isInteger ifTrue: [self class isVariable ifTrue: [self errorSubscriptBounds: index] ifFalse: [self errorNotIndexable]]. index isNumber ifTrue: [^self at: index asInteger] ifFalse: [self errorNonIntegerIndex] which allows one to write #(seriously ?) at: 1.0 HTH, Eliot

Nov. 1, 2013

Re: [Pharo-dev] Fuel: fix for Squeak trunk

by StÃ©phane Ducasse

> I have an easy fix for Fuel on Squeak trunk. > It concerns the FuelCompatibility layer, so I hesitate to publish on Pharo fogbugz... > Is there a dedicated bug tracker? check because may be there is a fuel subproject in fogbugz > What is the preferred procedure? > > Nicolas

Nov. 1, 2013