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

[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

[pharo-project/pharo-core]

by GitHub

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

Sept. 18, 2015

[pharo-project/pharo-core] 9c0520: 50331

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9c0520696d637781a4d225f3b83f862488b36f6b https://github.com/pharo-project/pharo-core/commit/9c0520696d637781a4d225f3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-18 (Fri, 18 Sep 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50330.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50331.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50330.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50331.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Changes.package/ChangeSet.class/class/defaults/promptForDefaultChangeSetDirectoryIfNecessary.st M System-Changes.package/ManifestSystemChanges.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R System-Changes.package/extension/PositionableStream/instance/nextChunkText.st A Text-Core.package/extension/PositionableStream/instance/nextChunkText.st Log Message: ----------- 50331 16594 System-Changes should not depend on Text-Core https://pharo.fogbugz.com/f/cases/16594 http://files.pharo.org/image/50/50331.zip

Sept. 18, 2015

Re: [Pharo-dev] EncodedCharSets

by Nicolas Cellier

Yes, but first step consists in reading http://www.ipa.go.jp/files/000005751.pdf to exactly understand which feature you're going to loose, or better, how you're going to support it differently. Nicolas 2015-09-18 10:10 GMT+02:00 Christophe Demarey <Christophe.Demarey(a)inria.fr>: > Thanks all for your explanations. > It looks like there are still a lot of things to clean. > > Christophe > > Le 17 sept. 2015 Ã 19:26, Eliot Miranda a Ã©crit : > > Hi Christophe, > > On Thu, Sep 17, 2015 at 7:09 AM, Christophe Demarey < > Christophe.Demarey(a)inria.fr> wrote: > >> Hi again, >> >> Does anyone know the rationale behind this? >> >> declareEncodedCharSet: anEncodedCharSetOrLanguageEnvironmentClass >> atIndex: aNumber >> >> EncodedCharSets at: aNumber put: >> anEncodedCharSetOrLanguageEnvironmentClass >> >> "this method is used to modularize the old initialize method: >> EncodedCharSets at: 0+1 put: Unicode. >> EncodedCharSets at: 1+1 put: JISX0208. >> EncodedCharSets at: 2+1 put: GB2312. >> EncodedCharSets at: 3+1 put: KSX1001. >> EncodedCharSets at: 4+1 put: JISX0208. >> EncodedCharSets at: 5+1 put: JapaneseEnvironment. >> EncodedCharSets at: 6+1 put: SimplifiedChineseEnvironment. >> EncodedCharSets at: 7+1 put: KoreanEnvironment. >> EncodedCharSets at: 8+1 put: GB2312. >> EncodedCharSets at: 12+1 put: KSX1001. >> EncodedCharSets at: 13+1 put: GreekEnvironment. >> EncodedCharSets at: 14+1 put: Latin2Environment. >> EncodedCharSets at: 15+1 put: RussianEnvironment. >> EncodedCharSets at: 17+1 put: Latin9Environment. >> EncodedCharSets at: 256 put: Unicode. >> >> " >> > > what Henrik says is correct. Here's the relevant definition in Character: > > Character>>leadingChar > "Answer the value of the 8 highest bits which is used to identify the > language. > This is mostly used for east asian languages CJKV as a workaround against > unicode han-unification." > ^ self asInteger bitShift: -22 > > > i.e. the top 8 bytes of the leading character in a string is (was?) used > to index EncodedCharSets to determine what language the string is in. > > _,,,^..^,,,_ > best, Eliot > > >

Sept. 18, 2015