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

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

by Marcus Denker

>>> >> >> 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 and how to save it in monticelloâ¦ could be interesting to have. > I will try to hack a bit this weekend and see if I can add some kind of automation to marking a class as used. I.e. if you see a critic, you should be able to mark the class as being used with 1-2 clicks. If you are developing some king of facade, you should know that you will not reference it from your library. > ok. Marcus

Sept. 18, 2015

Re: [Pharo-dev] Bitmap VS WordArray in System-Hashing

by Max Leske

> On 18 Sep 2015, at 13:51, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Hi, > > With Max M., we try to kill the dependency between System-Hashing to Graphics - Display Objects. > The dependency is there because SHA1 and SHA256 use the Bitmap class to store raw data. > We came to replace the use of Bitmap by a WordArray. Tests are still working. > > Could someone tell us if this fix is right or if we miss something? > > Thanks, > Max and Christophe Looks good to me. Also: the âtotalsâ variable (which is the bitmap) is never used in SHA-256 (only written once and then assigned nil later). Cheers, Max

Sept. 18, 2015

Bitmap VS WordArray in System-Hashing

by Christophe Demarey

Hi, With Max M., we try to kill the dependency between System-Hashing to Graphics - Display Objects. The dependency is there because SHA1 and SHA256 use the Bitmap class to store raw data. We came to replace the use of Bitmap by a WordArray. Tests are still working. Could someone tell us if this fix is right or if we miss something? Thanks, Max and Christophe

Sept. 18, 2015

Re: [Pharo-dev] ANSICompatibility package

by Jan Vrany

> > 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 5 and method extensions

by roberto.minelli＠usi.ch

Dear all, I just moved to Pharo 5 for development and discovered that it does not correctly show method extensions. I opened a case https://pharo.fogbugz.com/f/cases/16601/Pharo-5-does-not-show-method-extens… Cheers, R

Sept. 18, 2015

Re: [Pharo-dev] Configuration Madness

by roberto.minelli＠usi.ch

Thanks a lot Dale, this works indeed. P.s. Sorry for the delay in the answer but my mailbox went crazy! R > On 16 Sep 2015, at 17:43, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > > On 9/16/15 8:07 AM, Max Leske wrote: >>> On 16 Sep 2015, at 16:39, roberto.minelli(a)usi.ch wrote: >>> >>> Dear all, >>> >>> I have a question about the ConfigurationOf my project, and I really hope you can help. >>> >>> In my project I have a package called âDevFlow-Extensionsâ that is a âplaceholderâ for code that is dependent on the Pharo version. >>> >>> On the ConfigurationOf, according to the Pharo version I do something like >>> >>> spec for: #'pharo3.x' >>> do: [ >>> >>> spec blessing: #baseline. >>> spec repository: 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'. >>> >>> spec package: 'DevFlow-Extensions' with: 'DevFlow-Extensions30'. >>> ]. >>> >>> spec for: #'pharo4.x' >>> do: [ >>> >>> spec blessing: #baseline. >>> spec repository: 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'. >>> >>> spec package: 'DevFlow-Extensions' with: 'DevFlow-Extensions40'. >>> ]. >>> >>> In this way, in Pharo 3.0 Iâd load DevFlow-Extensions30 and in Pharo 4.0 Iâd load DevFlow-Extensions40. Super cool. >>> I am using a single package (âDevFlow-Extensionsâ) to specify of groups, for example: >>> >>> spec group: 'User' with: #( >>> 'DevFlow-Meta' >>> ... >>> 'DevFlow-Announcement' >>> 'DevFlow-Extensions'). >>> >>> Now the problem is that for Pharo 5 I have to load both 'DevFlow-Extensions40â and 'DevFlow-Extensions50â. >>> I read the chapter on Metacello, but didnât find a solution. I tried some combinations of #includes: and #requires: but with no luck. >>> >>> Any help is appreciated, thank you very much! >>> >>> Roberto >> Shouldnât this work? >> >> spec package: 'DevFlow-Extensions' with: #('DevFlow-Extensions40â âDevFlow-Extensions50). >> >> >> > Good idea, but it's not quite correct, I think this will work: > > spec for: #'pharo5.x' > do: [ > spec package: 'DevFlow-Extensions40' . > spec package: 'DevFlow-Extensions50' . > spec group: 'DevFlow-Extensions' with: #('DevFlow-Extensions40â âDevFlow-Extensions50) ]. > > > Dale >

Sept. 18, 2015

Re: [Pharo-dev] EncodedCharSets

by Christophe Demarey

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

Re: [Pharo-dev] About the Unicode class

by Christophe Demarey

Thanks for your answers. I also took a look in Squeak 5.0 but the implementation is also incomplete. I think the best is to remove unused unicode character categories. Le 17 sept. 2015 Ã 18:27, Nicolas Cellier a Ã©crit : > There has been some work on Squeak by Levente in this area, maybe it's time to harvest... > > 2015-09-17 18:22 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> On 17 Sep 2015, at 2:58 , Christophe Demarey <christophe.demarey(a)inria.fr> wrote: >> >> Hi, >> >> Does anyone know why there are so many class variables in Unicode and what they are used for? >> Most of them have no sender. >> >> EncodedCharSet subclass: #Unicode >> instanceVariableNames: '' >> classVariableNames: 'Cc Cf Cn Co Cs DecimalProperty GeneralCategory Ll Lm Lo Lt Lu Mc Me Mn Nd Nl No Pc Pd Pe Pf Pi Po Ps Sc Sk Sm So ToCasefold ToLower ToUpper Zl Zp Zs' >> category: 'Multilingual-Encodings' >> >> Thanks, >> Christophe > > A partial / incomplete / broken implementation of querying character properties, I'd guess. > See for instance: > http://en.wikipedia.org/wiki/Unicode_character_property > http://www.fileformat.info/info/unicode/category/index.htm > > Cheers, > Henry >

Sept. 18, 2015

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

by Stephan Eggermont

On 17-09-15 23:11, Nicolai Hess wrote: > DragWell > startDrag: evt > WorldState addDeferredUIMessage: [ evt hand grabMorph: self copy ]. > > calls > Morph>>#copy > and this makes a veryDeepCopy. > > I don't know exactly how this affects the other rubric text morphs, but > replacing > self copy > with > self shallowCopy > seems to work. Thanks. So there's something wrong with how I hold onto the Rubric text morph and or model. Something shouldn't be copied there. We don't have many examples of using veryDeepCopy and the fixups needed in image, and I'm not sure I fully understand the class comment of DeepCopier :( The clone menu option for a code card does a duplicate, and that creates the same problem as shown with the color panel. In CodeCard I hold onto both the model and the morph. They are connected using announcements, if I understand it correctly? Shouldn't that connection be rewired when doing a copy? Stephan

Sept. 18, 2015

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

by Yuriy Tymchuk

> On 18 Sep 2015, at 08:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> Maybe we can hijack that mechanism with a class side method e.g. >> >> rbNotReferenced >> <lint> >> >> >> Do your modifications test sends of subclassesDo: and friends? >> >> OR >> >> #(#MyClass1 #MyClass2 #MyClass3) collect:[:ea | (Smalltalk at: ea) >> doSomething]. >> >> The reason I ask is I'm planning to do a bunch of cleanup of a package and >> it would be nice to not worry about those cases getting missed >> > > 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. Also is there any work on pragmas for classes, at some point Iâve heard something about it but canât recall. I will try to hack a bit this weekend and see if I can add some kind of automation to marking a class as used. I.e. if you see a critic, you should be able to mark the class as being used with 1-2 clicks. If you are developing some king of facade, you should know that you will not reference it from your library. Uko > > Marcus

Sept. 18, 2015