- Pharo-dev - lists.pharo.org

Re: [Pharo-project] ProgressBar improvements

by Camillo Bruni

sssh it's secret https://code.google.com/p/pharo/issues/detail?id=5874 have fun On 2012-09-01, at 20:50, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Which slice ? > > Ben > > On Sep 1, 2012, at 8:48 PM, Camillo Bruni wrote: > >> Sean and I worked on a proof of concept for a new progress handling >> at ESUG. Over the last 2 days I refactored what we did and pushed >> it into a Slice on PharoInbox. >> >> At this time it would be nice if someone else could have a look at >> it and say what they think about it :). >> >> see: Job>>basicExample for more details. >> >> best >> cami >> > >

Sept. 1, 2012

Re: [Pharo-project] ProgressBar improvements

by Benjamin

Which slice ? Ben On Sep 1, 2012, at 8:48 PM, Camillo Bruni wrote: > Sean and I worked on a proof of concept for a new progress handling > at ESUG. Over the last 2 days I refactored what we did and pushed > it into a Slice on PharoInbox. > > At this time it would be nice if someone else could have a look at > it and say what they think about it :). > > see: Job>>basicExample for more details. > > best > cami >

Sept. 1, 2012

[Pharo-project] ProgressBar improvements

by Camillo Bruni

Sean and I worked on a proof of concept for a new progress handling at ESUG. Over the last 2 days I refactored what we did and pushed it into a Slice on PharoInbox. At this time it would be nice if someone else could have a look at it and say what they think about it :). see: Job>>basicExample for more details. best cami

Sept. 1, 2012

[Pharo-project] Xtreams (and other cross-platform projects)

by DeNigris Sean

I'm posting this to squeak-dev, pharo dev, and esug, but it'd be great to keep discussion in one place, like the esug list, or even better, the issue link below if appropriate... At ESUG, Martin Kobetic, Dale Henrich, and I worked on some key pieces to port and maintain cross-platform projects via github. By adapting Filetree to convert between VW namespaces and class name prefixes, we: 1. loaded Xtreams from squeaksource 2. via a Filetree repo, pushed it to github in a directory structure identical to that of the VW branch 3. again via Filetree, loaded the pushed version into another Pharo image, where all the tests passed. This is an initial proof-of-concept (some things are hard-coded, conditional halts left as sanity checks, etc.), but it shows that it is possible. Some limitations: * only one level of namespace is supported * source code is not transformed More details can be found at https://github.com/dalehenrich/filetree/issues/59 Cheers, Sean

Sept. 1, 2012

Re: [Pharo-project] What happens with Warning when running in headless image (2.0)?

by Igor Stasenko

On 31 August 2012 23:22, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> wrote: > I created two bug entries: > http://code.google.com/p/pharo/issues/detail?id=6624 > http://code.google.com/p/pharo/issues/detail?id=6625 > btw, can you try one thing: try to recompile the Deprecation class. > > 2012/8/31 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> >> >> Ok thanks for reply anyway. Really I don't have hurry (I fixed that with a >> horrible code I wrote), I just want report that issue. >> >> >> 2012/8/31 Igor Stasenko <siguctua(a)gmail.com> >>> >>> On 31 August 2012 15:24, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> >>> wrote: >>> > Hi Igor. >>> > >>> > Here, in a linux box, I guess that this warning occurs and raise the >>> > NonInteractiveUIManager exception, and is showed in stdout when I run >>> > in >>> > headless mode. >>> > >>> you'd better wait for Camillo's reply then. >>> Because originally, i wrote that code , so it was ignoring warnings. >>> Then Camillo is added some steroids to it, so an image(s) became far >>> more friendly to consoles, >>> including headless mode. >>> >>> > >>> > 2012/8/31 Igor Stasenko <siguctua(a)gmail.com> >>> >> >>> >> in headless mode all warnings are suppressed (so they don't >>> >> interfere). >>> >> i'm not sure if it prints something on stdout.. >>> >> it could be that it simply ignored and continues running the stuff. >>> >> >>> >> On 31 August 2012 14:11, GastÃ³n Dall' Oglio >>> >> <gaston.dalloglio(a)gmail.com> >>> >> wrote: >>> >> > Hello. >>> >> > >>> >> > I install Seaside in a Pharo 1.4 summer image. Then I run it in >>> >> > headless >>> >> > from console and I go to the /status app, and a >>> >> > "MessageNotUnderstood: >>> >> > >>> >> > >>> >> > NonInteractiveUIManager>>openDebuggerOn:context:label:contents:fullView:" >>> >> > exception occurs and the vm close. >>> >> > >>> >> > Then I run this image in gui and an "Deprecation: The method >>> >> > SmalltalkImage>>isRunningCog has been deprecated." dialog box are >>> >> > raised. I >>> >> > evaluate Deprecation raiseWarning: false but no take effect, the >>> >> > dialog >>> >> > is >>> >> > raised anyway. >>> >> > >>> >> > Maybe another is correct way to disable raise deprecation? >>> >> > >>> >> > 2012/8/31 Camillo Bruni <camillobruni(a)gmail.com> >>> >> >> >>> >> >> if run from the command line you should get a decent error >>> >> >> message... >>> >> >> >>> >> >> what kind of error do you get? >>> >> >> >>> >> >> BTW: just show me the code and I'll fix it :P >>> >> >> >>> >> >> On 2012-08-31, at 07:24, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>> >> >> >>> >> >> > I'm running a headless pharo2.0 from a script and the vm >>> >> >> > disappears >>> >> >> > without a trace (no pharodebug.log info etc.) ... when I run the >>> >> >> > script in a >>> >> >> > gui, I see that a warning dialog box is popping up, so perhaps >>> >> >> > this >>> >> >> > is the >>> >> >> > source of the issue? ... or perhaps it's something else? >>> >> >> > >>> >> >> > Dale >>> >> >> > >>> >> >> >>> >> >> >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Best regards, >>> >> Igor Stasenko. >>> >> >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > -- Best regards, Igor Stasenko.

Aug. 31, 2012

Re: [Pharo-project] What happens with Warning when running in headless image (2.0)?

by GastÃ³n Dall' Oglio

I created two bug entries: http://code.google.com/p/pharo/issues/detail?id=6624 http://code.google.com/p/pharo/issues/detail?id=6625 2012/8/31 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > Ok thanks for reply anyway. Really I don't have hurry (I fixed that with a > horrible code I wrote), I just want report that issue. > > > 2012/8/31 Igor Stasenko <siguctua(a)gmail.com> > >> On 31 August 2012 15:24, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> >> wrote: >> > Hi Igor. >> > >> > Here, in a linux box, I guess that this warning occurs and raise the >> > NonInteractiveUIManager exception, and is showed in stdout when I run in >> > headless mode. >> > >> you'd better wait for Camillo's reply then. >> Because originally, i wrote that code , so it was ignoring warnings. >> Then Camillo is added some steroids to it, so an image(s) became far >> more friendly to consoles, >> including headless mode. >> >> > >> > 2012/8/31 Igor Stasenko <siguctua(a)gmail.com> >> >> >> >> in headless mode all warnings are suppressed (so they don't interfere). >> >> i'm not sure if it prints something on stdout.. >> >> it could be that it simply ignored and continues running the stuff. >> >> >> >> On 31 August 2012 14:11, GastÃ³n Dall' Oglio < >> gaston.dalloglio(a)gmail.com> >> >> wrote: >> >> > Hello. >> >> > >> >> > I install Seaside in a Pharo 1.4 summer image. Then I run it in >> headless >> >> > from console and I go to the /status app, and a >> "MessageNotUnderstood: >> >> > >> >> > >> NonInteractiveUIManager>>openDebuggerOn:context:label:contents:fullView:" >> >> > exception occurs and the vm close. >> >> > >> >> > Then I run this image in gui and an "Deprecation: The method >> >> > SmalltalkImage>>isRunningCog has been deprecated." dialog box are >> >> > raised. I >> >> > evaluate Deprecation raiseWarning: false but no take effect, the >> dialog >> >> > is >> >> > raised anyway. >> >> > >> >> > Maybe another is correct way to disable raise deprecation? >> >> > >> >> > 2012/8/31 Camillo Bruni <camillobruni(a)gmail.com> >> >> >> >> >> >> if run from the command line you should get a decent error >> message... >> >> >> >> >> >> what kind of error do you get? >> >> >> >> >> >> BTW: just show me the code and I'll fix it :P >> >> >> >> >> >> On 2012-08-31, at 07:24, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> >> >> >> >> >> > I'm running a headless pharo2.0 from a script and the vm >> disappears >> >> >> > without a trace (no pharodebug.log info etc.) ... when I run the >> >> >> > script in a >> >> >> > gui, I see that a warning dialog box is popping up, so perhaps >> this >> >> >> > is the >> >> >> > source of the issue? ... or perhaps it's something else? >> >> >> > >> >> >> > Dale >> >> >> > >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >

Aug. 31, 2012

Re: [Pharo-project] Pharo summer is 14557 or 14457?

by GastÃ³n Dall' Oglio

;), thanks you Esteban for your work. Bernardo, I guess that is not necessary open an issue for this little typo. Regards. 2012/8/31 Esteban Lorenzano <estebanlm(a)gmail.com> > oops! > I will fix it :P > > thanks, > Esteban > > On Aug 31, 2012, at 4:40 PM, GastÃ³n Dall' Oglio < > gaston.dalloglio(a)gmail.com> wrote: > > > Hi. > > > > I download Pharo-1.4-14557-OneClick.zip (named Pharo Summer in Pharo > website), but this image in "System -> About..." dialog is showing Latest > update: #14457. But in CI lastest is 1.4 #14459. Maybe it is a typo in zip > file name? > > > > Another little type, in Linux script of Pharo-1.3-13328-OneClick.zip, > exec "$BASE/pharo" should be exec "$BASE/CogVM". > > > > Regards. > > >

Aug. 31, 2012

Re: [Pharo-project] What happens with Warning when running in headless image (2.0)?

by GastÃ³n Dall' Oglio

Ok thanks for reply anyway. Really I don't have hurry (I fixed that with a horrible code I wrote), I just want report that issue. 2012/8/31 Igor Stasenko <siguctua(a)gmail.com> > On 31 August 2012 15:24, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > wrote: > > Hi Igor. > > > > Here, in a linux box, I guess that this warning occurs and raise the > > NonInteractiveUIManager exception, and is showed in stdout when I run in > > headless mode. > > > you'd better wait for Camillo's reply then. > Because originally, i wrote that code , so it was ignoring warnings. > Then Camillo is added some steroids to it, so an image(s) became far > more friendly to consoles, > including headless mode. > > > > > 2012/8/31 Igor Stasenko <siguctua(a)gmail.com> > >> > >> in headless mode all warnings are suppressed (so they don't interfere). > >> i'm not sure if it prints something on stdout.. > >> it could be that it simply ignored and continues running the stuff. > >> > >> On 31 August 2012 14:11, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com > > > >> wrote: > >> > Hello. > >> > > >> > I install Seaside in a Pharo 1.4 summer image. Then I run it in > headless > >> > from console and I go to the /status app, and a "MessageNotUnderstood: > >> > > >> > > NonInteractiveUIManager>>openDebuggerOn:context:label:contents:fullView:" > >> > exception occurs and the vm close. > >> > > >> > Then I run this image in gui and an "Deprecation: The method > >> > SmalltalkImage>>isRunningCog has been deprecated." dialog box are > >> > raised. I > >> > evaluate Deprecation raiseWarning: false but no take effect, the > dialog > >> > is > >> > raised anyway. > >> > > >> > Maybe another is correct way to disable raise deprecation? > >> > > >> > 2012/8/31 Camillo Bruni <camillobruni(a)gmail.com> > >> >> > >> >> if run from the command line you should get a decent error message... > >> >> > >> >> what kind of error do you get? > >> >> > >> >> BTW: just show me the code and I'll fix it :P > >> >> > >> >> On 2012-08-31, at 07:24, Dale Henrichs <dhenrich(a)vmware.com> wrote: > >> >> > >> >> > I'm running a headless pharo2.0 from a script and the vm disappears > >> >> > without a trace (no pharodebug.log info etc.) ... when I run the > >> >> > script in a > >> >> > gui, I see that a warning dialog box is popping up, so perhaps this > >> >> > is the > >> >> > source of the issue? ... or perhaps it's something else? > >> >> > > >> >> > Dale > >> >> > > >> >> > >> >> > >> > > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

Aug. 31, 2012

Re: [Pharo-project] An idea about visual feedback in Athens

by Igor Stasenko

i am actually quite intrigued. .. by following a numerous code paths i found this: handlerForMouseDown: anEvent "Return the (prospective) handler for a mouse down event. The handler is temporarily installed and can be used for morphs further down the hierarchy to negotiate whether the inner or the outer morph should finally handle the event." anEvent blueButtonPressed ifTrue: [^ self handlerForBlueButtonDown: anEvent]. anEvent yellowButtonPressed ifTrue: [^ self handlerForYellowButtonDown: anEvent]. anEvent controlKeyPressed ifTrue: [^ self handlerForMetaMenu: anEvent]. (self handlesMouseDown: anEvent) ifFalse: [^ nil]. "not interested" anEvent handler ifNil: [^ self ]. "Same priority but I am innermost" "Nobody else was interested" ^self mouseDownPriority >= anEvent handler mouseDownPriority ifTrue: [ self] ifFalse: [ nil] now, i was wondering, what that #mouseDownPriority means.. and how it influencing the overall logic for determining who will handle the event.. and as it appears, this guy means nothing.. because the only implementation of it in Pharo is: mouseDownPriority "Return the default mouse down priority for the receiver" ^ 0 and 2 methods sending it (the above one and following): handlerForYellowButtonDown: anEvent "Return the (prospective) handler for a mouse down event with the yellow button pressed. The handler is temporarily installed and can be used for morphs further down the hierarchy to negotiate whether the inner or the outer morph should finally handle the event." (self hasYellowButtonMenu or: [ self handlesMouseDown: anEvent ]) ifFalse: [ ^ nil]. "Not interested." anEvent handler ifNil: [^ self]. "Nobody else was interested" "Same priority but I am innermost." ^ self mouseDownPriority >= anEvent handler mouseDownPriority ifFalse: [nil ] ifTrue: [self] Notice that both methods are actually semantically equivalent in their last statement, but at first glance i thought not, because first uses ifTrue: [ self] ifFalse: [ nil] but second uses: ifFalse: [nil ] ifTrue: [self] so, the last statement is always answers self... Ok, after reading it, i think i finally got an idea what it does: it looks like a way to redefine the natural z-order of morphs by overriding this method and answering other value(s). But my mind fails to figure at least one case where it can be useful. What about yours? -- Best regards, Igor Stasenko.

Aug. 31, 2012

Re: [Pharo-project] An idea about visual feedback in Athens

by Igor Stasenko

On 31 August 2012 21:21, Igor Stasenko <siguctua(a)gmail.com> wrote: > and to give an idea, how current Morphic doing that, a starting point is > MorphicEventDispatcher > > personally, i find this code too complex to understand, given heavy > use of case statements and branches. > > But i figured out, that this method: > > > dispatchEvent: anEvent with: aMorph > "Dispatch the given event for a morph that has chosen the receiver to > dispatch its events. The method implements a shortcut for repeated > dispatches of events using the same dispatcher." > anEvent type == lastType ifTrue:[^self perform: lastDispatch with: > anEvent with: aMorph]. > "Otherwise classify" > lastType := anEvent type. > anEvent isMouse ifTrue:[ > anEvent isMouseDown ifTrue:[ > lastDispatch := #dispatchMouseDown:with:. > ^self dispatchMouseDown: anEvent with: aMorph]]. > anEvent type == #dropEvent ifTrue:[ > lastDispatch := #dispatchDropEvent:with:. > ^self dispatchDropEvent: anEvent with: aMorph]. > anEvent isWindowEvent ifTrue:[ > lastDispatch := #dispatchWindowEvent:with:. > ^self dispatchWindowEvent: anEvent with: aMorph]. > lastDispatch := #dispatchDefault:with:. > ^self dispatchDefault: anEvent with: aMorph > > --- > > actually can be replaced by one-liner: > > dispatchEvent: anEvent with: aMorph > morph := aMorph. > ^ anEvent sentTo: self oh.. it is two lines, sorry.. > .. yeah.. my favorite thing: double-dispatch. > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Aug. 31, 2012