November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Internship

by Goubier Thierry

Le 22/11/2012 16:57, Igor Stasenko a Ã©crit : > Very interesting topic and very userful. > We could use C parser for automatic generation of FFI bindings to C libraries. Yes, but... Someone who has a full C parser has a tendency to make that an asset, given how much it costs to do and maintain. Still, there are a few open solutions available: CLANG and maybe CIL. CLANG maybe the best bet, because it seems to be able to output the parsed AST in a neutral format. I spend some time looking at the CLANG source code a while back, but I didn't try the parse tree output. CLANG is a part of LLVM. CIL is used for parsing C in one of the CEA tools, Frama-C. It's in ocaml (and ocamlyacc). > 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 >> > > > -- 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] New Change System

by Ezequiel Lamonica

Hi guys, We are working on a New Change System<http://smalltalkhub.com/#!/~EzequielLamonica/NewChangeSystem/> . In this link you can see the project. It uses Pharo 2.0. There are some little bugs related to refactors which we are solving. Some features: - Semantic changes - Tracking in real time - Undo/redo of every change - Select a snapshot and redo changes from it to the end. So, if your image is broken, you can open the image again, open the change browser, select the last snapshot and right click -> redo changes. That's all. - Change browser with filters and a tree view for compound changes like refactors, class removals, etc - Diff view to see the impact of a change in the time when it was created To open the change browser: open the world menu -> tools -> Change Browser Try it and give me your feedback. Here you are the gofer script: *Gofer new* *smalltalkhubUser: 'EzequielLamonica' project: 'NewChangeSystem';* *package: 'Changes';* *load* * * Thanks!

Nov. 22, 2012

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

by Igor Stasenko

On 22 November 2012 16:34, David T. Lewis <lewis(a)mail.msen.com> wrote: > 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. > aye... and with a bit of assembler black magic you can actually generate a code to call those two functions in same primitive, so you don't leave to interpreter at all. bit still it would be nice if it could work using two separate FFI calls. > 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. >> > >> > -- Best regards, Igor Stasenko.

Nov. 22, 2012

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