- Pharo-dev - lists.pharo.org

[Pharo-project] vm crash - code snippet provided

by Francisco Garau

Hi - a short code snippet that crashes the CogVM in WindowsXP using a fresh Pharo 1.4 image. Open a System Browser and evaluate the below in a Workspace. window := SystemWindow allInstances first. aForm := window imageForm offset: 0@0. startPoint := (-194@61). endPoint := (276.0(a)134.0) aForm slideFrom: startPoint to: endPoint nSteps: 12 delay: 15. Cheers, Francisco

March 26, 2012

[Pharo-project] CogVM speed

by Pavel Krivanek

Hi, I tried a few benchmarks from Computer Language Benchmark Game (http://shootout.alioth.debian.org/u32/which-programming-languages-are-faste…) on CogVM to compare it with VisualWorks and with the rest of the world. Of course this benchmarks are not ideal (like all benchmarks) but the result is that CogVM is in average 1.8 times slower than VisualWorks 7.8 NC. For the most successful benchmark (binary-trees) it was 13.5 times slower than C (gcc) but in general we may except CogVM to be 20-30 times slower than C for this kind of tasks. Thank you for the great work! Cheers, -- Pavel

March 26, 2012

Re: [Pharo-project] FFI error message: Heisenbug

by Schwab,Wilhelm K

Eliot, Ok, I'm chewing on that :) Thanks. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Sunday, March 25, 2012 3:46 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI error message: Heisenbug On Sun, Mar 25, 2012 at 9:36 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: I'm working on GSL+callbacks, and have hit a genuine Heisenbug - the behavior changes depending on when/where I break and/or step over or into code. Callbacks are getting hit successfully(!!!) but there is one function that crashes, unless I step over the call, in which case I get an error. In particular, if I step far enough into things to see the call, calling gsl_multifit_fdfsolver_set() is raising an error (vs. crashing if I don't look<g>) that says 'No module to load address from'. Anybody know what that means? I'm using the CogVM on Ubuntu Lucid. That's the error associated with FFIErrorNoModule, see ExternalFunction class>initializeErrorMessages. An FFI call will fail with this when it can't find the call address in the first method literal (or when doing ExternalFunction>invokeWithArguments and the receiver doesn't have a call address). Bill -- best, Eliot

March 26, 2012

Re: [Pharo-project] FFI error message: Heisenbug

by Schwab,Wilhelm K

Eliot, I didn't think of that, but your NotInLibrary() test "works" in that it raises a not-found error. So it looks like gsl_multifit_fdfsolver_set() is available. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Sunday, March 25, 2012 3:35 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI error message: Heisenbug On Sun, Mar 25, 2012 at 9:55 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: I started asking whether the setter function might somehow not be visible through my wrapper .so. Running objdump -T /home/bills/Work2010/gslWrapper/bin/Release/libgslWrapper.so | grep gsl_multifit_fdfsolver_set gives nothing, but my experience has been the wrapper "magically" exports everything from blas and gsl, but I'm not sure how to list all of the exports. Regardless, Alien lookup:'gsl_multifit_fdfsolver_set' inLibrary:'libgslWrapper.so' returns an Alien with a handle, so can I assume that the function is indeed exported by the wrapper? yes. But have you thought to confirm by trying Alien lookup:'this_is_not_in_the_library' inLibrary:'libgslWrapper.so' ? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>] Sent: Sunday, March 25, 2012 12:36 PM To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr> Subject: [Pharo-project] FFI error message: Heisenbug I'm working on GSL+callbacks, and have hit a genuine Heisenbug - the behavior changes depending on when/where I break and/or step over or into code. Callbacks are getting hit successfully(!!!) but there is one function that crashes, unless I step over the call, in which case I get an error. In particular, if I step far enough into things to see the call, calling gsl_multifit_fdfsolver_set() is raising an error (vs. crashing if I don't look<g>) that says 'No module to load address from'. Anybody know what that means? I'm using the CogVM on Ubuntu Lucid. Bill -- best, Eliot

March 26, 2012

[Pharo-project] New ECompletion

by StÃ©phane Ducasse

Hello I just created a configuration of the New ECompletion package. Now it worked nicely in 1.4. I hope one of these days to have the time to fix OCompletion to work nicely and without breaking ECompletion. Gofer new url: 'http://ss3.gemstone.com/ss/NEC'; package: 'ConfigurationOfNewECompletion'; load. ((Smalltalk at: #ConfigurationOfNewECompletion) project version: #stable) load Stef

March 26, 2012

[Pharo-project] Announcement vs SystemChangeNotifier

by StÃ©phane Ducasse

Hi guys I'm starting to look at how we can remove SystemChangeNotifier to only use SystemAnnouncement. Now Is there an equivalent to SystemChangeNotifier uniqueInstance doSilently: [â¦â¦] for Announcement? Stef

March 26, 2012

Re: [Pharo-project] FFI error message: Heisenbug

by Eliot Miranda

On Sun, Mar 25, 2012 at 9:36 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I'm working on GSL+callbacks, and have hit a genuine Heisenbug - the > behavior changes depending on when/where I break and/or step over or into > code. Callbacks are getting hit successfully(!!!) but there is one > function that crashes, unless I step over the call, in which case I get an > error. > > In particular, if I step far enough into things to see the call, calling > gsl_multifit_fdfsolver_set() is raising an error (vs. crashing if I don't > look<g>) that says 'No module to load address from'. Anybody know what > that means? I'm using the CogVM on Ubuntu Lucid. > That's the error associated with FFIErrorNoModule, see ExternalFunction class>initializeErrorMessages. An FFI call will fail with this when it can't find the call address in the first method literal (or when doing ExternalFunction>invokeWithArguments and the receiver doesn't have a call address). > Bill > > -- best, Eliot

March 26, 2012

[Pharo-project] Reducing the use of DependentFields

by StÃ©phane Ducasse

Hi DependentFields is a classVar in Object to make sure that an object can have dependent even if it does not inherit from Model. Cuis got this fixed and I would like to get the same. Now finding users of it is difficult. I found that MCWorkingCopies use a lot this behavior but I'm looking where exactly. So may be changing the superclass of MCPckageManager is the solution. Any ideas? Stef

March 26, 2012

Re: [Pharo-project] FFI error message: Heisenbug

by Eliot Miranda

On Sun, Mar 25, 2012 at 9:55 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I started asking whether the setter function might somehow not be > visible through my wrapper .so. Running > > objdump -T /home/bills/Work2010/gslWrapper/bin/Release/libgslWrapper.so | > grep gsl_multifit_fdfsolver_set > > gives nothing, but my experience has been the wrapper "magically" exports > everything from blas and gsl, but I'm not sure how to list all of the > exports. > > Regardless, > > Alien > lookup:'gsl_multifit_fdfsolver_set' > inLibrary:'libgslWrapper.so' > > returns an Alien with a handle, so can I assume that the function is > indeed exported by the wrapper? > yes. But have you thought to confirm by trying Alien lookup:'this_is_not_in_the_library' inLibrary:'libgslWrapper.so' ? > Bill > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm > K [bschwab(a)anest.ufl.edu] > *Sent:* Sunday, March 25, 2012 12:36 PM > *To:* pharo-project(a)lists.gforge.inria.fr > *Subject:* [Pharo-project] FFI error message: Heisenbug > > I'm working on GSL+callbacks, and have hit a genuine Heisenbug - the > behavior changes depending on when/where I break and/or step over or into > code. Callbacks are getting hit successfully(!!!) but there is one > function that crashes, unless I step over the call, in which case I get an > error. > > In particular, if I step far enough into things to see the call, calling > gsl_multifit_fdfsolver_set() is raising an error (vs. crashing if I don't > look<g>) that says 'No module to load address from'. Anybody know what > that means? I'm using the CogVM on Ubuntu Lucid. > > Bill > > -- best, Eliot

March 26, 2012

Re: [Pharo-project] FFI error message: Heisenbug

by Schwab,Wilhelm K

I started asking whether the setter function might somehow not be visible through my wrapper .so. Running objdump -T /home/bills/Work2010/gslWrapper/bin/Release/libgslWrapper.so | grep gsl_multifit_fdfsolver_set gives nothing, but my experience has been the wrapper "magically" exports everything from blas and gsl, but I'm not sure how to list all of the exports. Regardless, Alien lookup:'gsl_multifit_fdfsolver_set' inLibrary:'libgslWrapper.so' returns an Alien with a handle, so can I assume that the function is indeed exported by the wrapper? Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Sunday, March 25, 2012 12:36 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] FFI error message: Heisenbug I'm working on GSL+callbacks, and have hit a genuine Heisenbug - the behavior changes depending on when/where I break and/or step over or into code. Callbacks are getting hit successfully(!!!) but there is one function that crashes, unless I step over the call, in which case I get an error. In particular, if I step far enough into things to see the call, calling gsl_multifit_fdfsolver_set() is raising an error (vs. crashing if I don't look<g>) that says 'No module to load address from'. Anybody know what that means? I'm using the CogVM on Ubuntu Lucid. Bill

March 26, 2012