- Pharo-dev - lists.pharo.org

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

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

Aug. 7, 2013

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

by StÃ©phane Ducasse

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: ? > > sounds good. > >> >> Cheers, >> Henry >> >> >> > >

Aug. 7, 2013

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

by Esteban Lorenzano

ok, jumping in... :) so... there are some problems with the recommended approach. 1) having a branch/trunk whatever that contains just "blessed" versions in the meaning of "stable" is a nonsense. For that, is easier to have a zip somewhere. One thing that is complete wrong is to keep VMMaker version and Platform Sources separated. That's bad for many reasons, but the principal one is that we cannot TAG a version and be sure that everything, platform + vmmaker are in sync. 2) CI is built against "blessed" repository. Since we cannot know if a commit is ok (and therefore, "blessed") until after the build is done and the tests are run (and green), one of both is wrong: - the repository is actually not blessed, or - the CI is taking bad sources (again, this can be solved by tagging, but well...) 3) at beginning of year we decided to take "stable" versions of VMs precisely to avoid this problems and give us time to stabilize. Now I understand people want to get over the SmallInteger bug, but well, we are all humans and our days is still 24hs. So, as a conclusion: - "blessed", for me, does not means "stable"... is more like a "trunk" - working with pull requests would be ideal, but also time consuming, and no-one here has many of that, who put the bell in the cat's neck? - sure we can have branches for experiments, etc... but the key stuff is not that, is a very long time needed work (and for me, since is needed to build real key combinations, is also essential). - we really need to improve the process. First step is to have all sources in one single repository. - I would like to review the use we give to CI process, because IMHO, now we are using it more like a "builder" than a real continuous integration tool. Esteban out On Tue, Aug 6, 2013 at 9:51 PM, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > > On Tue, Aug 6, 2013 at 9:33 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> I imagine that having a branch is the way to go. >> > > To me, a branch is a fork in the code. That is, you split and they evolve > differently. If you want to tag a version as stable, you use a tag :). And > git already supports all that. But we don't use it ;). > > However, branches make sense to me if we have for example > > - vm for pharo2 > - vm for pharo3 > - vm .... > > With that setup, in the pharo2 branch we can backport fixes from the > pharo3 branch, but they may evolve differently. > And more importantly, we do not need to maintain all the compatibility > with the world. Whoever wants a pharo2 vm, they go to the pharo2 branch, > which on release is freezed (as well as the image). > > Now, in Git, I do not think there is a need for having many repositories > for that. It's enough with branches and tags... > > >> Like that esteban can integrate the fixes of eliot and you do not stress >> to finish. >> > > Yes, but esteban has already lots of things to do :). And every time I > made a pull request, a had to push it myself into the main branch because > if not, nobody did it. And ask Camillo, he was in the same situation... In > the image side we have Stef, Marcus and Esteban that integrate fixes. In > the vm side it's only Esteban :/. > > Once this is ready there is a merge. >> > > But that's what happen today, only the naming is bad in the git branch :). > > - We have a stable VM, which you can download as stable. That VM does not > have the latest changes. I do not know if there is a tag, but there should > be. > - We have a unstable VM, which we call latest. It has the latest sources > which we should test and prove before "blessing" it as the stable. > > >> >> At least this is what I was thinking the process was: >> one main blessed stream >> > several others at different level of maturity with the ultimate goal to >> avoid bottleneck. >> > > Yes, but with that we lack also a good management of the issue tracking > and stuff :). Above in this thread I was asking where do I submit an issue. > Maybe we should put everything in the pharo issue tracker and be happy with > only one tool. > > BTW, tomorrow I go to lille, we can discuss if you have some minutes :). > > >> Stef >> >> >> On Tue, Aug 6, 2013 at 8:06 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 6 August 2013 17:47, Guillermo Polito <guillermopolito(a)gmail.com> >>> wrote: >>> > ah, forgot to say. Latest vms from jenkins should be ready in a while, >>> not >>> > yet :). >>> > >>> yes, and that's why i want you to answer a following question: >>> why you think the repository was named 'blessed' as in [1]? >>> >> >> I don't know... That some saint has come and blessed it? :) >> If not, point me to where it is explained, is there a wiki page or >> something? >> >> Igor, I do not know how to read that question. Now, really: >> >> - I thought that moving the VM repository to gitorious was meant to open >> it. If only a couple of people (lets say you, Camilo and Esteban) have the >> rights to commit, then I feel it defeats the purpose >> >> - Maybe I should make a pull-request, but you can see that there are >> three there, one for at least one year, waiting for integration and >> probably out of date [1] >> >> - to me one benefit of using a CVS is that it gives you the ability to >> revert and going back in the history, and there are not much commits in cog >> to traverse... So, if it is really broken we go back and there are no >> problems. Should I be afraid of committing something? >> >> - As Stef says, you only can break if you do... >> >> - Now, maybe I should continue not trying to fix some stuff in the vm if >> people get pissed off when using latest and a bug is found >> >> [1] https://gitorious.org/cogvm/blessed/merge_requests >> >> >>> [1] https://gitorious.org/cogvm/blessed/ >>> >>> > >>> > On Tue, Aug 6, 2013 at 5:46 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> >>> > wrote: >>> >> >>> >> >>> >> On Tue, Aug 6, 2013 at 4:53 PM, StÃ©phane Ducasse >>> >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> >>> thanks guillermo :) >>> >>> Cleaning events at VM level is important. >>> >> >>> >> >>> >> Cleaning is not sooooo easy :). >>> >> >>> >> I've been able to reproduce some of these problems (the delete key >>> and the >>> >> double keyUp:). I've tried to fix them, bah, actually I did in here, >>> but I'd >>> >> like someone else tests in their keyboard layouts in their homes :). >>> >> >>> >> Regarding the difference of the keyValues between keyUp and keyDown, >>> I did >>> >> not address it, and it kinda orthogonal, nothing to do with this >>> particular >>> >> issue. >>> >> >>> >> To see my changes, people can have a look at the diff in here: >>> >> >>> >> >>> >> >>> https://gitorious.org/cogvm/blessed/commit/2214cee58a5c5266b8ab2322b9847155… >>> >> >>> >> I'd like to start putting this in some issue tracker. Cog issue >>> tracker or >>> >> Pharo one? :) Esteban? >>> >> >>> >>> >>> >>> On Aug 6, 2013, at 4:32 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> >>> >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Aug 6, 2013 at 3:40 PM, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> >>>> >>> >>>> I changed this method to see better what happens: >>> >>>> HandMorph class>>showDebugEvent: evt >>> >>>> >>> >>>> ShowEvents == true ifTrue: [ >>> >>>> | ofs| >>> >>>> Display fill: (0@0 extent: 500@120) rule: Form over >>> >>>> fillColor: Color white. >>> >>>> ofs := (owner hands indexOf: self) - 1 * 60. >>> >>>> evt printString displayAt: (0@ofs) + (evt >>> isKeyboard >>> >>>> ifTrue: [0@30] >>> >>>> ifFalse: [0@0]). >>> >>>> self keyboardFocus printString displayAt: >>> >>>> (0@ofs)+(0@45). >>> >>>> >>> >>>> evt isKeyboard ifTrue: [ Transcript show: evt >>> >>>> printString;cr ] >>> >>>> ]. >>> >>>> >>> >>>> >>> >>>> KeyboardEvent>> printOn: aStream >>> >>>> "Print the receiver on a stream" >>> >>>> >>> >>>> aStream nextPut: $[. >>> >>>> aStream nextPutAll: type; nextPutAll: ' '''. >>> >>>> self printKeyStringOn: aStream. >>> >>>> aStream nextPut: $'. >>> >>>> >>> >>>> aStream space; nextPutAll: 'keyValue: ', self keyValue >>> >>>> asString. >>> >>>> >>> >>>> aStream nextPut: $] >>> >>>> >>> >>>> set >>> >>>> HandMorph showEvents:true >>> >>>> >>> >>>> Now, pressing single space, gives me this: >>> >>>> >>> >>>> [keyDown ' ' keyValue: 49] >>> >>>> [keystroke ' ' keyValue: 32] >>> >>>> [keyUp ' ' keyValue: 49] >>> >>>> [keyUp ' ' keyValue: 49] >>> >>>> >>> >>>> Pressing delete key (or fn-backspace , for those who having a lot of >>> >>>> spare fingers to use bad keyboards): >>> >>>> >>> >>>> [keyDown ' ' keyValue: 117] >>> >>>> [keystroke 'â¦' keyValue: 188] >>> >>>> [keyUp ' ' keyValue: 117] >>> >>>> [keyUp ' ' keyValue: 117] >>> >>>> >>> >>>> now, can someone tell me , why there is 2 keyUp events for each >>> keyDown? >>> >>> >>> >>> >>> >>> That I don't know >>> >>> >>> >>>> >>> >>>> >>> >>>> and of course, main question is why key values are different for >>> >>>> keydown and keystroke events? >>> >>> >>> >>> >>> >>> That I'll dive right now into the vm to see what it is :). >>> >>> >>> >>>> >>> >>>> (and why delete key is not 127, but 117 or 188?) >>> >>>> >>> >>>> Editor expecting 127: >>> >>>> >>> >>>> cmdMap at: (127 + 1) put: #forwardDelete:. "del >>> >>>> key" >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Best regards, >>> >>>> Igor Stasenko. >>> >>>> >>> >>> >>> >>> >>> >> >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >> >> >

Aug. 6, 2013