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

Re: [Pharo-dev] Quitting the community

by Igor Stasenko

P.S. regardless.. about the subject, so, now Here's an example nil asValueHolder shall be refactored to nil asReactiveVariable ? sounds like a plan :) ==== And yes, Ben, you are wrong, if you consider this as a personal attack. This code smells, to say it politely. But i prefer to call it crap. When i see such things, the only thing, which comes to my mind is: 'when the only tool you have is a hammer, you tend to treat everything as nail'. But this is example to show you that when your college says "you're wrong" it don't actually means "i hate you and you should leave". You should probably learn to make a difference between "fundamentalist's hatred" towards bad code/design decisions, and "hatred based on personal basis". Because i do, and while i hate bad code, and can explode with curses & blasphemy, it doesn't means that i am targeting its author. No, it is just the code. I am really miss your company and your sense of humor. To my opinion, you was a part of what was making a great atmosphere in our team, at least for me. Too bad, that you decided to leave, instead of standing and fighting, defending your opinion and proving it right. Because this is what i would do, considering the amount of energy i put into it, and based on honest and strong will to make it even better. -- Best regards, Igor Stasenko.

Aug. 19, 2014

Re: [Pharo-dev] Quitting the community

by Sean P. DeNigris

philippeback wrote > This thread is also useful and Nice raises the legacy issue: > http://forum.world.st/COTDC-108-NewValueHolder-td4738066.html Yes, this is where it all began. For the record, the name change was my idea, not Ben's. I didn't think it was controversial - more of a question. As you can see, it was discussed on the mailing list and, seeing no dissent, Ben and I pushed the change. I too was sorry to waste the time making the change, and wished someone would've spoken up on the mailing list, but I realize we can't read and respond to every mail, so I let it go and moved on. But is this really what the whole fight is about?! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Quitting-the-community-tp4773730p4773795.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 19, 2014

Re: [Pharo-dev] Quitting the community

by Igor Stasenko

Ben, there is a lot more positive way to say bye.. As life goes on, i hope, one day you will learn how to do it. I can't believe that subtle disagreement, especially on technical basis (like naming convention) could lead you to such decision. Unless it is your own decision, then it (as well as anything else) can serve as a good excuse. But hey.. lets be real.. Really, Ben, you could just come one day and say: - you know guys, i am fed up with all of you and Pharo.. i wanna leave and look and try something else. Because you cannot bet, that you will never cross the roads with one or another guy you were working with, for the rest of your life.. and the last thing you want at such moment, is the guy shooting at you at sight. -- Best regards, Igor Stasenko.

Aug. 18, 2014

Stack size for compiled methods (issue 13854 Crash/hang on array access)

by Nicolai Hess

Hi, on what depends the stack size for a compiled method? I try to figure out, why the old compiler and the opal compile generate different compiled method headers. I think this comes from a wrong stack size computed by opal, but I can not figure out how the stack size is computed. Old Compiler PolygonMorph>>#lineSegmentsDo: header -> "primitive: 0 numArgs: 1 numTemps: 3 numLiterals: 23 frameSize: 56" Opal compiler: PolygonMorph>>#lineSegmentsDo: header -> "primitive: 0 numArgs: 1 numTemps: 3 numLiterals: 23 frameSize: 16"

Aug. 18, 2014

Re: [Pharo-dev] Quitting the community

by phil＠highoctane.be

On Mon, Aug 18, 2014 at 9:58 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > @ Phil > > Yes, I am sad as well, this is not how it should be. I really liked each > of them a lot. > Now, whenever people collaborate there will be conflicts, this is > inevitable. A conflict is often complex, has always two sides to it, and a > long history (it is not just about one thing right now, most of the history > is unknown to us, lots of personal things come into play as well). How > conflicts are dealt with (or left festering) is what counts. > haro is not about one person, it is an open source community. It is not > good to generalise and hold the community hostage, or hurt it deliberately > - this goes against the very thing you contributed selflessly to in the > first place. > > We have a rudimentary mechanism to deal with conflicts, it is called the > board: > > <from the website> > > The board > > Pharo has a board composed of Marcus Denker, Stephane Ducasse, Sven Van > Caekenberghe, Tudor GÃ®rba and Esteban Lorenzano. > > The role of the board is to make decisions if in the future the community > can't decide on a course of action. > > </from the website> > > Even if the conflict involves a board member, the board should play its > role. If necessary, individual board members can be contacted. This has not > happened. > Let's remember that for the next case. > > > @ Ben > > I am sad and sorry about you leaving. You will be missed and I thank you > for all you did. I hope that maybe one day we will hear from you again. > > I remember that young student coming in with all this energy, writing a > new code browser, Nautilus, from scratch, and doing Spec along the way - it > was a herculean task. You did great work and we all benefit from it. > > > @ Camillo > > Iden ditto: you leaving makes me really sad and I will miss you - thank > you for everything you did. I hope we'll meet again. > > I have fond memories about meeting you during sprints starting in the old > INRIA building. Your enthusiasm was really contagious, there was no task > you would not want to tackle. You rewrote the book for Pharo for command > line handling, issue tracking, issue validation, git integration, the eye > inspector, source/change file compaction and so much more. You have a great > sense of good design, we're all better for it. > > > Peace, > > Sven > > On 18 Aug 2014, at 11:55, phil(a)highoctane.be wrote: > > > I'd say that we now have: > > > > Camillo - pissed off to death > > Ben - same > > Nico - gone > > > > There is something amiss there. > > > > These people are significant contributors and made the system move > forward in new and much needed directions (Zeroconf/CommandLine, Spec, > Amber). > > > > Pissing them off is really a bad approach, no matter why/how/... Get the > house in order please and stop the ego trips. Yelling at people/each other > just doesn't work and doesn't help. Try that at your cat. > > > > Oh, yeah, it helps in pushing great people to other communities... As we > needed that. > > > > And now, I am feeling sad. > > > > Phil > > > > On Mon, Aug 18, 2014 at 11:36 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > Hi Ben, > > > > Thanks for letting us know. > > > > I am sorry you feel this way, but I believe your presentation of the > situation is both unfair and unfortunate. You are obviously referring to > issues that are of personal nature, and as outsiders we are left with only > an ugly feeling without being able to either understand or fix anything. > > > > I was actually having fun until your email, and as far as I can tell, > others were having fun as well. I am not sure what the intention of your > email was, but at least for me, your mail did manage to spoil the fun for a > second. > > > > I appreciate the work you put in Pharo, I respect your decision, but I > do not sympathize with your behavior. > > > > Good luck, > > Doru > > > > > > > > > > On Mon, Aug 18, 2014 at 8:38 AM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > Hello guys, > > > > I am sending this email to explain why I am quiting the Pharo community, > > as well as the Smalltalk community. > > > > I can not bear Stephane Ducasse's behavior anymore whether at a public > > level or a private level. > > > > It seems that his ego is preventing him from being able to have a > discussion > > without overreacting, being agressive, or insulting. > > > > I can not approve how Stephane is constantly talking behind my back to > unleash > > his irrationnal wrath and to provide his very own version of the facts. > > > > I can not see how this can lead to a peaceful and respectful community > > where we can all have fun building a future. > > > > Therefore I will not be part of this project anymore, since the way > Stephane > > is acting is taking away all the fun I can have interacting with all of > you. > > > > It was a hard decision to take, but I can not be part of a community led > > by someone whose behaviour is going against all my principles. > > > > I wish to all of you to have fun, and keep me in touch > > if you want to have a beer someday ;) > > > > Ben > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > >

Aug. 18, 2014

Re: [Pharo-dev] Quitting the community

by Sven Van Caekenberghe

@ Phil Yes, I am sad as well, this is not how it should be. I really liked each of them a lot. Now, whenever people collaborate there will be conflicts, this is inevitable. A conflict is often complex, has always two sides to it, and a long history (it is not just about one thing right now, most of the history is unknown to us, lots of personal things come into play as well). How conflicts are dealt with (or left festering) is what counts. Pharo is not about one person, it is an open source community. It is not good to generalise and hold the community hostage, or hurt it deliberately - this goes against the very thing you contributed selflessly to in the first place. We have a rudimentary mechanism to deal with conflicts, it is called the board: <from the website> The board Pharo has a board composed of Marcus Denker, Stephane Ducasse, Sven Van Caekenberghe, Tudor GÃ®rba and Esteban Lorenzano. The role of the board is to make decisions if in the future the community can't decide on a course of action. </from the website> Even if the conflict involves a board member, the board should play its role. If necessary, individual board members can be contacted. This has not happened. @ Ben I am sad and sorry about you leaving. You will be missed and I thank you for all you did. I hope that maybe one day we will hear from you again. I remember that young student coming in with all this energy, writing a new code browser, Nautilus, from scratch, and doing Spec along the way - it was a herculean task. You did great work and we all benefit from it. @ Camillo Iden ditto: you leaving makes me really sad and I will miss you - thank you for everything you did. I hope we'll meet again. I have fond memories about meeting you during sprints starting in the old INRIA building. Your enthusiasm was really contagious, there was no task you would not want to tackle. You rewrote the book for Pharo for command line handling, issue tracking, issue validation, git integration, the eye inspector, source/change file compaction and so much more. You have a great sense of good design, we're all better for it. Peace, Sven On 18 Aug 2014, at 11:55, phil(a)highoctane.be wrote: > I'd say that we now have: > > Camillo - pissed off to death > Ben - same > Nico - gone > > There is something amiss there. > > These people are significant contributors and made the system move forward in new and much needed directions (Zeroconf/CommandLine, Spec, Amber). > > Pissing them off is really a bad approach, no matter why/how/... Get the house in order please and stop the ego trips. Yelling at people/each other just doesn't work and doesn't help. Try that at your cat. > > Oh, yeah, it helps in pushing great people to other communities... As we needed that. > > And now, I am feeling sad. > > Phil > > On Mon, Aug 18, 2014 at 11:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Ben, > > Thanks for letting us know. > > I am sorry you feel this way, but I believe your presentation of the situation is both unfair and unfortunate. You are obviously referring to issues that are of personal nature, and as outsiders we are left with only an ugly feeling without being able to either understand or fix anything. > > I was actually having fun until your email, and as far as I can tell, others were having fun as well. I am not sure what the intention of your email was, but at least for me, your mail did manage to spoil the fun for a second. > > I appreciate the work you put in Pharo, I respect your decision, but I do not sympathize with your behavior. > > Good luck, > Doru > > > > > On Mon, Aug 18, 2014 at 8:38 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Hello guys, > > I am sending this email to explain why I am quiting the Pharo community, > as well as the Smalltalk community. > > I can not bear Stephane Ducasse's behavior anymore whether at a public > level or a private level. > > It seems that his ego is preventing him from being able to have a discussion > without overreacting, being agressive, or insulting. > > I can not approve how Stephane is constantly talking behind my back to unleash > his irrationnal wrath and to provide his very own version of the facts. > > I can not see how this can lead to a peaceful and respectful community > where we can all have fun building a future. > > Therefore I will not be part of this project anymore, since the way Stephane > is acting is taking away all the fun I can have interacting with all of you. > > It was a hard decision to take, but I can not be part of a community led > by someone whose behaviour is going against all my principles. > > I wish to all of you to have fun, and keep me in touch > if you want to have a beer someday ;) > > Ben > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Aug. 18, 2014

Re: [Pharo-dev] Deep SIXX

by Ken Treis

Hi Sebastian, The primary strategy is to convert the code to subElementsFrom:do:, but it doesn't work for everything. I described the challenges and strategies in the blog post under the "Gory Details" heading. In general, you'll probably need to find a way to split instantiation from state restoration. Instantiate the object first (when you first see the tag), then restore its state as you traverse sub-elements of the XML. Also, the float test that you were fighting is a bad test case. Change it to something like: | original restored | original := 42.42. restored := Object readSixxFrom: object sixxString. self assert: original class == restored class. self assert: (original - restored) abs < 0.00001 -- Ken Treis Miriam Technologies, Inc. (866) 652-2040 x221 On Aug 18, 2014, at 9:05 AM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > ah sorry duplicate Ken, good to know > > What sixx seems to be expecting is the sub elements of the current element > > Is there any strategy that comes to your mind about making the pullParser to return elements/ satisfy that? > > from iPad > > On 18/08/2014, at 12:26, Ken Treis <ken(a)miriamtech.com> wrote: > >> Thanks Sebastian. I'm on the Pharo list too. >> >> -- >> Ken Treis >> Miriam Technologies, Inc. >> (866) 652-2040 x221 >> >> On Aug 18, 2014, at 5:26 AM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> >>> cc/ >>> >>> from iPad >>> >>> Begin forwarded message: >>> >>>> From: Sebastian Sastre <sebastian(a)flowingconcept.com> >>>> Date: 17 de agosto de 2014 20:35:49 BRT >>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>> Subject: [Pharo-dev] Deep SIXX >>>> Reply-To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>> >>>> Hey guys, >>>> >>>> Thanks to Ken Treis we might have a (big) stream of SIXX coming into or going out of Pharo. >>>> >>>> Iâm sharing progress of the port here before I can do the contribution PR to Masashi: >>>> http://smalltalkhub.com/#!/~sebastianconcept/SIXX >>>> >>>> To load the code take a fresh Pharo and do: >>>> >>>> Gofer it >>>> squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfSIXX'; >>>> load. >>>> >>>> (Smalltalk at: #ConfigurationOfSIXX) project latestVersion load. >>>> >>>> and then load the package from here (which is a merge from Masashiâs and Kenâs fork plus what Iâve patched): >>>> http://smalltalkhub.com/#!/~sebastianconcept/SIXX >>>> >>>> Iâm very close to make this to start being useful. >>>> >>>> Iâm currently stuck in getting this test to pass: >>>> >>>> testFloat >>>> >>>> self should:[ 42.42 = (Object readSixxFrom: 42.42 sixxString) ] >>>> >>>> Any ideas on making >>>> #initializeIndexFieldsFromSixxElement: sixxElement context: aDictionary >>>> >>>> work with the PullParser? >>>> >>>> sebastian >>>> >>>> o/ >>>> >>>> blog: http://sebastianconcept.com >>>> LinkedIn: http://www.linkedin.com/in/sebastiansastre >>>> github: https://github.com/sebastianconcept >>>> >>>> >>>> >>>> >>

Aug. 18, 2014

Re: [Pharo-dev] Digging to understand Cmd+Click and Ctrl+Click

by phil＠highoctane.be

I am in. Using linux and hating the current behavior. Phil Le 18 aoÃ»t 2014 19:30, "Guillermo Polito" <guillermopolito(a)gmail.com> a Ã©crit : > Hi! > > Most of you already know that in Mac, if you do cmd+click on a class name > or a selector, you get to browse the class or the implementors of the > method. > > Now, most of you know that it does not work on linux :). So I was digging > today and I'll share a bit here what I found... > > First, the navigation through cmd+click is managed by the TextAttribute > subclasses, in particular TextLink, TextClassLink and TextMethodLink. And > these are the important methods: > > TextLink>>mayActOnEvent: anEvent > ^ anEvent isMouseUp and: [ anEvent commandKeyPressed ] > > TextClassLink>>actOnClick: anEvent for: target in: aParagraph editor: > anEditor > anEvent shiftPressed > ifFalse: [ anEditor browseClassFrom: self className ] > ifTrue: [ anEditor referencesTo: self className ]. > ^ true > > And another similar in TextMethodLink. > > Now, the first thing I tried was to add a "or: [ anEvent controlKeyPressed > ]" into the first method. Guess what? That did not work. > > So I noticed a weird behavior. > - On mac: When you do cmd+click, the text morph, if it was not selected, > gets selected on mouse down, and on mouse up it gets deselected and the > class is browsed. > > - On linux: when you do a ctrl+click, the text morph never gets selected > on the first place. And that's why it never handles the mouseUp:. Just > check: > > Morph>>handleMouseUp: anEvent > "System level event handling." > anEvent wasHandled ifTrue: [^self]. "not interested" > *==> anEvent hand mouseFocus == self ifFalse: [^self]. "Not interested in > other parties"* > > So... the question is, why is the text morph not getting the focus? > > Well, it turns out that morphic decodes a Ctrl+click as a blueButton. So > in the method Morph>>handlerForMouseDown: the execution differs between mac > and linux. > > And weirder, the event that arrives there, is modified by some strange > table that I hate. So the event has a SHIFT, which I didn't press! That > shift gets introduced in the event in here: > > InputEventSensor>>processEvent: evt > ... > ... > type = EventTypeMouse > ifTrue: [ > "Transmogrify the button state according to the platform's button map > definition" > * evt at: 5 put: (ButtonDecodeTable at: (evt at: 5) + 1).* > "Map the mouse buttons depending on modifiers" > * evt at: 5 put: (self mapButtons: (evt at: 5) modifiers: (evt at: 6)).* > > So much FUN! > > Well, so far I do not know how to solve it. But I know I do not like the > "One table to decode strangely bits that should work for all platforms but > it works just for one of them" approach :) > > I'll try to follow this later, but if someone wants to help, I welcome it > :) > > Guille >

Aug. 18, 2014

Digging to understand Cmd+Click and Ctrl+Click

by Guillermo Polito

Hi! Most of you already know that in Mac, if you do cmd+click on a class name or a selector, you get to browse the class or the implementors of the method. Now, most of you know that it does not work on linux :). So I was digging today and I'll share a bit here what I found... First, the navigation through cmd+click is managed by the TextAttribute subclasses, in particular TextLink, TextClassLink and TextMethodLink. And these are the important methods: TextLink>>mayActOnEvent: anEvent ^ anEvent isMouseUp and: [ anEvent commandKeyPressed ] TextClassLink>>actOnClick: anEvent for: target in: aParagraph editor: anEditor anEvent shiftPressed ifFalse: [ anEditor browseClassFrom: self className ] ifTrue: [ anEditor referencesTo: self className ]. ^ true And another similar in TextMethodLink. Now, the first thing I tried was to add a "or: [ anEvent controlKeyPressed ]" into the first method. Guess what? That did not work. So I noticed a weird behavior. - On mac: When you do cmd+click, the text morph, if it was not selected, gets selected on mouse down, and on mouse up it gets deselected and the class is browsed. - On linux: when you do a ctrl+click, the text morph never gets selected on the first place. And that's why it never handles the mouseUp:. Just check: Morph>>handleMouseUp: anEvent "System level event handling." anEvent wasHandled ifTrue: [^self]. "not interested" *==> anEvent hand mouseFocus == self ifFalse: [^self]. "Not interested in other parties"* So... the question is, why is the text morph not getting the focus? Well, it turns out that morphic decodes a Ctrl+click as a blueButton. So in the method Morph>>handlerForMouseDown: the execution differs between mac and linux. And weirder, the event that arrives there, is modified by some strange table that I hate. So the event has a SHIFT, which I didn't press! That shift gets introduced in the event in here: InputEventSensor>>processEvent: evt ... ... type = EventTypeMouse ifTrue: [ "Transmogrify the button state according to the platform's button map definition" * evt at: 5 put: (ButtonDecodeTable at: (evt at: 5) + 1).* "Map the mouse buttons depending on modifiers" * evt at: 5 put: (self mapButtons: (evt at: 5) modifiers: (evt at: 6)).* So much FUN! Well, so far I do not know how to solve it. But I know I do not like the "One table to decode strangely bits that should work for all platforms but it works just for one of them" approach :) I'll try to follow this later, but if someone wants to help, I welcome it :) Guille

Aug. 18, 2014

Re: [Pharo-dev] Quitting the community

by Esteban A. Maringolo

2014-08-18 6:55 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > I'd say that we now have: > Camillo - pissed off to death > Ben - same > Nico - gone > > There is something amiss there. > > These people are significant contributors and made the system move forward > in new and much needed directions (Zeroconf/CommandLine, Spec, Amber). > Pissing them off is really a bad approach, no matter why/how/... Get the > house in order please and stop the ego trips. Yelling at people/each other > just doesn't work and doesn't help. Try that at your cat. In my own interest I'd like all parties settle down and continue working to make Pharo advance. Pharo should advance whether people love or hate Stephane (or whoever is in the board). > Oh, yeah, it helps in pushing great people to other communities... As we needed that. > And now, I am feeling sad. Same feeling here. We can't afford losing valuable contributors. But also if this is the result of something, it is not very different to how Pharo started (and also other "forks" not only in the Smalltalk community). > At the same time, none of this kind of thing ever prevented progress. > I guess you can remember the dual hierarchies in previous version of Pharo... > Pharo itself came to life because we wanted progress. > Now, we attract people who want to do things differently. > And then are surprised that they want to do just that. > Who got named "Random Refactorers"? Remember that? And calling people names? How I see it, Pharo as a project is in a perpetual struggle about what you mention, because: A) It is building everything it can to let new developers flourish without a central authority B) It still is "design by committee" at a large extent. The outcome of this struggle is going to be next turning point (for better or for worse). Progress in point A is evident, and I can understand why B is still current (community size). Nowadays it feels "ministerial" a lot , and it's our own fault to look to Pharo (as an organization) every time we have a need. A "take it or leave it" situation. Or more like "a take it or fork it" ;-) Esteban A. Maringolo

Aug. 18, 2014