- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by Douglas Brebner

On 09/05/2012 09:08, GÃ¶ran Krampe wrote: > Ok, regarding changing the syntax of Smalltalk: > > - Personally I don't care that much for ANSI. It's dead. I think > Smalltalk needs to evolve and bloody hell, you have *Traits* in Pharo, > that is a HUGE difference compared to a bit of literal changes. ;) > > - If we *do* decide to "Hey, let's take a look at our literal syntax", > then we should probably see if we can harmonize a bit. Again, see my > article for some thoughts in that area. > > I agree that Smalltalk literals are quite powerful but I think they > can be improved. One thing that occurred to me after reading your article was with a formal prefix for #literal and Â§dynamic syntax, wouldn't it open the door to cleanly supporting other, even non-textual objects directly in the source? Whether that's a good idea or not is another question :)

May 9, 2012

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

by Marcus Denker

On May 8, 2012, at 11:49 PM, Pavel Krivanek wrote: > Hi, > > If you take the latest Pharo 2.0 image from Jenkins (20059) and you execute the expression: > > (Metaclass allInstances select: [:c | c superclass = ProtoObject class]) inspect > It seems to disappear when evaluating Smalltalk cleanUp. Maybe we should do that anyway on the build server for each build... -- Marcus Denker -- http://marcusdenker.de

May 9, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by Esteban A. Maringolo

GÃ¶ran Krampe wrote > > I don't want to sound like a broken record - but you do realize that I > wrote about this in the article and mentioned this exact syntax? > > I know, the article was a tad long - but just go to planet.smalltalk.org > and search down to "Sidestory: Adding literal Dictionaries to Smalltalk?". > > regards, GÃ¶ran > I do realize, and read the entire post. I simply didn't want to just say "+1" to everything you state in the blog post, and did a summary of what's interesting for me. :) Regards! -- View this message in context: http://forum.world.st/ANN-STON-Smalltalk-Object-Notation-tp4609808p4620638.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 9, 2012

Re: [Pharo-project] MC, Ring and RPackage dependencies

by StÃ©phane Ducasse

> Hi, > > I yesterday put Pharo Kernel Gofer 2.0 job into operation (together > with some other dependent like Seaside and OSProcess evaluator). But > unfortunatelly I have to say it was quite complicated and I had to do > some ugly hacks because we do not have solved dependencies between > Monticello, Ring and RPackage. > > The loading order we use now is: > 'Monticello' > 'MonticelloConfigurations' > 'Ring-Core-Kernel' > 'RPackage-Core' > 'RPackage-SystemIntegration' Pavel this is strange because RPackage was always managed using Metacello. Now we should fix the dependencies. > Authors of this packages should know that this are primitive packages > that cannot be loaded in one bundle via Monticello but must be loaded > one by one as standard *.st files. That means that that we have to > have well known and working loading order. As an example, currently > the initialization of the package 'RPackage-Core' is dependent on > presence of 'RPackage-SystemIntegration'. > > Cheers, > -- Pavel >

May 9, 2012