March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] HOPomodoro (was Contribution CI Semantics)

by stephane ducasse

> > Cool :) > > One of my plan for 3.0 is more agile tools :) > I have started a new auto test, and I wanted a Pomodoro :) Yes I want more tdd tools. Now pay attention not to be too BigBrother. > > Now we can join forces :) > What I thought was cool is a pomodoro which block the ui during pauses, log the changes during sessions, and commit in the package-cache at the end of each iteration :P > > Ben > > On Mar 25, 2013, at 11:03 PM, DeNigris Sean <sean(a)clipperadams.com> wrote: > >>> philippeback: >>> I started this little thing, anyone welcome to improve it... >>> >>> http://smalltalkhub.com/#!/~philippeback/HOPomodoro >> >> Cool idea! I fixed the layout for the Morph and the control button so it doesn't look like: >> >> <Screen Shot 2013-03-25 at 5.45.47 PM.png> >> >> Cheers, >> Sean >> >> p.s. if you add me to the repo, I'll commit myself next time ;) >> >> <HighOctane-Pomodoro-SeanDeNigris.15.mcz> >

March 26, 2013

Re: [Pharo-project] Fuelout Stack: where in 2.0?

by phil＠highoctane.be

Maybe I have a simplified debugger on errors, right? Thx 2013/3/26 Marcus Denker <marcus.denker(a)inria.fr>: > > On Mar 26, 2013, at 8:06 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> I may be blind but it seems this is gone from the debugger. >> >> How comes? Is this coming back in 3.0 ? >> > It should be thereâ¦ last entry in the menu. > > Marcus > >

March 26, 2013

Re: [Pharo-project] Fuelout Stack: where in 2.0?

by Marcus Denker

On Mar 26, 2013, at 8:06 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > I may be blind but it seems this is gone from the debugger. > > How comes? Is this coming back in 3.0 ? > It should be thereâ¦ last entry in the menu. Marcus

March 26, 2013

[Pharo-project] [update 3.0] #30013

by Marcus Denker

March 26, 2013

[Pharo-project] Fuelout Stack: where in 2.0?

by phil＠highoctane.be

I may be blind but it seems this is gone from the debugger. How comes? Is this coming back in 3.0 ? Phil

March 26, 2013

Re: [Pharo-project] redefining default smalltalk shortcuts in (pluggable)textmorph

by phil＠highoctane.be

Yes, it would be very useful. Phil 2013/3/26 Tudor Girba <tudor(a)tudorgirba.com>: > Exactly. In fact, every time we start implementing anything we should do it per object, and not per class :). The class should only provide defaults at most. > > But in Keymappings we have now: > Morph>>detachAllKeymapCategories > > However, we do not yet have something like detachKey:. > > Cheers, > Doru > > > On Mar 25, 2013, at 10:27 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> Tudor Girba-2 wrote >>> I am trying to redefine shortcuts such as Cmd+s for an instance of >>> PluggableTextMorph >> >> I had trouble there when implementing Vim bindings. What I realized was >> (from >> http://forum.world.st/Keymapping-Class-vs-Instance-Targets-tp4639863p464022…) >> >> >>> What I want is: each instance gets its own copy of all its maps. If the >>> morph instance doesn't have any per-instance customizations, this can >>> point to the class defaults to save space (but I think this would be >>> premature optimization). However, as soon as the instance differs at all >>> from the class defaults, it /must/ have it's own local copy of all the >>> maps. I don't want to have to override each shortcut of a category >>> attached to the class. I want to detach the category /for just this >>> instance/. >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/redefining-default-smalltalk-shortcuts-in-pluggable-t… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > >

March 26, 2013

Re: [Pharo-project] HOPomodoro (was Contribution CI Semantics)

by phil＠highoctane.be

Interesting post on just that from one of my reference guys (from Fusebox era): http://www.halhelms.com/blog/index.cfm?mode=entry&entry=057F0E9E-FF20-683A-… Forget git and let's make images or package-cache saves. That's what triggered me to do the rli (run latest image) thing (attached sh) aliases in my .profile are: alias pharo=/usr/local/pharo/bin/vm-ui.sh alias pharocli=/usr/local/pharo/bin/vm.sh alias pharo20='/usr/local/pharo/bin/vm-ui.sh /usr/local/pharo/image/20/Pharo.image' alias pharo14='/usr/local/pharo/bin/vm-ui.sh /usr/local/pharo/image/14/Pharo-1.4.image' . ~/MyScripts/extracommands.sh e.g. opw Pomodoro rli opw Pomodoro pharocli `lsli` save HODev20130336_1130 rli Thinking of which, I'd add rpw and cpw and lspw (remove pharo workspace, copy pharo workspace, ls pharo workspaces). Ha, it is time to do that in Pharo itself with a command line handler... More to learn but FileSystem is going to help for sure :-) Phil 2013/3/25 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: > Cool :) > > One of my plan for 3.0 is more agile tools :) > I have started a new auto test, and I wanted a Pomodoro :) > > Now we can join forces :) > What I thought was cool is a pomodoro which block the ui during pauses, log > the changes during sessions, and commit in the package-cache at the end of > each iteration :P > > Ben > > On Mar 25, 2013, at 11:03 PM, DeNigris Sean <sean(a)clipperadams.com> wrote: > > philippeback: > I started this little thing, anyone welcome to improve it... > > http://smalltalkhub.com/#!/~philippeback/HOPomodoro > > > Cool idea! I fixed the layout for the Morph and the control button so it > doesn't look like: > > <Screen Shot 2013-03-25 at 5.45.47 PM.png> > > Cheers, > Sean > > p.s. if you add me to the repo, I'll commit myself next time ;) > > <HighOctane-Pomodoro-SeanDeNigris.15.mcz> > >

March 26, 2013

Re: [Pharo-project] HOPomodoro (was Contribution CI Semantics)

by phil＠highoctane.be

Cause I wanted my Pomodoro to work to help with the Pomodoro technique and do the actual work instead of turning my Pomodoro into new work :-) Jokes aside, I like to understand what goes under and even if I know enough about Spec to make it work, I just felt it fine to do it like that. What I think is that little thingy is small enough to make people understand how to do things from the old way to the spec way with intermediate steps. So, take me to the new step: Spec :-) You've go the commit rights. Phil 2013/3/26 Sean P. DeNigris <sean(a)clipperadams.com>: > philippeback wrote >> I used standard buttons but then moved to UIManager kind of things. > > Why not Spec? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/HOPomodoro-was-Contribution-CI-Semantics-tp4678266p46… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 26, 2013

Re: [Pharo-project] redefining default smalltalk shortcuts in (pluggable)textmorph

by Tudor Girba

Exactly. In fact, every time we start implementing anything we should do it per object, and not per class :). The class should only provide defaults at most. But in Keymappings we have now: Morph>>detachAllKeymapCategories However, we do not yet have something like detachKey:. Cheers, Doru On Mar 25, 2013, at 10:27 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Tudor Girba-2 wrote >> I am trying to redefine shortcuts such as Cmd+s for an instance of >> PluggableTextMorph > > I had trouble there when implementing Vim bindings. What I realized was > (from > http://forum.world.st/Keymapping-Class-vs-Instance-Targets-tp4639863p464022…) > > >> What I want is: each instance gets its own copy of all its maps. If the >> morph instance doesn't have any per-instance customizations, this can >> point to the class defaults to save space (but I think this would be >> premature optimization). However, as soon as the instance differs at all >> from the class defaults, it /must/ have it's own local copy of all the >> maps. I don't want to have to override each shortcut of a category >> attached to the class. I want to detach the category /for just this >> instance/. > > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/redefining-default-smalltalk-shortcuts-in-pluggable-t… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

March 26, 2013

Re: [Pharo-project] redefining default smalltalk shortcuts in (pluggable)textmorph

by Tudor Girba

Exactly. In fact, every time we start implementing anything we should do it per object, and not per class :). The class should only provide defaults at most. But in Keymappings we have now: Morph>>detachAllKeymapCategories However, we do not yet have something like detachKey:. Cheers, Doru On Mar 25, 2013, at 10:27 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Tudor Girba-2 wrote >> I am trying to redefine shortcuts such as Cmd+s for an instance of >> PluggableTextMorph > > I had trouble there when implementing Vim bindings. What I realized was > (from > http://forum.world.st/Keymapping-Class-vs-Instance-Targets-tp4639863p464022…) > > >> What I want is: each instance gets its own copy of all its maps. If the >> morph instance doesn't have any per-instance customizations, this can >> point to the class defaults to save space (but I think this would be >> premature optimization). However, as soon as the instance differs at all >> from the class defaults, it /must/ have it's own local copy of all the >> maps. I don't want to have to override each shortcut of a category >> attached to the class. I want to detach the category /for just this >> instance/. > > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/redefining-default-smalltalk-shortcuts-in-pluggable-t… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

March 26, 2013