September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] catching FFI errors

by Eliot Miranda

Hi Ben, On Sep 25, 2014, at 5:50 PM, Ben Coman <btc(a)openInWorld.com> wrote: > > I had a brief moment wondering about the general problem we have when calling out through FFI that we expose ourselves to bugs in the external library that crash the Image. I wonder... > > 1. Debuggers like gdb can run a program that crashes, without themselves itself crashing. Could our FFI calls be wrapped in similar mechanism? > > 2. Languages have exception handling, so that errors like divide by zero can be caught. Could our FFI calls be wrapped in similar mechanism? > cheers -ben one thing that is pretty straight-forward to do is to catch and report errors during FFI calls as primitive failures with error codes. I added this to the VisualWorks VM a while ago It works like this: 1. The VM installs a first-level exception handler (windows) or signal handlers for SIGSEGV et al (unix). (This is something the VM already does). 2. When an FFI call out is made the VM can find the activation they made an FDI call out. It must be able to do this if it is to handle a callback. 3. An FFI call out is modified to set a flag, eg inFFICall, that is tested by the first-level exception handler. The flag is cleared when the FFI call completes or cleared when taking a callback and restored when the callback returns. 4. When the first level exception/signal handler is invoked it tests the inFFICall flag. If unset it does what it always did (exit, do nothing, etc). If the flag is set it collects the error information, located the FFI activation for the FFI call, does a long jump that returns from the FFI call as a primitive failure, supplying the error information. Now this is useful because the VM doesn't crash (provided the error was localized in its effects and didnt eg corrupt the heap), and hence easy for the developer to find out which FFI call provoked the error, but not as useful as catching the error in gdb. The exception info is typically an exception code and an address, which may be difficult for the programmer to decode. Hence the mechanism needs to be made optional, typically in by default, and then disabled to investigate under gdb. Does this sound useful? Eliot (phone)

Sept. 26, 2014

Re: [Pharo-dev] [Pharo-users] Your picture on Pharo contributors :)

by Serge Stinckwich

If you have a gravatar picture, you can generate a 70x70 picture like that: (ZnEasy getJpeg: 'http://www.gravatar.com/avatar/', (ZnDigestAuthenticator md5Hash: 'serge.stinckwich(a)gmail.com'),'?s=70' ) asMorph openInWorld On Fri, Sep 26, 2014 at 7:55 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 26 Sep 2014, at 07:25, stepharo <stepharo(a)free.fr> wrote: > >> Hi guys >> >> do not forget to sign the license agreement >> http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf >> and send us your picture to be added to >> http://pharo.org/about >> >> Stef > > The picture should be a 70x70 PNG. > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Sept. 26, 2014

Re: [Pharo-dev] Building .deb with Pharo VM

by Jan Vrany

Hi Markus & Damien, Markus, thanks for the hint, I'll try. Damien, yes, the problematic patch was source-hardening.patch as Markus pointed out. And then also something about native vs. quilt package format. So far I struggled with recipe given by Clement, mainly because of libgit2 - it refuses to compile cleanly in 32bit mode under 64bit system (I had this problem 2 years ago when playing with libgit2, apparently no progress here :-) Bit of sed would do it, although super ugly. Then the vm generator generated sources to the wrong directory. It either does not respect process CWD os it was something else... However, I already exhausted my free time. I'll try again later and get back to you. Best, Jan On Thu, 2014-09-25 at 15:37 +0200, Markus Fritsche wrote: > On 2014-09-25 13:58, Damien Cassou wrote: > > >> I tried that,but some patches applied to the sources above are rejected > >> so package dpkg-buildpackage fails - at least on Debian Jessie > > > can you give more information? > > source-hardening.patch has to be adjusted > > --- a/src/vm/cogit.c 2014-09-24 11:26:13.117242533 +0200 > +++ b/src/vm/cogit.c 2014-09-24 11:26:55.181154041 +0200 > @@ -19339,7 +19339,7 @@ printTrampolineTable(void) > for (i = 0; i < trampolineTableIndex; i += 2) { > printHex(((sqInt)(trampolineAddresses[i + 1]))); > print(": "); > - print(((char *) (trampolineAddresses[i]))); > + printf("%s", trampolineAddresses[i]); > cr(); > } > } > > > Kind regards, > Markus >

Sept. 26, 2014

Re: [Pharo-dev] showing decompiled code in the browser (was "Nautilus roadmap / icons")

by Esteban Lorenzano

On 26 Sep 2014, at 09:04, Craig Latta <craig(a)netjam.org> wrote: > > Hi Marcus-- > >> Honestly, I do not get why [showing decompiled code in the browser] >> was useful, ever. > > Some of my debugging sessions require using the virtual machine > simulator. I find browser-presented decompilation useful for finding my > place in a method I'm running that way. It's also useful for learning > about how the compiler and virtual machine work. so is a good functionality for putting in plugin, not a standard feature of nautilus: if working with vm simulator, if debugging it, ifâ¦ Esteban > > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > >

Sept. 26, 2014

showing decompiled code in the browser (was "Nautilus roadmap / icons")

by Craig Latta

Hi Marcus-- > Honestly, I do not get why [showing decompiled code in the browser] > was useful, ever. Some of my debugging sessions require using the virtual machine simulator. I find browser-presented decompilation useful for finding my place in a method I'm running that way. It's also useful for learning about how the compiler and virtual machine work. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Sept. 26, 2014

Re: [Pharo-dev] Nautilus roadmap / icons

by Marcus Denker

On 25 Sep 2014, at 23:02, phil(a)highoctane.be wrote: > Well, the full story is that the decompiler is now gone with Opal. > There is a decompiler again in Pharo4 > So, there were 3 in the beginning. So, of course with 2, this becomes a switch. > > Why no decompiler anymore, for the layman I am? > The *option* of showing decompiled code in the browser: Honestly, I do not get why this was useful, ever. Marcus

Sept. 26, 2014

Re: [Pharo-dev] [Pharo-users] Your picture on Pharo contributors :)

by Sven Van Caekenberghe

On 26 Sep 2014, at 07:25, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > do not forget to sign the license agreement > http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf > and send us your picture to be added to > http://pharo.org/about > > Stef The picture should be a 70x70 PNG.

Sept. 26, 2014

Your picture on Pharo contributors :)

by stepharo

Hi guys do not forget to sign the license agreement http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf and send us your picture to be added to http://pharo.org/about Stef

Sept. 26, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 8cce4c: 40254

by Ronie Salgado

> So others don't need to google UFFI. I found... > http://users.dcc.uchile.cl/~rsalgado/uffi-fourth-draft.pdf > > Very interesting. Call backs for NativeBoost, static C function generator, > and I particularly like "The special emphasis in documentation, is given > because of the lack of an easy to ï¬nd and consult centralized > documentation, that it is required to allow the entrance of new people > working in core features and also for users, that needs a simple > step-by-step tutorial for getting started, and a full reference manual when > they need more advanced features." Well, that was the original proposal. After some discussions, the plans changed a lot, but the end user interface is almost the same. When I started implementing that original plan, I was having some issues with the GC. I noticed that the biggest problem with the static C code generator was going to be in defining a interface for objects references in the C code. Because of this problem, the static C code generator was discarded in an earlier stage of development. After having some discussion with Eliot, we decided to exploit the new bytecode extensibility features, to encode the semantics required to perform a C function call. I called Lowcode the extension for FFI. And the objective now is to implement it in the StackInterpreter and the Cogit. What I am doing with these instructions is to add all the power of C to the VM. The main new features are primitive machine types, pointers and function calls. I already have implemented the StackInterpreter version, and I have implemented most of the new bytecode instructions in the Cogit. Currently I am starting to test the new FFI. I should be having the new FFI soon. Now, currently I am just implementing the callouts. I am still missing the new callbacks, but they should be implemented in some time. Best regards, Ronie 2014-09-25 22:09 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > stepharo wrote: > >> Basically the idea is that we get a API to manage all the windowing and >> event information. >> We will be to clean the VM event handling code. >> Right now it works normally. Soon we will have a SDL plugin as a back end. >> And it should be using Ronie UFFI >> Stef >> > > So others don't need to google UFFI. I found... > http://users.dcc.uchile.cl/~rsalgado/uffi-fourth-draft.pdf > > Very interesting. Call backs for NativeBoost, static C function generator, > and I particularly like "The special emphasis in documentation, is given > because of the lack of an easy to ï¬nd and consult centralized > documentation, that it is required to allow the entrance of new people > working in core features and also for users, that needs a simple > step-by-step tutorial for getting started, and a full reference manual when > they need more advanced features." > > cheers -ben > > > > > 14071 OSWindow integration part1 >>>> >>> Can we get a short status update? What can be done on which platforms? >>> Thanks :) >>> >>> >> >> > > >

Sept. 26, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 8cce4c: 40254

by Ben Coman

stepharo wrote: > Basically the idea is that we get a API to manage all the windowing > and event information. > We will be to clean the VM event handling code. > Right now it works normally. Soon we will have a SDL plugin as a back > end. > And it should be using Ronie UFFI > Stef So others don't need to google UFFI. I found... http://users.dcc.uchile.cl/~rsalgado/uffi-fourth-draft.pdf Very interesting. Call backs for NativeBoost, static C function generator, and I particularly like "The special emphasis in documentation, is given because of the lack of an easy to ï¬nd and consult centralized documentation, that it is required to allow the entrance of new people working in core features and also for users, that needs a simple step-by-step tutorial for getting started, and a full reference manual when they need more advanced features." cheers -ben >>> 14071 OSWindow integration part1 >> Can we get a short status update? What can be done on which platforms? >> Thanks :) >> > >

Sept. 26, 2014