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

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

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

by Igor Stasenko

On 1 June 2012 22:29, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > You're right. But let's be real, how many progress-bar related actions do you > perform on a hourly based? > > I've been programming daily in smalltalk for the last 7+ years, and most of > the times progress bars show up when: > - Performing a long/deep search in the image (which I have to wait until it > finishes) > - Serializing a big object (+20s must be a BIG/heavy object graph) > - Deploying (nothing else should be done before it finishes) > - Downloading from a repository. > > And I don't do that more than once per day, if much. > > All the other progress bars are "app related" (like querying the database, > or similar). > > I can't figure more regular use cases of progress bar usage. > Igor have one, Chris has another. I added my two cents. :) > Yes, i am talking about tasks, which we perform on a regular basis: - read file(s) from web/OS/whatever - compiling & installing new code etc irregular ones (like using a render farm to render special effects for new Holywood blockbuster) is out of scope. > The only one that could be sent to be background is when > uploading/downloading from a repository, and that's because most of the > times it is slow, even in comparison with other package management tools > (such as apt-get, npm, etc.), which in turn mode you in while working. > > Regards! > > > > > > > -- > View this message in context: http://forum.world.st/What-i-would-like-to-have-instead-of-progress-bar-tp4… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

June 1, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Igor Stasenko

ah.. sorry it will not work without these patches. These are just couple minor refactorings for accepting '$' as valid part of function name. Because we discovered that we had to use 'readdir$INODE64' function instead of 'readdir' actually we could use older one, but 64 is a bit better :) (i will do a new snapshot of Nativeboost-Core soon) -- Best regards, Igor Stasenko.

June 1, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Igor Stasenko

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. 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 1, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Chris Cunningham

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 1, 2012

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

by Igor Stasenko

On 1 June 2012 20:12, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > StÃ©phane Ducasse wrote >> >> we should produce more 5 min videos!!! >> Look we are not able to even do that. >> > > No smalltalker with a sane mind would record himself five minutes doing his > regular work. :) > Haha.. well said! > 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. > The most impressive thing in the demo, and I'd bet that was the main > resonator in the audience, was the variables replacement by its current > values. > > 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). -- Best regards, Igor Stasenko.

June 1, 2012