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

Re: [Pharo-dev] Dark Theme in Pharo 4

by Esteban Lorenzano

using #installFullTheme? thatâs super weirdâ¦ after all, Pharo4 is almost Pharo3 now, and I just merged inâ¦ Esteban On 28 May 2014, at 19:01, kilon alios <kilon.alios(a)gmail.com> wrote: > I don't know if you are aware of this, even though dark theme is integrated in Pharo 4 I see several problems that I dont have with my Pharo 3 install of Dark theme. > > 1) Pharo background appears still white > > 2) Code completion has also white background > > 3) fonts appear black in workspace and inside methods code. > > > Most likely you are aware of this and I realise that Pharo 4 just started but I decided to report just in case. > > Just for the record Rubric workspace also has issues with Dark Theme.

May 28, 2014

Dark Theme in Pharo 4

by kilon alios

I don't know if you are aware of this, even though dark theme is integrated in Pharo 4 I see several problems that I dont have with my Pharo 3 install of Dark theme. 1) Pharo background appears still white 2) Code completion has also white background 3) fonts appear black in workspace and inside methods code. Most likely you are aware of this and I realise that Pharo 4 just started but I decided to report just in case. Just for the record Rubric workspace also has issues with Dark Theme.

May 28, 2014

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

by Nicolas Cellier

2014-05-28 22:49 GMT+02:00 stepharo <stepharo(a)free.fr>: > > On 26/5/14 23:07, 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 :) > >> >> 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 >> >> >> > > -1 The sole purpose of categories is to provide backward compatibility support, or am I mistaken? If it's for backward compatibility, why the hell rename it? We have #categories -> #realCategories (to avoid bogus --all-- inclusion) and now -> #protocols That's way too much erraticity. If the purpose is driving buts people caring of package management and cross dialect compatibility, then +1, it's a successfull path ;) I know, I know, Pharo values clean API - protocols ;) - more than compatibility, but cleaning a message dedicated to compatibility somehow sounds too much. If you opt for protocols, at least, please remove --all--

May 28, 2014

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

by Nicolas Cellier

2014-05-28 22:24 GMT+02:00 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net >: > Hey Philippe, > > > Yes but #= is blissfully unaware of normalization in Squeak/Pharo. In >> fact AFAIK Squeak/Pharo is unaware of normalization. Having a short look >> at it doesn't even look as if case insensitivity worked in Squeak/Pharo >> outside of Latin-1 (I could be wrong though). >> > > Yes, that's what I am thinking about. To be more explicit, suppose > "Unicode" series of characters got into the image via the keyboard, a file, > a socket... once decoded, what could one do with them? Are all types of > decoded character series going to be represented as instances of a single > class, although they have inherently different behavior? > > I've got some changes pending to use Unicode for case insensitivity in Squeak, if it's urgent i can publish now... But since Eliot is working on Character representation in Spur, i decided to wait a little bit. Normalization is really a complex beast. There was an attempt by Yoshiki (CombinedChar) to correctly render the most simple composition sequences in now dead MultiCharacter* classes. We decided to remove this incomplete support and postponed the rewrite for later... (since we would need canonical representation in other places, it's better to separate it...) The CombinedChar utility is still there but unused in rendering. It is used in UnicodeCompositionStream which is used in ParagraphEditor>>readKeyboard (yes the st80 one!) Pharo 3.0 has a UTF8DecomposedTextConverter, but that's far less general, is using CombinedChar and is unused in base. > > In addition you probably don't want #= to do normalization "because >> performance". And even if you did you probably still want a fast path >> for ByteString receiver and ByteString argument in which case #size is >> safe. >> > > Assuming all fixed width representation strings (e.g. byte strings) will > always have the same encoding (e.g. same code page), then the size check > for those seems ok to me. > > Just to make sure, I am not celebrating all this complexity in the > world... however, given that it's there, how are we going to deal with it? > I'm concerned about the long term consequences of making things more > complex than they are by reinterpreting them. The problem I see is that > ultimately programs just won't Work(TM). > > Andres. > > Sure, Unicode is aggregating centuries of history from the whole word, how could it be simple... Our support is really bare minimum.

May 28, 2014

Re: [Pharo-dev] Bad naming: users

by stepharo

On 26/5/14 14:52, Stephan Eggermont wrote: > Hmm, how do I make sure the changes are applied in the right order? > Do I need to split the change in multiple slices, or is there an easier way? multiple slices is the way to go. > > Stephan > >

May 28, 2014

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

by stepharo

On 26/5/14 23:07, 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 :) > > 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 28, 2014

Re: [Pharo-dev] Request write access to Pharo40Inbox

by Attila Magyar

I created a slice (SLICE-Issue-13272-No-temporary-to-instvar-suggestion) then I tried to save it to the repo below, using the monticello browser. MCHttpRepository location: 'http://smalltalkhub.com/mc/Pharo/Pharo40Inbox/main' user: 'zeroflag' password: '*****' What other details would you like to know? -- View this message in context: http://forum.world.st/Request-write-access-to-Pharo40Inbox-tp4760747p476076… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 28, 2014

Re: [Pharo-dev] Request write access to Pharo40Inbox

by Sean P. DeNigris

Attila Magyar wrote > Hm, it said: 'Could not save version'. Response code is 500. > ZnResponse(500 Internal Server Error text/plain;charset=utf-8 30B) What are the details of the mcz(s) you're trying to commit? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Request-write-access-to-Pharo40Inbox-tp4760747p476076… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 28, 2014

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

by Andres Valloud

Hey Philippe, > Yes but #= is blissfully unaware of normalization in Squeak/Pharo. In > fact AFAIK Squeak/Pharo is unaware of normalization. Having a short look > at it doesn't even look as if case insensitivity worked in Squeak/Pharo > outside of Latin-1 (I could be wrong though). Yes, that's what I am thinking about. To be more explicit, suppose "Unicode" series of characters got into the image via the keyboard, a file, a socket... once decoded, what could one do with them? Are all types of decoded character series going to be represented as instances of a single class, although they have inherently different behavior? > In addition you probably don't want #= to do normalization "because > performance". And even if you did you probably still want a fast path > for ByteString receiver and ByteString argument in which case #size is safe. Assuming all fixed width representation strings (e.g. byte strings) will always have the same encoding (e.g. same code page), then the size check for those seems ok to me. Just to make sure, I am not celebrating all this complexity in the world... however, given that it's there, how are we going to deal with it? I'm concerned about the long term consequences of making things more complex than they are by reinterpreting them. The problem I see is that ultimately programs just won't Work(TM). Andres.

May 28, 2014

Re: [Pharo-dev] PharoVM building with Pharo3

by Nicolas Cellier

Good work and thanks for sharing! IMO, answering the pseudo category '--all--' among regular categories was really a design mistake of Pharo 3.0 and should better be reverted. Message #categories has been designed as a compatibility layer, but it is not really compatible. The current workaround is to replace it with a new alternate message #realCategories. If we have to patch each and every external package (not counting base image patches like https://pharo.fogbugz.com/f/cases/13093/File-Out-save-each-method-twice-Fro…) this is kind of ruining the idea of compatibility and gives extra work to everybody and un-necessary break compatibility with Squeak. 2014-05-28 20:24 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > I adapted sources for generating VM to build with Pharo3 (so we stay in > sync). > > https://ci.inria.fr/pharo/view/4.0-VM/ > > and even wrote a post about it :P > > http://smallworks.eu/web/blog/2014-05-28-generate-vm-with-pharo3 > > cheers, > Esteban > > ps: there is a small problem with windows builds, but thatâs not because > of the problem but some clean needed in the jenkins slave >

May 28, 2014