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

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

by Tudor Girba

Hi, On 22 Nov 2012, at 18:04, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > ----- 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 ... Ok. We disagree on this one :). This is because in practice, it is not a problem. > | - 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. Precisely. So, you see: that shows that introducing a BaselineOf uses the mechanism of a regular version and it is enough. > 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:) Dale, I just clarified what Stef was asking. I still think it is a valid concern for those that do not work on Git. > 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 am not fixated. I just see an extra concept that is not needed :). I am still interested in looking into this, but my time is severely limited these days. > 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. I am not sure I quite understand that part in the context of dependencies to independent projects. You would still need to somehow refer to a version of the sub-project. How is that achieved? Cheers, Doru -- www.tudorgirba.com "Quality cannot be an afterthought."

Nov. 23, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 491 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Nov. 23, 2012

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

by Igor Stasenko

On 22 November 2012 20:22, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > 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?)... hmm.. i think we can't because that will make Collections package dirty. So, there's not much choice: we should use only extension methods. What i thinking is getting rid of ulongAt/put protocols, and use uint32 instead to be more precise and to not confuse with C types. > 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 -- Best regards, Igor Stasenko.

Nov. 22, 2012

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