- Pharo-dev - lists.pharo.org

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 5 regressions found. Tests.Bugs.TestValueWithinFix.testValueWithinTimingBasic Tests.Bugs.TestValueWithinFix.testValueWithinTimingNestedInner Tests.Bugs.TestValueWithinFix.testValueWithinTimingNestedOuter Tests.Bugs.TestValueWithinFix.testValueWithinTimingRepeat Zinc.Zodiac.ZnHTTPSTests.testGetPharoVersion

Sept. 9, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 4 regressions found. Tests.Bugs.TestValueWithinFix.testValueWithinTimingBasic Tests.Bugs.TestValueWithinFix.testValueWithinTimingNestedInner Tests.Bugs.TestValueWithinFix.testValueWithinTimingNestedOuter Tests.Bugs.TestValueWithinFix.testValueWithinTimingRepeat

Sept. 9, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linu… 4 regressions found. Tests.Bugs.TestValueWithinFix.testValueWithinTimingBasic Tests.Bugs.TestValueWithinFix.testValueWithinTimingNestedInner Tests.Bugs.TestValueWithinFix.testValueWithinTimingNestedOuter Tests.Bugs.TestValueWithinFix.testValueWithinTimingRepeat

Sept. 9, 2013

[update 3.0] #30384

by Marcus Denker

30384 ----- 11513 testReturnStruct1Byte failing on Linux on the Build Server https://pharo.fogbugz.com/f/cases/11513 11448 BlockClosure >> #timeToRun should return a Duration https://pharo.fogbugz.com/f/cases/11448 11176 MessageBrowser: droplist shows a DropListItem https://pharo.fogbugz.com/f/cases/11176 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.235… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tools-MarcusDenker.136.d… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NativeBoost-Tests-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1604.diff

Sept. 9, 2013

Re: [Pharo-dev] gsoc - Debugger updates

by Damien Cassou

Hi Clara, On Sun, Sep 8, 2013 at 9:32 PM, Clara Allende <clari.allende(a)gmail.com>wrote: > I will write a post on my blog to explain this in more detail, anyway. could you please announce where your blog is? I would love to follow it. Thank you for your work -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 9, 2013

[update 3.0] #30383

by Esteban Lorenzano

30383 ----- 11542 Load FileTree in the image core https://pharo.fogbugz.com/f/cases/11542 (removing a remaining abstract method in Object) Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/MonticelloFileTree-Core.pharo…

Sept. 9, 2013

[update 3.0] #30382

by Marcus Denker

30382 ----- 11549 PluggableTextMorph closes completion menu on keydown https://pharo.fogbugz.com/f/cases/11549 11543 Select protocol name with suggestions https://pharo.fogbugz.com/f/cases/11543 11556 subclassResponsability -> subclassResponsibility https://pharo.fogbugz.com/f/cases/11556 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-MarcusDenker.567.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1242.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1601.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/CollectionsTests-MarcusDenker…

Sept. 9, 2013

Re: [Pharo-dev] gsoc - Debugger updates

by Marcus Denker

On Sep 8, 2013, at 9:33 PM, Clara Allende <clari.allende(a)gmail.com> wrote: > > -Object-centric debugger > This is a tricky one. I had tried, and Nico tried too, to migrate BifrÃ¶st to Pharo3.0, so far without success :( > BifrÃ¶st relies on the old compiler's ast dependencies and behavior, so it has not been easy to make it work with Opal. We have got in touch with Jorge Ressia and he promised us that he is going to take a look at this ASAP, to tell us whether it's likely or not that we migrate BifrÃ¶st. Nevertheless, it's going to take a while. > That being said, I am interested on getting BifrÃ¶st to work in Pharo3.0, and I'm a little sad that I couldn't get to play with object centric reflection for gsoc :( But I intend to keep on working on this after gsoc is over; so I promise I will let you know as soon as I have any news on this. > > Maybe if we can't integrate BifrÃ¶st we could think of a rework, basing on Jorge's ideas... Or maybe try another approach. > > Please let me know of any questions, suggestions,etc, I much appreciate them :) > I think the way to go is to first have a full and working an debugged version of Reflectivity for Pharoâ¦ and then build on top of that. The problem is that this is a project in itself. Marcus

Sept. 9, 2013

Re: [Pharo-dev] gsoc - Debugger updates

by StÃ©phane Ducasse

Thanks Clara for these news. Let us know how we can help you. We love so much the object centric debugger :) Also once you are in sync with andrei it would be good to see what should be pushed into Pharo. Stef On Sep 8, 2013, at 9:32 PM, Clara Allende <clari.allende(a)gmail.com> wrote: > Hi guys, sorry for the long time between updates :) > > On these months of gsoc, I have been working mostly on two aspects: > > -Adding support for filtering the stack > Andrei, NicolÃ¡s and I agreed that we wanted filters to be rich objects, so that we can combine them and add new ones at will. After two or three iterations, we ended up having a hierarchy of filters that can combine with other filters by sending #and: and #or: messages, and also we can create filters from any boolean block :) > So we have something like: > fromBlockFilter := [:ctx | ctx isNotNil] asFilter. > doItFilter:= SelectorFilter forSelector: #doIt. > > fromBlockFilter and: doItFilter. > > Which return a filter, that can decide if a context should be displayed or not, by sending #shouldDisplay: message. > This way, the filters handle a context, and the debugger handles the stack. I > > filterStack > > ^self class filterCommonMessageSends ifTrue:[ > self stack reject: [:aContext | (self enabledFilters anySatisfy: > [:aFilter | aFilter shouldDisplay: aContext]) > and: [aContext = self currentContext ] ] > ] > I will write a post on my blog to explain this in more detail, anyway. > > So far the default filters from the old debugger have their equivalent in this new filter api. Now I am working on having them as default configuration in settings browser; and the idea is > a) enable/disable filters at will > b) to let the user add new filters in a per-debugger custom configuration. > c) let the users "publish" a custom configuration to be used as default. > > <PharoScreenshot.1.png> > > -Object-centric debugger > This is a tricky one. I had tried, and Nico tried too, to migrate BifrÃ¶st to Pharo3.0, so far without success :( > BifrÃ¶st relies on the old compiler's ast dependencies and behavior, so it has not been easy to make it work with Opal. We have got in touch with Jorge Ressia and he promised us that he is going to take a look at this ASAP, to tell us whether it's likely or not that we migrate BifrÃ¶st. Nevertheless, it's going to take a while. > That being said, I am interested on getting BifrÃ¶st to work in Pharo3.0, and I'm a little sad that I couldn't get to play with object centric reflection for gsoc :( But I intend to keep on working on this after gsoc is over; so I promise I will let you know as soon as I have any news on this. > > Maybe if we can't integrate BifrÃ¶st we could think of a rework, basing on Jorge's ideas... Or maybe try another approach. > > Please let me know of any questions, suggestions,etc, I much appreciate them :) > > Cheers! > Clara > >

Sept. 9, 2013

Re: [Pharo-dev] Nautilus Newlist

by Benjamin

Is there something beside manpower which prevent you from anything ? :P But to answer your question, no, nothing. The thing is since the initialisation is a bit different with the NewList, it's tricky in some situation Ben On Sep 8, 2013, at 6:54 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Is there anything besides manpower that prevents us form using NewList in Nautilus?

Sept. 8, 2013