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

[Pharo-project] FileList efficiency could hardly be worse

by Nicolas Cellier

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 9, 2012

Re: [Pharo-project] FFI in Fedora

by Casimiro de Almeida Barreto

On 09-05-2012 16:17, Adriel Paredes wrote: > I have the 32 bits libraries... It works in ubuntu, but not in fedora This stuff of FFI has been discussed in the VM-dev list. Making FFI work in linux x86_64 is a real pain. First, CogVM as it comes with Pharo distribution or as you get from Eliot's repositories are 32bits. Then you have to have all 32bit libraries installed <and> LD_LIBRARY_PATH adjusted to point first to the /usr/lib instead of /usr/lib64. But even so, things just don't work plainly. I am having trouble with OpenGL, Fann and some other libraries. Also, currently FFI doesn't support 64bit binaries. CdAB > > On Wed, May 9, 2012 at 4:15 PM, Milan Mimica <milan.mimica(a)gmail.com > <mailto:milan.mimica@gmail.com>> wrote: > > Does FFI even support 64-bit binaries? > > > On 9 May 2012 20:42, Adriel Paredes <adriel.paredes(a)gmail.com > <mailto:adriel.paredes@gmail.com>> wrote: > > Hi Folks... > > I'm having some troubles with FFI in Fedora x86_64. I tried to > execute some OS functions. I have all the libreries needed for > that, but I always have the same error. In the *stack top > *into FFICallbackThunk class when I send the > allocateExcecutablePage message i got this: *#'insufficient C > memory' * > > Has anyone had this kind of error before? > > > This is the stack trace in my terminal. > > PrimitiveFailed: primitive #allocateExecutablePage in > FFICallbackThunk class failed > FFICallbackThunk class(Object)>>primitiveFailed: > FFICallbackThunk class(Object)>>primitiveFailed > FFICallbackThunk class>>allocateExecutablePage > FFICallbackThunk class>>unusedBlockInExecutablePage in Block: > [ExecutablePages add: self allocateExecutablePage]...etc... > Semaphore>>critical: in Block: [caught := true.... > BlockClosure>>ensure: > Semaphore>>critical: > FFICallbackThunk class>>unusedBlockInExecutablePage > FFICallbackThunk class>>privateFinalizingNew > FFICallbackThunk class>>newCCall > > > -- > Adriel Paredes > E-Mail: adriel.paredes(a)gmail.com > <mailto:adriel.paredes@gmail.com> > Twitter: @adrielparedes > Skype: adriel.paredes > > > > > > -- > Milan Mimica > http://sparklet.sf.net > > > > > -- > Adriel Paredes > E-Mail: adriel.paredes(a)gmail.com <mailto:adriel.paredes@gmail.com> > Twitter: @adrielparedes > Skype: adriel.paredes > >

May 9, 2012

Re: [Pharo-project] tentative schedule for the pharo conference

by Francisco Garau

Hi Stef - there is one hour difference between the iCal and HTML versions. It starts at 9am, correct? - Francisco On 9 May 2012 12:20, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Hi guys > > Here is a tentative schedule for the forth coming conference. > > ICAL: > > https://www.google.com/calendar/ical/2d97rjlqso704v09d49sgcsjec%40group.cal… > > HTML: > > https://www.google.com/calendar/embed?src=2d97rjlqso704v09d49sgcsjec%40grou… > > > please lets us know if you have any idea feedback. > -- > > Sef >

May 9, 2012

Re: [Pharo-project] Strangest object ever seen?

by Pavel Krivanek

On Wed, May 9, 2012 at 3:39 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Now I do not understand why this guy cannot get printed. >>> >>> I do not see why >>> >>> ClassDescription>>printOn: aStream >>> Â Â Â Â aStream nextPutAll: self name >>> >>> Metaclass>>name >>> Â Â Â Â "Answer a String that is the name of the receiver, either 'Metaclass' or >>> Â Â Â Â the name of the receiver's class followed by ' class'." >>> >>> Â Â Â Â thisClass == nil >>> Â Â Â Â Â Â Â Â ifTrue: [^'a Metaclass'] >>> Â Â Â Â Â Â Â Â ifFalse: [^thisClass name , ' class'] >>> >>> self first soleInstance printString >>> Â Â Â Â -> leads to have emergency debugger. > > you do not get emergency! > I do not like when we do not get the same bugsâ¦ on some inst vars and expressions I get the emergency evaluator. > > >> self name shows: >> >> a Dictionary(#DependentsFields->a WeakIdentityKeyDictionary(a >> CategoryWidget->a DependentsArray(a PluggableIconListMorph(217841664)) >> a ContextVariablesInspector->a DependentsArray(a >> PluggableListMorph(445382656) a PluggableTextMorph(1046216704)) a >> ContextVariablesInspector->a DependentsArray(a >> PluggableListMorph(290193408) ... ) >> >> The source of printing problems will be in thisClass. >> >> The next interesting thing is that it has no pointers and it is >> removed after garbageCollect. > > So this is a good news :). The question is what produced such strange object and how many similar ones we still have in the image. It can have very unwelcome consequences - for example the segmentation faults on Fuel packages exports when executed from command line. But from workspace it behaves differently. -- Pavel > >> >> -- Pavel >> >> >> >> >>> Stef >>> >>> >>> >>> >>> >> > >

May 9, 2012

Re: [Pharo-project] FFI in Fedora

by Adriel Paredes

I have the 32 bits libraries... It works in ubuntu, but not in fedora On Wed, May 9, 2012 at 4:15 PM, Milan Mimica <milan.mimica(a)gmail.com> wrote: > Does FFI even support 64-bit binaries? > > > On 9 May 2012 20:42, Adriel Paredes <adriel.paredes(a)gmail.com> wrote: > >> Hi Folks... >> >> I'm having some troubles with FFI in Fedora x86_64. I tried to execute >> some OS functions. I have all the libreries needed for that, but I always >> have the same error. In the *stack top *into FFICallbackThunk class when >> I send the allocateExcecutablePage message i got this: *#'insufficient C >> memory' * >> >> Has anyone had this kind of error before? >> >> >> This is the stack trace in my terminal. >> >> PrimitiveFailed: primitive #allocateExecutablePage in FFICallbackThunk >> class failed >> FFICallbackThunk class(Object)>>primitiveFailed: >> FFICallbackThunk class(Object)>>primitiveFailed >> FFICallbackThunk class>>allocateExecutablePage >> FFICallbackThunk class>>unusedBlockInExecutablePage in Block: >> [ExecutablePages add: self allocateExecutablePage]...etc... >> Semaphore>>critical: in Block: [caught := true.... >> BlockClosure>>ensure: >> Semaphore>>critical: >> FFICallbackThunk class>>unusedBlockInExecutablePage >> FFICallbackThunk class>>privateFinalizingNew >> FFICallbackThunk class>>newCCall >> >> >> -- >> Adriel Paredes >> E-Mail: adriel.paredes(a)gmail.com >> Twitter: @adrielparedes >> Skype: adriel.paredes >> >> >> > > > -- > Milan Mimica > http://sparklet.sf.net > -- Adriel Paredes E-Mail: adriel.paredes(a)gmail.com Twitter: @adrielparedes Skype: adriel.paredes

May 9, 2012

Re: [Pharo-project] FFI in Fedora

by Milan Mimica

Does FFI even support 64-bit binaries? On 9 May 2012 20:42, Adriel Paredes <adriel.paredes(a)gmail.com> wrote: > Hi Folks... > > I'm having some troubles with FFI in Fedora x86_64. I tried to execute > some OS functions. I have all the libreries needed for that, but I always > have the same error. In the *stack top *into FFICallbackThunk class when > I send the allocateExcecutablePage message i got this: *#'insufficient C > memory' * > > Has anyone had this kind of error before? > > > This is the stack trace in my terminal. > > PrimitiveFailed: primitive #allocateExecutablePage in FFICallbackThunk > class failed > FFICallbackThunk class(Object)>>primitiveFailed: > FFICallbackThunk class(Object)>>primitiveFailed > FFICallbackThunk class>>allocateExecutablePage > FFICallbackThunk class>>unusedBlockInExecutablePage in Block: > [ExecutablePages add: self allocateExecutablePage]...etc... > Semaphore>>critical: in Block: [caught := true.... > BlockClosure>>ensure: > Semaphore>>critical: > FFICallbackThunk class>>unusedBlockInExecutablePage > FFICallbackThunk class>>privateFinalizingNew > FFICallbackThunk class>>newCCall > > > -- > Adriel Paredes > E-Mail: adriel.paredes(a)gmail.com > Twitter: @adrielparedes > Skype: adriel.paredes > > > -- Milan Mimica http://sparklet.sf.net

May 9, 2012

[Pharo-project] FFI in Fedora

by Adriel Paredes

Hi Folks... I'm having some troubles with FFI in Fedora x86_64. I tried to execute some OS functions. I have all the libreries needed for that, but I always have the same error. In the *stack top *into FFICallbackThunk class when I send the allocateExcecutablePage message i got this: *#'insufficient C memory' * Has anyone had this kind of error before? This is the stack trace in my terminal. PrimitiveFailed: primitive #allocateExecutablePage in FFICallbackThunk class failed FFICallbackThunk class(Object)>>primitiveFailed: FFICallbackThunk class(Object)>>primitiveFailed FFICallbackThunk class>>allocateExecutablePage FFICallbackThunk class>>unusedBlockInExecutablePage in Block: [ExecutablePages add: self allocateExecutablePage]...etc... Semaphore>>critical: in Block: [caught := true.... BlockClosure>>ensure: Semaphore>>critical: FFICallbackThunk class>>unusedBlockInExecutablePage FFICallbackThunk class>>privateFinalizingNew FFICallbackThunk class>>newCCall -- Adriel Paredes E-Mail: adriel.paredes(a)gmail.com Twitter: @adrielparedes Skype: adriel.paredes

May 9, 2012

Re: [Pharo-project] Help reading dump?

by Eliot Miranda

On Wed, May 9, 2012 at 8:16 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > The attached is diagnostic output from the Linux vm. I am doing some > iterative numerical analysis that won't always work out, so I expect errors > and non-sense results at times - it all depends on whether a particular > segment of a signal is clean or noisy; if the latter, all assumptions are > off. > > One thought is that early terminated iterations (or maybe ones that go too > long?) are leaving conditions that finalization can't clean, or maybe does > not clean before the next iteration begins. A segmentation fault seems a > bit harsh, but they are happening and I need to find a way around them. > > Is there anything in the attached dump that strikes you as significant? > Maybe something that says whether its the main thread or a background > thread that's blowing up, or some other clue that is obvious to the correct > eye? As it is, I see the #iterate, #basicIterate part of the stack, which > is what I would expect the code to be trying to do - fit curves to data. > > The numbers at the beginning are trace info (using C++ cout) to confirm > sanity of the arriving parameters. > > My next thought is to add some more tracing to show which segment/harmonic > is being attacked as it blows up. Then I might be able to set clever > breakpoints and get some handle on it. Suggestions are welcome. > Put instrumentation around the calls that allow you to write a C program that makes the exact same calls and see if that crashes? > Bill > > > > > > -- best, Eliot

May 9, 2012

[Pharo-project] [update 2.0] #20062

by Marcus Denker

20062 ----- Issue 5602: Unicode Initialization lost http://code.google.com/p/pharo/issues/detail?id=5602 Issue 5851: Drag and drop broken in Nautilus http://code.google.com/p/pharo/issues/detail?id=5851 Issue 5849: remove empty packages Network-RemoteDirectory and ScriptLoader13 http://code.google.com/p/pharo/issues/detail?id=5849 -> do a #cleanUpForRelease -- Marcus Denker -- http://marcusdenker.de

May 9, 2012

[Pharo-project] Help reading dump?

by Schwab,Wilhelm K

The attached is diagnostic output from the Linux vm. I am doing some iterative numerical analysis that won't always work out, so I expect errors and non-sense results at times - it all depends on whether a particular segment of a signal is clean or noisy; if the latter, all assumptions are off. One thought is that early terminated iterations (or maybe ones that go too long?) are leaving conditions that finalization can't clean, or maybe does not clean before the next iteration begins. A segmentation fault seems a bit harsh, but they are happening and I need to find a way around them. Is there anything in the attached dump that strikes you as significant? Maybe something that says whether its the main thread or a background thread that's blowing up, or some other clue that is obvious to the correct eye? As it is, I see the #iterate, #basicIterate part of the stack, which is what I would expect the code to be trying to do - fit curves to data. The numbers at the beginning are trace info (using C++ cout) to confirm sanity of the arriving parameters. My next thought is to add some more tracing to show which segment/harmonic is being attacked as it blows up. Then I might be able to set clever breakpoints and get some handle on it. Suggestions are welcome. Bill

May 9, 2012