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

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

Re: [Pharo-project] NB FileSystem Primitives Speedup

by Esteban Lorenzano

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

June 1, 2012

[Pharo-project] NB FileSystem Primitives Speedup

by Camillo Bruni

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

June 1, 2012

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

by Igor Stasenko

On 1 June 2012 17:58, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Chris Cunningham wrote >> >> I have cases where I have multiple background processes going on that >> occassionally wake up, and in that case, I really, really appreciate >> the stacking progress bars - I can tell that one (or more) background >> processes have kicked off. Â This isn't quite 'nesting', although I >> think it uses some of the same features. >> >> As long as some result out of this discussion doesn't remove that >> capability, I agree with what you are saying. > > +1. > > 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 :) > it is... > I need to wait until it finishes, I think > it should be as it is now. > > Regards, > > Esteban. > > > -- > 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] light-table: live programming for python

by StÃ©phane Ducasse

we should get an infrastructure so that it is easy to experiment with such things. This is why we need OPAL and AST right in the system. It is time to rethink our system before it gets just too oldish. Stef On Jun 1, 2012, at 8:12 PM, Esteban A. Maringolo 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. :) > > But truth is we should find a way to impress people like light table did. > > 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. > > Regards, > > -- > Esteban. > > > > > > -- > 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] ClassBoxes... bitrotted, or usable?

by StÃ©phane Ducasse

On Jun 1, 2012, at 8:08 PM, Alexandre Bergel wrote: > Hi Frank, > > It would be cool to have Classboxes back on track. Now I would like to see a real system like seaside or moose (too complex probably) build and used before. > The original version of Classbox requires a new method lookup. This can be achieved either by modifying the VM or wrapping the method to intercept a call (using method wrapper for example). > > Interesting variants of classboxes could be realized by: > - having a lookup for classes: when you write "Morph new", then the name "Morph" is looked up, pretty much as methods are > - having a class Selector that get evaluated into a symbol. You can then achieved selector namespaces, which does not incur a cost at execution. what alex wants to say is that in S# dave simmons enhanced symbol with === and namespace.symbol equality was different than symbol equality so it was easy to add selector namespace into the system by just compiling symbol as namespace.symbol so message sends where namespacified. Namespac1 foo self bar => foo self Namespac1 But selector namespaces as well as class boxes are not a panacea because you always find strange beasts. So I'm curious to see what ruby people took for the semantics because we worked with alex 4 years on that and I was not satisfied. Stef > > Cheers, > Alexandre > > > On Jun 1, 2012, at 10:55 AM, Frank Shearar wrote: > >> I mused with a colleague about how I'd like to see "lexically scoped >> monkey patching", and he pointed me to some guys that want to add that >> to Ruby (http://timelessrepo.com/refinements-in-ruby) Note the >> inspiration for their work: ClassBoxes! >> (http://scg.unibe.ch/research/classboxes) >> >> I remember reading the paper years ago, and started working through it >> again now. Something that's not clear to me is this: does ClassBoxes >> require VM-side changes? (Because it changes the method lookup, after >> all, searching packages for methods before working up the inheritance >> tree.) If so, how invasive are they? If not, do we have a ball-park >> estimate of how much work it would be to update ClassBoxes to a more >> recent Squeak/Pharo? >> >> I'm more than happy to do the dogwork. I'd just like to know whether >> I'm signing up for months of work or not. >> >> Thanks! >> >> frank >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

June 1, 2012