- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Internship

by Igor Stasenko

Very interesting topic and very userful. We could use C parser for automatic generation of FFI bindings to C libraries. On 22 November 2012 15:42, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi all, > > I'm looking for some help in parsing C files (and the opportunity to use > Petit Parser (Parseur?)) so I'm looking for an internship candidate (Master > level). > > The objective is to do a C preprocessor with a targeted integration in an > existing C parser, and, in particular, provide high-level information about > applied macros/defines for the tokens provided to the C parser itself. > Platform should be Pharo (2.0:)). > > Place is Saclay, SW of Paris. The lab has a strong team on compilation tool > chains for embedded manycores, from programming language design down to > micro-kernel and mapping, and is able to select good interns for further > work opportunities. > > http://www.cea.fr/ressources-humaines/stages-et-formation-en-alternance/les… > > Regards, > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- Best regards, Igor Stasenko.

Nov. 22, 2012

Re: [Pharo-project] [ANN] Limbo: a simple shell wrapper for NativeBoost

by Igor Stasenko

On 22 November 2012 16:04, Max Leske <maxleske(a)gmail.com> wrote: > > On 22.11.2012, at 12:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 22 November 2012 11:19, Max Leske <maxleske(a)gmail.com> wrote: >>> I have run into a small problem with fork(): >>> >>> pid := self primitiveRun. >>> pid isZero >>> ifTrue: [ "child code with exec" ] >>> ifFalse: [ "parent code" ] >>> >>> primitiveRun >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >>> ^ self nbCall: #( int fork() ) >>> >>> Only the parent code is ever executed, #pid is never 0. >> >> are you sure about that? >> if you evaluate >> self fork >> it will always answer non-zero.. because it is parent process, >> where you observing result. >> But that doesnt means that there is no child process which observes >> different return value. > > Assuming that I wouldn't be able to observer when #pid is 0, then the following should still work: > > pid := self primitiveRun. > pid isZero > ifTrue: [ StandardFileStream forceNewFileNamed: 'foo.log' ] <----------------------- > ifFalse: [ "parent code" ] > > The file 'foo.log' is never created. > > The UnixOSProcessPlugin has pretty much the same code: > > ((pid := self cCode: 'vfork()') = 0) > ifFalse: > [ "child code" ] > ifTrue: > [ "parent code" ] > > BTW: using vfork() instead of fork() (as OSProcess does) doesn't work either (the image hangs as expected but the file 'foo.log' is not created). > what you mean image hangs? do you see if child process created? -- Best regards, Igor Stasenko.

Nov. 22, 2012

Re: [Pharo-project] [ANN] Limbo: a simple shell wrapper for NativeBoost

by David T. Lewis

On Thu, Nov 22, 2012 at 04:04:00PM +0100, Max Leske wrote: > > On 22.11.2012, at 12:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 22 November 2012 11:19, Max Leske <maxleske(a)gmail.com> wrote: > >> I have run into a small problem with fork(): > >> > >> pid := self primitiveRun. > >> pid isZero > >> ifTrue: [ "child code with exec" ] > >> ifFalse: [ "parent code" ] > >> > >> primitiveRun > >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > >> ^ self nbCall: #( int fork() ) > >> > >> Only the parent code is ever executed, #pid is never 0. > > > > are you sure about that? > > if you evaluate > > self fork > > it will always answer non-zero.. because it is parent process, > > where you observing result. > > But that doesnt means that there is no child process which observes > > different return value. > > Assuming that I wouldn't be able to observer when #pid is 0, then the following should still work: > > pid := self primitiveRun. > pid isZero > ifTrue: [ StandardFileStream forceNewFileNamed: 'foo.log' ] <----------------------- > ifFalse: [ "parent code" ] > > The file 'foo.log' is never created. > > The UnixOSProcessPlugin has pretty much the same code: > > ((pid := self cCode: 'vfork()') = 0) > ifFalse: > [ "child code" ] > ifTrue: > [ "parent code" ] > > BTW: using vfork() instead of fork() (as OSProcess does) doesn't work either (the image hangs as expected but the file 'foo.log' is not created). > Assuming that you are trying to do a fork followed by exec, you will want to do the exec immediately after the fork. This may introduce some complications when you do it as two FFI calls, because your child process is still running Smalltalk on the VM, and it needs to keep running long enough to the second FFI call. Opening a new file stream on 'foo.log' implies a *lot* of processing in the child VM, so I am not surprised that this does not work. You might try just making a little "hello world" C program, and see if you can exec that program after doing the fork. That would be a lot less processing for your child VM, so it may have a better chance of working. But you still may have a few issues to sort out in keeping the child VM running long enough to get the the exec FFI call. Dave > > > > >> Looking at UnixOSProcessPlugin I see that there are some special things Dave did before forking and I'm wondering if these would be necessary with NB. In the method #forkAndExecInDirectory: > >> 1. possible use of a sig handler > >> 2. special secure mode handling (what's that?) > >> 3. turn off the interval timer > >> > >> Any ideas? > >> > >> Cheers, > >> Max > >> > >> On 21.11.2012, at 08:50, Max Leske <maxleske(a)gmail.com> wrote: > >> > >>> > >>> On 20.11.2012, at 21:56, David T. Lewis <lewis(a)mail.msen.com> wrote: > >>> > >>>> On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote: > >>>>> > >>>>> Providing bindings to fork/pipe kernel functions is piece of cake. > >>>>> But writing a wrapper around it would be a bit of work.. but still it > >>>>> is possible. And you should try. > >>>>> > >>>>> And yes, using fork() stuff having many treacherous pitfalls, but > >>>>> don't think that if you call this function from code written in C > >>>>> instead of NB will make it less treacherous. > >>>>> I think Dave can give some more input on that, because he also using > >>>>> fork() in OSProcess. > >>>> > >>>> In normal use, the fork() call is immediately followed by an exec(), so > >>>> it is not tricky at all. The only thing that was tricky to do in OSProcess > >>>> was forkSqueak() which forks the VM itself and then attempts to continue > >>>> running. But that is really an unusual use case. > >>>> > >>>> The system calls such as fork() and pipe() should work the same whether > >>>> you are calling from FFI or from generated C in a primitive. You can > >>>> find examples for many of these calls in OSProcess. In general, the > >>>> interface to system calls and standard C library functions is in > >>>> UnixOSProcessPlugin, and the associated glue to tie it into the image > >>>> is in UnixOSProcessAccessor. I have not looked at it closely but I > >>>> think that in some cases you could change the methods in UnixOSProcessAccessor > >>>> to make FFI calls, at least in order to get something working initially > >>>> (I don't know if the design of OSProcess is what you want, but it could > >>>> get you started). > >>>> > >>> Thanks Dave, that's good to know. > >>> > >>> Cheers, > >>> Max > >>> > >>>> Dave > >>>> > >>>> > >>> > >> > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > >

Nov. 22, 2012

[Pharo-project] [update 2.0] #20416

by Marcus Denker

20416 ----- Issue 7032: DummySystemProgressItem is used only by UIManger --> move there http://code.google.com/p/pharo/issues/detail?id=7032 Issue 7016: repackage restoreAllNotifications http://code.google.com/p/pharo/issues/detail?id=7016 Diff information: http://ss3.gemstone.com/ss/Pharo20/UIManager-MarcusDenker.92.diff http://ss3.gemstone.com/ss/Pharo20/SystemProgress-MarcusDenker.5.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.748.diff http://ss3.gemstone.com/ss/Pharo20/System-PragmaCollector-MarcusDenker.11.d… http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1257.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 22, 2012

Re: [Pharo-project] [ANN] Limbo: a simple shell wrapper for NativeBoost

by Max Leske

On 22.11.2012, at 12:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 22 November 2012 11:19, Max Leske <maxleske(a)gmail.com> wrote: >> I have run into a small problem with fork(): >> >> pid := self primitiveRun. >> pid isZero >> ifTrue: [ "child code with exec" ] >> ifFalse: [ "parent code" ] >> >> primitiveRun >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >> ^ self nbCall: #( int fork() ) >> >> Only the parent code is ever executed, #pid is never 0. > > are you sure about that? > if you evaluate > self fork > it will always answer non-zero.. because it is parent process, > where you observing result. > But that doesnt means that there is no child process which observes > different return value. Assuming that I wouldn't be able to observer when #pid is 0, then the following should still work: pid := self primitiveRun. pid isZero ifTrue: [ StandardFileStream forceNewFileNamed: 'foo.log' ] <----------------------- ifFalse: [ "parent code" ] The file 'foo.log' is never created. The UnixOSProcessPlugin has pretty much the same code: ((pid := self cCode: 'vfork()') = 0) ifFalse: [ "child code" ] ifTrue: [ "parent code" ] BTW: using vfork() instead of fork() (as OSProcess does) doesn't work either (the image hangs as expected but the file 'foo.log' is not created). > >> Looking at UnixOSProcessPlugin I see that there are some special things Dave did before forking and I'm wondering if these would be necessary with NB. In the method #forkAndExecInDirectory: >> 1. possible use of a sig handler >> 2. special secure mode handling (what's that?) >> 3. turn off the interval timer >> >> Any ideas? >> >> Cheers, >> Max >> >> On 21.11.2012, at 08:50, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 20.11.2012, at 21:56, David T. Lewis <lewis(a)mail.msen.com> wrote: >>> >>>> On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote: >>>>> >>>>> Providing bindings to fork/pipe kernel functions is piece of cake. >>>>> But writing a wrapper around it would be a bit of work.. but still it >>>>> is possible. And you should try. >>>>> >>>>> And yes, using fork() stuff having many treacherous pitfalls, but >>>>> don't think that if you call this function from code written in C >>>>> instead of NB will make it less treacherous. >>>>> I think Dave can give some more input on that, because he also using >>>>> fork() in OSProcess. >>>> >>>> In normal use, the fork() call is immediately followed by an exec(), so >>>> it is not tricky at all. The only thing that was tricky to do in OSProcess >>>> was forkSqueak() which forks the VM itself and then attempts to continue >>>> running. But that is really an unusual use case. >>>> >>>> The system calls such as fork() and pipe() should work the same whether >>>> you are calling from FFI or from generated C in a primitive. You can >>>> find examples for many of these calls in OSProcess. In general, the >>>> interface to system calls and standard C library functions is in >>>> UnixOSProcessPlugin, and the associated glue to tie it into the image >>>> is in UnixOSProcessAccessor. I have not looked at it closely but I >>>> think that in some cases you could change the methods in UnixOSProcessAccessor >>>> to make FFI calls, at least in order to get something working initially >>>> (I don't know if the design of OSProcess is what you want, but it could >>>> get you started). >>>> >>> Thanks Dave, that's good to know. >>> >>> Cheers, >>> Max >>> >>>> Dave >>>> >>>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Nov. 22, 2012

Re: [Pharo-project] Athens, Nativeboost and Igor's gray hair

by Sven Van Caekenberghe

Very nice & cool ! On 22 Nov 2012, at 15:38, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Last week I've been sick, and because of that I've been bored. To get some fun I started to learn NativeBoos and Athens (and to stress Igor's patience on explain things :). > > After all, I prototyped a couple of examples that I think are fun: > > 1) AthensPlayground. This is a workspace prepared to fast-prototype athens animations (taking the same idea of http://www.processing.org/) > > You can see a video of the (for now) results here: http://youtu.be/NaR_fyk3qq4 > > I think it can be a good addition for people willing to do some animation work :) > > 2) After that, of course I was very happy, but I thought "why to stop there? now I want more!" and so, I made a quick search about physics library and after a couple of hours I made a (very primitive) Chipmunk usage framework and an even more primitive and simple "game engine like" framework, to mix both Athens and Chipmunk library. > > A video of the results can be found here: http://youtu.be/ZK-JlbeN09A > > Pretty cool, isn't? > > Ok, I know... is not like I invented the hot water, all of this was more or less present in morphic... but is cool to have real examples on using external libraries (also, physics are really hard to simulate, so... better to use something already existent). > > If you want to play with it, you can go to: http://smalltalkhub.com/#!/~estebanlm/Storm > > Enjoy :) > > Esteban -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Nov. 22, 2012

[Pharo-project] Internship

by Goubier Thierry

Hi all, I'm looking for some help in parsing C files (and the opportunity to use Petit Parser (Parseur?)) so I'm looking for an internship candidate (Master level). The objective is to do a C preprocessor with a targeted integration in an existing C parser, and, in particular, provide high-level information about applied macros/defines for the tokens provided to the C parser itself. Platform should be Pharo (2.0:)). Place is Saclay, SW of Paris. The lab has a strong team on compilation tool chains for embedded manycores, from programming language design down to micro-kernel and mapping, and is able to select good interns for further work opportunities. http://www.cea.fr/ressources-humaines/stages-et-formation-en-alternance/les… Regards, Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Nov. 22, 2012

[Pharo-project] Athens, Nativeboost and Igor's gray hair

by Esteban Lorenzano

Hi, Last week I've been sick, and because of that I've been bored. To get some fun I started to learn NativeBoos and Athens (and to stress Igor's patience on explain things :). After all, I prototyped a couple of examples that I think are fun: 1) AthensPlayground. This is a workspace prepared to fast-prototype athens animations (taking the same idea of http://www.processing.org/) You can see a video of the (for now) results here: http://youtu.be/NaR_fyk3qq4 I think it can be a good addition for people willing to do some animation work :) 2) After that, of course I was very happy, but I thought "why to stop there? now I want more!" and so, I made a quick search about physics library and after a couple of hours I made a (very primitive) Chipmunk usage framework and an even more primitive and simple "game engine like" framework, to mix both Athens and Chipmunk library. A video of the results can be found here: http://youtu.be/ZK-JlbeN09A Pretty cool, isn't? Ok, I know... is not like I invented the hot water, all of this was more or less present in morphic... but is cool to have real examples on using external libraries (also, physics are really hard to simulate, so... better to use something already existent). If you want to play with it, you can go to: http://smalltalkhub.com/#!/~estebanlm/Storm Enjoy :) Esteban

Nov. 22, 2012

Re: [Pharo-project] smalltalkhub and project ownership

by Camillo Bruni

On 2012-11-22, at 11:01, "Torsten Bergmann" <astares(a)gmx.de> wrote: >> We should keep in mind that Smalltalkhub is still under development :) >> >> And our poor Nicolas is running out of time (too many things to do) :D > > Sorry for reminding on this: I see a clear downside of all > this since smalltalk hub is currently very concentrated on > one person and his time schedule. > > I'm sure the next version of SmalltalkHub will provide > many new wanted features and it is a great system and service for Pharo. > > On the other side now two communities waiting for Nicolas to > bring something more awesome (see Amber [1]) ;) > > Yes SH is open source - but it would help if the impatient community > would be able to participate in one or the other way or follow > this new development... > > A ConfigurationOfSmalltalkHub would be a start ... ...or work on help improving git for Pharo (sorry I had to..)

Nov. 22, 2012

Re: [Pharo-project] smalltalkhub and project ownership

by Norbert Hartl

Am 22.11.2012 um 13:47 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com>: >> Is there an explanation why in smalltalkhub every project resides below a user? > > > because things in this universe don't get done if someone isn't leading it? :D > > the leader of any project is (a) the curator of that project and (b) the one positioned to better inspire followers > > if people likes it, people follows the project and/or the guy > > if someone doesn't like the direction, that person can fork and lead it himself in another direction > > github got it right, I'm glad smalltalkhub too > > and it's not about mimicking github (which wouldn't be bad) it's mimicking the way people want to work > > it's about natural selection applied to software projects at its best > > makes sense? partially. Don't want to extend it here! > > PD: if someone abandons a project, no big deal, it will be there hanging out while another fork might be flourishing. Also projects property should be transferrable from one user to another for the cases in which that happens orderly. > > Yep, that is my point. I didn't want to argue against anything smalltalkhub does. Regardless if you mimick github or "the way people want to work[â¢]" you need to have basic functionality. In github forks are connected so I always see where a thing comes from. By just copying stuff we will produce a mess. Someone that encounters smalltalkhub will then see 5 slightly different copies of the same thing and he couldn't estimate which one is the one to go first. So my question was if there is an idea how to solve this in smalltalkhub. No matter if it exists already or is being planned. Norbert

Nov. 22, 2012