- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

thanks for the report. we should investigate that. Stef On May 11, 2012, at 3:20 AM, 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 11, 2012

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

by Camillo Bruni

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! 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 11, 2012

Re: [Pharo-project] [review needed] Do we remove SmartRefStream?

by Fernando Olivero

I would remove them, you made a strong point in favor of simply removing it: A cleanup of an unneeded class. Its nice to see this kind of complex classes disappear from Pharo, more and more. Fernando On Fri, May 11, 2012 at 10:27 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > With Fuel, we should take the opportunity to clean up the systm. There are things we need to keep > for a while (DataStream, for example, a it is used by Monticello). > > But what about SmartRefStream? With ImageSegment already gone, does it make sense to keep > it? The code looks horrible. > > One can just remove it and all remaining users like this: > > http://code.google.com/p/pharo/issues/detail?id=5859 > > Can we do that? do we need to formally deprecate it? > > -- > Marcus Denker -- http://marcusdenker.de > >

May 11, 2012

[Pharo-project] [review needed] Do we remove SmartRefStream?

by Marcus Denker

With Fuel, we should take the opportunity to clean up the systm. There are things we need to keep for a while (DataStream, for example, a it is used by Monticello). But what about SmartRefStream? With ImageSegment already gone, does it make sense to keep it? The code looks horrible. One can just remove it and all remaining users like this: http://code.google.com/p/pharo/issues/detail?id=5859 Can we do that? do we need to formally deprecate it? -- Marcus Denker -- http://marcusdenker.de

May 11, 2012

Re: [Pharo-project] PHARO_VM on Jenkins

by Christophe Demarey

Hi Pavel, Yes, I did some experiments to use the latest compiled (and successfully tested) VM for Jenkins jobs. I choose the following option to avoid too much additional configuration to jenkins jobs : The build.sh script is used in most of jobs defined in jenkins. This script use the PHARO_VM environment variable to get the VM path. What I did is that is the variable is not defined, it calls a script named fetchLatestVM.sh to download the appropriate VM (according to OS @ Architecture)in the job workspace. Then, the PHARO_VM is set with the downloaded VM. I was not aware of other jobs that don't use the build.sh script. I will update the build-kernel.sh script to have the same behavior as build.sh. I will also update the job. Thank for your feedback. Regards, Christophe. Le 10 mai 2012 Ã 14:22, Pavel Krivanek a Ã©crit : > Hi, > > I got this error on Pharo Kernel 2.0 Jenkins build: > PHARO_VM environment variable is not set. > > Did somebody some VM related changes on Jenkins? > > -- Pavel >

May 11, 2012

Re: [Pharo-project] Form sliding causing VM segfault (Form>>slideFrom:to:nSteps:delay:)

by Francisco Garau

The recent issue with form sliding was reported here: http://code.google.com/p/pharo/issues/detail?id=5568 - Francisco On 11 May 2012 02:40, Chris Muller <asqueaker(a)gmail.com> wrote: > Don't have any info but I observed this problem in Squeak a couple of > times doing the exact same thing -- dragging a form outside window > bounds. > > On Thu, May 10, 2012 at 4:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > remember the recent issue with form sliding? > > It strikes again.. i dragged my window outside of OS window bounds and > > then released the button.. > > > > i'm not sure if this a VM issue or image/side.. > > but i think VM has to be blamed, because it should do range checking > > before accepting requests for doing stupid operations, like > > blitting outside the buffer :) > > > > Luckily i were running debug version of VM and under debugger doing > > things completely unrelated to this :) > > > > Here some info about crash point: > > > > Program received signal EXC_BAD_ACCESS, Could not access memory. > > Reason: KERN_PROTECTION_FAILURE at address: 0x0000000a > > 0x00034949 in longAtPointer (ptr=0xa <Address 0xa out of bounds>) at > > sqMemoryAccess.h:81 > > 81 static inline sqInt longAtPointer(char *ptr) > { return *(sqInt *)ptr; } > > (gdb) bt > > #0 0x00034949 in longAtPointer (ptr=0xa <Address 0xa out of bounds>) > > at sqMemoryAccess.h:81 > > #1 0x00034969 in longAt (oop=10) at sqMemoryAccess.h:98 > > #2 0x0003a1c0 in ceSendsupertonumArgs (selector=525641856, > > superNormalBar=0, rcvr=10, numArgs=0) at > > /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:10729 > > #3 0x1f40005c in ?? () > > #4 0x00049045 in initStackPagesAndInterpret () at > > /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:17865 > > #5 0x00026ad1 in interpret () at > > /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-cointerp.c:1979 > > > > > > (gdb) call printCallStack() > > 0xbff5dc80 M [] in Form(DisplayObject)>slideFrom:to:nSteps:delay: > > 578564724: a(n) Form > > 0xbff5dcc4 I Form(DisplayObject)>follow:while:bitsBehind:startingLoc: > > 578564724: a(n) Form > > 0xbff5dcfc I Form(DisplayObject)>follow:while: 578564724: a(n) Form > > 0xbff5dd2c I Form(DisplayObject)>slideFrom:to:nSteps:delay: 578564724: > a(n) Form > > 0xbff5dd78 I NautilusWindow(Morph)>slideBackToFormerSituation: > > 565212772: a(n) NautilusWindow > > 0xbff5dd9c I NautilusWindow(Morph)>rejectDropMorphEvent: 565212772: > > a(n) NautilusWindow > > 0xbff5ddc8 I HandMorph>dropMorph:event: 535318276: a(n) HandMorph > > 0xbff5ddf4 I [] in HandMorph>dropMorphs: 535318276: a(n) HandMorph > > 0xbff5de14 M Array(SequenceableCollection)>reverseDo: 578544144: a(n) > Array > > 0xbff5de38 I HandMorph(Morph)>submorphsReverseDo: 535318276: a(n) > HandMorph > > 0xbff5de5c I HandMorph>dropMorphs: 535318276: a(n) HandMorph > > 0xbff5de80 M HandMorph>handleEvent: 535318276: a(n) HandMorph > > 0xbff5deac M HandMorph>processEvents 535318276: a(n) HandMorph > > 0xbff5dec4 M [] in WorldState>doOneCycleNowFor: 526955120: a(n) > WorldState > > 0xbff5dee8 M Array(SequenceableCollection)>do: 525348844: a(n) Array > > 0xbff5df04 M WorldState>handsDo: 526955120: a(n) WorldState > > 0xbff5df20 M WorldState>doOneCycleNowFor: 526955120: a(n) WorldState > > 0xbff5df3c M WorldState>doOneCycleFor: 526955120: a(n) WorldState > > 0xbff5df58 M PasteUpMorph>doOneCycle 526861788: a(n) PasteUpMorph > > 0xbff5df70 M [] in MorphicUIManager>spawnNewProcess 526984156: a(n) > > MorphicUIManager > > > > i think best solution right now is to avoid using sliding > > (NautilusWindow(Morph)>slideBackToFormerSituation:). for a longer > > term, a best solution is to fix this issue, of course :) > > > > -- > > Best regards, > > Igor Stasenko. > > > >

May 11, 2012

Re: [Pharo-project] I cannot see the code in the latest Moose build

by Tudor Girba

I can reproduce the problem. Nautilus is loaded from its own repository like: Gofer new url: 'http://ss3.gemstone.com/ss/Nautilus'; package: 'ConfigurationOfNautilus'; load. (ConfigurationOfNautilus project version: #stable) load. It seems that when you load this in Pharo 1.4, there is a mismatch with RPackage-Core: if I load the latest RPackage-Core version, it seems to work. But, if you load the version (213) from the MetaRepoForPharo14, it works. So, now I changed the loading code to be: Gofer new squeaksource:'MetaRepoForPharo14'; package: 'ConfigurationOfNautilus'; load. (ConfigurationOfNautilus project version: #stable) load. Nevertheless, it would be good if the ConfigurationOfNautilus would continue to load properly in 1.4. Cheers, Doru On 10 May 2012, at 15:01, Fabrizio Perin wrote: > Hi, > I download the latest yellow build from the moose web site (8 may). When I open Nautilus I cannot see the code. > > I don't have any clue if it is about Nautilus or about how Nautilus is loaded in Moose or about something else. > > Any idea? > > Cheers, > Fabrizio -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

May 11, 2012

Re: [Pharo-project] DateAndTime hash was: Re: [squeak-dev] true hash

by Paul DeBruicker

I made issue 5858: https://code.google.com/p/pharo/issues/detail?id=5858 And Nicolas Cellier improved my suggestion as noted in the issue. Mariano Martinez Peck wrote > > On Thu, May 10, 2012 at 3:21 PM, Paul DeBruicker <pdebruic@> wrote: > >> On 05/10/2012 04:21 AM, Nicolas Cellier wrote: >> >>> Sure, I already changed various Number>>hash and could as well change >>> Point hash to follow recommendations from Andres valloud book hashing >>> in smalltalk... >>> >>> Nicolas >>> >> >> DateAndTime>>#hash could be changed to : >> >> hash >> ^ (jdn hashMultiply bitXor: seconds + offset asSeconds) bitXor: >> nanos >> >> which is 130x faster than whats currently in the image: >> >> hash >> ^ self asUTC ticks hash >> >> >> The collision rate on the proposed hash function is 0.04% ( 4 per 10,000 >> ) >> >> > > please, open an issue for pharo also ;) > > > -- > Mariano > http://marianopeck.wordpress.com > -- View this message in context: http://forum.world.st/Re-DateAndTime-hash-was-Re-squeak-dev-true-hash-tp462… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 11, 2012

Re: [Pharo-project] [OT] ffs![SEC=UNCLASSIFIED]

by Stephen Taylor

On Thu, 2012-05-10 at 16:26 +0200, Igor Stasenko wrote: > i found this funny.. > > most of you probably know, what ffs means.. > if not, see here: http://www.urbandictionary.com/define.php?term=FFS I believe it stands for "fair's fair - surely". It's often found near another acronym "WTF:, which stands for "well that's funny...". cheers, Steve

May 11, 2012

Re: [Pharo-project] Short rant on platforms and sessions

by Schwab,Wilhelm K

It's a nice system - we should take lessons from it where we can. In this case, they *clearly* have it right. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Chris Muller [asqueaker(a)gmail.com] Sent: Thursday, May 10, 2012 8:56 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Short rant on platforms and sessions > Dolphin shows us the correct path: session awareness. The image "wakes up" > and decides where it is running - the vm can certainly help in Pharo's > case. External resources are *not* cleared on image save - the image might > keep running, so why release and reallocate? Finalization is best-effort. > External resources are cleared just before exiting, but *after* any > associated image save. When the image wakes, one of its first duties is to > clear (not release via calls) any external resources, because they are known > to be garbage at this point. > > It works, and works well. I don't have experience with Dolphin, but that does sound like a clever solution to avoiding the release/reallocate burden on image save (and not exiting)..

May 11, 2012