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

What is WeakActionSequence?

by Camillo Bruni

What is that class? No comments, two single methods on Object that refer to it?

Oct. 4, 2013

Re: [Pharo-dev] additional Milestone label for applications

by Camillo Bruni

If you want to track an external project on fogbugz, we should also create a proper fogbugz project, so it is clearly separated. On a project-basis you can define custom milestones. So in that sense, milestones do not serve for distinguishing external projects. Additionally you can define a simpler workflow for external projects (e.g. open / closed) which might serve your purposes better. PharoLauncher might not be the best example as it is maintained by core members, but usually for other projects it makes sense to manage them externally. Github is really a good option for that. On 2013-10-04, at 19:10, btc(a)openinworld.com wrote: > > I've been advised that for application related issues tracked on Fogbugz (e.g. for PharoLauncher) to avoid tagging the Milestone as 'Pharo3.0' - which is reserved for image related issues. Fair enough, but the only available alternative 'Later' just doesn't seem a good fit. Can adding another milestone be considered, like 'non-image' or 'application'. > > btw, my reasoning for tagging with Pharo3.0 was to do with the idea of simultaneous release [1] of related tools with the image. With the CI now operating for a lot of projects, it is not unfeasible that such a co-ordinated release occur. This might be good to encourage participation in testing and bug hunting in the final weeks and maybe speed the uptake of 3.0. On the other hand, it might unreasonably stretch resources trying to co-ordinate it. > > [1] http://wiki.eclipse.org/Simultaneous_Release > > cheers -ben

Oct. 4, 2013

additional Milestone label for applications

by btc＠openinworld.com

Oct. 4, 2013

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

by Martin Dias

Oct. 4, 2013

[update 3.0] #30452

by Marcus Denker

30452 ----- 11707 Tree Inspector: code pane needs to bind self https://pharo.fogbugz.com/f/cases/11707 11778 Can not <- or -> in TextModel https://pharo.fogbugz.com/f/cases/11778 11780 clean up unused FilePath and #asSqueakPathName https://pharo.fogbugz.com/f/cases/11780 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.1… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.177.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Files-MarcusDenker.ducasse.31… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Strings-MarcusDen…

Oct. 4, 2013

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

by Martin Dias

Excellent!!!!!!!!!!!!!!!!!!!!!!!!!! On Fri, Oct 4, 2013 at 3:21 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Now it would be nice to see what other actions do we need in the debugger > for creating methods > https://pharo.fogbugz.com/f/cases/5338/Create-button-in-debugger-for-subcla… > > > On Fri, Oct 4, 2013 at 2:57 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> 30449 >> ----- >> >> 11777 Fix SpecTests >> https://pharo.fogbugz.com/f/cases/11777 >> >> 11776 Fix Create action on #subclassResponsibility >> https://pharo.fogbugz.com/f/cases/11776 >> >> >> The debugger now displays the create button when an exception of type >> #subclassResponsibility is shown. However this action should only be shown >> if we are not working with an object of the abstract class (yes, normally it >> should not happen). Also all possible superclasses in which the method can >> be added should be displayed: >> for example consider this hierarchy: >> Parent >> -> Child1 >> -> Child11 >> -> Child111 >> and >> Parent>>doSomething >> self subclassResponsibility >> >> In this case 'Parent new doSomething' should not add a create action in >> the debugger. >> 'Child1 new doSomething' should automatically implement the method in the >> class Child1 >> 'Child3 new doSomething' should allow the user to select if he wants to >> add the method in classes Child1, Child2 or Child3. >> In all cases traits should be taken into account. >> >> >> >> >> Diff information: >> >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tests-MarcusDenker.37.di… >> >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerActions-MarcusDenker.… >> >

Oct. 4, 2013

[update 3.0] #30451

by Marcus Denker

30451 ----- 11457 #asSqueakPathName is a bad name https://pharo.fogbugz.com/f/cases/11457 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.9… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Settings-Polymorph-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Files-MarcusDenker.ducasse.31… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-MarcusDenker.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compression-MarcusDenker.133.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Strings-MarcusDen…

Oct. 4, 2013

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

by Andrei Chis

Now it would be nice to see what other actions do we need in the debugger for creating methods https://pharo.fogbugz.com/f/cases/5338/Create-button-in-debugger-for-subcla… On Fri, Oct 4, 2013 at 2:57 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 30449 > ----- > > 11777 Fix SpecTests > https://pharo.fogbugz.com/f/cases/11777 > > 11776 Fix Create action on #subclassResponsibility > https://pharo.fogbugz.com/f/cases/11776 > > > The debugger now displays the create button when an exception of type > #subclassResponsibility is shown. However this action should only be shown > if we are not working with an object of the abstract class (yes, normally > it should not happen). Also all possible superclasses in which the method > can be added should be displayed: > for example consider this hierarchy: > Parent > -> Child1 > -> Child11 > -> Child111 > and > Parent>>doSomething > self subclassResponsibility > > In this case 'Parent new doSomething' should not add a create action in > the debugger. > 'Child1 new doSomething' should automatically implement the method in the > class Child1 > 'Child3 new doSomething' should allow the user to select if he wants to > add the method in classes Child1, Child2 or Child3. > In all cases traits should be taken into account. > > > > > Diff information: > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tests-MarcusDenker.37.di… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerActions-MarcusDenker.… > >

Oct. 4, 2013

[update 3.0] #30450

by Marcus Denker

30450 ----- 11759 Protocol names should be Symbols https://pharo.fogbugz.com/f/cases/11759 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/ClassOrganizer-Core-MarcusDen…

Oct. 4, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=wi… 1 regressions found. Zinc.Tests.ZnServerTests.testEntityTooLarge

Oct. 4, 2013