May 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] implementors of...

by blake

If I have a method showing in the method pane, I can right-click on renderContentOn: and get a list of all the implementors of that method. What if I don't know of a class that has the renderContentOn: method? How can I find the classes then? ===Blake===

May 13, 2012

Re: [Pharo-project] Pharo and the ST-80 classes

by blake

On Sun, May 13, 2012 at 12:49 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Do you need it for a model or for drawing? > Because for drawing there is > > Â Â Â Â LineMorph > > stef I'm not sure what you mean by "a model". I've never been really good with Morphic, so when I started this current project and needed to render some simple graphics I went back to Stephen Wessel's Laser Game tutorial and noted he was using Line and some other ST80 classes. I know about LineMorph but I was shying away from it. When I think of a morph, I think of an object with all these propertiesâproperties that I don't want. (One of the things I love about Pharo is that I'm not always accidentally activating the damn halos!) What I like about the Line class is that I understand it: It's a collection of points and a form to draw them on. Simple.

May 13, 2012

Re: [Pharo-project] Implementors of...

by Hilaire Fernandes

The main drawback from usability point of view: it is an implicit feature, invisible to newbie and other out of the context. Hilaire On 13/05/2012 14:15, Nicolas Cellier wrote: > 2012/5/12 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: >> Hello :) >> >> Do you have opened an entry ? >> >> Honestly, I am not a fan of this mechanism (as Marcus said, when I want something specific, I select it from the text, then use shortcuts :) ) >> But I can understand you miss it. >> > > In Nautilus, unlike old Browser it now works for multiple keywords, so > things are improving. > Though in term of number of actions necessary to reach information, > I'm not sure it's a clear win. > There's a balance between simplicity and efficiency. > Isn't it also a step backward in promotion of keyboard navigation over > mouse navigation? > > Nicolas > >> >> Open an entry to be sure it's not lost in the mailing list, and as soon as I can, I will see to add a setting for this :) >> (right now I am more in a "bugs fix" phase that "add new features" one ^^) >> >> Ben >> >> >> >> On May 12, 2012, at 11:47 AM, Hilaire Fernandes wrote: >> >>> Tried from Nautilus: >>> >>> Why when asking 'implementors of ' in the method menu, I only got the >>> implementor of this method. >>> >>> Am I doing something wrong? >>> >>> Look like the browser need a lot of love. >>> >>> Hilaire >>> >>> -- >>> Dr. Geo -- http://www.drgeo.eu >>> >>> >> >> > > -- Dr. Geo -- http://www.drgeo.eu

May 13, 2012

[Pharo-project] FileBrowser/FileList rant

by Nicolas Cellier

Hi, it seems that FileBrowser/FileList is never used... And I absolutely don't understand some design choices. 1) Having a single reference inst var for both selectedDirectory and selectedFile : this is a bug factory, see http://code.google.com/p/pharo/issues/detail?id=5881 and http://code.google.com/p/pharo/issues/detail?id=5884 for example of bugs (I could open 1 bug entry per menu item I guess) 2) auto-selecting the file item under pop-up menu click This is a windows thing and anti-Smalltalk-UI-custom This is not at all uniform in the rest of Pharo UI (not even on the directory list) The implementation is buggish (see ttp://code.google.com/p/pharo/issues/detail?id=5882 which is duplicate of ttp://code.google.com/p/pharo/issues/detail?id=5625) There was (and still is) a specific menu when no file is selected... fileListMenu: aMenu reference ifNil: [^ self noFileSelectedMenu: aMenu] ifNotNil: [^ self fileSelectedMenu: aMenu]. I don't want to argue whether or not FileList did deserve a clean-up, I'm quite sure it did. And I also agree that we can temporarily break things in development images. But when the clean-up is so far from anything functional, I just wonder who do you want to eat the dog food? I'm a bit sick of it ;) Nicolas

May 13, 2012

Re: [Pharo-project] FileList efficiency could hardly be worse

by Nicolas Cellier

2012/5/11 Camillo Bruni <camillobruni(a)gmail.com>: > I just checked: > - Using the old FileDirectory has the advantage that we keep the low level entries directory => O(n^n) > - FIleSystem doesn't do that ;) => O(n^3) > > we should really switch to the other, direct access primitive! > The code for switching to lookupDirectory:filename: is there but commented. The primitive works OK on my mac with Eliot's VM... But the commented code only handle the case of bad directory... If directory exists, but does not contain the named file, then it answers nil... Find updated code at: http://code.google.com/p/pharo/issues/detail?id=5880 Nicolas > On 2012-05-11, at 03:20, Chris Muller wrote: >> Please excuse my clarification but... Â this is a Pharo issue not a >> Squeak issue. Â Squeak is fine and always has been. >> >> Time to display my package-cache directory in Squeak 4.3: Â < 1 second >> >> Time to display my package-cache directory in Pharo 1.4: Â > 5 minutes >> and still waiting before I give up and kill -9.. >> >> >> >> On Wed, May 9, 2012 at 5:33 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> This is one of those things that I find shocking. Â Squeak has been around for 15+ years, and still has no efficient way to get files matching a wildcard pattern (I sure couldn't find it), FFI does not (easily) support callbacks, etc. >>> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] >>> Sent: Wednesday, May 09, 2012 6:18 PM >>> To: Pharo Development >>> Subject: [Pharo-project] FileList efficiency could hardly be worse >>> >>> The efficiency of FileList>>listForPattern: is something which should >>> deserve a bit more care. >>> >>> It tries to sort the files, for example by name, but wants to display >>> directory first >>> Â Â Â Â ^ [ :x :y | |xIsDir| >>> Â Â Â Â Â Â Â Â Â Â Â Â ((xIsDir := x isDirectory) = y isDirectory) >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ Â x basename <= y basename Â ] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [ >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "directories always precede files" >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â xIsDir ]] >>> >>> Alas, this isDirectory test cost you an arm: >>> >>> FileReference>>isDirectory >>> Â Â Â Â ^ filesystem isDirectory: path >>> >>> FileSystem>>isDirectory: aResolvable >>> Â Â Â Â "Resolve the argument, and answer true if the result refers >>> Â Â Â Â to a directory, false if it refers to a file or doesn't exist." >>> >>> Â Â Â Â ^ store isDirectory: (self resolve: aResolvable) >>> >>> FileSystemStore>>isDirectory: aPath >>> Â Â Â Â aPath isRoot ifTrue: [ ^ true ]. >>> Â Â Â Â self >>> Â Â Â Â Â Â Â Â nodeAt: aPath >>> Â Â Â Â Â Â Â Â ifPresent: [ :entry | ^ self basicIsDirectory: entry ] >>> Â Â Â Â Â Â Â Â ifAbsent: [ ^ false ]. >>> >>> DiskStore>>nodeAt: aPath ifPresent: presentBlock ifAbsent: absentBlock >>> Â Â Â Â | name| >>> Â Â Â Â aPath isRoot ifTrue: [ ^ presentBlock value: self rootNode ]. >>> Â Â Â Â "| encodedPath encodedBasename entry | >>> Â Â Â Â encodedPath := Primitives encode: (self stringFromPath: aPath parent). >>> Â Â Â Â encodedBasename := Primitives encode: aPath basename. >>> Â Â Â Â entry := Primitives lookupDirectory: encodedPath filename: encodedBasename. >>> Â Â Â Â ^ entry == #badDirectoryPath >>> Â Â Â Â Â Â Â Â ifTrue: absentBlock >>> Â Â Â Â Â Â Â Â ifFalse: [ >>> Â Â Â Â Â Â Â Â Â Â Â Â entry at: 1 put: aPath basename. >>> Â Â Â Â Â Â Â Â Â Â Â Â presentBlock value: entry ]." >>> Â Â Â Â name := aPath basename. >>> Â Â Â Â self >>> Â Â Â Â Â Â Â Â directoryAt: aPath parent >>> Â Â Â Â Â Â Â Â ifAbsent: absentBlock >>> Â Â Â Â Â Â Â Â nodesDo: >>> Â Â Â Â Â Â Â Â Â Â Â Â [ :entry | >>> Â Â Â Â Â Â Â Â Â Â Â Â (self filename: (entry at: 1) matches: name) >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ ^ presentBlock value: entry ] ]. >>> Â Â Â Â ^ absentBlock value >>> >>> Arghh, it scans the whole parent directory again! >>> If sort is O(n log n), then we transform it into O(2 n^2 log n). >>> >>> Try to browse your package-cache if you're not a chicken. >>> Seriously, it's unusable... >>> >>> Nicolas >>> >>> >> > >

May 13, 2012

Re: [Pharo-project] Implementors of...

by Benjamin

On May 13, 2012, at 2:15 PM, Nicolas Cellier wrote: > 2012/5/12 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: >> Hello :) >> >> Do you have opened an entry ? >> >> Honestly, I am not a fan of this mechanism (as Marcus said, when I want something specific, I select it from the text, then use shortcuts :) ) >> But I can understand you miss it. >> > > In Nautilus, unlike old Browser it now works for multiple keywords, so > things are improving. > Though in term of number of actions necessary to reach information, > I'm not sure it's a clear win. You're right :) > There's a balance between simplicity and efficiency. > Isn't it also a step backward in promotion of keyboard navigation over > mouse navigation? Right again, so maybe I should try to change my habits :) But the things is that 90% of the time, I want senders/implementors of the selected methods. So I will add the setting, and try to play with both to have a real opinion ;) Ben > Nicolas > >> >> Open an entry to be sure it's not lost in the mailing list, and as soon as I can, I will see to add a setting for this :) >> (right now I am more in a "bugs fix" phase that "add new features" one ^^) >> >> Ben >> >> >> >> On May 12, 2012, at 11:47 AM, Hilaire Fernandes wrote: >> >>> Tried from Nautilus: >>> >>> Why when asking 'implementors of ' in the method menu, I only got the >>> implementor of this method. >>> >>> Am I doing something wrong? >>> >>> Look like the browser need a lot of love. >>> >>> Hilaire >>> >>> -- >>> Dr. Geo -- http://www.drgeo.eu >>> >>> >> >> >

May 13, 2012

Re: [Pharo-project] Copying classes: breaking contract or not?

by Nicolas Cellier

It depends of the usage of copy... If the purpose is to modify a class, then the copy will replace the original in a short future, and you should better keep the associations untouched and only change them in a final Namespace at: className put: theClassCopy... If the purpose is to create a new class, then yes, there's some additional operation required. But where will you bind the new association? Another namespace? Nicolas 2012/5/13 Igor Stasenko <siguctua(a)gmail.com>: > yes, this looks like a bug. > But i would recompile all methods of copied class, so all these > nuances is handled. > > On 12 May 2012 14:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >> >> On Sat, May 12, 2012 at 12:41 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> On May 12, 2012, at 12:05 PM, Mariano Martinez Peck wrote: >>> >>> > Hi guys. The last literal of a instance-side compiled method always >>> > points to the SAME (#==) association of the class in Smalltalk global. >>> > The literals of a compiled method that refer to class variables refer to >>> > the same association (#==) of the classPool of its class: >>> > >>> > self assert: ((GRPlatform class >> #current) literalAt: 1) == >>> > (GRPlatform classPool associationAt: #Current). Â -> true >>> > >>> > However, if I do a copy of the class: >>> > >>> > | copy | >>> > copy := GRPlatform copy. >>> > self assert: ((copy class >> #current) literalAt: 1) == (copy classPool >>> > associationAt: #Current). >>> > >>> > this is not true anymore. Of course, you can see this because of the >>> > Class >> #copy implementation: >>> > >>> > So my question is....is #copy breaking the contract (and therefore it >>> > has to be fixed) or this is not mandatory for the system (as it is with the >>> > last literal pointing to classes)? >>> >>> since namespace binding are shared between method literal and namespace, I >>> think that this is a bug. >>> >> >> I did this workaround >> >> Class >> rebindClassVariablesInMethods >> >> Â Â Â self class methodDict valuesDo: [ :aCompiledMethod | >> Â Â Â Â Â Â 1 to: aCompiledMethod numLiterals-2 do: [ :index | >> Â Â Â Â Â Â Â Â Â | literal | >> Â Â Â Â Â Â Â Â Â literal := aCompiledMethod literalAt: index. >> Â Â Â Â Â Â Â Â Â literal isVariableBinding ifTrue: [ >> Â Â Â Â Â Â Â Â Â Â Â Â (self innerBindingOf: literal key) ifNotNil: [:aBinding | >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â aCompiledMethod literalAt: index put: aBinding >> Â Â Â Â Â Â Â Â Â Â Â Â ] >> Â Â Â Â Â Â Â Â Â ] >> Â Â Â Â Â Â ] >> Â Â Â ] >> >>> >>> Stef >>> > >>> > Thanks, >>> > >>> > -- >>> > Mariano >>> > http://marianopeck.wordpress.com >>> > >>> >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Best regards, > Igor Stasenko. >

May 13, 2012

Re: [Pharo-project] Implementors of...

by Nicolas Cellier

2012/5/12 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: > Hello :) > > Do you have opened an entry ? > > Honestly, I am not a fan of this mechanism (as Marcus said, when I want something specific, I select it from the text, then use shortcuts :) ) > But I can understand you miss it. > In Nautilus, unlike old Browser it now works for multiple keywords, so things are improving. Though in term of number of actions necessary to reach information, I'm not sure it's a clear win. There's a balance between simplicity and efficiency. Isn't it also a step backward in promotion of keyboard navigation over mouse navigation? Nicolas > > Open an entry to be sure it's not lost in the mailing list, and as soon as I can, I will see to add a setting for this :) > (right now I am more in a "bugs fix" phase that "add new features" one ^^) > > Ben > > > > On May 12, 2012, at 11:47 AM, Hilaire Fernandes wrote: > >> Tried from Nautilus: >> >> Why when asking 'implementors of ' in the method menu, I only got the >> implementor of this method. >> >> Am I doing something wrong? >> >> Look like the browser need a lot of love. >> >> Hilaire >> >> -- >> Dr. Geo -- http://www.drgeo.eu >> >> > >

May 13, 2012

Re: [Pharo-project] Copying classes: breaking contract or not?

by Igor Stasenko

yes, this looks like a bug. But i would recompile all methods of copied class, so all these nuances is handled. On 12 May 2012 14:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sat, May 12, 2012 at 12:41 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> >> On May 12, 2012, at 12:05 PM, Mariano Martinez Peck wrote: >> >> > Hi guys. The last literal of a instance-side compiled method always >> > points to the SAME (#==) association of the class in Smalltalk global. >> > The literals of a compiled method that refer to class variables refer to >> > the same association (#==) of the classPool of its class: >> > >> > self assert: ((GRPlatform class >> #current) literalAt: 1) == >> > (GRPlatform classPool associationAt: #Current). Â -> true >> > >> > However, if I do a copy of the class: >> > >> > | copy | >> > copy := GRPlatform copy. >> > self assert: ((copy class >> #current) literalAt: 1) == (copy classPool >> > associationAt: #Current). >> > >> > this is not true anymore. Of course, you can see this because of the >> > Class >> #copy implementation: >> > >> > So my question is....is #copy breaking the contract (and therefore it >> > has to be fixed) or this is not mandatory for the system (as it is with the >> > last literal pointing to classes)? >> >> since namespace binding are shared between method literal and namespace, I >> think that this is a bug. >> > > I did this workaround > > Class >> rebindClassVariablesInMethods > > Â Â Â self class methodDict valuesDo: [ :aCompiledMethod | > Â Â Â Â Â Â 1 to: aCompiledMethod numLiterals-2 do: [ :index | > Â Â Â Â Â Â Â Â Â | literal | > Â Â Â Â Â Â Â Â Â literal := aCompiledMethod literalAt: index. > Â Â Â Â Â Â Â Â Â literal isVariableBinding ifTrue: [ > Â Â Â Â Â Â Â Â Â Â Â Â (self innerBindingOf: literal key) ifNotNil: [:aBinding | > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â aCompiledMethod literalAt: index put: aBinding > Â Â Â Â Â Â Â Â Â Â Â Â ] > Â Â Â Â Â Â Â Â Â ] > Â Â Â Â Â Â ] > Â Â Â ] > >> >> Stef >> > >> > Thanks, >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

May 13, 2012

[Pharo-project] Strange logic in PolygonMorph>>fromHand: hand

by StÃ©phane Ducasse

Hi I'm cleaning Sensor use so that we end up with a better layered system. Now I see this method and I wonder (replacing Sensor by hand does not work. But I do not understand why this methods has to explicitly invoke runStepMethodsâ¦ to me it looks like a broken behavior due probably to the lack of a functionality or ticking behavior. What do you think? fromHand: hand "Let the user draw a polygon, clicking at each vertex, and ending by clicking within 5 of the first point..." "self fromHand: ActiveHand" | p1 poly oldVerts pN opposite | Cursor crossHair showWhile: [[Sensor anyButtonPressed] whileFalse: [self currentWorld displayWorldSafely; runStepMethods]. p1 := Sensor cursorPoint]. opposite := (Display colorAt: p1) negated. opposite = Color transparent ifTrue: [opposite := Color red]. (poly := LineMorph from: p1 to: p1 color: opposite width: 2) openInWorld. oldVerts := {p1}. self currentWorld displayWorldSafely; runStepMethods. [true] whileTrue: [[Sensor anyButtonPressed] whileTrue: [pN := Sensor cursorPoint. poly setVertices: (oldVerts copyWith: pN). self currentWorld displayWorldSafely; runStepMethods]. (oldVerts size > 1 and: [(pN dist: p1) < 5]) ifTrue: [hand position: Sensor cursorPoint. "Done -- update hand pos" ^ (poly setVertices: (poly vertices copyWith: p1)) delete]. oldVerts := poly vertices. [Sensor anyButtonPressed] whileFalse: [pN := Sensor cursorPoint. poly setVertices: (oldVerts copyWith: pN). self currentWorld displayWorldSafely; runStepMethods]].

May 13, 2012