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

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

by Igor Stasenko

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. > 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] when do we go beta?

by Goubier Thierry

Le 22/11/2012 12:10, StÃ©phane Ducasse a Ã©crit : > do you have slides of your lectures? No. I did an on the fly explanation of the implementation of that model in Smalltalk: http://compilation.gforge.inria.fr/2012_06_Rennes/talks.html#thierry (With just enough Smalltalk to let non-smalltalkers write a bit of code : 30'). I'll try to make the code and the examples available. Thierry > Stef > >>>> I've used Pharo 2.0 for teaching on Monday/Tuesday. Apart from a few bugs here and there, it worked fine (but the bugs were rather annoying to explain to Smalltalk beginners). >>> >>> 2.0 was shaky. I would have used 1.4 for newbies >> >> It worked well enough to teach process network programming with it... >> >>>> At the same time, my production development is on 1.4. >>>> >>>> So I think it could/should go beta soon. I'd be happy if I know some of the core packages won't change under me :) >>> >>> We will. I want to really stabilize now. >> >> +1 >> >> 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

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

by Tudor Girba

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 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. Cheers, Doru On Thu, Nov 22, 2012 at 12:36 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Wednesday, November 21, 2012 2:34:36 PM > | Subject: Re: [Pharo-project] Metacello Why symbolicversion and not > simply tagged version:? > | > | > | On Nov 21, 2012, at 8:16 PM, Dale Henrichs wrote: > | > | > Doru, > | > > | > I guess because I don't agree that the following statement would be > | > true: > | > > | > there will never be a regular version named 'stable' > | > > | > I know that in git I can have a branch named 'stable' and a tag > | > named 'stable' and that causes problems ... for me. > | > > | > Besides, the set of symbolic versions is not restricted to #stable > | > and #development ... one could choose to define a symbolic version > | > called #default or #'1.0'â¦ > | > | I would not. > > I would not, at least right now... But someday, #stable may not be > sufficient it may be necessary to reason about "the #stable version of > Metacello 1.0 and the #stable version of Metacello 2.0", then #'1.0' and > #'2.0' may turn out to be useful ... > > | I would like that Metacello constraints the space. Because we should > | have less option and more structured supported scenarios. > > I'm not sure that we know the extent of the space quite yet, but for now > we have a convention where we are primarily using only the #stable symbolic > version so we've successfully avoided a proliferation of symbolic versions > which is a good thing ... > > As I do more work with git I see the linear versions become more like tags > of specific git commits with the burden of version management falling onto > git instead of Metacello. Then with platform-specific branches in the git > repository it becomes possible to use a cross branch tag (a linear version) > which may obsolete symbolic versions altogether, but it is way too early in > the learning curve with git to tell... > > | > | > I intend for there to be two namespaces the linear version > | > namespace and the symbolic version namespace to make a clear > | > distinction between the two, because they have different > | > semantics. > | > | Ok it was not clear to me that they have a different semantics. > > I think it is important that we have a language that differentiates > between a linear version '1.0' which refers to a specific set of packages > that do not change over time and a symbolic version #stable (or #'1.0') > which refers to a family of related versions the members of which may > change over time. > > | > | > One shouldn't be surprised that when version #stable of project foo > | > is loaded the current version of the project is '1.0' on one day > | > and '1.1' on the next. > | > | How this can be possible? Ok you mean because the guy changed the > | stable definition. > > Exactly ... symbolic versions were invented exactly because the > "recommended version" changes over time .... > > | > | > Or when they load #'1.0' that the current version is '1.0-beta.19'. > | > > | > This distinction is obviously not important to you and I am okay > | > with that:) > | > > | > Dale > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 22, 2012

[Pharo-project] NativeBoost callbacks - status?

by Ciprian Teodorov

Hi Igor, What is the extent to which callbacks are currently supported in NB? On my machine (macos10.6) they do not seem to work properly. The quick sort test crashes the VM. What are the limitations of the current implementation? Thanks Ciprian

Nov. 22, 2012

Re: [Pharo-project] MongoTalk update

by StÃ©phane Ducasse

Nicolas will do a tutorial to us and we will produce some slides and after a chapter about mongoDB :) Stef On Nov 22, 2012, at 11:28 AM, Norbert Hartl wrote: > Hey Nico, > > I looked into your new stuff and I like it. Especially the MongoQueries stuff is very simple and clean approach to do a small DSL. That boosts the usability of MongoTalk extremely. Bravo! > > Norbert > > Am 19.11.2012 um 15:37 schrieb Nicolas Petton <petton.nicolas(a)gmail.com>: > >> >> Hi guys, >> >> Lately I worked a bit on the Pharo Mongo driver for SmalltalkHub. I made >> several changes (in the new version 1.4): >> >> The query API changed: >> >> - MongoCollection>>query: now takes a 1 arg block, improving the API >> quite a bit. >> >> Queries like: >> >> aCollection query: (aCollection query >> query: { 'foo' -> 'bar'} asDictionary; >> yourself) >> >> Is now written: >> >> aCollection query: [ :query | >> query where: { 'foo' -> 'bar'} ] >> >> Sending #asDictionary has also been made optional, the query builder >> will send #asMongoQuery to the query collection. >> >> >> The MongoQueries package: >> >> Version 1.4 comes with a new package MongoQueries, a small DSL allowing >> us to use traditional blocks instead of dictionaries to perform >> queries. This is optional and backward compatible. >> >> Queries like: >> >> aCollection select: { '$or' -> { 'name' -> 'foo'. 'age' -> { '$gt' -> 23 } >> asDictionary } asDictionary } asDictionary >> >> can be expressed: >> >> aCollection select: [ :each | (each name = 'foo') | (each age > 23) ] >> >> The MongoQueries package should support the entire mongo query language >> (including nested queries), and comes with unit tests. >> >> Nico >> > >

Nov. 22, 2012

Re: [Pharo-project] when do we go beta?

by StÃ©phane Ducasse

do you have slides of your lectures? Stef >>> I've used Pharo 2.0 for teaching on Monday/Tuesday. Apart from a few bugs here and there, it worked fine (but the bugs were rather annoying to explain to Smalltalk beginners). >> >> 2.0 was shaky. I would have used 1.4 for newbies > > It worked well enough to teach process network programming with it... > >>> At the same time, my production development is on 1.4. >>> >>> So I think it could/should go beta soon. I'd be happy if I know some of the core packages won't change under me :) >> >> We will. I want to really stabilize now. > > +1 > > 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] Re; About new TxText text model

by Stephan Eggermont

Hi Igor, The TxText model to me seems to mix two concerns. The storage of the text and manipulating it? Both cursor positioning and selection manipulation are view dependent, and there might be more than one. Stephan

Nov. 22, 2012

[Pharo-project] smalltalkhub and project ownership

by Norbert Hartl

Is there an explanation why in smalltalkhub every project resides below a user? I just saw that Francois moved the MongoTalk from squeaksource to smalltalkhub. With the move the project moved into francois' projects. That seems like a step back at first. In squeaksource projects are global and have certain roles attached. Thus making it easier to shift responsibility. Especially when a user takes over a project and then stops working on it what would be the workflow for this? Can projects be moved? Do we need to copy? I can see that there is a tension to mimick github. But in github I just fork a project under my own account where it can reside even if the original author abandoned the project. What would be a good way to handle that common use case? thanks, Norbert

Nov. 22, 2012

Re: [Pharo-project] MongoTalk update

by Norbert Hartl

Hey Nico, I looked into your new stuff and I like it. Especially the MongoQueries stuff is very simple and clean approach to do a small DSL. That boosts the usability of MongoTalk extremely. Bravo! Norbert Am 19.11.2012 um 15:37 schrieb Nicolas Petton <petton.nicolas(a)gmail.com>: > > Hi guys, > > Lately I worked a bit on the Pharo Mongo driver for SmalltalkHub. I made > several changes (in the new version 1.4): > > The query API changed: > > - MongoCollection>>query: now takes a 1 arg block, improving the API > quite a bit. > > Queries like: > > aCollection query: (aCollection query > query: { 'foo' -> 'bar'} asDictionary; > yourself) > > Is now written: > > aCollection query: [ :query | > query where: { 'foo' -> 'bar'} ] > > Sending #asDictionary has also been made optional, the query builder > will send #asMongoQuery to the query collection. > > > The MongoQueries package: > > Version 1.4 comes with a new package MongoQueries, a small DSL allowing > us to use traditional blocks instead of dictionaries to perform > queries. This is optional and backward compatible. > > Queries like: > > aCollection select: { '$or' -> { 'name' -> 'foo'. 'age' -> { '$gt' -> 23 } > asDictionary } asDictionary } asDictionary > > can be expressed: > > aCollection select: [ :each | (each name = 'foo') | (each age > 23) ] > > The MongoQueries package should support the entire mongo query language > (including nested queries), and comes with unit tests. > > Nico >

Nov. 22, 2012

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

by Max Leske

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. 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 >> >> >

Nov. 22, 2012