- Pharo-dev - lists.pharo.org

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

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

by StÃ©phane Ducasse

Do you need it for a model or for drawing? Because for drawing there is LineMorph stef > I went to use a "Line" today and found it wasn't in Pharo. > > Apparently this is part of the ST80-* (ST80-Paths) classes which > aren't carried over to Pharo. > > So...how do I draw a line on a morph (without creating another morph)? > > ===Blake=== >

May 13, 2012

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

by blake

Thanks, Igor! On Sat, May 12, 2012 at 7:52 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 13 May 2012 00:30, blake <dsblakewatson(a)gmail.com> wrote: >> I went to use a "Line" today and found it wasn't in Pharo. >> >> Apparently this is part of the ST80-* (ST80-Paths) classes which >> aren't carried over to Pharo. >> >> So...how do I draw a line on a morph (without creating another morph)? >> > > Morphic is much much younger than ST-80. > > Create new morph class, > override drawOn: method > > use > canvas line: pt1 to: pt2 color: c > > & friends. > >> ===Blake=== >> > > > > -- > Best regards, > Igor Stasenko. >

May 13, 2012

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

by Igor Stasenko

On 13 May 2012 00:30, blake <dsblakewatson(a)gmail.com> wrote: > I went to use a "Line" today and found it wasn't in Pharo. > > Apparently this is part of the ST80-* (ST80-Paths) classes which > aren't carried over to Pharo. > > So...how do I draw a line on a morph (without creating another morph)? > Morphic is much much younger than ST-80. Create new morph class, override drawOn: method use canvas line: pt1 to: pt2 color: c & friends. > ===Blake=== > -- Best regards, Igor Stasenko.

May 13, 2012

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

by blake

Seems like I ought to be able to load in the ST80 classes but I don't see anything on Monti/Meta. On Sat, May 12, 2012 at 3:30 PM, blake <dsblakewatson(a)gmail.com> wrote: > I went to use a "Line" today and found it wasn't in Pharo. > > Apparently this is part of the ST80-* (ST80-Paths) classes which > aren't carried over to Pharo. > > So...how do I draw a line on a morph (without creating another morph)? > > ===Blake===

May 13, 2012