- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Fix in Athens-Cairo

by Igor Stasenko

Just to make it clear: when you get zero-divide error, where you think the bug is , in #/ method, or maybe in code which passed zero as divisor? by analogy, when you want to draw an arc with zero length, which makes it non-arc, where you think the bug is, in code which implements drawing an arc or in code which provides wrong input? because this change actually hiding the mistakes, so instead of getting error and fixing it, user now will have hard times figuring out, why it not draws things as intended and where his mistake is. -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Keyboard events is broken.

by Igor Stasenko

My understanding how it should be: - you work in own branch (and in git, repository clone is already a branch, just on your computer). If you want to make it public you need to make own branch on gitorious and commit there. - once you finished with changes and tested it , you are free to merge with blessed (no need to have GODs permission to do that, or make pull requests) now i understand we are humans and not immune to mistakes, but i insist that committing to blessed should be done after some manual testing and checking it don't breaks things badly, and of course blessed is not for committing the unfinished code , which in the middle of work. That is my only issue , that you committed code which is not yet finished, and makes VM unusable, and we cannot release VM with important fix to smallinteger bug before you finish, which turns yourself into a bottleneck. -- Best regards, Igor Stasenko.

Aug. 7, 2013

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

by Igor Stasenko

I agree, except that as far as i know there is no platform-specific tests yet. On 7 August 2013 09:49, 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 -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Fix in Athens-Cairo

by Igor Stasenko

On 7 August 2013 10:03, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi Igor, > > I think have I found a bug when circle are drawn. > > I have added "(start = end) ifTrue: [ ^ self ]." in this method: > your change just makes it fool-proof. The bug is in user code which specifies wrong data (drawing arc with two coinciding points?) Anyways, i added it. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- Best regards, Igor Stasenko.

Aug. 7, 2013

Re: [Pharo-dev] Please test: New PharoVM built

by StÃ©phane Ducasse

thanks I will try it now. Stef On Aug 7, 2013, at 1:11 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Guille built a new vm with an attept of fixing the key combinations problem. > Can you test it? > > http://files.pharo.org/vm/pharo/ > > (and pick the latest for your platform) > > Thanks, > Esteban > >

Aug. 7, 2013

Please test: New PharoVM built

by Esteban Lorenzano

Hi, Guille built a new vm with an attept of fixing the key combinations problem. Can you test it? http://files.pharo.org/vm/pharo/ (and pick the latest for your platform) Thanks, Esteban

Aug. 7, 2013

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

by StÃ©phane Ducasse

Tx, I did the same except that when I want to integrate the package and I reload it I get this error. Now hypothesis one: - may be this is the verify logic that is not good, because I reload all the packages without order so may be we are in the case where a package is loaded before another one. I will check with igor. > 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 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