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

Re: [Pharo-project] Pharo is exploding

by Marcus Denker

On May 15, 2012, at 7:47 AM, Max Leske wrote: > A random thought: how about a stackexchange site for smalltalk? Most of the things disussed on the list could probably go there and the list would once again be a quiet place for core stuff only. > Yes, we were discussing that on Friday.... the developres of Rascal are using it: http://www.rascal-mpl.org/ > We (or I) would have to propose a new site and we would need people from Pharo AND Squeak (and hopefully other dialects too) to come aboard to promote the site. The entire process of creation is explained here: http://area51.stackexchange.com/faq > But would multi dialect not be very confusing? Marcus -- Marcus Denker -- http://marcusdenker.de

May 15, 2012

Re: [Pharo-project] Pharo is exploding

by Esteban Lorenzano

Hi, I don't believe a site for all smalltalks would be good at all. Reason is that they are very different and generates tons of different answers (increasing our difficulty to keep track of what is happening, who needs help, etc.)... Even related smalltalks like Pharo and Squeak are diverging really fast, and is becoming harder to have same answer applying to both (of course this is not 100% true, and still there are things that fits both words) One exclusive for Pharo, on the other hand, could be a great addition :) best, Esteban On May 15, 2012, at 7:46 AM, Max Leske wrote: > A random thought: how about a stackexchange site for smalltalk? Most of the things disussed on the list could probably go there and the list would once again be a quiet place for core stuff only. > > We (or I) would have to propose a new site and we would need people from Pharo AND Squeak (and hopefully other dialects too) to come aboard to promote the site. The entire process of creation is explained here: http://area51.stackexchange.com/faq > > Cheers, > Max > > On 15.05.2012, at 07:30, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > >> >> On 15 May 2012, at 04:43, Igor Stasenko wrote: >> >>> it was a time, when were able to track all activities around squeak, >>> pharo and vm.. >>> >>> today the amount of updates, news and activities is just overwhelming.. >>> >>> a rusty locomotive, which once staying in backyard, repaired by Stef >>> and Marcus and now goes faster and faster :) >> >> So true: I am happy and frustrated at the same time. So much is happening, I can't even follow all the stuff that falls into my own domain, let alone all the other interesting things. >> >> Sven >> >> >

May 15, 2012

Re: [Pharo-project] Pharo is exploding

by Marcus Denker

On May 15, 2012, at 4:44 AM, Igor Stasenko wrote: > it was a time, when were able to track all activities around squeak, > pharo and vm.. > > today the amount of updates, news and activities is just overwhelming.. > > a rusty locomotive, which once staying in backyard, repaired by Stef > and Marcus and now goes faster and faster :) :-) I think that we will now slowly see the feeback effects that I always try to explain to people: that when you improve something a little, you can use that small improvement to improve the system again, leading to exponential growth. The easiest example to understand this is tools: better tools make us productive, if we are more productive we can just do more. Like making the tools even better. But this is not just tools, it's everything. I think we will really realize what this means soon: that you can do things that are *impossible* else and that will feel truly like magic. (And I think we will see that the idea that you can just do research on top of an unchanged Squeak is completely wrong. With what we will have soon, we can do things on a qualitatively so different level that people will not even be able to compare... and nobody will even believe that we had to fight so hard for the obvious.) Marcus -- Marcus Denker -- http://marcusdenker.de

May 15, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by StÃ©phane Ducasse

On May 12, 2012, at 6:07 PM, Sean P. DeNigris wrote: > Issue 5874: [ENH]: Notify progress with Announcements instead of Exceptions > http://code.google.com/p/pharo/issues/detail?id=5874 > > This seems like a natural use case for Announcements and Exceptions seems > like more of a hack. > > I found the Exception behavior very hard to customize. I caught the > ProgressInitiationException, but the ProgressNotification exceptions seemed > to be caught elsewhere and I could not get to them. > > What do you guys think? I remember discussing with lukas about announcement vs. exception use but I do not remember. I have to think. > > Sean > > -- > View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 15, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by StÃ©phane Ducasse

And I cleaned it removing broken options :) In essence this is a dsl built using functional programming style. Would be better to have an object :) On May 14, 2012, at 4:56 PM, Sean P. DeNigris wrote: > Holy crap, SystemProgressMorph's "instance creation" method doesn't return an > instance at all but a block. I really wish I understood this design decision > before I try to cut all this out. Yikes, check out > SystemProgressMorph>>label:min:max: > > label: shortDescription min: startMinValue max: startMaxValue > "Answer the block that updates the progress bar." > > "some fun stuff added (by kph) > > - bar value: #label. - tell me my current label. > - bar value: 'newLabel'. - enable changing the label from within the > workBlock > - bar value: #increment. - enable progress by one without keeping a counter > - bar value: #decrement. - go backwards (if you really have to, useful for > an abort, or rollback)! > > - bar value: newBigNum. - change the max on the fly - when you find there > is more to do. > - bar value: (bar value: #setMax) + 20 - change the max on the fly - when > you find there is more/less to do. > - bar value: (bar value: #setMin) - 20 - change the min on the fly - not > sure why you would want to. > " > | slot range barSize lastRefresh maxValue minValue bar| > maxValue := startMaxValue. > minValue := startMinValue. > ((range := maxValue - minValue) <= 0 or: [(slot := self nextSlotFor: > shortDescription) = 0]) > ifTrue: [^[:barVal| 0 ]]. > self recenter. > self openInWorld. > barSize := -1. "Enforces a inital draw of the morph" > lastRefresh := Time millisecondClockValue. > bar := bars at: slot. > ^[:barValArg | | barVal return newBarSize | > barVal := barValArg. > return := nil. > bar := bars at: slot. > "new fun stuff here" > barVal == #current ifTrue: [ return := barSize ]. > barVal == #label ifTrue:[ return := (labels at: slot) contents ]. > barVal == #setMax ifTrue: [ return := maxValue. maxValue := minValue ]. > barVal == #setMin ifTrue: [ return := minValue. minValue := maxValue ]. > barVal == #increment ifTrue: [return := barVal := barSize + 1]. > barVal == #decrement ifTrue: [ return := barVal := barSize - 1]. > (barVal isString and: [barVal isSymbol not]) ifTrue: [ > (labels at: slot) contents: barVal. > barVal := #refresh]. > barVal == #refresh ifTrue: [self currentWorld displayWorld. return := > true]. > (barVal == SmallInteger maxVal or: [ barVal == #finished ]) ifTrue: > [return := slot]. > return ifNil: [ > barVal > maxValue ifTrue: [return := maxValue := barVal]. > barVal < minValue ifTrue: [return := minValue := barVal]. > (barVal between: minValue and: maxValue) > ifTrue: [newBarSize := (barVal - minValue / range * BarWidth) truncated. > newBarSize = barSize > ifFalse: [barSize := newBarSize. > (Time millisecondsSince: lastRefresh) > 25 > ifTrue: [barVal := #refresh ]]]. > barVal == #refresh ifTrue: [ > ((bar valueOfProperty: #useStripes) ifNil: [false]) > ifTrue: [bar fillStyle origin: bar position - ((Time > millisecondClockValue // 50 \\ 30) @ 0)]. > bar barSize: barSize. > self currentWorld displayWorld. > lastRefresh := Time millisecondClockValue]]. > return] > > -- > View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 15, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by StÃ©phane Ducasse

On May 14, 2012, at 3:05 PM, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote >> >> * String>>displayProgressAt:from:to:during: has "deprecated" in the >> comment, but is not in a deprecated category. The timestamp is 9/7/11 >> which puts it either 1.2 or early 1.3, but either way, it should be >> removed for 2.0, right? Yes >> There is only one sender in the image, which can >> easily be fixed to call #displayProgressFrom:to:during: >> > > Steph, this one's yours, do you know why it was deprecated and why it was > done in the comment instead of using deprecated:on:in:? Is wanting to place > a progress bar in a specific location not ever needed? If not, we should > remove it from all the UIManagers also, right? Because this is the responsibility of the domain to take decision on the UI placement. This is the UI manager or other that should take such decision. It also removes breaking layer and forcing people to query from the domain the current mouse position and most of the time people used Sensor hence violating again basic layering because in Morphic the mouse position should be queried by activeHand. > > Thanks. > Sean > > -- > View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 15, 2012

Re: [Pharo-project] Pharo is exploding

by Max Leske

A random thought: how about a stackexchange site for smalltalk? Most of the things disussed on the list could probably go there and the list would once again be a quiet place for core stuff only. We (or I) would have to propose a new site and we would need people from Pharo AND Squeak (and hopefully other dialects too) to come aboard to promote the site. The entire process of creation is explained here: http://area51.stackexchange.com/faq Cheers, Max On 15.05.2012, at 07:30, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 15 May 2012, at 04:43, Igor Stasenko wrote: > >> it was a time, when were able to track all activities around squeak, >> pharo and vm.. >> >> today the amount of updates, news and activities is just overwhelming.. >> >> a rusty locomotive, which once staying in backyard, repaired by Stef >> and Marcus and now goes faster and faster :) > > So true: I am happy and frustrated at the same time. So much is happening, I can't even follow all the stuff that falls into my own domain, let alone all the other interesting things. > > Sven > >

May 15, 2012

Re: [Pharo-project] Pharo is exploding

by Sven Van Caekenberghe

On 15 May 2012, at 04:43, Igor Stasenko wrote: > it was a time, when were able to track all activities around squeak, > pharo and vm.. > > today the amount of updates, news and activities is just overwhelming.. > > a rusty locomotive, which once staying in backyard, repaired by Stef > and Marcus and now goes faster and faster :) So true: I am happy and frustrated at the same time. So much is happening, I can't even follow all the stuff that falls into my own domain, let alone all the other interesting things. Sven

May 15, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by Sean P. DeNigris

I have a few questions about displaying progress... 1. What's the best way to do something like the following: I may be in the UI thread. I want to process a loop in a background thread, but block my current execution path, while still letting the world update. This is my use case... NewSystemProgressMorph>>show: aString from: startNumber to: endNumber during: aBlock | progressMorph | progressMorph := self addItemShowing: aString from: startNumber to: endNumber. self recenter. self openInWorld. [ [ progressMorph do: aBlock ] ensure: [ self close: progressMorph ] ] fork. [ progressMorph hasResult ] whileFalse: [ self currentWorld displayWorld. (Delay forMilliseconds: 20) wait ]. ^ progressMorph result I kept the #displayWorld from the old SystemProgressMorph, but it feels like a hack. I can't rely on stepping because I have to block until result is returned. "progressMorph do: aBlock" sets result, protected by a critical section of a Semaphore (I don't know if that's right/safe, just cobbled it together from the old implementation and a little googling). 2. what morphic messages from a non-UI thread have to be wrapped in addDeferredUIMessage:? #delete? repositioning a Morph? Is it any message sent to a morph, or only particular ones. 3. If anyone's using the following SystemProgressMorph functionality, please speak up. It seems overcomplicated and may disappear very soon :) value: newBigNum. - change the max on the fly - when you find there is more to do. bar value: (bar value: #setMax) + 20 - change the max on the fly - when you find there is more/less to do. bar value: (bar value: #setMin) - 20 - change the min on the fly - not sure why you would want to. -- View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 15, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by Sean P. DeNigris

Sean P. DeNigris wrote > > Holy crap, SystemProgressMorph... As a first step, I cleaned out the system progress morph classes... Issue 5897: [ENH]: Clean SystemProgressMorph and friends Fix in inbox: SLICE-Issue-5897-ENH-Clean-SystemProgressMorph-and-friends-SeanDeNigris.1 * create NewSystemProgressMorph as a replacement for SystemProgressMorph * create SystemProgressItemMorph to capture all the behavior from the huge block in SystemProgressMorph>>label:min:max: * Rename SystemProgressBarMorph to ProgressBarMorph (there's nothing System-specific) and clean I'd like someone to review the code, especially the process/semaphore parts of NewSystemProgressMorph before I integrate these classes with the system via the UIManagers. I had to do "Compiler recompileAll" when I filed the classes in because the system was confused between SystemProgressBarMorph and ProgressBarMorph. I'm not sure why. -- View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 15, 2012