- Pharo-dev - lists.pharo.org

Re: [Pharo-project] NB FileSystem Primitives Speedup

by David T. Lewis

On Fri, Jun 01, 2012 at 11:01:29PM +0200, Igor Stasenko wrote: > On 1 June 2012 22:47, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > > On Fri, Jun 1, 2012 at 12:17 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> For those complaining lately about the new FS being a bit slow ;) > >> Igor and I hacked together a test version for accessing files using NativeBoost. > >> > >> From our stupid example (listing /usr/bin with ~1k Files) we were incredible 40 times! faster > >> than the file primitives in the current image (5ms instead of 200ms). > >> > >> With the current FS infrastructure such a migration can be done absolutely painless by > >> simply replacing one back-end a time. > >> > >> best > >> cami > > > > Can you share this work? ??I've been interested in this particular use > > for NB for a while now, but haven't gotten around to trying it (or, > > unfortunately, NB itself) yet. ??This would probably push me into a > > user role - and is definitely something I'd like to see. > > > > hehe.. there's almost nothing to show about.. > we're just making calls to two C functions: > opendir() > and > readdir() > from standard C library. That will definitely make a huge performance improvement. Here is something similar (probably bit rotted but maybe still of interest): http://wiki.squeak.org/squeak/2274 > > a very basic stuff, which you would do if your programming language is C :) > > anyways, see attached. > > If you on mac, it shall work.. try something like: > > (UnixDir on: '/usr/bin') entries > > > > -Chris > > -- > Best regards, > Igor Stasenko.

June 2, 2012

Re: [Pharo-project] Process Tests and

by Frank Shearar

On 2 June 2012 12:24, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 2 June 2012 11:40, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: >> >> On 02 Jun 2012, at 11:07, Igor Stasenko wrote: >> >>> On 2 June 2012 10:28, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: >>>> Hi Sean: >>>> >>>> On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: >>>> >>>>> During the process, I noticed that the Blue Book specifies that #fork >>>>> returns the block itself (pg. 252), while in Pharo it returns the process >>>>> (see #testFork in the slice). Should our implementation be changed to match >>>>> the Blue Book? >>>> >>>> Why would it be desirable to have the block? >>> >>>> How would you obtain the process object after your change? >>>> >>> by using #newProcess. >>> >>> using the return Â value of fork provokes you to write incorrect concurrent code. >>> for instance, i found once, some code which assumes that forked >>> process not yet started, >>> or not yet terminated, and people trying to do something with process >>> immediately after issuing #fork. >> >> So, just because somebody made a mistake, the whole thing is not worthwhile anymore? >> What is the value of having the direct reference to the block? >> What are you going to do with it? >> >> I would buy an argument that #fork should return a promise (or you can call it future if you like) to the return value of the block. >> >> I don't see how the block itself would be of any use. > > agreed. > I didn't said that returning block has any value.. just noted that > returning a process is not much more valuable. Because there is a good > chances that the process which you get is already terminated :) And handily, in this case returning a Promise/Future means you... simply get the resolved value! frank >> I do see however, that the block (i.e., self) was returned in earlier versions just because of convention, and no further thought. >> [Some people claim that the whole idea of Process in Smalltalk was never fully thought out anyway. (And that's not me.)] >> >> Best regards >> Stefan >> >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: Â +32 2 629 3525 >> >> > > > > -- > Best regards, > Igor Stasenko. >

June 2, 2012

Re: [Pharo-project] Process Tests and

by Igor Stasenko

On 2 June 2012 11:40, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > > On 02 Jun 2012, at 11:07, Igor Stasenko wrote: > >> On 2 June 2012 10:28, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: >>> Hi Sean: >>> >>> On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: >>> >>>> During the process, I noticed that the Blue Book specifies that #fork >>>> returns the block itself (pg. 252), while in Pharo it returns the process >>>> (see #testFork in the slice). Should our implementation be changed to match >>>> the Blue Book? >>> >>> Why would it be desirable to have the block? >> >>> How would you obtain the process object after your change? >>> >> by using #newProcess. >> >> using the return Â value of fork provokes you to write incorrect concurrent code. >> for instance, i found once, some code which assumes that forked >> process not yet started, >> or not yet terminated, and people trying to do something with process >> immediately after issuing #fork. > > So, just because somebody made a mistake, the whole thing is not worthwhile anymore? > What is the value of having the direct reference to the block? > What are you going to do with it? > > I would buy an argument that #fork should return a promise (or you can call it future if you like) to the return value of the block. > > I don't see how the block itself would be of any use. agreed. I didn't said that returning block has any value.. just noted that returning a process is not much more valuable. Because there is a good chances that the process which you get is already terminated :) > I do see however, that the block (i.e., self) was returned in earlier versions just because of convention, and no further thought. > [Some people claim that the whole idea of Process in Smalltalk was never fully thought out anyway. (And that's not me.)] > > Best regards > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: Â +32 2 629 3525 > > -- Best regards, Igor Stasenko.

June 2, 2012

Re: [Pharo-project] Process Tests and

by Stefan Marr

On 02 Jun 2012, at 11:07, Igor Stasenko wrote: > On 2 June 2012 10:28, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: >> Hi Sean: >> >> On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: >> >>> During the process, I noticed that the Blue Book specifies that #fork >>> returns the block itself (pg. 252), while in Pharo it returns the process >>> (see #testFork in the slice). Should our implementation be changed to match >>> the Blue Book? >> >> Why would it be desirable to have the block? > >> How would you obtain the process object after your change? >> > by using #newProcess. > > using the return value of fork provokes you to write incorrect concurrent code. > for instance, i found once, some code which assumes that forked > process not yet started, > or not yet terminated, and people trying to do something with process > immediately after issuing #fork. So, just because somebody made a mistake, the whole thing is not worthwhile anymore? What is the value of having the direct reference to the block? What are you going to do with it? I would buy an argument that #fork should return a promise (or you can call it future if you like) to the return value of the block. I don't see how the block itself would be of any use. I do see however, that the block (i.e., self) was returned in earlier versions just because of convention, and no further thought. [Some people claim that the whole idea of Process in Smalltalk was never fully thought out anyway. (And that's not me.)] Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

June 2, 2012

Re: [Pharo-project] Process Tests and

by Igor Stasenko

On 2 June 2012 10:28, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi Sean: > > On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: > >> During the process, I noticed that the Blue Book specifies that #fork >> returns the block itself (pg. 252), while in Pharo it returns the process >> (see #testFork in the slice). Should our implementation be changed to match >> the Blue Book? > > Why would it be desirable to have the block? > How would you obtain the process object after your change? > by using #newProcess. using the return value of fork provokes you to write incorrect concurrent code. for instance, i found once, some code which assumes that forked process not yet started, or not yet terminated, and people trying to do something with process immediately after issuing #fork. > Having the process directly is useful to do fork/join style operations. > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: Â +32 2 629 3525 > > -- Best regards, Igor Stasenko.

June 2, 2012

Re: [Pharo-project] Process Tests and

by Stefan Marr

Hi Sean: On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: > During the process, I noticed that the Blue Book specifies that #fork > returns the block itself (pg. 252), while in Pharo it returns the process > (see #testFork in the slice). Should our implementation be changed to match > the Blue Book? Why would it be desirable to have the block? How would you obtain the process object after your change? Having the process directly is useful to do fork/join style operations. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by StÃ©phane Ducasse

sure you are welcome. we would also love to get OSProcess plugin rewritten. Stef On Jun 1, 2012, at 10:47 PM, Chris Cunningham wrote: > On Fri, Jun 1, 2012 at 12:17 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> For those complaining lately about the new FS being a bit slow ;) >> Igor and I hacked together a test version for accessing files using NativeBoost. >> >> From our stupid example (listing /usr/bin with ~1k Files) we were incredible 40 times! faster >> than the file primitives in the current image (5ms instead of 200ms). >> >> With the current FS infrastructure such a migration can be done absolutely painless by >> simply replacing one back-end a time. >> >> best >> cami > > Can you share this work? I've been interested in this particular use > for NB for a while now, but haven't gotten around to trying it (or, > unfortunately, NB itself) yet. This would probably push me into a > user role - and is definitely something I'd like to see. > > -Chris >

June 2, 2012

Re: [Pharo-project] Process Tests and

by Sean P. DeNigris

The thread title should've been "... and #fork return value" -- View this message in context: http://forum.world.st/Process-Tests-and-tp4632878p4632879.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 2, 2012

[Pharo-project] Process Tests and

by Sean P. DeNigris

I was reading the Blue Book chapter on processes and figured I'd turn it into tests... Issue 6009: Improved ProcessTest http://code.google.com/p/pharo/issues/detail?id=6009 During the process, I noticed that the Blue Book specifies that #fork returns the block itself (pg. 252), while in Pharo it returns the process (see #testFork in the slice). Should our implementation be changed to match the Blue Book? Thanks, Sean -- View this message in context: http://forum.world.st/Process-Tests-and-tp4632878.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 2, 2012

Re: [Pharo-project] light-table: live programming for python

by Esteban A. Maringolo

Igor Stasenko wrote > > On 1 June 2012 20:12, Esteban A. Maringolo <emaringolo@> wrote: >>> But truth is we should find a way to impress people like light table >>> did. >>The truth is, that its not impressed me.. after things i seen in smalltalk. > Not me either, I even ranted about it as soon as it was published (http://goo.gl/7Eaxa) Apparently I have no community impact :P Igor Stasenko wrote > >>> I don't know how hard would be to have debugger with a splitted window >>> or >>> viewing mode showing the code with the actual values of the variables. > >>we should have better text/parser model.. >>then you can easily view the variable value(s), just by hovering mouse >>over the text piece in debugger. > >>btw, Gaucho already takes steps into that direction: it using parser >>to navigate the code >>using the AST tree (so you not walking over separate characters, but >>over AST nodes) >>it is not far from that point to debugger and/or code pane, where you >>can exploit that (code highlighting/contextual help, navigating etc >>etc). > We take a similar approach in our software app, where users program formulas in a pseudo language for which we use SmaCC and hence we have a parse tree. Then users can see both their "code" with the variables replaced by their values (evaluated with a particular domain context), and even view and browse the expression tree (no one uses it, it just was simple to build). Though it is not in real time because could involve heavy DB queries, it is completely feasible to do with "regular" smalltalk code. Regards! -- View this message in context: http://forum.world.st/light-table-live-programming-for-python-tp4632751p463… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 1, 2012