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

[update 3.0] #30262

by Marcus Denker

30262 ----- 11089 Update Zn+Zdc July 2013 https://pharo.fogbugz.com/f/cases/11089

July 10, 2013

Re: [Pharo-dev] Some Spec questions

by ClÃ©ment Bera

Hello, So in the current spec debugger, the receiver's inspector widget is changed dynamically. Even if it looks like the same because it is always an inspector, it is not the same widget (could be any subclass of EyeInspector depending on receiver's type). So it is possible to change the main debugger spec dynamically object side. To change dynamically you have to do something like: MyClass class>>myDynamicLayout <spec> ^ SpecLayout composed add: #aModel; yourself MyClass>>changeLayoutDynamically self buildWithSpec: #myDynamicLayout. Then you can add: aComposableModel needRebuild: false on some widgets not to rebuild them and to speed up the spec generation. However, as this was too slow to do it for the full debugger (in the case of the receiver inspector), an inspectorWrapper class was made so the debugger has fixed spec and only the inspector wrapper spec changed. Depending on how often you change the toolbar, you may need to do something similar, even if it's a bit overly complex. You can have a look at inspectorWrapper, in Pharo 3.0. (InspectorWrapper>>updateInspectorFrom:) Hope it helped you, 2013/7/10 Andrei Vasile Chis <chisvasileandrei(a)gmail.com> > > > Hi folks, while working on the new debugger, I've come up with some >> questions... >> > >> > *is there any other implementation for dynamic widgets other that the >> current one? >> >> I do not get your question ... >> > > > This is related to my previous question about dynamic spec, if it's > possible to define the layout of > a widget on the object side. > > >> >> > >> > *right now the toolbar is a static widget, and I would like to have a >> dynamic one to filter out the actions that should not be available (which >> are a subset of the default ones). Would it make sense to regenerate the >> toolbar everytime the selection changes? Is there any other approach I >> should consider? >> >> It may make sense to dynamically regenerate the toolbar (or at least >> remove only what needs to be removed, add only what needs to be added). >> Then you should also think in term of user experience. Having things >> changing may be disturbing and counter productive :) > > > Right now our use case are post mortem contexts (that do not have a > process attached). In there case only few actions make sense. > The current debugger sets the toolbar at the creation of the debugger. If > the context turns post mortem during debugging the actions should also > change. Now the question would be if this is actually possible? > > >

July 10, 2013

Jenkins build is back to stable : Pharo-2.0-Tests Â» run 1,vm,win #259

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/Run=run%201,VM=vm,label=win/2…>

July 10, 2013

[update 2.0] #20612

by Marcus Denker

20612 ----- 10569 Backport 2.0: Better Interrruptionche https://pharo.fogbugz.com/f/cases/10569 10940 Backport 2.0: 10925 Use caching in Gofer https://pharo.fogbugz.com/f/cases/10940 Diff information: http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.782.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1350.diff http://ss3.gemstone.com/ss/Pharo20/Gofer-Core-MarcusDenker.194.diff

July 10, 2013

Re: [Pharo-dev] [update 3.0] #30261

by Damien Cassou

On Wed, Jul 10, 2013 at 10:21 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 11138 Implementation of user directories is a mess > https://pharo.fogbugz.com/f/cases/11138 > yeahhhh. Now, you can ask FileLocator for the desktop, documents, home... directories!! -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by Damien Cassou

On Wed, Jul 10, 2013 at 8:16 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > I use them. I always fix the red tests first because they are mostly > easier to fix and some of them lead to yellow tests I agree with you. I tend to do that as well. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 10, 2013

[update 3.0] #30261

by Marcus Denker

30261 ----- 11138 Implementation of user directories is a mess https://pharo.fogbugz.com/f/cases/11138 11152 Monticello not creating proper changes when moving trait methods to/from class https://pharo.fogbugz.com/f/cases/11152 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-MarcusDenker.542.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-MarcusDenker.…

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by Camillo Bruni

On 2013-07-10, at 09:08, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi Camillo: > > On 10 Jul 2013, at 02:46, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> Does anybody here distinguish failures and errors for real when doing TDD? > > To make your live a little more difficult, I actually introduced an additional type of failure on top of that: blue for still to be implemented. that on the other hand I like :) because a different action is needed. Which exactly is not the case when it is red vs yellow. I have to debug in either case... > I liked that a lot for prototyping to see all my todos in the test runner in a different pane, and to be able to distinguish between unimplemented stuff, and stuff I just broke again. > > However, to your actual question, I have not noticed that difference in JUnit, so, I guess, I don't really care for the destination between errors and failures.

July 10, 2013

Re: [Pharo-dev] Some Spec questions

by Andrei Vasile Chis

> > Hi folks, while working on the new debugger, I've come up with some > questions... > > > > *is there any other implementation for dynamic widgets other that the > current one? > > I do not get your question ... > This is related to my previous question about dynamic spec, if it's possible to define the layout of a widget on the object side. > > > > > *right now the toolbar is a static widget, and I would like to have a > dynamic one to filter out the actions that should not be available (which > are a subset of the default ones). Would it make sense to regenerate the > toolbar everytime the selection changes? Is there any other approach I > should consider? > > It may make sense to dynamically regenerate the toolbar (or at least > remove only what needs to be removed, add only what needs to be added). > Then you should also think in term of user experience. Having things > changing may be disturbing and counter productive :) Right now our use case are post mortem contexts (that do not have a process attached). In there case only few actions make sense. The current debugger sets the toolbar at the creation of the debugger. If the context turns post mortem during debugging the actions should also change. Now the question would be if this is actually possible?

July 10, 2013

More manpower needed for reviewing fixes...

by Marcus Denker

Hi, We mananged to nearly review (and often integrate) almost all pending fixes and enhancements. There are 4 issues left: https://pharo.fogbugz.com/f/filters/36/Review It would be nice if more people would be involved. If *you* don't comment, it might be we will do the wrong thing? Marcus

July 10, 2013