- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] New version of Mocketry 2.3

by Denis Kudriashov

ConfigurationOfTxText should be fixed with new Mocketry version 2014-08-18 14:15 GMT+01:00 stepharo <stepharo(a)free.fr>: > Thanks a lot Denis! > Now TxText should load without any problems. > > Igor ? > > Stef > > > On 18/8/14 12:46, Denis Kudriashov wrote: > > Hello. > > Some of you ask me to adopt Mocketry for Pharo 4. Done. > > Gofer it > smalltalkhubUser: 'dionisiy' project: 'Mocketry'; > package: 'ConfigurationOfMocketry'; > load. > > (Smalltalk at: #ConfigurationOfMocketry) load. > > Best regards, > Denis > > >

Aug. 18, 2014

Re: [Pharo-dev] Get not accepted text from TextModel

by ClÃ©ment Bera

Hello Yuriy, you can do: aTextModel spec instance widget textMorph text. I am not sure there is an easier way to get this non accepted text. 2014-08-18 13:28 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi, > > TextModel has getText, but it only gives you text that was accepted. Can I > get somehow text that is just there? > > Uko >

Aug. 18, 2014

Re: [Pharo-dev] New version of Mocketry 2.3

by stepharo

Thanks a lot Denis! Now TxText should load without any problems. Igor ? Stef On 18/8/14 12:46, Denis Kudriashov wrote: > Hello. > > Some of you ask me to adopt Mocketry for Pharo 4. Done. > > Gofer it > smalltalkhubUser: 'dionisiy' project: 'Mocketry'; > package: 'ConfigurationOfMocketry'; > load. > > (Smalltalk at: #ConfigurationOfMocketry) load. > > Best regards, > Denis

Aug. 18, 2014

Re: [Pharo-dev] New version of Mocketry 2.3

by Tudor Girba

Excellent! Thanks a lot, Doru On Mon, Aug 18, 2014 at 12:46 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > Some of you ask me to adopt Mocketry for Pharo 4. Done. > > Gofer it > smalltalkhubUser: 'dionisiy' project: 'Mocketry'; > package: 'ConfigurationOfMocketry'; > load. > > (Smalltalk at: #ConfigurationOfMocketry) load. > > Best regards, > Denis > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 18, 2014

Re: [Pharo-dev] Quitting the community

by phil＠highoctane.be

On Mon, Aug 18, 2014 at 12:20 PM, stepharo <stepharo(a)free.fr> wrote: > Ben, > > I'm sad about your decision and I think that it is a bit biaised against > me. > Your statements are your point of view and I will not argue with you. > > Now for the others I got a disagreement on the rename of ValueHolder into > ReactiveVariable (see my reasons below) > as referred here > - https://github.com/spec-framework/spec/issues/16 > - https://pharo.fogbugz.com/default.asp?13824 I let you judge. > This thread is also useful and Nice raises the legacy issue: http://forum.world.st/COTDC-108-NewValueHolder-td4738066.html > For me the picture at the end of https://pharo.fogbugz.com/ > default.asp?13824 tells a lot on your state of mind and I do not think > that this is a > good state of mind to work in an open-source community. > Would there be a way to get a two-way apology/shake of hands by getting carried too far on a minor concern and move on from there? Feelings have been hurt. No one ever heals from misplaced pride and ego issues. Life is short. > I think that we can have disagreements with other people and we can > discuss but it seems that it became difficult to discuss with you recently > and this is sad. (Members of the rmod team still did not get why you left > the team without saying bye to them). > > Here are my reasons: > > - I do not want that people can say that innovation in Pharo is just > by renaming existing concepts. The concept of ValueHolder is the basis of > VisualWorks. Spec is > influenced by the application model of VisualWorks and valueHolder. So > using this name is recognizing its influence. When people using VW will > come to Pharo they > should not think that too and they should not get lost. > > - Stephan Eggermont mentioned in addition that > - Reactive variable is a concept from reactive programming. For > the record > - Value Holder is a pattern described by Bobby Woolf in 1994 in > http://c2.com/ppr/vmodels.html and referred to in much of the pattern > literature. > > - The books of X. Briffault, Bernard Horan, Tim Howard, Ivan Tomek, > plus all the tutorial and docs of VisualWorks are using ValueHolder. > Probably more but I did not have the time to check. > > - I programmed since some of you in VW since 1998 and telling that > the books we used are obsolete does not help because there are still > accurate. > > - Now if Spec would be an external library that can be loaded in > Pharo, I would not care and you could use any name want. But Spec is part > of Pharo and Spec is > based on my ideas too. So I would a bit of care to be taken. > > I imagine that you can understand my point. I really wish I would not have > to write such mail. I'm immensely sad. > There is a powerful movement going on with all things "Reactive". (Meteor comes to mind). Of course, ppl want to get these things. Especially in the UI space like Spec. Younger guns are of course drawn to it. It is hopeless to think that there will be no tension there. And yes, we are a kind of fashion industry. Isn't Pharo going to be innovative and taking in the new stuff ? ValueHolder is a known thing. It is frankly not more sensical that ReactiveVariable. Of course, now, we understand it. But when it first started, it could have been a lot of other names. In Java, it is an interface... http://docs.oracle.com/javaee/6/api/javax/faces/component/ValueHolder.html Look at Seaside's DynamicVariables... not that super clear when encountered at first. Are they really what Lisp calls Dynamic Variables? In 3.0 NewValueHolder is with this in the class comment: / ! \ IMPORTANT / ! \ NewValueHolder will soon be replaced by ReactiveVariable ============================================= Within Spec itself, NewValueHolder has been renamed to ReactiveVariable (during the beta phase of Pharo 3). Since Pharo 3 was already in beta, NewValueHolder has been kept untouched. For new code (and all code in future versions of Pharo), use the following two hook methods: asReactiveVariable - use wherever you would have used asValueHolder, which will soon be deprecated. For now, it returns a NewValueHolder. In the future it will return a (polymorphic) ReactiveVariable selectionReactiveVariable - as above, returns a SelectionValueHolder for now. This extension method allows the two different packages to coexist without having direct references from the Spec model. ... A variable that emits announcements when changed looks quite reactive indeed. Of course a couple of things are using the NewValueHolder (Roassal2Spec, GT-Inspector) But subclasses of NewValueHolder: CollectionValueHolder, DictonaryValueHolder, IdentityNewValueHolder (yikes!), SelectionValueHolder This is confusing. 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? https://groups.yahoo.com/neo/groups/squeak/conversations/messages/109404 > Related links: > - https://github.com/spec-framework/spec/issues/16 > - https://pharo.fogbugz.com/default.asp?13824 > > > Yeah, the pic at the end is an ad hominem. There is a ton of such things. http://coolhaus.de/art-of-controversy/ Too bad we ended up on http://coolhaus.de/art-of-controversy/erist38.htm so fast. On Spec itself, we got good stuff. Like docs. http://spec.st/ And getting this to go GPLv3 is going to hurt. https://github.com/spec-framework/spec/blob/master/LICENSE-GPL3 MIT is a big plus for Pharo tech. This is a bad precedent. Phil > > > > On 18/8/14 08:38, Benjamin 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 >> >> > >

Aug. 18, 2014

New version of Mocketry 2.3

by Denis Kudriashov

Hello. Some of you ask me to adopt Mocketry for Pharo 4. Done. Gofer it smalltalkhubUser: 'dionisiy' project: 'Mocketry'; package: 'ConfigurationOfMocketry'; load. (Smalltalk at: #ConfigurationOfMocketry) load. Best regards, Denis

Aug. 18, 2014