- Pharo-dev - lists.pharo.org

[Pharo-project] could metacello be hosted on ss3 or smalltalkhub or not load configurationOfHelp?

by Torsten Bergmann

Stef wrote: >because right now we cannot load configurations because it requires >configuration of Help and >squeaksource is done. >It would be good to have a small version of metacello just loading the bare >minimum. to Dale: Especially since "configuration of Help" is not required anymore. Help system is in Pharo and Squeak included. A "core" without help would be good Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

June 22, 2012

Re: [Pharo-project] could metacello be hosted on ss3 or smalltalkhub or not load configurationOfHelp?

by Frank Shearar

If it's a question of availability, Metacello's canonical repository is actually here: http://seaside.gemstone.com/ss/metacello. This has as its latest version dkh.694. frank On 22 June 2012 08:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > because right now we cannot load configurations because it requires configuration of Help and > squeaksource is done. > It would be good to have a small version of metacello just loading the bare minimum. > > Stef

June 22, 2012

Re: [Pharo-project] New System Progress Bar

by Pavel Krivanek

http://code.google.com/p/pharo/issues/detail?id=6123 On Fri, Jun 22, 2012 at 11:27 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > It seems that the new progress bar doesn't work well with DummyUIManager, see > https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%… > > -- Pavel > > On Thu, Jun 21, 2012 at 4:14 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> To help explain the changes, here's a snippet from the fix to "Issue 6099: >> Deprecate #value: for system progress (was red cross during updates)" >> (http://code.google.com/p/pharo/issues/detail?id=6099) The API (see >> SystemProgressItemMorph) is not set in stone, but it's already much less >> confusing than the old pseudo-class implementation. Ultimately, I'd like to >> move to announcements instead of exceptions to signal progress, and decouple >> the progress model/view - maybe just [un]registering the progress morph to >> enable/disable. >> >> The slice in the inbox for this issue should fix the "red cross during >> updates" problem... >> >> MOTIVATION: >> The old system progress worked like this (for example)... >> >> Â Â Â Â SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | >> Â Â Â Â Â Â Â Â 1 to: 100 do: [ :x | >> Â Â Â Â Â Â Â Â Â Â Â Â bar value: x. >> Â Â Â Â Â Â Â Â Â Â Â Â bar value: 'On iteration ', x asString. >> Â Â Â Â Â Â Â Â Â Â Â Â (Delay forMilliseconds: 20) wait "Just to slow it down so we can see >> what's going on" ] ]. >> >> * The work block ([ :bar | ... ] above) would accept one argument >> * That argument (:bar above) would be a block, that would act as a >> pseudo-class. Depending on what was passed to #value:, it would perform >> different functions. Two are illustrated above: >> Â - #value: aNumber; where aNumber is between the min and max of the >> progress range -> Set the bar's current progress mark to that position. For >> example, 'bar value: 50' above would show the operation half complete >> Â - #value: aString -> Set the label of the progress morph to aString >> >> This was very confusing, so we created a real class, >> SystemProgressItemMorph, which now gets passed to the work block, and has a >> real API. So, for example, the following becomes: >> >> Â Â Â Â SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | >> Â Â Â Â Â Â Â Â 1 to: 100 do: [ :x | >> Â Â Â Â Â Â Â Â Â Â Â Â bar current: x. >> Â Â Â Â Â Â Â Â Â Â Â Â bar label: 'On iteration ', x asString. >> Â Â Â Â Â Â Â Â Â Â Â Â (Delay forMilliseconds: 20) wait "Just to slow it down so we can see >> what's going on" ] ]. >> >> As you can see, '#value: newValue' has become '#current: newValue', and >> '#value: newLabel' has become '#label: newLabel'. >> >> One wrinkle is that some users were passing a nil-like block instead of the >> the pseudo-class to suppress the system progress bar. For example: >> Â Â Â Â informUserDuring: aBlock >> Â Â Â Â Â Â Â Â aBlock value: [:string | ]. >> >> Above, [:string | ] would now cause a DNU when sent, for example, #current:, >> which obviously blocks don't understand. So, these cases were changed like >> so: >> Â Â Â Â informUserDuring: aBlock >> Â Â Â Â Â Â Â Â aBlock value: DummySystemProgressItem new. >> >> Where DummySystemProgressItem simply ignores all messages without signaling >> an error >> >> -- >> View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>

June 22, 2012

Re: [Pharo-project] New System Progress Bar

by Pavel Krivanek

It seems that the new progress bar doesn't work well with DummyUIManager, see https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%… -- Pavel On Thu, Jun 21, 2012 at 4:14 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > To help explain the changes, here's a snippet from the fix to "Issue 6099: > Deprecate #value: for system progress (was red cross during updates)" > (http://code.google.com/p/pharo/issues/detail?id=6099) The API (see > SystemProgressItemMorph) is not set in stone, but it's already much less > confusing than the old pseudo-class implementation. Ultimately, I'd like to > move to announcements instead of exceptions to signal progress, and decouple > the progress model/view - maybe just [un]registering the progress morph to > enable/disable. > > The slice in the inbox for this issue should fix the "red cross during > updates" problem... > > MOTIVATION: > The old system progress worked like this (for example)... > > Â Â Â Â SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | > Â Â Â Â Â Â Â Â 1 to: 100 do: [ :x | > Â Â Â Â Â Â Â Â Â Â Â Â bar value: x. > Â Â Â Â Â Â Â Â Â Â Â Â bar value: 'On iteration ', x asString. > Â Â Â Â Â Â Â Â Â Â Â Â (Delay forMilliseconds: 20) wait "Just to slow it down so we can see > what's going on" ] ]. > > * The work block ([ :bar | ... ] above) would accept one argument > * That argument (:bar above) would be a block, that would act as a > pseudo-class. Depending on what was passed to #value:, it would perform > different functions. Two are illustrated above: > Â - #value: aNumber; where aNumber is between the min and max of the > progress range -> Set the bar's current progress mark to that position. For > example, 'bar value: 50' above would show the operation half complete > Â - #value: aString -> Set the label of the progress morph to aString > > This was very confusing, so we created a real class, > SystemProgressItemMorph, which now gets passed to the work block, and has a > real API. So, for example, the following becomes: > > Â Â Â Â SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | > Â Â Â Â Â Â Â Â 1 to: 100 do: [ :x | > Â Â Â Â Â Â Â Â Â Â Â Â bar current: x. > Â Â Â Â Â Â Â Â Â Â Â Â bar label: 'On iteration ', x asString. > Â Â Â Â Â Â Â Â Â Â Â Â (Delay forMilliseconds: 20) wait "Just to slow it down so we can see > what's going on" ] ]. > > As you can see, '#value: newValue' has become '#current: newValue', and > '#value: newLabel' has become '#label: newLabel'. > > One wrinkle is that some users were passing a nil-like block instead of the > the pseudo-class to suppress the system progress bar. For example: > Â Â Â Â informUserDuring: aBlock > Â Â Â Â Â Â Â Â aBlock value: [:string | ]. > > Above, [:string | ] would now cause a DNU when sent, for example, #current:, > which obviously blocks don't understand. So, these cases were changed like > so: > Â Â Â Â informUserDuring: aBlock > Â Â Â Â Â Â Â Â aBlock value: DummySystemProgressItem new. > > Where DummySystemProgressItem simply ignores all messages without signaling > an error > > -- > View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 22, 2012

[Pharo-project] [update 2.0] #20153

by Esteban Lorenzano

20153 ----- Issue 6069: Test guard for 20132 http://code.google.com/p/pharo/issues/detail?id=6069 Issue 6041: smart characters behave wrong on deletion http://code.google.com/p/pharo/issues/detail?id=6041 Issue 5945: Nice packaging for Text stuff http://code.google.com/p/pharo/issues/detail?id=5945

June 22, 2012

Re: [Pharo-project] Array size in inspector

by Ben Coman

Damien Cassou wrote: > On Thu, Jun 21, 2012 at 2:50 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > >> It doens't need to be StackOverflow necessary. We also have: >> "A friendly place where any question about pharo is welcome" >> <pharo-users(a)lists.gforge.inria.fr>, >> > > you are right. I've just update the Pharo website to give more > emphasis to this user mailing list and to stackoverflow. > > something looks wrong from FireFox 12.0 on Windows 7. see attached. It looks okay when I view it in IETab.

June 22, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,mac - Build # 151 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 22, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,linux - Build # 151 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 22, 2012

Re: [Pharo-project] New System Progress Bar

by Igor Stasenko

On 22 June 2012 09:46, Camillo Bruni <camillobruni(a)gmail.com> wrote: > You already have that igor (not as complete as you want, but it's there) > > Collection >> #do:displayingProgress: > > ah, good to know > On 2012-06-22, at 02:37, Igor Stasenko wrote: > >> btw, about human readable.., >> i don't understand, why we don't have something as simple as: >> >> collection do: [... ] showingProgress: 'Processing collection' >> (1 to: 100) do: [ ...] showingProgress: 'Processing ' >> >> 1 to: 100 do: [ ...] showingProgress: 'Processing ' >> >> i don't care what happens inside, but this interface is IMO much simpler >> and straightforward: >> a user just adds showingProgress: at the end, and voila, his silent block >> now showing a progress. >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

June 22, 2012

Re: [Pharo-project] Squeaksource down?

by Fabrizio Perin

We are having problems with the server hosting squeaksource. It will be up again soon. Fabrizio 2012/6/22 phil(a)highoctane.be <phil(a)highoctane.be> > Cannot reach it from here (lots of other sites are fine). > > Annoying for getting the configs loaded for a fresh image... (testing 1.4 > #441) > > Phil >

June 22, 2012