September 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Reflectivity: Links that de-install themselves (oneShot)

by stepharo

Marcus I have a API design question when you offer options: #(optionOneShot); versus optionOneShot Do you do a perform of the arrays selectors? What is the benefit of options: STef Le 16/9/15 08:52, Marcus Denker a Ã©crit : > Hi, > > This is just a one-liner to add to the framework, but that makes it even more fun: One-Shot links. > > A link now can have the #optionOneShot, which means that it will de-install itself when activated for > the first time: > > link := MetaLink new > metaObject: self; > options: #(optionOneShot); > selector: #tagExec. > > The full test looks like this: > > testLinkOneShot > | sendNode link | > sendNode := (ReflectivityExamples>>#exampleMethod) sendNodes first. > link := MetaLink new > metaObject: self; > options: #(optionOneShot); > selector: #tagExec. > sendNode link: link. > self assert: sendNode hasMetalink. > self assert: tag isNil. > self assert: (ReflectivityExamples new exampleMethod = 5). > self assert: (tag = #yes). > self deny: sendNode hasMetalink. > tag := nil. > self assert: (ReflectivityExamples new exampleMethod = 5). > self assert: tag isNil. > > > https://pharo.fogbugz.com/f/cases/16581/one-shot-links > > Marcus >

Sept. 18, 2015

Re: [Pharo-dev] Rubric/Event handling issue?

by Stephan Eggermont

On 15-09-15 17:49, Stephan Eggermont wrote: > There is an interesting bad interaction between my drag-and-drop code > and Rubric. It kills all Rubric editors at the same time, so it looks > to me like a problem with the Rubric background thread interacting with > mouseMove or mouseEnter/Leave. > > https://vimeo.com/139353992 I've removed the video. As noted by Henrik in 'RubAbstractTextArea copying', a RubScrolledTextMorph cannot be safely copied, which can be seen by opening the halos on a playground's edit space and trying to duplicate the morph. Stephan

Sept. 18, 2015

Re: [Pharo-dev] RubAbstractTextArea copying

by Stephan Eggermont

On 18-09-15 22:52, Henrik Nergaard wrote: > It does not seem that RubScrolledTextMorph supports duplication/copy (tried to duplicate one from nautilus code area and the same clear all code happened. Trying to duplicate a Playground just freezes the image (might be some circular references that is not handled when copying )). > > Anyway: this code works ish.. (does not add unaccepted edits) > > CodeCard>>#duplicate > | newCard | > > newCard := self class new. > newCard > selector: self selector; "must be before selectedClass" > selectedClass: self selectedClass; > updateCodeWith: self textModel text. > self activeHand attachMorph: newCard. "attachMorph: is nicer than grabMorph: :)" > selected := false. > self changed. > Thanks Henrik. I'm slowly getting to the finer points of Morphic. Stephan

Sept. 18, 2015

Re: [Pharo-dev] RubAbstractTextArea copying

by Henrik Nergaard

It does not seem that RubScrolledTextMorph supports duplication/copy (tried to duplicate one from nautilus code area and the same clear all code happened. Trying to duplicate a Playground just freezes the image (might be some circular references that is not handled when copying )). Anyway: this code works ish.. (does not add unaccepted edits) CodeCard>>#duplicate | newCard | newCard := self class new. newCard selector: self selector; "must be before selectedClass" selectedClass: self selectedClass; updateCodeWith: self textModel text. self activeHand attachMorph: newCard. "attachMorph: is nicer than grabMorph: :)" selected := false. self changed. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont Sent: Friday, September 18, 2015 6:19 PM To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] RubAbstractTextArea copying On 18-09-15 16:50, Henrik Nergaard wrote: > I looked into the bug a bit and found something strange.... > > | m m2 | > > m := ColorPanel open. > m2 := m submorphs third copy. > m = m2 panel. "prints false; the panel is duplicated " Yes, that is a bug, that should stay the same. > add this method to DragWelL: > > veryDeepInner: deepCopier > super veryDeepInner: deepCopier That seems to work. > Another observation is that after all the text is lost, > if you have a Playground that is effected and try to do > something like: (ColorPanel allInstances size.) it raises > an error 'MessageNotUnderstood: receiver of "style:" is nil' > from "a GLMMorphicPharoPlaygroundRenderer actOnHighlightAndEvaluate: ann" Yes. All editors break. That is independent of the ColorPanel, I've verified with the cloning of cards. I just don't know how I can safely copy a Rubric editor morph. Either directly, or through its textModel. Stephan

Sept. 18, 2015

Re: [Pharo-dev] [ANN]: AconcaguaAddOns

by HernÃ¡n Morales Durand

Hi Sean, First thanks for sharing this. Now I suppose this was AconcaguaDeluxe before? Do you have a ConfigurationOf for AconcaguaAddOns? I want to use it but don't have idea what to load. HernÃ¡n 2015-04-21 13:21 GMT-03:00 Sean P. DeNigris <sean(a)clipperadams.com>: > I pushed some Aconcagua extensions to > http://smalltalkhub.com/mc/SeanDeNigris/AconcaguaAddOns/main/ > > One part consists of tiny (so far) Aconcagua models of various domains - > Time*, Money, and Weight at the moment. > > The other is the Aconcagua-Magritte package. This gives you > MAMeasureDescription, which represents an Aconcagua Measure. It mostly acts > like a number field mapped to its amount. You just have to tell it which > unit to use to convert the amount number into a Measure. > > Example usage: > MAMeasureDescription new > accessor: #replacementPrice; > label: 'Replacement Price'; > unit: AmDollar new; > yourself > > Then, you can type 100 in a Magritte form and "100 dollars" will be saved > to > the model. Enjoy! > > * Yes, I know Chalten has months and years, but (I think when Chalten was > extended to handle non-Gregorian calendars) months and year units are no > longer derived from each other, and so can not be compared. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/ANN-AconcaguaAddOns-tp4820940.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Sept. 18, 2015

Re: [Pharo-dev] RubAbstractTextArea copying

by Stephan Eggermont

On 18-09-15 16:50, Henrik Nergaard wrote: > I looked into the bug a bit and found something strange.... > > | m m2 | > > m := ColorPanel open. > m2 := m submorphs third copy. > m = m2 panel. "prints false; the panel is duplicated " Yes, that is a bug, that should stay the same. > add this method to DragWelL: > > veryDeepInner: deepCopier > super veryDeepInner: deepCopier That seems to work. > Another observation is that after all the text is lost, > if you have a Playground that is effected and try to do > something like: (ColorPanel allInstances size.) it raises > an error 'MessageNotUnderstood: receiver of "style:" is nil' > from "a GLMMorphicPharoPlaygroundRenderer actOnHighlightAndEvaluate: ann" Yes. All editors break. That is independent of the ColorPanel, I've verified with the cloning of cards. I just don't know how I can safely copy a Rubric editor morph. Either directly, or through its textModel. Stephan

Sept. 18, 2015

Re: [Pharo-dev] ANSICompatibility package

by Jan Vrany

On Fri, 2015-09-18 at 23:04 +0800, Ben Coman wrote: > Thanks for your contribution Jan. It is interesting how in > "CompatibilitySmalltalkX class>>initialize" you deal with missing > classes by inserting what are essentially alias into the Smalltalk > dictionary. So, I'm happy I learnt something new today. > > Just curious though why both the class-side and instance-side > #initialize methods set the same alias, but different ways. Well, this is (was) a bug, I by mistake defined the method on instance side (where it makes no sense). The Nautilus UI is rather stupid in that respect, not making clear whether what you see is class side or instance side... > > Also curious why "ClassDescription>>isClass" is blank. It would seem > to need a boolean return value. Accident, should be removed. Both issues fixed in Compatibility-SmalltalkX-JanVrany.11 Thanks for spotting! Jan > > cheers -ben > > On Fri, Sep 18, 2015 at 10:05 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> > wrote: > > Thanks, Ben. Stuff copied. > > > > Cheers, Jan > > > > > > On Fri, 2015-09-18 at 21:54 +0800, Ben Coman wrote: > > > Jan, Thanks for your contribution. Actually I hadn't uploaded > > > anything > > > yet since I was waiting on more votes on renaming, but to push > > > ahead > > > I > > > settled on SmalltalkCompatibility [1], since I think the repo can > > > serve a wider purpose than just ANSI. > > > > > > I added you to the PharoExtras team. Hopefully that works. > > > > > > [1] > > > http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility > > > > > > cheers -ben > > > > > > On Fri, Sep 18, 2015 at 7:10 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz > > > > > > > wrote: > > > > > > > > > > I would rename it to SmalltalkCompatibility to > > > > > > ANSICompatibility > > > > > > because "Compatibility" is a too general term and could > > > > > > mean > > > > > > backward compatibility > > > > > > of Pharo versions or compatibility to other languages as > > > > > > well. > > > > > > > > > > That was me :) I was thinking more broadly that over time > > > > > the > > > > > "repository" might hold different packages Compatibility > > > > > -ANSI, > > > > > Compatibility-VW, Compatibility-Dolphin. But maybe that is > > > > > overreaching and its better to be more focussed. Let me know > > > > > what > > > > > you > > > > > think on this and restate what you think the repository name > > > > > should > > > > > be. > > > > > > > > Ben, could you please give me a commit access? I intend to > > > > move Compatibility-SmalltalkX and Compatibility-ANSI (which > > > > I created and "maintain" for my own need). Maybe some others > > > > may find them useful or maybe even contribute. > > > > > > > > Cheers, Jan > > > > > > > > > > > > > > > Also see http://wiki.squeak.org/squeak/2384 and > > > > > > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32 > > > > > > d338 > > > > > > 9ec > > > > > > which could be a start. > > > > > > > > > > I saw those, but they interact with existing classes, so I > > > > > thought it > > > > > easier to kickstart by loading in the tests first, which are > > > > > all > > > > > new > > > > > classes. I only created the repository since the tests were > > > > > *hard* > > > > > to > > > > > find eventually at > > > > > http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-com > > > > > pati > > > > > bili > > > > > ty/ > > > > > So I thought it would be good make them more accessible as a > > > > > Monticello Package. > > > > > > > > > > cheers -ben > > > > > > > > > > P.S. I don't quite follow "to SmalltalkCompatibility to > > > > > ANSICompatibility" > > > > > do you mean "to SmalltalkCompatibility or ANSICompatibility" > > > > > ? > > > > > > > > > > > > > > > > > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr > > > > > > > Von: stepharo <stepharo(a)free.fr> > > > > > > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > > > > > > Betreff: Re: [Pharo-dev] ANSICompatibility package > > > > > > > > > > > > > > We should have a SmalltalkCompatibility (not Ansi per se) > > > > > > > package > > > > > > > were we can add some methods to help migration. > > > > > > > > > > > > > > Stef > > > > > > > > > > > > > > > > > > > > > Le 8/9/15 06:04, Ben Coman a Ã©crit : > > > > > > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany < > > > > > > > > jan.vrany(a)fit.cvut.cz> wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > is there actually such a thing like ANSICompatibility > > > > > > > > > package? > > > > > > > > > (it has been mentioned here lately, but I cannot find > > > > > > > > > it) > > > > > > > > > > > > > > > > > > Thanks, Jan > > > > > > > > > > > > > > > > > I made it up for the purpose of discussion to see what > > > > > > > > interest > > > > > > > > it generated. > > > > > > > > Should we start one ? > > > > > > > > cheers -ben > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

Sept. 18, 2015

Re: [Pharo-dev] ANSICompatibility package

by Ben Coman

Thanks for your contribution Jan. It is interesting how in "CompatibilitySmalltalkX class>>initialize" you deal with missing classes by inserting what are essentially alias into the Smalltalk dictionary. So, I'm happy I learnt something new today. Just curious though why both the class-side and instance-side #initialize methods set the same alias, but different ways. Also curious why "ClassDescription>>isClass" is blank. It would seem to need a boolean return value. cheers -ben On Fri, Sep 18, 2015 at 10:05 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > Thanks, Ben. Stuff copied. > > Cheers, Jan > > > On Fri, 2015-09-18 at 21:54 +0800, Ben Coman wrote: >> Jan, Thanks for your contribution. Actually I hadn't uploaded >> anything >> yet since I was waiting on more votes on renaming, but to push ahead >> I >> settled on SmalltalkCompatibility [1], since I think the repo can >> serve a wider purpose than just ANSI. >> >> I added you to the PharoExtras team. Hopefully that works. >> >> [1] http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility >> >> cheers -ben >> >> On Fri, Sep 18, 2015 at 7:10 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> >> wrote: >> > >> > > > I would rename it to SmalltalkCompatibility to >> > > > ANSICompatibility >> > > > because "Compatibility" is a too general term and could mean >> > > > backward compatibility >> > > > of Pharo versions or compatibility to other languages as well. >> > > >> > > That was me :) I was thinking more broadly that over time the >> > > "repository" might hold different packages Compatibility-ANSI, >> > > Compatibility-VW, Compatibility-Dolphin. But maybe that is >> > > overreaching and its better to be more focussed. Let me know what >> > > you >> > > think on this and restate what you think the repository name >> > > should >> > > be. >> > >> > Ben, could you please give me a commit access? I intend to >> > move Compatibility-SmalltalkX and Compatibility-ANSI (which >> > I created and "maintain" for my own need). Maybe some others >> > may find them useful or maybe even contribute. >> > >> > Cheers, Jan >> > >> > > >> > > > Also see http://wiki.squeak.org/squeak/2384 and >> > > > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d338 >> > > > 9ec >> > > > which could be a start. >> > > >> > > I saw those, but they interact with existing classes, so I >> > > thought it >> > > easier to kickstart by loading in the tests first, which are all >> > > new >> > > classes. I only created the repository since the tests were >> > > *hard* >> > > to >> > > find eventually at >> > > http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compati >> > > bili >> > > ty/ >> > > So I thought it would be good make them more accessible as a >> > > Monticello Package. >> > > >> > > cheers -ben >> > > >> > > P.S. I don't quite follow "to SmalltalkCompatibility to >> > > ANSICompatibility" >> > > do you mean "to SmalltalkCompatibility or ANSICompatibility" ? >> > > >> > > > >> > > > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr >> > > > > Von: stepharo <stepharo(a)free.fr> >> > > > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> > > > > Betreff: Re: [Pharo-dev] ANSICompatibility package >> > > > > >> > > > > We should have a SmalltalkCompatibility (not Ansi per se) >> > > > > package >> > > > > were we can add some methods to help migration. >> > > > > >> > > > > Stef >> > > > > >> > > > > >> > > > > Le 8/9/15 06:04, Ben Coman a Ã©crit : >> > > > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany < >> > > > > > jan.vrany(a)fit.cvut.cz> wrote: >> > > > > > > Hi, >> > > > > > > >> > > > > > > is there actually such a thing like ANSICompatibility >> > > > > > > package? >> > > > > > > (it has been mentioned here lately, but I cannot find it) >> > > > > > > >> > > > > > > Thanks, Jan >> > > > > > > >> > > > > > I made it up for the purpose of discussion to see what >> > > > > > interest >> > > > > > it generated. >> > > > > > Should we start one ? >> > > > > > cheers -ben >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > >> > > >> > >> >> >

Sept. 18, 2015

Re: [Pharo-dev] RubAbstractTextArea copying

by Henrik Nergaard

Hi Stephan, I looked into the bug a bit and found something strange.... | m m2 | m := ColorPanel open. m2 := m submorphs third copy. m = m2 panel. "prints false; the panel is duplicated " ------------- add this method to DragWelL: veryDeepInner: deepCopier super veryDeepInner: deepCopier and it returns true. Another observation is that after all the text is lost, if you have a Playground that is effected and try to do something like: (ColorPanel allInstances size.) it raises an error 'MessageNotUnderstood: receiver of "style:" is nil' from "a GLMMorphicPharoPlaygroundRenderer actOnHighlightAndEvaluate: ann" Hope this helps Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont Sent: Friday, September 18, 2015 4:09 PM To: pharo-dev(a)lists.pharo.org Subject: [Pharo-dev] RubAbstractTextArea copying I'm trying to understand how to copy a rubric text morph. I don't have a 2nd implementor of #text:textStyle:textColor so how does this work? RubAbstractTextArea>>text: t textStyle: s color: c textColor: tc "Private -- for use only in morphic duplication" self releaseParagraph. super text: t textStyle: s color: c textColor: tc.

Sept. 18, 2015

Re: [Pharo-dev] R: ANSICompatibility package

by Ben Coman

Thanks Lorenzo, but I'm not clear what the offer is... * making VisualSmalltalk compatible with ANSI ? * making Pharo compatible with VisualSmalltalk ? cheers -ben On Fri, Sep 18, 2015 at 10:09 PM, Lorenzo Schiavina <lorenzo(a)edor.it> wrote: > Hi Ben, > > I am available if you want to include VisualSmalltalk into ANSICompatibility package. > I have both full documentation and lot of applications. > > Lorenzo > > -----Messaggio originale----- > Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Ben Coman > Inviato: venerdÃ¬ 18 settembre 2015 15:54 > A: Pharo Development List > Oggetto: Re: [Pharo-dev] ANSICompatibility package > > Jan, Thanks for your contribution. Actually I hadn't uploaded anything yet since I was waiting on more votes on renaming, but to push ahead I settled on SmalltalkCompatibility [1], since I think the repo can serve a wider purpose than just ANSI. > > I added you to the PharoExtras team. Hopefully that works. > > [1] http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility > > cheers -ben > > On Fri, Sep 18, 2015 at 7:10 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> >>> > I would rename it to SmalltalkCompatibility to ANSICompatibility >>> > because "Compatibility" is a too general term and could mean >>> > backward compatibility of Pharo versions or compatibility to other >>> > languages as well. >>> >>> That was me :) I was thinking more broadly that over time the >>> "repository" might hold different packages Compatibility-ANSI, >>> Compatibility-VW, Compatibility-Dolphin. But maybe that is >>> overreaching and its better to be more focussed. Let me know what you >>> think on this and restate what you think the repository name should >>> be. >> >> Ben, could you please give me a commit access? I intend to move >> Compatibility-SmalltalkX and Compatibility-ANSI (which I created and >> "maintain" for my own need). Maybe some others may find them useful or >> maybe even contribute. >> >> Cheers, Jan >> >>> >>> > Also see http://wiki.squeak.org/squeak/2384 and >>> > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d3389ec >>> > which could be a start. >>> >>> I saw those, but they interact with existing classes, so I thought it >>> easier to kickstart by loading in the tests first, which are all new >>> classes. I only created the repository since the tests were *hard* >>> to find eventually at >>> http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compatibili >>> ty/ >>> So I thought it would be good make them more accessible as a >>> Monticello Package. >>> >>> cheers -ben >>> >>> P.S. I don't quite follow "to SmalltalkCompatibility to >>> ANSICompatibility" >>> do you mean "to SmalltalkCompatibility or ANSICompatibility" ? >>> >>> > >>> > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr >>> > > Von: stepharo <stepharo(a)free.fr> >>> > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> > > Betreff: Re: [Pharo-dev] ANSICompatibility package >>> > > >>> > > We should have a SmalltalkCompatibility (not Ansi per se) package >>> > > were we can add some methods to help migration. >>> > > >>> > > Stef >>> > > >>> > > >>> > > Le 8/9/15 06:04, Ben Coman a Ã©crit : >>> > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany < >>> > > > jan.vrany(a)fit.cvut.cz> wrote: >>> > > > > Hi, >>> > > > > >>> > > > > is there actually such a thing like ANSICompatibility >>> > > > > package? >>> > > > > (it has been mentioned here lately, but I cannot find it) >>> > > > > >>> > > > > Thanks, Jan >>> > > > > >>> > > > I made it up for the purpose of discussion to see what interest >>> > > > it generated. >>> > > > Should we start one ? >>> > > > cheers -ben >>> > > > >>> > > > >>> > > >>> > > >>> > > >>> > >>> >>> >> > >

Sept. 18, 2015