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

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

by Igor Stasenko

On 7 August 2013 15:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> 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) > > > We did all that. We tested it with Ben because he needed the change to send > ctrl events from the vm to the image, which were not sent. We tested in our > computers, and we had no much trouble. > > - I do not use delete key because I don't have one > - circumflex accent (return) was working with my keyboard layout > > So the vm was to me in a completely usable state. > >> >> >> now i understand we are humans and not immune to mistakes, but i >> insist that committing to blessed > > > 'blessed' is a crappy name for a repository. And the idea that the code in > this repository is always working flawlessly is nonsense. For example, we > had for months the problem with the smallinteger in there. > > And then, the unstable is in another repository then? Where is that > repository? Why do we have to make another repository for that and not just > a branch (in the same repo, not in my machine)? > so what you proposing? lets everyone put own unfinished changes into same repository without synchronization and see how it flies? it won't fly, i can tell you even without trying. >> >> 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. > > > First, we considered it as finished. What you found was a bug, not a pending > to do task. > Ah, in that case it is perfectly ok then. It is your messages in previous mails gave me impression that it is 'not done yet' but 'work in progress' and change is not finished. > Second, I have not the time to change to and learn every keyboard layout to > test, nor to plug every external keyboard and see how it behaves. So if you > think we should have done that, it will never be finished, and we will die > with what we have. > > Third, we need an unstable official branch for the pharo vm code for people > to test. To me, as blessed is the only repository out there, it is the only > place where I can put it. > It is blessed in terms that every change you pushing there is blessed by you (as developer), which means "i recommend to use new version by others". And until you can bless your own changes you should not push them into this repository, while obviously you free to push/commit them elsewhere. >> >> >> That is my only issue , that you committed code which is not yet >> finished, and makes VM unusable, > > > Now again. To me the latest vm was completely usable. How can I prove that > the change is then finished if I do not test with every existing device and > layout? > > So people has to test it. And let's be realistic: given the few people using > nowadays the latest pharo vm, if I put my code in my own personal > repository, how many people will download my experimental VM to test it from > my hidden branch in my hidden and personal repo? I guess almost none. > > No one tests => never proved => never finished => never merged => dies > Agreed. > That does not work. > > So if bleesed is the stable branch, which is the latest unstable branch? Do > we need many repositories for that? > it is not stable branch, it is development. stable versions come time to time, we can tag them as stable. >> and we cannot release VM with important fix to smallinteger bug before >> you finish, which turns yourself >> into a bottleneck. > > > You can always go to the vm log > > https://gitorious.org/cogvm/blessed/commits/master > > and check my last commits and try to rollback them in any case. This change > was only two lines of code. I'm of course not the code owner. > > > Now, I'm tired to argue. I want to solve this by stating: > - how do we get the latest unstable and where should the code be > - how do we get the latest stable and where should the code be > > Something else is that I have the feeling that we are discussing because of > the stupid "blessed" name. So I did this: > - create a new pharovm repo inside https://gitorious.org/cogvm, the old > blessed repo stays the same > - I copied everything from the repo blessed to pharovm, including history > - I created a blessed branch, which should in the future have the properties > you like <=> latest stable > - let master for latest bleedingEdge (not experimental, but maybe buggy) > > And then if we want other branches we create them. > > https://gitorious.org/cogvm/pharovm just one question: why adding 'blessed' branch if you think it is stupid? name it stable then, since you don't understand/value of blessing or consider it is stupid and unnecessary. but again, we don't need 'stable' as separate branch.. makes little sense, since we can just tag certain versions as stable, like everyone else does. -- Best regards, Igor Stasenko.

Aug. 7, 2013

becomeCompactSimplyAt: and Integer class>>initialize

by Martin Dias

Hi 1) I'm working on an issue related to compact classes index and I discovered that behaviours implement #becomeCompactSimplyAt:, which has this comment: "Make me compact, but don't update the instances. *For importing segments* ." This made me think that it's no longer needed in the image since we removed ImageSegment. In other hand, I don't know why sender might decide if the instances of the class must be updated or not... do you? 2) The only users in Pharo 3 are in: Integer class >> initialize "Integer initialize" "Ensure we have the right compact class index" "LPI has been a compact class forever - just ensure basic correctness" (LargePositiveInteger indexIfCompact = 5) ifFalse:[ (Smalltalk compactClassesArray at: 5) ifNil:[LargePositiveInteger becomeCompactSimplyAt: 5] ifNotNil:[self error: 'Unexpected compact class setup']]. (LargeNegativeInteger indexIfCompact = 4) ifFalse:[ (Smalltalk compactClassesArray at: 4) ifNil:[LargeNegativeInteger becomeCompactSimplyAt: 4] ifNotNil:[self error: 'Unexpected compact class setup']]. Now, looking for other users of #indexIfCompact, I see that here is the only place in the image where compact indexes are checked/fixed. 3) I wonder if we should remove both #becomeCompactSimplyAt: and Integer class>>initialize. Thank you in advance. MartÃn

Aug. 7, 2013

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

by Guillermo Polito

On Wed, Aug 7, 2013 at 2:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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) > We did all that. We tested it with Ben because he needed the change to send ctrl events from the vm to the image, which were not sent. We tested in our computers, and we had no much trouble. - I do not use delete key because I don't have one - circumflex accent (return) was working with my keyboard layout So the vm was to me in a completely usable state. > > now i understand we are humans and not immune to mistakes, but i > insist that committing to blessed > 'blessed' is a crappy name for a repository. And the idea that the code in this repository is always working flawlessly is nonsense. For example, we had for months the problem with the smallinteger in there. And then, the unstable is in another repository then? Where is that repository? Why do we have to make another repository for that and not just a branch (in the same repo, not in my machine)? > 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. > First, we considered it as finished. What you found was a bug, not a pending to do task. Second, I have not the time to change to and learn every keyboard layout to test, nor to plug every external keyboard and see how it behaves. So if you think we should have done that, it will never be finished, and we will die with what we have. Third, we need an unstable official branch for the pharo vm code for people to test. To me, as blessed is the only repository out there, it is the only place where I can put it. > > That is my only issue , that you committed code which is not yet > finished, and makes VM unusable, > Now again. To me the latest vm was completely usable. How can I *prove*that the change is then finished if I do not test with every existing device and layout? So people has to test it. And let's be realistic: given the few people using nowadays the latest pharo vm, if I put my code in my own personal repository, how many people will download my *experimental* VM to test it from my hidden branch in my hidden and personal repo? I guess almost none. No one tests => never proved => never finished => never merged => dies That does not work. So if *bleesed* is the stable branch, which is the latest unstable branch? Do we need many repositories for that? and we cannot release VM with important fix to smallinteger bug before > you finish, which turns yourself > into a bottleneck. You can always go to the vm log https://gitorious.org/cogvm/blessed/commits/master and check my last commits and try to rollback them in any case. This change was only two lines of code. I'm of course not the code owner. Now, I'm tired to argue. I want to solve this by stating: - how do we get the latest *unstable* and where should the code be - how do we get the latest *stable* and where should the code be Something else is that I have the feeling that we are discussing because of the stupid "blessed" name. So I did this: - create a new pharovm repo inside https://gitorious.org/cogvm, the old blessed repo stays the same - I copied everything from the repo blessed to pharovm, including history - I created a blessed branch, which should in the future have the properties you like <=> latest stable - let master for latest bleedingEdge (not experimental, but maybe buggy) And then if we want other branches we create them. https://gitorious.org/cogvm/pharovm > -- > Best regards, > Igor Stasenko. > >

Aug. 7, 2013

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