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

Re: [Pharo-dev] SWIG for Native Boost FFI

by Ronie Salgado

Its completely different approach. SWIG is a tool designed to create bindings, for which you provide an interface descripitions, which usually includes your C/C++ headers, and you provide some SWIG specific directives for improving the generated bindings. It produces C side module and a language specific module. The C side is required, since some C stuff can only be detected by an actual C compiler. In these matter, maybe TalkFFI is better, because is based in an actual compiler(clang), but maybe you lose some bindings fine tuning. The problem is when you add C++ to the mix. In C++ there's not a standard defined ABI, so a module made in one C++ compiler is almost for sure going to be incompatible with a module made by another C++ compiler. For making bindings to a C++ module, you have to first make C bindings to that module, compile those bindings with the same compiler that was used for the original module and then you can start making NativeBoost bindings. This is the only portable way for C++. For example, gcc and Microsoft Visual C++ compilers are completely incompatible for C++, but for C they can interact. Clang is apparently designed to use the same ABI as gcc, so maybe it could be used in Linux, Mac but not for a closed source library in Window. What SWIG does is generating the C bindings and Smalltalk code that calls the C bindings ready to be filed in. In addition, you can add extra code to the bindings to make things that hard to do using directly NativeBoost but can be easy to do with an intermediate function in C, for example messing with some unions and things that required lot of pointer arithmetic, that could be used maybe for a bad written library that some project needs. P.S I have yet to make an example. When I add some documentation, which is required to be able to integrate into the main SWIG distribution, I will post a new message to the list. Greetings Ronie Salgado 2014/1/23 Stefan Marr <smalltalk(a)stefan-marr.de> > Hi Ronie: > > > On 22 Jan 2014, at 21:25, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > > I started working on extending SWIG to generate bindings for NativeBoost > FFI, using as a reference the C# binding generator. I am committing my work > on this into https://github.com/ronsaldo/swig/ . > > Just out of curiosity, how does it compare to TalkFFI? > ( > http://lists.gforge.inria.fr/pipermail/pharo-project/2013-January/072847.ht…, > http://vimeo.com/63472765) > > Best regards > Stefan > > > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > >

Jan. 23, 2014

Re: [Pharo-dev] Services and -vm-display-null

by btc＠openinworld.com

Jan. 23, 2014

Re: [Pharo-dev] Morphic Alarms

by Chris Muller

When the hand enters a Morph, a help balloon appears, not instantly, but after a time elapsed. On Thu, Jan 23, 2014 at 12:39 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Is anyone using them? What is a real world use case? I've read through the > class comment, senders (currently seems to be only DebuggerSession), etc... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Morphic-Alarms-tp4738603.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Jan. 23, 2014

Re: [Pharo-dev] Services and -vm-display-null

by Sebastian Sastre

Thanks Sven bue I have no issues on Pharo 2 The problem is with Pharo 3 on the latest VM With services and all this I was referring not to things inside the image but in the OS (the headless image as service) Yes, having a init.d script to start the image is the goal Are you using your scrips on any Pharo 3? sebastian o/ On Jan 23, 2014, at 1:32 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > On 23 Jan 2014, at 16:14, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Hi there, >> >> What are you using to monitor processes in headless images? >> >> I ask because the new way to start a headless image in linux is: >> >> pharo-vm/pharo -vm-display-null your.image âno-quit >> >> And it seems that it always quits > > I always start images with no preconfigured servers/services in them and then use an st script to start servers/services. Then you are using the STCommandLineHandler that does _not_ quit by default. > > Furthermore, I have a script to control image/vm start/stop/restart/pid which I use from /etc/init.d with monit using these last scripts. > > If you want, I can send you the code. > > You could try extracting it from http://stfx.eu/pharo-server/ but that page is old. > > HTH, > > Sven > >> For example supervisord* is really unhappy about this way to run a service. >> >> Itâs really unfortunate. This is a show stopper. >> >> Is there an OS signal being sent when you use -vm-display-null or the process stays normally up? >> >> There is no way to run a headless image like we used to? >> >> sebastian >> >> o/ >> >> >> *http://supervisord.org/ > >

Jan. 23, 2014

Re: [Pharo-dev] SWIG for Native Boost FFI

by Stefan Marr

Hi Ronie: On 22 Jan 2014, at 21:25, Ronie Salgado <roniesalg(a)gmail.com> wrote: > I started working on extending SWIG to generate bindings for NativeBoost FFI, using as a reference the C# binding generator. I am committing my work on this into https://github.com/ronsaldo/swig/ . Just out of curiosity, how does it compare to TalkFFI? (http://lists.gforge.inria.fr/pipermail/pharo-project/2013-January/072847.ht…, http://vimeo.com/63472765) Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

Jan. 23, 2014

Re: [Pharo-dev] Pharo 3.0 on Raspberry Pi - Yes/No

by Jean Baptiste Arnaud

I made some advance and cleaning about the RaspberryPi, compilation. I cross compile from an unix slave, that is really faster and allow me easily to compile the fast bltbit file. Now I integrate the fastbltbit into the StackVM (there a job associated but at term It will be merged): https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Cro… https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Cro… We have a small bug on the git tracker now but once it will solve the job will automatically follow the update. The version downloadable should work. I try Sven you are right the UI seems always busy even with fast bltbit (at least on my RaspberryPi ). I will inspect that. If you have already clues about that, feel free to educate me :-). On 20 Jan 2014, at 23:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Jean Baptiste, > > On 20 Jan 2014, at 21:51, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > >> >> On 20 Jan 2014, at 19:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> Hi, >>> >>> Here is another step forward in getting Pharo 3.0 to run on a Raspberry Pi. >>> >>> Yes: >>> >>> pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'SystemVersion current' >>> Pharo3.0 of 18 March 2013 update 30710 >>> >>> pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'ZTimestamp now' >>> 2014-01-20T18:21:50Z >>> >>> No errors. >>> >>> >>> No: >>> >>> When doing something more complex, like: >>> >>> pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' >>> a ZnManagingMultiThreadedServer(running 1701) >>> >>> The HTTP Server does respond normally to one request and then seems to hang. >> Strange ... > > Yeah, I will retest tomorrow or so, the wireless adaptor on the Pi did act a bit up during testing, maybe that interfered, I don't know. > >>> When running with a UI, the image comes up, draws everything but remains unresponsive otherwise. >> I think it is because the UI is to slow and run in software only. >> The raspberry completely overcharged by the ui. >> I actually push fast bltbit, then we should have a slow but responsible UI . > > Hmm, it really didn't do anything, I try again. > >>> No PharoDebug.log output. >> Because that do not crash just over lag. Due to the UI. > > I just meant to say there were no errors ;-) > > Sending USR1 didn't reveal much either (no weird loops). > > I still think there is something wrong, does it work for you ? > > Sven > >>> Events ? Multi-processing ? >>> >>> >>> How ? >>> >>> Use Jean-Baptiste's VM from here: >>> >>> https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Com… >>> >>> Take a stock 3.0 image and apply Pavel's unloadNB.st script (see the thread with subject unload all). >>> >>> So, we're getting closer... >>> >>> If anyone is interested, I could make some kind of all in one download. >>> >>> Sven >>> >>> >> >> Best Regards >> Jean Baptiste Arnaud >> jbaptiste.arnaud(a)gmail.com >> >> >> >> >> >> >> > > Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Jan. 23, 2014

Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel

by Benjamin

On 23 Jan 2014, at 12:53, btc(a)openinworld.com wrote: > I gave this a try and indeed #whenBuiltDo: works from #initialize. However in PharoLauncher <Create Image> stopped updating the list. After a bit of a muddling around I found that I am prevented from registering the event "wherever I wanted", since the subscription does not go to theValueHolder but to the contents of theValueHolder. That sounds strange :( > That is as far as I can push this for now. I have a working solution with previously proposed ComposableModel>>topWindowHolder and ComposableModel>>whenWindowClosed: so I will proceed with that. Any objections to pushing these into Pharo 3 at this late stage :) and I'll just make them extensions from PharoLauncher. If you submit a slice, I will review it :) Note that you can also do it on top of the bleeding edge Spec[1] Ben [1]https://github.com/SpecForPharo/spec > > cheers -ben > >> >> >>> I tried to avoid calling in #windowHolder but would that preferred? >>> Do you have another suggestion? >>> >> >> I was not talking about the name, more the implementation :P >> (but not more than #window :) ) >> >> >> >>> btw, the 'window' i-var of ComposableModel seems like it should be 'windowHolder' >>> >> >> I think all the other variable should be name without holder at the end :) >> >> Ben >> >> >

Jan. 23, 2014

Re: [Pharo-dev] #windowIsClosing not sent to model of WindowModel

by btc＠openinworld.com

Jan. 23, 2014

Re: [Pharo-dev] Services and -vm-display-null

by Sven Van Caekenberghe

Hi, On 23 Jan 2014, at 16:14, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Hi there, > > What are you using to monitor processes in headless images? > > I ask because the new way to start a headless image in linux is: > > pharo-vm/pharo -vm-display-null your.image âno-quit > > And it seems that it always quits I always start images with no preconfigured servers/services in them and then use an st script to start servers/services. Then you are using the STCommandLineHandler that does _not_ quit by default. Furthermore, I have a script to control image/vm start/stop/restart/pid which I use from /etc/init.d with monit using these last scripts. If you want, I can send you the code. You could try extracting it from http://stfx.eu/pharo-server/ but that page is old. HTH, Sven > For example supervisord* is really unhappy about this way to run a service. > > Itâs really unfortunate. This is a show stopper. > > Is there an OS signal being sent when you use -vm-display-null or the process stays normally up? > > There is no way to run a headless image like we used to? > > sebastian > > o/ > > > *http://supervisord.org/

Jan. 23, 2014

Services and -vm-display-null

by Sebastian Sastre

Hi there, What are you using to monitor processes in headless images? I ask because the new way to start a headless image in linux is: pharo-vm/pharo -vm-display-null your.image âno-quit And it seems that it always quits For example supervisord* is really unhappy about this way to run a service. Itâs really unfortunate. This is a show stopper. Is there an OS signal being sent when you use -vm-display-null or the process stays normally up? There is no way to run a headless image like we used to? sebastian o/ *http://supervisord.org/

Jan. 23, 2014