- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] setting fonts in pharo 3.0

by Tudor Girba

Oh, I see. The previous code relied on the assumption that the free types are not enabled: FreeTypeSystemSettings loadFt2Library: true. This implicitly triggered the fonts update. So, now I am doing: FreeTypeFontProvider current updateFromSystem. and it works just fine. Thanks. Doru On Fri, Nov 1, 2013 at 10:40 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 01 Nov 2013, at 21:51, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > I am porting Moose to Pharo 3.0. I could get the image code to load > rather painlessly, and that is great. > > > > The first thing I notice is that something changed in the font > management: I cannot seem to be able to set non-bitmap fonts anymore. I > also noticed that the base Pharo image does not come with the advertised > non-bitmap fonts either. > > > > I am trying this: > > > > #('SourceCodeProRegular' 'SourceCodeProBold' 'SourceSansProRegular' > 'SourceSansProBold') do: [ :each | > > Gofer new > > smalltalkhubUser: 'girba' project: 'FreeFonts'; > > package: each; > > load. > > (Smalltalk at: each asSymbol) new install ]. > > FreeTypeSystemSettings loadFt2Library: true. > > StandardFonts > > setAllStandardFontsTo: (LogicalFont familyName: 'Source > Sans Pro' pointSize: 10); > > haloFont: (LogicalFont familyName: 'Source Sans Pro' > pointSize: 10); > > windowTitleFont: (LogicalFont familyName: 'Source Sans > Pro' pointSize: 14); > > balloonFont: (LogicalFont familyName: 'Source Sans Pro' > pointSize: 10); > > codeFont: (LogicalFont familyName: 'Source Code Pro' > pointSize: 10) > > > > Could anyone point me in the right direction? > > This is how I customise newly downloaded 3.0 images (filing in this code): > > === > Author fullName: 'SvenVanCaekenberghe'. > > TaskbarMorph showWindowPreview: false. > > SourceCodeProRegular new install. > OpenSansRegular new install. > FreeTypeFontProvider current updateFromSystem. > > #( > #(#defaultFont: 'Open Sans' 12) > #(#listFont: 'Open Sans' 12) > #(#menuFont: 'Open Sans' 12) > #(#windowTitleFont: 'Open Sans' 12) > #(#balloonFont: 'Open Sans' 10) > #(#codeFont: 'Source Code Pro' 11) > #(#buttonFont: 'Open Sans' 12) > #(#haloFont: 'Open Sans' 10)) do: [ :spec | > | font | > font := LogicalFont familyName: spec second pointSize: > spec third. > StandardFonts perform: spec first with: font ] > === > > I did not manage to make the window title font bold though ;-) > > Sven > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 1, 2013