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

Re: [Pharo-dev] catching FFI errors

by Ronie Salgado

Hello, 1. Debuggers like gdb can run a program that crashes, without themselves > itself crashing. Could our FFI calls be wrapped in similar mechanism? I don't think so. A debugger does not run in the same process as the program being debugged. Also, you don't have any guarantee that you have not corrupted something important as the VM. If we have the debugger in the same process as the program being debugged, then the debugger could be corrupted by the error in the external C library. Trying to do something like that could be very dangerous. > 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 The short answer is that it cannot be done automatically, without losing a lot in portability Exception handling implementations depends in the language, operating system and CPU architectude. The way that exceptions are implemented is a wild territory. For C++, you do not have a standard ABI. You cannot interface directly with C++ without losing portability. For wrapping C++, you first have to write a C wrapper for the C++ library, and then you have to do a wrapper in Pharo to the C library. In this C wrapper, you could something like catching all the exceptions and store them in some data structure that can be retrieved later. Then in the Pharo image you have to check for a pending exception in this data structure, and then transform wrapped exception into something more appropriate. Greetings, Ronie 2014-09-25 21:50 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > > 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 > >

Sept. 26, 2014

catching FFI errors

by Ben Coman

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

Sept. 26, 2014

Why version `GLIBC_2.15'?

by Bernardo Ezequiel Contreras

hi all, i just want to know why the pharo-vm is compiled with `GLIBC_2.15'? is there a bug due to glibc's version? thanks. -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Sept. 26, 2014

Re: [Pharo-dev] Nautilus roadmap / icons

by Esteban Lorenzano

afaik, we have a new decompiler, to correct that absence (which was just temporal). check at Opal-Decompiler package. Esteban 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. > > 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? > > Phil > > > On Thu, Sep 25, 2014 at 10:26 PM, stepharo <stepharo(a)free.fr> wrote: > > On 24/9/14 18:14, phil(a)highoctane.be wrote: > > In https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Cleaning… > > I see that you want to remove history, text/bytecode icons > > Why ? > > I am using those. > > I propose that. > I would prefer that people use the plugins that they want and that the default is lighter. > > Simplifying > - the history to me is really limited. > - for the buttons > one button is to switch mode > other button (the I) with the same symbolic feel are queries (ugly) > - I do not see why we need button to switch more for something that really few people use (it could be a menu) > or at least a checkbox and not a button. > > > Phil > > > >

Sept. 25, 2014

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

by Esteban Lorenzano

no, it works (or at least it shouldâ¦) Esteban On 25 Sep 2014, at 22:59, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > stepharo wrote >> Right now it works normally > > IIRC last time I checked it was not working on Mac, no? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/pharo-project-pharo-core-8cce4c-40254-tp4780221p47803… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 25, 2014

Re: [Pharo-dev] Nautilus roadmap / icons

by phil＠highoctane.be

Well, the full story is that the decompiler is now gone with Opal. 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? Phil On Thu, Sep 25, 2014 at 10:26 PM, stepharo <stepharo(a)free.fr> wrote: > > On 24/9/14 18:14, phil(a)highoctane.be wrote: > >> >> In https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/ >> CleaningNautilusRoadmap.md >> >> I see that you want to remove history, text/bytecode icons >> >> Why ? >> >> I am using those. >> >> I propose that. > I would prefer that people use the plugins that they want and that the > default is lighter. > > Simplifying > - the history to me is really limited. > - for the buttons > one button is to switch mode > other button (the I) with the same symbolic feel are queries (ugly) > - I do not see why we need button to switch more for something that > really few people use (it could be a menu) > or at least a checkbox and not a button. > > > Phil >> >> > >

Sept. 25, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 18c33b: 30858

by Sean P. DeNigris

Sean P. DeNigris wrote > maybe we should do them all for this release and be done with it... Issue 14080: Nuke remaining subStringXyz's https://pharo.fogbugz.com/default.asp?14080 ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-18c33b-30858-tp4779985p47803… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 25, 2014

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

by Sean P. DeNigris

stepharo wrote > Right now it works normally IIRC last time I checked it was not working on Mac, no? ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-8cce4c-40254-tp4780221p47803… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 25, 2014

Re: [Pharo-dev] can not compile pharo-vm on linux

by Damien Cassou

On Thu, Sep 25, 2014 at 7:49 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Problem solved! > Ubuntu 10.04 uses cmake 2.8.0 and for some reason the add_custom_command > does not work > in that version. > I was finally able to build a vm on linux with cmake 2.8.10.2 congratulations. But it is already obsolete :-). Please use the new source tree http://files.pharo.org/vm/src/vm-unix-sources/blessed. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 25, 2014

Re: [Pharo-dev] new VMs promoted ad stable

by Esteban Lorenzano

Hi, yeahâ¦ so? :) I just promoted a new stable version with *less bugs*, not *bug free* :P seriously: I didnât have the time to check at the issue, Iâm sorryâ¦ (though it is in my TODO list...) Esteban, the orchestra-man On 25 Sep 2014, at 22:38, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Esteban, > > But the Windows VM still has this bug, see here > > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/1… > > and here > > https://pharo.fogbugz.com/f/cases/13995/Recent-Windows-VM-does-not-reopen-f… > > cheers, > T. > >> Gesendet: Donnerstag, 25. September 2014 um 17:53 Uhr >> Von: "Esteban Lorenzano" <estebanlm(a)gmail.com> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: [Pharo-dev] new VMs promoted ad stable >> >> Hi, >> >> I promoted latest VMs to stable. >> Not many changes, but at least infamous SmallInteger bug should not be there anymore. >> >> cheers, >> Esteban >>

Sept. 25, 2014