- Pharo-dev - lists.pharo.org

Re: [Pharo-project] NativeBoost callbacks - status?

by Ciprian Teodorov

Hi Igor, My bet ... extracting the nbXAtOffset to the TNBMemoryAccessors broke the callbacks since I have also removed the ulongAt: and ulongAt:put: accessors which are used by the callback counter (there are some strange argument conversions going on). Though if I merge your .78.mcz with my .83.mcz all tests pass ... I don't know what you think about having the memory accessors in a trait? the bad thing is that I do not see any way of sharing them with the ones from ByteArray (can we extend a class with traits?)... however such a trait might be handy if we want to implement something like FloatArray using NB (think about FloatArray32, FloatArray64, etc)... I will try to fix this issue during the WE... if I will find the time. Thanks very much! Ciprian On Thu, Nov 22, 2012 at 2:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > i will check. > > I didn't merged with your code, Ciprian yet.. > does it crashing for NativeBoost-Core-IgorStasenko.78 or > in your code? > > i will merge your stuff and check. > > > -- > Best regards, > Igor Stasenko. > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Nov. 22, 2012

Re: [Pharo-project] sources location

by Marcus Denker

ceterum censeo... we need really should get rid of the .sources and .changes implementation. (one of the things I want for 3.0... and I am sure all the people who now say "how unimportant" will be amazed what this will get us...) Marcus On Nov 22, 2012, at 6:38 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > the packages for Linux distribution have troubles to work with > *.sources files. Currently the image is looking for sources files in > this order: > - vm directory > - image directory > - working directory > There are packages for the virtual machine and the image. All in > latest versions. The sources file should be part of the image package. > But in that case it must copy the sources file into the VM location > (and that may be complicated because of version string in the vm > path). > In case that you update the image package and the image uses newer > sources version, the old one should be deleted. > There are several more or less bad solutions: > - copy the sources file next to the image and changes file when the > new custom image is being created. Very space consuming > - create symlink next to the image and changes file. Bad because in > case you update image package the old source file is deleted > - collect all old source files in the vm package. Bad because you do > not know what image version will be used > - collect all old source files in the image package. Very strange and > you have to place the sources files somehow next to the virtual > machine > - have standalone package for every source file and place symlinks > next to the image file when a new custom image is created > > So as you may see, we really need some next way how to resolve sources > files location. In ideal world we would be able to read it from a > system variable. The user will have in his home all source files that > images he owns use. But we do not have VM support for that. > > Cheers, > -- Pavel > -- Marcus Denker -- http://marcusdenker.de

Nov. 22, 2012

[Pharo-project] sources location

by Pavel Krivanek

Hi, the packages for Linux distribution have troubles to work with *.sources files. Currently the image is looking for sources files in this order: - vm directory - image directory - working directory There are packages for the virtual machine and the image. All in latest versions. The sources file should be part of the image package. But in that case it must copy the sources file into the VM location (and that may be complicated because of version string in the vm path). In case that you update the image package and the image uses newer sources version, the old one should be deleted. There are several more or less bad solutions: - copy the sources file next to the image and changes file when the new custom image is being created. Very space consuming - create symlink next to the image and changes file. Bad because in case you update image package the old source file is deleted - collect all old source files in the vm package. Bad because you do not know what image version will be used - collect all old source files in the image package. Very strange and you have to place the sources files somehow next to the virtual machine - have standalone package for every source file and place symlinks next to the image file when a new custom image is created So as you may see, we really need some next way how to resolve sources files location. In ideal world we would be able to read it from a system variable. The user will have in his home all source files that images he owns use. But we do not have VM support for that. Cheers, -- Pavel

Nov. 22, 2012

[Pharo-project] New Change System

by Torsten Bergmann

Nice! You should disable the "undo" menu on evaluted expressions since they can not be undone. UI need some work (alignment, splitter size, ...) Will it support grouping similar to "Tools" -> "Recent Messages" so I can see changes I did on a method, class, ...? Thanks T.

Nov. 22, 2012

Re: [Pharo-project] New Change System

by GÃ¶ran Krampe

Hi! On 11/22/2012 05:10 PM, Ezequiel Lamonica wrote: > Hi guys, > > We are working on a New Change System > <http://smalltalkhub.com/#!/~EzequielLamonica/NewChangeSystem/>. > In this link you can see the project. I should of course look at the code but could you outline differences/similarities to my/our work on Deltas? Then I might be able to give some thoughtful feedback - and yes, I will look at the code too but it is always interesting to hear "intentions" too. :) regards, GÃ¶ran

Nov. 22, 2012

Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:?

by Dale Henrichs

----- Original Message ----- | From: "Tudor Girba" <tudor(a)tudorgirba.com> | To: "pharo-project" <Pharo-project(a)lists.gforge.inria.fr> | Sent: Thursday, November 22, 2012 3:15:36 AM | Subject: Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:? | | Hi Dale, | | | I think your concerns are not consistent :): | | | - you make a distinction between symbolic and regular versions, but | you do not make a distinction between baseline and regular versions. | Why not? Because it is good practice to have a proper naming that | distinguishes between baseline and the regular versions without | having this distinction hardcoded in the engine. And it works just | fine. Of course, people can mess it up by having a version called | 'baseline', but in practice it works just fine. | | The same could apply to symbolic versions. You're really stretching here, Doru ... I would claim that not making a distinction between baselines and versions was a mistake that should not be repeated with symbolic versions ... | - you say that when people load a '1.0' symbolic version they would | be confused when they in fact get '1.0.37'. I think it will be | equally confusing when the symbolic version is named #'1.0'. The | problem is really that the name of the symbolic version should be | different. I see the difference between '1.0' and #'1.0' and I assume that you are able to perceive that difference as well:) For me the important message to take from this is that the fact that Metacello must be involved in version control is the real travesty here ... not the invention of symbolic versions:) If one starts to use a version control system that can manage more than one file at a time like git/svn/mercurial/etc. you quickly find out that the need to monkey with linear versions begins to fade away, because the primary function of the linear version is to act as a version control data base ... When using git I use a BaselineOf which has a single baseline specification. There's no need to distinguish between different baseline specifications and the notion of baseline version disappears... The ConfigurationOf relegates the linear versions to the role of tags with no need to maintain an exhaustive list of mcz file names ... So with git Metacello begins to explicitly distinguishes between baselines (configurations) and versions (tags). I don't need to use a ConfigrationOf for development at all ... The ConfigurationOf becomes a deployment/publishing artifact. The fate of symbolic versions in the presence of git is still up in the air...It may be possible to simply stop using symbolic versions, I would think...The fate of symbolic versions is the least of my worries:) Frankly Doru, I would welcome your critical eye applied to the Metacello Preview. I think that managing Moose with git would simplify a number of your development problems. Perhaps this whole linearizing the packages thing would just disappear? I'm pretty sure your fixation on symbolic versions would go away:) I haven't released the Preview precisely because I want critical feedback before setting features in stone by releasing them ... As it stands the Metacello Preview is production ready (I've been using it constantly in my work for months now)... Metacello dipped it's toe into the version control business out of necessity, but Metacello is not a complete version control system and I really have no desire to add branching and merging features to Metacello ... those features are the domain of a version control system .... Truly the whole Metacello story gets much simpler when one can leverage a fully-featured version control system. Dale

Nov. 22, 2012

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

by Max Leske

On 22.11.2012, at 17:00, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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, That's the plan, although I'll have to do some stuff with the pipes before exec'ing. >> 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. >> Ok. Not quite sure how that all works but I tried to come up with a program that is as short as possible: run | pid args | args := (LimboCommand new command: '/bin/echo'; arguments: { 'foo' }) primitiveArguments. pid := self primitiveRun. pid isZero ifTrue: [ self primitiveExecv: args first arguments: args ] ifFalse: [ "parent code" ]. Still not working. fork() does create the child process but it won't exec (because it never reaches that point in execution somehow) and I can't kill the child process on the command line (have to close the image; the childs are not zombies) > > 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. Cool :) Will be my last resort though. Regarding the "hanging" image: yes the child process is created but as the man page for fork() states that the parent will be suspended until the child is exec'ed. Therefore, having the image "hang" is expected because I can't exec the child. Thanks for the help guys. Max > > 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 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