July 2013 - Pharo-dev - lists.pharo.org

utf8 in mcz (SmalltalkHub)

by Goubier Thierry

Has someone seen something happening with Monticello Mcz handling extended characters ? If I add a non-ascii character to MCMockClassA comment, such as Ã¸, then MCMczInstallerTest>>testInstallFromFile fails. If I add an ascii character instead to MCMockClassA comment, then this test pass. (On 2.0 / 20610) It's recent and has appeared between mid-june and now. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 4, 2013

[update 3.0] #30254

by Marcus Denker

30254 ----- 7492 Convert MetacelloConfigurationBrowser to Spec https://pharo.fogbugz.com/f/cases/7492 11056 Traits in _UnpackagedPackage https://pharo.fogbugz.com/f/cases/11056 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1168.diff

July 4, 2013

Re: [Pharo-dev] We did it! SlotClassBuilder is active

by Sebastian Tleye

Congrats!! This opens more doors to me since i we can have stateful traits now :) 2013/7/4 Damien Cassou <damien.cassou(a)gmail.com> > On Thu, Jul 4, 2013 at 11:17 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > > +1 for the blog post. I don't have too much to say of the plans for > > the future but I could write about the current state of the project. > > > yes please, current state description is already great. You may want > to write it in Pier format so that we get a nice chapter. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

July 4, 2013

[update 3.0] #30253

by Marcus Denker

30253 ----- 10936 Athens update (was: As yet unclassified) https://pharo.fogbugz.com/f/cases/10936 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Morphic-MarcusDenker.1… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Core-MarcusDenker.33.d… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-CairoPools-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Cairo-MarcusDenker.44.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Athens-Balloon-MarcusDenker.1…

July 4, 2013

Re: [Pharo-dev] Abbreviations

by Camillo Bruni

On 2013-07-04, at 12:52, Torsten Bergmann <astares(a)gmx.de> wrote: > Usually I thought only the C/C++ people fell in love with abbreviations - but > now its our own community: > > in Pharo 3.0 one can write: > > Smalltalk os env actually that #env there is more complicated than you think :) - `Smalltalk os` returns OSPlatform, the class - implementing #environment on the class side will break the compiler for this class My first attempt was of course to use #environment as a name, which failed horribly ;) So first we have to complete the refactoring that `Smalltalk os` returns an instance of OSPlatform. Only then we can move to #environment, which by looking at #OSEnvironment is the intended name. So all in all you detected the symptoms of a much worse problem, using class-sides instead of instances. In any case, I agree that #env is not nice at all...

July 4, 2013

R: Abbreviations

by Lorenzo Schiavina

+1 -----Messaggio originale----- Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Max Leske Inviato: giovedÃ¬ 4 luglio 2013 12:58 A: Pharo Development List Oggetto: Re: [Pharo-dev] Abbreviations I agree wholeheartedly! I still believe in (mostly) self documenting code and that cannot be achieved by using abbreviations. Max On 04.07.2013, at 12:52, Torsten Bergmann <astares(a)gmx.de> wrote: > Usually I thought only the C/C++ people fell in love with > abbreviations - but now its our own community: > > in Pharo 3.0 one can write: > > Smalltalk os env > > or would it be better to use: > > Smalltalk operatingSystem environment > > in the future? > > So is the current > > Smalltalk vm > > better than > > Smalltalk virtualMachine > > I know: even a newcomer should know what "OS" means. At least > Smalltalkers/Java people should know they need a "VM". But nonetheless > I think a common goal would be to keep Pharo code and method selectors readable and avoid abbreviations when possible. > > Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: > (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" > which does not use abbreviations) > > Should we care (with an issue) and use the more readable forms in the > future and deprecated the abbreviation forms? > > Or will we keep abbreviations for the lazy and easier typing? > > If you comment please think about the goal to get readable code, the > goal to get more newcomers into programming and your own first steps > with Smalltalk and IT ... > > > > >

July 4, 2013

Re: [Pharo-dev] Abbreviations

by Max Leske

On 04.07.2013, at 13:09, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote: > >> Usually I thought only the C/C++ people fell in love with abbreviations - but >> now its our own community: >> >> in Pharo 3.0 one can write: >> >> Smalltalk os env >> >> or would it be better to use: >> >> Smalltalk operatingSystem environment >> >> in the future? >> >> So is the current >> >> Smalltalk vm >> >> better than >> >> Smalltalk virtualMachine >> >> I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should >> know they need a "VM". But nonetheless I think a common goal would be to keep >> Pharo code and method selectors readable and avoid abbreviations when possible. >> >> Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: >> (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" >> which does not use abbreviations) >> >> Should we care (with an issue) and use the more readable forms in >> the future and deprecated the abbreviation forms? >> >> Or will we keep abbreviations for the lazy and easier typing? >> >> If you comment please think about the goal to get readable code, the goal to >> get more newcomers into programming and your own first steps with Smalltalk >> and IT ... > > My 2c: > Acronyms work fine, also in method names. (os, vm) > As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit â¦ zealous. Agreed. There are conventional terms that can (and maybe should) be abbreviated. But in general I'm against abbreviations. > > Simple abbreviations, like env, rather than using the full word, I have much less empathy for. > > Cheers, > Henry

July 4, 2013

Re: [Pharo-dev] Abbreviations

by Norbert Hartl

Am 04.07.2013 um 13:09 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote: > >> Usually I thought only the C/C++ people fell in love with abbreviations - but >> now its our own community: >> >> in Pharo 3.0 one can write: >> >> Smalltalk os env >> >> or would it be better to use: >> >> Smalltalk operatingSystem environment >> >> in the future? >> >> So is the current >> >> Smalltalk vm >> >> better than >> >> Smalltalk virtualMachine >> >> I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should >> know they need a "VM". But nonetheless I think a common goal would be to keep >> Pharo code and method selectors readable and avoid abbreviations when possible. >> >> Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: >> (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" >> which does not use abbreviations) >> >> Should we care (with an issue) and use the more readable forms in >> the future and deprecated the abbreviation forms? >> >> Or will we keep abbreviations for the lazy and easier typing? >> >> If you comment please think about the goal to get readable code, the goal to >> get more newcomers into programming and your own first steps with Smalltalk >> and IT ... > > My 2c: > Acronyms work fine, also in method names. (os, vm) > As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit â¦ zealous. > > Simple abbreviations, like env, rather than using the full word, I have much less empathy for. > I like to avoid abbreviations as much as possible. But you are right when it comes to use very common ones I don't have a strong feeling about. To me I think vm and os are widely used so there is nothing to decipher in order to be able to understand it. The selector env I find not commonly used ( I know it mostly from console usage ). And there is Behavior>>#environment which I feel is inconsistent. Norbert

July 4, 2013

Re: [Pharo-dev] Abbreviations

by Norbert Hartl

+ One Norbert Am 04.07.2013 um 12:52 schrieb "Torsten Bergmann" <astares(a)gmx.de>: > Usually I thought only the C/C++ people fell in love with abbreviations - but > now its our own community: > > in Pharo 3.0 one can write: > > Smalltalk os env > > or would it be better to use: > > Smalltalk operatingSystem environment > > in the future? > > So is the current > > Smalltalk vm > > better than > > Smalltalk virtualMachine > > I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should > know they need a "VM". But nonetheless I think a common goal would be to keep > Pharo code and method selectors readable and avoid abbreviations when possible. > > Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: > (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" > which does not use abbreviations) > > Should we care (with an issue) and use the more readable forms in > the future and deprecated the abbreviation forms? > > Or will we keep abbreviations for the lazy and easier typing? > > If you comment please think about the goal to get readable code, the goal to > get more newcomers into programming and your own first steps with Smalltalk > and IT ... > > > > >

July 4, 2013

Re: [Pharo-dev] Abbreviations

by Henrik Johansen

On Jul 4, 2013, at 12:52 , Torsten Bergmann wrote: > Usually I thought only the C/C++ people fell in love with abbreviations - but > now its our own community: > > in Pharo 3.0 one can write: > > Smalltalk os env > > or would it be better to use: > > Smalltalk operatingSystem environment > > in the future? > > So is the current > > Smalltalk vm > > better than > > Smalltalk virtualMachine > > I know: even a newcomer should know what "OS" means. At least Smalltalkers/Java people should > know they need a "VM". But nonetheless I think a common goal would be to keep > Pharo code and method selectors readable and avoid abbreviations when possible. > > Also there are Pharo methods like #getEnv: instead of #getEnvironmentVariable: > (interesting that they wrap the native C/C++ API "GetEnvironmentVariableA" > which does not use abbreviations) > > Should we care (with an issue) and use the more readable forms in > the future and deprecated the abbreviation forms? > > Or will we keep abbreviations for the lazy and easier typing? > > If you comment please think about the goal to get readable code, the goal to > get more newcomers into programming and your own first steps with Smalltalk > and IT ... My 2c: Acronyms work fine, also in method names. (os, vm) As a basic rule require to spell out ante meridiem, light amplification by stimulated emission of radiation, radio detection and ranging, compact disk, and their likes, seems a bit â¦ zealous. Simple abbreviations, like env, rather than using the full word, I have much less empathy for. Cheers, Henry

July 4, 2013