- Pharo-dev - lists.pharo.org

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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50332 Home: https://github.com/pharo-project/pharo-core

Sept. 18, 2015

[pharo-project/pharo-core] 0f5bc4: 50332

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 0f5bc4ad3988e682b5dcb39d06356ed64e478bde https://github.com/pharo-project/pharo-core/commit/0f5bc4ad3988e682b5dcb39d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-18 (Fri, 18 Sep 2015) Changed paths: M Multilingual-Encodings.package/EncodedCharSet.class/class/class methods/ucsTable.st M Multilingual-Encodings.package/Latin1.class/class/class methods/initialize.st A Multilingual-Encodings.package/Latin1.class/class/class methods/initializeUcsTable.st M Multilingual-Encodings.package/ManifestMultilingualEncodings.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R Multilingual-Encodings.package/UCSTable.class/README.md R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/gb2312Table.st R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/initialize.st R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/initializeLatin1Table.st R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/jisx0208Table.st R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/ksx1001Table.st R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/latin1Table.st R Multilingual-Encodings.package/UCSTable.class/definition.st A Multilingual-Encodings.package/Unicode.class/class/character classification/ucsTable.st M Multilingual-OtherLanguages.package/GB2312.class/class/class methods/initialize.st A Multilingual-OtherLanguages.package/GB2312.class/class/class methods/initializeUcsTable.st R Multilingual-OtherLanguages.package/GB2312.class/class/class methods/ucsTable.st A Multilingual-OtherLanguages.package/JISX0208.class/class/character classification/initializeUcsTable.st M Multilingual-OtherLanguages.package/JISX0208.class/class/class methods/initialize.st R Multilingual-OtherLanguages.package/JISX0208.class/class/class methods/ucsTable.st M Multilingual-OtherLanguages.package/KSX1001.class/class/class methods/initialize.st A Multilingual-OtherLanguages.package/KSX1001.class/class/class methods/initializeUcsTable.st R Multilingual-OtherLanguages.package/KSX1001.class/class/class methods/ucsTable.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50331.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50332.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50331.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50332.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Unicode-Initialization.package/extension/CombinedChar/class/parseCompositionMappingFrom_.st R Unicode-Initialization.package/extension/UCSTable/class/initializeGB2312Table.st R Unicode-Initialization.package/extension/UCSTable/class/initializeJISX0208Table.st R Unicode-Initialization.package/extension/UCSTable/class/initializeKSX1001Table.st Log Message: ----------- 50332 16595 Get rid of UnicodeInitialization in the bootstrap https://pharo.fogbugz.com/f/cases/16595 http://files.pharo.org/image/50/50332.zip

Sept. 18, 2015

R: ANSICompatibility package

by Lorenzo Schiavina

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

RubAbstractTextArea copying

by Stephan Eggermont

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] ANSICompatibility package

by Jan Vrany

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] ANSICompatibility package

by Ben Coman

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

Re: [Pharo-dev] [review needed] speed up RBClassNotReferencedRule

by Jan Vrany

On Fri, 2015-09-18 at 14:48 +0200, Marcus Denker wrote: > > > > > > > > > > What I did is to implement #isUsed like this in e.g the hierarchy > > > of RBLintRule: > > > > > > isUsed > > > "all my sublasses are used" > > > ^self name ~= âRBLintRule' > > > > > > this way if RBLintRule is not used, it is seen by the Critique, > > > but all subclasses > > > are used by default. > > > > > > I implemented that in TestCase, too, and removed the explicit > > > check for TestCase > > > subclasses from the rule. > > > > This is a nice thing. In the same way we can deal with abstract > > classes. So if someone develops an abstract class with an intent to > > use it, he can specify that itâs ok to use the class. > > > > True. > > Also is there any work on pragmas for classes, at some point Iâve > > heard something about it but canât recall. > > > Yes, the question is where to put it syntactically After a class declaration like this: LLVMDisposableObject subclass:#LLVMDIBuilder instanceVariableNames:'' classVariableNames:'' poolDictionaries:'LLVMModuleFlagBehavior' category:'LLVM-S-Core' Annotation key: 'disposable:' value: 'true' This ANSI-compatible way (see page 39 of NCITS J20 DRAFT of ANSI Smalltalk Standard, rev 1.9). Perhaps nice way is Annotation disposable: true > and how to save it in monticelloâ¦ In the source as above. In the binary, in a separate entry in the .zip so the other MC implementation won't crash but silently ignore them.

Sept. 18, 2015