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

Re: [Pharo-dev] [Pharo-fuel] Fuel API bug

by Denis Kudriashov

2013/8/5 Francisco Garau <francisco.garau(a)gmail.com> > I'd prefer #when:do: rather than #onAnnouncement:do: > > Yes. And it was original API from VisualWorks. And maybe it stay in VW now > - Francisco > > On 5 Aug 2013, at 18:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > On Aug 5, 2013, at 4:18 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > false polymorphism with exception handling? > > > indeed. > > When I read code and I see on:do: there is a big sign that shows up in my > mind: exception. > > In addition when I look inside the senders I get false sense of use. > > This is the case for example with on:do: for announcement which I really > do not like. > I think that we will rename on:do: into onAnnouncement:do: > because I did not see one case where suddenly I would like to mix > exception with announcement. > > Stef > > > > > 2013/8/5 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> Indeed, I thought the same. >> Stef, could you tell us why implementing on:do: is wrong? >> >> >> On Mon, Aug 5, 2013 at 10:30 AM, Martin Dias <tinchodias(a)gmail.com>wrote: >> >>> Hi >>> >>> Thanks Stef for fighting with the leak and thanks Max for the fast >>> response. >>> >>> >>> I think was me who added the method #on:do:, and my reasoning was: >>> >>> - FileStream has #fileNamed: and #fileNamed:do: >>> - PositionableStream has #on: >>> - I needed the analog to FileStream>>fileNamed:do: in PositionableStream >>> >>> So, I created #on:do:. It looked consistent. >>> >>> MartÃn >>> >>> >>> On Sun, Aug 4, 2013 at 5:02 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>> > impressive :) >>> > Tx guys. >>> > We are fighting with memory leaks like mad :) >>> > >>> > Stef >>> > >>> > On Aug 4, 2013, at 4:49 PM, Max Leske <maxleske(a)gmail.com> wrote: >>> > >>> >> Done. >>> >> >>> >> Name: ConfigurationOfFuel-MaxLeske.207 >>> >> Author: MaxLeske >>> >> Time: 4 August 2013, 4:49:17.037 pm >>> >> UUID: 5cc59075-e365-4a58-a20b-22e40b2b70c9 >>> >> Ancestors: ConfigurationOfFuel-MartinDias.206 >>> >> >>> >> * created new version 1.9.2 for development >>> >> * pointed development to 1.9.2 >>> >> * includes changes Camillo wanted to introduce into 1.9.1 >>> (DateAndTime fix) >>> >> >>> >> >>> >> On 04.08.2013, at 16:35, Max Leske <maxleske(a)gmail.com> wrote: >>> >> >>> >>> Yeah, no problem. I'll get on it right away. >>> >>> >>> >>> Max >>> >>> >>> >>> On 04.08.2013, at 16:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>> >>> >>> >>>> Hi guys >>> >>>> >>> >>>> can you rename this method? >>> >>>> >>> >>>> on: aCollectionOrStream do: aBlock >>> >>>> "Evaluates a block with a new stream based on the collection or >>> stream. Answers the result of the block evaluation. Follows the style of >>> FileStream>>fileNamed:do:." >>> >>>> | aStream | >>> >>>> aStream := self on: aCollectionOrStream. >>> >>>> [ ^ aBlock value: aStream ] ensure: [ aStream close ] >>> >>>> >>> >>>> >>> >>>> Please do not use on:do: for something that is not about exception >>> (and announcements). >>> >>>> >>> >>>> It is too confusing and refactor after. >>> >>>> >>> >>>> Stef >>> >>> >>> >> >>> >> >>> >> _______________________________________________ >>> >> Pharo-fuel mailing list >>> >> Pharo-fuel(a)lists.gforge.inria.fr >>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> > >>> > >>> > _______________________________________________ >>> > Pharo-fuel mailing list >>> > Pharo-fuel(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> >>> _______________________________________________ >>> Pharo-fuel mailing list >>> Pharo-fuel(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > >

Aug. 7, 2013

NB and OS specific tests

by Torsten Bergmann

Hi Stef, #nbBindingOf: is an extension on Behavior from the NativeBoost Core package. I tried and it works: - using Pharo2.0 Latest update: #20603 - adding http://smalltalkhub.com/#!/~Pharo/NativeBoost - loading latest version of Core, Examples, Pools, Mac, Unix, Win32, Tests All NB tests pass. Thx T.

Aug. 7, 2013

Re: [Pharo-dev] [Pharo-fuel] Fuel API bug

by Henrik Johansen

On Aug 7, 2013, at 8:55 , StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 6, 2013, at 4:47 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > >> >>> #when:do: is there already ;) >> >> even better then :) >> >>> #when:send:to: and #when:do:for: should be added though. > > what would be when:do:for: ? Its use is to specify a non-standard subscriber. In VW it is pretty much mandatory when using weak subscription, as VW subscribes the block. In Pharo it's much less useful, both because the at the moment weak when:do: doesn't work, but also since Pharo subscribes the block's receiver by default, which is what you want in 95% of cases. Still nice to have around in the edge cases one might still need it though. Cheers, Henry

Aug. 7, 2013

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

by Sebastian Tleye

Aug. 7, 2013

Fix in Athens-Cairo

by Alexandre Bergel

Hi Igor, I think have I found a bug when circle are drawn. I have added "(start = end) ifTrue: [ ^ self ]." in this method: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= AthensCairoPathBuilder>>arcTo: newEndPoint angle: angle cw: aBool " Add a clockwise arc segment, starting from current path endpoint and ending at andPt. Angle should be specified in radians " | start end center v radius startAngle endAngle cwAngle | angle isZero ifTrue: [ ^ self lineTo: newEndPoint ]. start := endPoint. endPoint := end := self toAbsolute: newEndPoint. "we have to transform the input. because Cario expects the center , radius, starting and ending angle, and we have the starting point, the ending point , and the angle. " aBool ifTrue: [cwAngle := angle] ifFalse: [cwAngle := angle negated]. "Do nothing if the two points are the same" (start = end) ifTrue: [ ^ self ]. center := self calcCenter: start end: end angle: cwAngle. v := (start - center). radius := v r. startAngle := self angleOfVector: v. endAngle := self angleOfVector: (end-center). aBool ifTrue: [ self arcCenterX: center x centerY: center y radius: radius startAngle: startAngle endAngle: endAngle ] ifFalse: [ self arcNegativeCenterX: center x centerY: center y radius: radius startAngle: startAngle endAngle: endAngle ] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I have attached a new version of the package. It simply defines this new method. It would be great to have a solution in case the start and end points are the same. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 7, 2013

Re: [Pharo-dev] NB and OS specific tests

by StÃ©phane Ducasse

I like the idea. I tried to load the latest version of NativeBoost and I got at reload a nbBindingOf: error on a test so I found that totally confusing and I had to cancel my integration. Stef On Aug 7, 2013, at 9:49 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Igor, > > NB includes OS specific classes and examples that will/may require OS specific tests. > > IMHO it would make sense to change "NativeBoost-Tests" category into > > - "NativeBoost-Tests-Core" > - "NativeBoost-Tests-Mac" > - "NativeBoost-Tests-Unix" > - "NativeBoost-Tests-Win32" > > while still keeping "NativeBoost-Tests" as one package. Later the package can be > split easily (but only if necessary). > > So we have categories for the NB Core tests and OS specific tests similar to the other > packages/categories. > > I would further provide common superclasses for OS specific tests, for instance > > TestCase subclass: #NBWin32SpecificTest > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'NativeBoost-Tests-Win32' > > and similar NBUnixSpecificTest and NBMacSpecificTest also. > > By overriding their #isAbstract method we can make their hierarchy only be runnable on > the specific OS. So the OS specific Jenkins slaves will show broken OS specific code, > Unix tests will not run on Mac, etc. > > Therefore we can control that the tests only run on the OS platform and find > out when things fail. > > What do you think? I can do it when there is another minute. > > Thx > Torsten >

Aug. 7, 2013

NB and OS specific tests

by Torsten Bergmann

Hi Igor, NB includes OS specific classes and examples that will/may require OS specific tests. IMHO it would make sense to change "NativeBoost-Tests" category into - "NativeBoost-Tests-Core" - "NativeBoost-Tests-Mac" - "NativeBoost-Tests-Unix" - "NativeBoost-Tests-Win32" while still keeping "NativeBoost-Tests" as one package. Later the package can be split easily (but only if necessary). So we have categories for the NB Core tests and OS specific tests similar to the other packages/categories. I would further provide common superclasses for OS specific tests, for instance TestCase subclass: #NBWin32SpecificTest instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'NativeBoost-Tests-Win32' and similar NBUnixSpecificTest and NBMacSpecificTest also. By overriding their #isAbstract method we can make their hierarchy only be runnable on the specific OS. So the OS specific Jenkins slaves will show broken OS specific code, Unix tests will not run on Mac, etc. Therefore we can control that the tests only run on the OS platform and find out when things fail. What do you think? I can do it when there is another minute. Thx Torsten

Aug. 7, 2013

[update 3.0] #30326

by StÃ©phane Ducasse

Aug. 7, 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=win/… 1 regressions found. KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses

Aug. 7, 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/… 1 regressions found. KernelTests.Numbers.LargePositiveIntegerTest.testMethodsOfTheClassShouldNotBeRepeatedInItsSuperclasses

Aug. 7, 2013