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

Re: [Pharo-project] NB FileSystem Primitives Speedup

by David T. Lewis

On Sat, Jun 02, 2012 at 04:11:16PM +0200, St?phane Ducasse wrote: > >> 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 > >> > > > > it is a pity that this stuff was never integrated into VMs.. > > or actually never added to file plugin replacing it's naive implementation. > > I do not understand the process of VM enh. > David what prevent it to get used? > May be we should add it the pharo version and suddenly it will kick the system. > But I'm rather puzzled and sad. > > Stef That is easy to explain ... I was lazy and did not bother to maintain it ;) As for process, it is simple. Just build the plugin (though it probably will need maintenance for bit rot), and add it to your VM builds. On the image side, add the support to use the plugin if present, else fall back on old methods. I like small plugins because they are modular and reliable. They can be added and removed without a lot of coordination with VM builders, platform maintainers, etc. On the image side, you can easily detect if the plugin is present, so it is not necessary to worry so much about what version of VM or FilePlugin is running. So the answer is ... Just Do It :) <OT> IMHO more people need to learn how to write small plugins. It is important for modularity and reliability, and for trying new VM experiments without waiting for a "VM guru" to help. Maybe you can also provide a way for people to add their experimental plugins to the Jenkins builds too, so that they can be made quickly available to anyone with an interest. </OT> Dave

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by StÃ©phane Ducasse

>> 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 >> > > it is a pity that this stuff was never integrated into VMs.. > or actually never added to file plugin replacing it's naive implementation. I do not understand the process of VM enh. David what prevent it to get used? May be we should add it the pharo version and suddenly it will kick the system. But I'm rather puzzled and sad. Stef

June 2, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Igor Stasenko

On 2 June 2012 15:23, David T. Lewis <lewis(a)mail.msen.com> wrote: > 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 > it is a pity that this stuff was never integrated into VMs.. or actually never added to file plugin replacing it's naive implementation. > >> >> 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. > > > -- Best regards, Igor Stasenko.

June 2, 2012

Re: [Pharo-project] What i would like to have instead of progress bar

by StÃ©phane Ducasse

so if somebody would like to help - we should spot showWhile: useless senders - progress bar useless calls Stef On Jun 1, 2012, at 1:58 AM, Igor Stasenko wrote: > If you would ask me (yeah nobody asking me, by i will tell anyways ;) ) > how the indication of a progress of some process should look like, > here's my potential answer: > > > - a tiny one line in a corner of desktop (instead of huge banner > centered in window, > sticking on top of everything and obscuring the view) > - not blocking user input > - no stupid nesting.. i don't care what happens inside of something > else happens.. > if it is really necessary, i would just replace the title of a task > with it's subtask title while it performing. > this is just about first rule: it has to be a single line, not a bunch > of lines stocking one over another.. > i think this is abuse. > > most of the times, i just need a notion of progress of a whole thing, > not progress of it's subthings > (if user really wants, he can hover the mouse over progress line to > see the details, but by default > it should take minimal space on the screen). > > > > -- > Best regards, > Igor Stasenko. >

June 2, 2012

[Pharo-project] [ANN] NativeBoost v 1.2 -> release

by Igor Stasenko

Hi, as i promised, after some testing i changed the 1.2 version from #development blessing to #release. Here some more changes: - reorganized categories (mainly cleaning up the NativeBoost-Core category and move some stuff to NativeBoost-Core-FFI category) But this one might be interesting even to non-NB users: i added a fresh implementation of weak finalization registry (NBFinalizationRegistry). In short: - it's not using WeakIdentityDictionary to store registered objects - it produces less garbage, under high add/finalization pressure - it does not allows removal of object once it is registered, since it doesn't pretends to be a Collection, like WeakRegistry does. - if you really need to avoid executing the finalization, use the object returned by #add: method, which is an instance of NBWeakFinalizerItem and send #doNotFinalize message to it (note, any other methods are considered private and messing up with them can be fatal) You can extract implementation and use it without loading NB, but it will work only under VMs with support of new finalization scheme. (but since NB-enabled VMs already having it, i can afford to use it, without having crippling backwards compatibility schemes) -- Best regards, Igor Stasenko.

June 2, 2012

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