- Pharo-dev - lists.pharo.org

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

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

by Esteban A. Maringolo

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

June 1, 2012

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

by Igor Stasenko

On 1 June 2012 21:54, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2012/6/1 Esteban A. Maringolo <emaringolo(a)gmail.com>: >> >> Igor Stasenko wrote >>> >>> On 1 June 2012 17:58, Esteban A. Maringolo <emaringolo@> wrote: >>>> If the progress tracks something that happens in the background with no >>>> direct impact to the workflow (such as uploading/downloading something), >>>> I'm >>>> ok to have a separate out-of-bounds bar. >>>> >>>> If the progress is modal, >>> >>> then someone should stop programming and pick other activity in his life, >>> like organizing the queue during hot sales in supermarket :) >>> >> >> TouchÃ©. >> >> But I was thinking in short, less than 20 sec, modal tasks. Anything beyond >> that should go async. >> >> It would be like... "DON'T MODE ME IN" for more than 20 sec :) >> >> Regards. >> >> > > You should add every hour, because 20 sec every minute would obviously > be too much > yeah.. but then it defeats the point: why you need to reflect something which consumes something like 1/1000 of total run time.. by analogy it is like turning mouse into hourglass every time VM's runs GC :) > Nicolas > >> >> >> -- >> 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] What i would like to have instead of progress bar

by Nicolas Cellier

2012/6/1 Esteban A. Maringolo <emaringolo(a)gmail.com>: > > Igor Stasenko wrote >> >> On 1 June 2012 17:58, Esteban A. Maringolo <emaringolo@> wrote: >>> If the progress tracks something that happens in the background with no >>> direct impact to the workflow (such as uploading/downloading something), >>> I'm >>> ok to have a separate out-of-bounds bar. >>> >>> If the progress is modal, >> >> then someone should stop programming and pick other activity in his life, >> like organizing the queue during hot sales in supermarket :) >> > > TouchÃ©. > > But I was thinking in short, less than 20 sec, modal tasks. Anything beyond > that should go async. > > It would be like... "DON'T MODE ME IN" for more than 20 sec :) > > Regards. > > You should add every hour, because 20 sec every minute would obviously be too much Nicolas > > > -- > 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. >

June 1, 2012

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

by Esteban A. Maringolo

Igor Stasenko wrote > > On 1 June 2012 17:58, Esteban A. Maringolo <emaringolo@> wrote: >> If the progress tracks something that happens in the background with no >> direct impact to the workflow (such as uploading/downloading something), >> I'm >> ok to have a separate out-of-bounds bar. >> >> If the progress is modal, > > then someone should stop programming and pick other activity in his life, > like organizing the queue during hot sales in supermarket :) > TouchÃ©. But I was thinking in short, less than 20 sec, modal tasks. Anything beyond that should go async. It would be like... "DON'T MODE ME IN" for more than 20 sec :) 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.

June 1, 2012

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Igor Stasenko

fstat is your friend :) i don't know if primitives providing access to that very useful function. On 1 June 2012 21:21, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yeah that's great! > ...but we need a speed up of FS even without that. There are some simple protocols that needs to be enhanced, like the one that checks all entries in a root directory if I execute: '/tmp' asFileReference isDirectory :P > > On Jun 1, 2012, at 9:17 PM, Camillo Bruni 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 > > -- Best regards, Igor Stasenko.

June 1, 2012