May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] is ClassOrganization>>#categories right?

by GOUBIER Thierry

________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Marcus Denker [marcus.denker(a)inria.fr] EnvoyÃ© : mardi 27 mai 2014 09:58 Ã : Pharo Development List Objet : Re: [Pharo-dev] is ClassOrganization>>#categories right? On 27 May 2014, at 01:57, Ben Coman <btc(a)openInWorld.com> wrote: > GOUBIER Thierry wrote: >> In my own code, I allways use ClassOrganization>>#realCategories to avoid getting the --all-- category. I consider the --all-- category to be a GUI artifact, not a class organization concept. >> >> I'd prefer a #protocols (without the --all-- category, of course :)) so ok for deprecating #categories. >> > +1 for #protocols returning protocol objects, not symbolsâ¦ Up to you, just that it is consistent... protocol objects everywhere, or symbols everywhere. #categories for symbols, #protocols for protocol objects (and #addCategory: for symbols, #addProtocol: for protocols, and so on...). A subject for the Pharo Sprint planned by Serge in Paris in two weeks time ? Thierry Marcus

May 27, 2014

Re: [Pharo-dev] String >> #=

by Marcus Denker

On 27 May 2014, at 09:44, Philippe Marschall <philippe.marschall(a)netcetera.ch> wrote: > On 27.05.14 06:45, Eliot Miranda wrote: >> >> >> >> >> Hi Phillipe, >> >> >> On Mon, May 26, 2014 at 12:51 AM, Philippe Marschall >> <philippe.marschall(a)netcetera.ch >> <mailto:philippe.marschall@netcetera.ch>> wrote: >> >> Hi >> >> I have been investigating why Dictionary look up performance with >> String keys is not as good as I would expected. Something I noted is >> that String >> #= is implemented in terms of >> #compare:with:collated:. There is no short circuit if Strings are >> not the same size. In my case some Strings have the same prefix but >> a different length eg 'Content-Type' and 'Content-Length'. In that >> case a #compare:with:collated: is performed even though we know in >> advance the answer will be false because they have different sizes. >> >> >> Why not rewrite > > Yes, that would be my proposal as well. > Ok, I have added an issue: https://pharo.fogbugz.com/f/cases/13277/Speed-up-String Marcus

May 27, 2014

Re: [Pharo-dev] is ClassOrganization>>#categories right?

by Marcus Denker

On 27 May 2014, at 01:57, Ben Coman <btc(a)openInWorld.com> wrote: > GOUBIER Thierry wrote: >> In my own code, I allways use ClassOrganization>>#realCategories to avoid getting the --all-- category. I consider the --all-- category to be a GUI artifact, not a class organization concept. >> >> I'd prefer a #protocols (without the --all-- category, of course :)) so ok for deprecating #categories. >> > +1 for #protocols returning protocol objects, not symbolsâ¦ Marcus

May 27, 2014

Re: [Pharo-dev] String >> #=

by Philippe Marschall

On 27.05.14 06:45, Eliot Miranda wrote: > > > > > Hi Phillipe, > > > On Mon, May 26, 2014 at 12:51 AM, Philippe Marschall > <philippe.marschall(a)netcetera.ch > <mailto:philippe.marschall@netcetera.ch>> wrote: > > Hi > > I have been investigating why Dictionary look up performance with > String keys is not as good as I would expected. Something I noted is > that String >> #= is implemented in terms of > #compare:with:collated:. There is no short circuit if Strings are > not the same size. In my case some Strings have the same prefix but > a different length eg 'Content-Type' and 'Content-Length'. In that > case a #compare:with:collated: is performed even though we know in > advance the answer will be false because they have different sizes. > > > Why not rewrite Yes, that would be my proposal as well. Cheers Philippe

May 27, 2014

Re: [Pharo-dev] is ClassOrganization>>#categories right?

by Yuriy Tymchuk

and +1 for me. On 27 May 2014, at 01:57, Ben Coman <btc(a)openInWorld.com> wrote: > GOUBIER Thierry wrote: >> In my own code, I allways use ClassOrganization>>#realCategories to avoid getting the --all-- category. I consider the --all-- category to be a GUI artifact, not a class organization concept. >> >> I'd prefer a #protocols (without the --all-- category, of course :)) so ok for deprecating #categories. >> > +1 for #protocols >> Thierry >> ________________________________________ >> De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Esteban Lorenzano [estebanlm(a)gmail.com] >> EnvoyÃ© : lundi 26 mai 2014 21:20 >> Ã : Pharo Development List >> Objet : [Pharo-dev] is ClassOrganization>>#categories right? >> >> Hi, >> >> I wonder is current implementation of that method is good: right now, it answers all categories, including virtual ones (âallâ). >> A lot of things are made in that assumption, but I wonder if is not better to answer just real categories and to create a new method called #allCategories to answer the reals and the virtuals. >> >> Also, I wonder if wouldnât be better to just deprecate #categories and use the correct abstraction: #protocols. >> >> any opinions? >> >> Esteban >> >> >> > > >

May 27, 2014

Re: [Pharo-dev] String >> #=

by Eliot Miranda

Hi Phillipe, On Mon, May 26, 2014 at 12:51 AM, Philippe Marschall < philippe.marschall(a)netcetera.ch> wrote: > Hi > > I have been investigating why Dictionary look up performance with String > keys is not as good as I would expected. Something I noted is that String > >> #= is implemented in terms of #compare:with:collated:. There is no short > circuit if Strings are not the same size. In my case some Strings have the > same prefix but a different length eg 'Content-Type' and 'Content-Length'. > In that case a #compare:with:collated: is performed even though we know in > advance the answer will be false because they have different sizes. > Why not rewrite String>>= aString "Answer whether the receiver sorts equally as aString. The collation order is simple ascii (with case differences)." aString isString ifFalse: [ ^ false ]. ^ (self compare: self with: aString collated: AsciiOrder) = 2 as String>>= aString "Answer whether the receiver sorts equally as aString. The collation order is simple ascii (with case differences)." (aString isString and: [self size = aString size]) ifFalse: [^false]. ^ (self compare: self withSize: with: aString collated: AsciiOrder) = 2 ? One /could/ add a replacement compare:with:collated: primitive primitiveCompareString which took the sizes as arguments to avoid asking twice. But it wouldn't be safe. One could abuse the primitive and lie about the size. So I suspect it is best to add the size check to String>>#= and accept the duplication of the primitive finding the sizes of the two strings. The cost in the primitive is minimal. A WideString version of the primitive might pay its way, but if Spur and Sista arrive soon the primitive shouldn't be faster than the optimised Smalltalk code. -- best, Eliot

May 27, 2014

[bug?] SUnit shows wrong test result when Warning subclass signals on a test case method

by Masashi UMEZAWA

Hi all, I wrote this simple test case, but the result is always 'yellow' even if assertions are right (.st code attached). MyHtmlParserWarningTestCase>>testParserWarning1 | warning | warning := MyHtmlParserWarning new. self assert: (warning category isNil). self assert: (warning reason isEmpty). warning signal: #malformed reason: 'no close tag'. self assert: (warning category = #malformed). self assert: (warning reason = 'no close tag'). I think it is a bug on SUnit, so I put the issue 13242 on fogbugz. https://pharo.fogbugz.com/f/cases/13242/ I confirmed it is reproduced in Pharo 3.0.image and the latest image (Pharo-40000.image). Best regards, -- [:masashi | ^umezawa]

May 27, 2014

Re: [Pharo-dev] is ClassOrganization>>#categories right?

by Ben Coman

GOUBIER Thierry wrote: > In my own code, I allways use ClassOrganization>>#realCategories to avoid getting the --all-- category. I consider the --all-- category to be a GUI artifact, not a class organization concept. > > I'd prefer a #protocols (without the --all-- category, of course :)) so ok for deprecating #categories. > +1 for #protocols > Thierry > ________________________________________ > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Esteban Lorenzano [estebanlm(a)gmail.com] > EnvoyÃ© : lundi 26 mai 2014 21:20 > Ã : Pharo Development List > Objet : [Pharo-dev] is ClassOrganization>>#categories right? > > Hi, > > I wonder is current implementation of that method is good: right now, it answers all categories, including virtual ones (âallâ). > A lot of things are made in that assumption, but I wonder if is not better to answer just real categories and to create a new method called #allCategories to answer the reals and the virtuals. > > Also, I wonder if wouldnât be better to just deprecate #categories and use the correct abstraction: #protocols. > > any opinions? > > Esteban > > >

May 26, 2014

Re: [Pharo-dev] is ClassOrganization>>#categories right?

by GOUBIER Thierry

In my own code, I allways use ClassOrganization>>#realCategories to avoid getting the --all-- category. I consider the --all-- category to be a GUI artifact, not a class organization concept. I'd prefer a #protocols (without the --all-- category, of course :)) so ok for deprecating #categories. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Esteban Lorenzano [estebanlm(a)gmail.com] EnvoyÃ© : lundi 26 mai 2014 21:20 Ã : Pharo Development List Objet : [Pharo-dev] is ClassOrganization>>#categories right? Hi, I wonder is current implementation of that method is good: right now, it answers all categories, including virtual ones (âallâ). A lot of things are made in that assumption, but I wonder if is not better to answer just real categories and to create a new method called #allCategories to answer the reals and the virtuals. Also, I wonder if wouldnât be better to just deprecate #categories and use the correct abstraction: #protocols. any opinions? Esteban

May 26, 2014

Re: [Pharo-dev] what happened with ZipWriteStream class>>#crcTable ?

by Max Leske

On 26.05.2014, at 20:52, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I wonder what happen with that methodâ¦ why it was removed? no need of it? I removed that a while ago (see history of Compression package, MaxLeske.127). The crc table is now part of the CRC package and ZipWriteStream uses CRC. Cheers, Max > > Esteban

May 26, 2014