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

[Pharo-project] [update 2.0] #20067

by Marcus Denker

20067 ----- Issue 5850: Move SpaceTally and SpaceTallyItem to Tools-Profilers http://code.google.com/p/pharo/issues/detail?id=5850 Issue 5819: first iteration on moving fileIn users to new codeImporter http://code.google.com/p/pharo/issues/detail?id=5819 -- Marcus Denker -- http://marcusdenker.de

May 11, 2012

[Pharo-project] [update 2.0] #20066

by Marcus Denker

20066 ----- Issue 5860: Package System-Download is empty and can be removed http://code.google.com/p/pharo/issues/detail?id=5860 Issue 5858: DateAndTime >>#hash http://code.google.com/p/pharo/issues/detail?id=5858 Issue 5855: During snapshot: Send cr after Transcript message http://code.google.com/p/pharo/issues/detail?id=5855 Issue 5853: Pharo2.0a Latest update: #20064 One click brings debugger on Windows due to missing converter for stdout stream http://code.google.com/p/pharo/issues/detail?id=5853 Issue 5854: FixSomeTests: Unreferences Global and Ftp http://code.google.com/p/pharo/issues/detail?id=5854 -- Marcus Denker -- http://marcusdenker.de

May 11, 2012

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

by Fernando Olivero

That's why the OpenGL examples work when you re-open a saved image! Fernando On Fri, May 11, 2012 at 12:51 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > I agree with all your points. > I just can add, that if you start using NativeBoost FFI you'll find > that it follows _exactly_ the rules which you listed. > i dont know much about dolphin, but session awareness is one of the > first things which i implemented in NB, because as to me, it is the > right way how things should be done. > > > On 11 May 2012 04:08, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> 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).. >> >> > > > > -- > Best regards, > Igor Stasenko. >

May 11, 2012

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

by Igor Stasenko

I agree with all your points. I just can add, that if you start using NativeBoost FFI you'll find that it follows _exactly_ the rules which you listed. i dont know much about dolphin, but session awareness is one of the first things which i implemented in NB, because as to me, it is the right way how things should be done. On 11 May 2012 04:08, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > 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).. > > -- Best regards, Igor Stasenko.

May 11, 2012

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