- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Lowering the pain of newbies

by Peter UhnÃ¡k

I'd prefer to not use `setName:` nor `setClassName:` as `setX:`/`setX:Y:` is often used as a constructor initialization pattern (as per Kent Beck's Smalltalk book). Using `className:` could be confusing, as it could be unclear whether you are changing the name of the class itself, or the name of the class of the class (the "Class class" class :)). Maybe `changeNameTo:` to explicitly state the intent? > It indirectly becomes some sort of "reserved word" of the language. Class has many such methods (and I've destroyed my image many times before I subconsciously learned to avoid them), but only name tends to be problematic so introducing "special" methods for meta methods seems pointless, as a person doing metaprogramming would (must) take the care anyway to distinguish on which side they are working on. Peter On Mon, Aug 21, 2017 at 3:08 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I avoid get/set prefixes in method selectors, however it is a "good > practice pattern" the use of the "set" prefix as a private accessor. > > I use it to build initialized instances, > > MyClass class>>#attribute: anObject > ^self new setAttribute: aString > > In some cases MyClass doesn't have the `#attribute:` setter because > it's not meant to be modified externally. > > In the case of the `name` setter for a class, adding the `class` > prefix is redundant, so I think that `setName:` is the right selector > to use. > > It's like the Clipboard class, that has the `clipboardText:` selector > instead of `text:` or something similar, but without the redundant > `clipboard` prefix. > > But without diverting from the main topic, I think that the `name` > accessor is one of the things that causes a lot of trouble because of > unanticipated side effects. It indirectly becomes some sort of > "reserved word" of the language. > > Also `name` is a common property in many domain objects, and creating > the accessors will create name:/name1 selectors, which is confusing > for newcomers as well, because they'd expect the #name getter instead > of #name1. > > Regards, > > Esteban A. Maringolo > > > 2017-08-21 9:42 GMT-03:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > > its inconsistent to start using (set) in front of the name of methods and > > unnecessary > > > > className: > > > > makes more sense to me > > > > Another way to do this instead have something like classMetaData which > can > > be a dictionary containing all the data like name of the class, method > > dictionary etc this way we ensure that what happened with name does not > > happen with other methods too that may find themselves in a name > conflict by > > an unaware user. > > > > Or we can provide both ways or something else. > > > > Class name has caused me pain too and I am no newbie , when I was making > an > > API for Blender it clashed with the name of the 3d objects. So this is > > definitely not newbie orientated problem , its a fundamental problem. > > > > I dont mind which solution you guys follow , afterall its easy to solve > > cause its easy to override any solution I don't like. The beauty of > > Smalltalk :) > > > > On Mon, Aug 21, 2017 at 11:05 AM Marcus Denker <marcus.denker(a)inria.fr> > > wrote: > >> > >> > >> > On 20 Aug 2017, at 23:48, Brad <bsselfridge(a)gmail.com> wrote: > >> > > >> > I vote for setClassName: > >> > > >> > >> setName: is better because this is what is there since many many yearsâ¦ > >> and by just using it > >> we must need to deprecate one method, not two. > >> > >> Marcus > >

Aug. 21, 2017

Re: [Pharo-dev] TechTalk Dates for the rest of 2017

by Alexandre Bergel

> I'm not sure Pharo tech talk is the good place but would love to see such a presentation. > > Maybe you can do a Google or Twitch live video about that ? Sure! I am open to ideas :-) Alexandre > > EnvoyÃ© de mon iPhone > >> Le 21 aoÃ»t 2017 Ã 18:38, Alexandre Bergel <alexandre.bergel(a)me.com> a Ã©crit : >> >> Hi! >> >> I am currently giving a lecture on Neural Networks and Genetic Algorithm/Programming. >> Maybe I could turn this into an express 2 hours mini-lecture. Would this work? >> >> Anyone is interesting in programming, from scratch, a small artificial intelligence? >> >> Cheers, >> Alexandre >> >> >>> On Aug 21, 2017, at 10:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> Hi, >>> >>> We have added dates for tech talk discussions / Demos for the rest of 2017: >>> https://association.pharo.org/events >>> >>> We need to find some topics. In the past we had often formal âtalksâ or demos about >>> a topic with discussion afterwards, but a more relaxed form of just an open discussion >>> about a topic is possible, too, >>> >>> If you like to lead one of the dates (all but the November dates are available still), this >>> would be great. >>> >>> If a date does find a topic, we keep it as an open discussion round. >>> >>> Marcus >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >

Aug. 21, 2017

Re: [Pharo-dev] TechTalk Dates for the rest of 2017

by serge.stinckwich＠gmail.com

I'm not sure Pharo tech talk is the good place but would love to see such a presentation. Maybe you can do a Google or Twitch live video about that ? EnvoyÃ© de mon iPhone > Le 21 aoÃ»t 2017 Ã 18:38, Alexandre Bergel <alexandre.bergel(a)me.com> a Ã©crit : > > Hi! > > I am currently giving a lecture on Neural Networks and Genetic Algorithm/Programming. > Maybe I could turn this into an express 2 hours mini-lecture. Would this work? > > Anyone is interesting in programming, from scratch, a small artificial intelligence? > > Cheers, > Alexandre > > >> On Aug 21, 2017, at 10:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> We have added dates for tech talk discussions / Demos for the rest of 2017: >> https://association.pharo.org/events >> >> We need to find some topics. In the past we had often formal âtalksâ or demos about >> a topic with discussion afterwards, but a more relaxed form of just an open discussion >> about a topic is possible, too, >> >> If you like to lead one of the dates (all but the November dates are available still), this >> would be great. >> >> If a date does find a topic, we keep it as an open discussion round. >> >> Marcus > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Aug. 21, 2017

Re: [Pharo-dev] TechTalk Dates for the rest of 2017

by Alexandre Bergel

Hi! I am currently giving a lecture on Neural Networks and Genetic Algorithm/Programming. Maybe I could turn this into an express 2 hours mini-lecture. Would this work? Anyone is interesting in programming, from scratch, a small artificial intelligence? Cheers, Alexandre > On Aug 21, 2017, at 10:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > We have added dates for tech talk discussions / Demos for the rest of 2017: > https://association.pharo.org/events > > We need to find some topics. In the past we had often formal âtalksâ or demos about > a topic with discussion afterwards, but a more relaxed form of just an open discussion > about a topic is possible, too, > > If you like to lead one of the dates (all but the November dates are available still), this > would be great. > > If a date does find a topic, we keep it as an open discussion round. > > Marcus -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 21, 2017

TechTalk Dates for the rest of 2017

by Marcus Denker

Hi, We have added dates for tech talk discussions / Demos for the rest of 2017: https://association.pharo.org/events <https://association.pharo.org/events> We need to find some topics. In the past we had often formal âtalksâ or demos about a topic with discussion afterwards, but a more relaxed form of just an open discussion about a topic is possible, too, If you like to lead one of the dates (all but the November dates are available still), this would be great. If a date does find a topic, we keep it as an open discussion round. Marcus

Aug. 21, 2017

Re: [Pharo-dev] Lowering the pain of newbies

by Esteban A. Maringolo

I avoid get/set prefixes in method selectors, however it is a "good practice pattern" the use of the "set" prefix as a private accessor. I use it to build initialized instances, MyClass class>>#attribute: anObject ^self new setAttribute: aString In some cases MyClass doesn't have the `#attribute:` setter because it's not meant to be modified externally. In the case of the `name` setter for a class, adding the `class` prefix is redundant, so I think that `setName:` is the right selector to use. It's like the Clipboard class, that has the `clipboardText:` selector instead of `text:` or something similar, but without the redundant `clipboard` prefix. But without diverting from the main topic, I think that the `name` accessor is one of the things that causes a lot of trouble because of unanticipated side effects. It indirectly becomes some sort of "reserved word" of the language. Also `name` is a common property in many domain objects, and creating the accessors will create name:/name1 selectors, which is confusing for newcomers as well, because they'd expect the #name getter instead of #name1. Regards, Esteban A. Maringolo 2017-08-21 9:42 GMT-03:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > its inconsistent to start using (set) in front of the name of methods and > unnecessary > > className: > > makes more sense to me > > Another way to do this instead have something like classMetaData which can > be a dictionary containing all the data like name of the class, method > dictionary etc this way we ensure that what happened with name does not > happen with other methods too that may find themselves in a name conflict by > an unaware user. > > Or we can provide both ways or something else. > > Class name has caused me pain too and I am no newbie , when I was making an > API for Blender it clashed with the name of the 3d objects. So this is > definitely not newbie orientated problem , its a fundamental problem. > > I dont mind which solution you guys follow , afterall its easy to solve > cause its easy to override any solution I don't like. The beauty of > Smalltalk :) > > On Mon, Aug 21, 2017 at 11:05 AM Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> >> > On 20 Aug 2017, at 23:48, Brad <bsselfridge(a)gmail.com> wrote: >> > >> > I vote for setClassName: >> > >> >> setName: is better because this is what is there since many many yearsâ¦ >> and by just using it >> we must need to deprecate one method, not two. >> >> Marcus

Aug. 21, 2017

Re: [Pharo-dev] Lowering the pain of newbies

by Dimitris Chloupis

its inconsistent to start using (set) in front of the name of methods and unnecessary className: makes more sense to me Another way to do this instead have something like classMetaData which can be a dictionary containing all the data like name of the class, method dictionary etc this way we ensure that what happened with name does not happen with other methods too that may find themselves in a name conflict by an unaware user. Or we can provide both ways or something else. Class name has caused me pain too and I am no newbie , when I was making an API for Blender it clashed with the name of the 3d objects. So this is definitely not newbie orientated problem , its a fundamental problem. I dont mind which solution you guys follow , afterall its easy to solve cause its easy to override any solution I don't like. The beauty of Smalltalk :) On Mon, Aug 21, 2017 at 11:05 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 20 Aug 2017, at 23:48, Brad <bsselfridge(a)gmail.com> wrote: > > > > I vote for setClassName: > > > > setName: is better because this is what is there since many many yearsâ¦ > and by just using it > we must need to deprecate one method, not two. > > Marcus >

Aug. 21, 2017

[ Pharo 70 ] Build 51 PR 214 Matrix-Trivial-typo-fix

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/20326/Matrix-Trivial-typo-fix https://github.com/pharo-project/pharo/pull/214

Aug. 21, 2017

[ Pharo 70 ] Build 50 PR 215 Rubric-line-numbers-are-not-dark-theme-friendly

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/18172/Rubric-line-numbers-are-not-dark-th… https://github.com/pharo-project/pharo/pull/215

Aug. 21, 2017

Re: [Pharo-dev] Latest Debian, Ubuntu and CentOS packages of the pharo-vm

by Norbert Hartl

For the .deb based distributions the adding of the repo is missing. This would be for Ubuntu 16.04 echo "deb http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/x… ./" > /etc/apt/sources.list.d/pharo.list Ubuntu 14.04 echo "deb http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/x… ./" > /etc/apt/sources.list.d/pharo.list Debian 8 Ubuntu 16.04 echo "deb http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/D… ./" > /etc/apt/sources.list.d/pharo.list As nobody noticed I'm not sure if this is really needed ;) Feedback is highly appreciated! Norbert > Am 18.08.2017 um 11:54 schrieb Holger Freyther <holger(a)freyther.de>: > > Hi, > > when running Pharo in production you might want to install the image and a VM from distribution packages. So far there were no current public packages and during the last months I have modernized the debian packaging and recently added CentOS rpm packaging as well. The process of generating new source packages is integrated into the pharo-vm travis-ci build as well. > > Every time that master of pharo-vm.git is updated a new source package will be uploaded to the Open(SUSE) Build Service and new packages will be built and are available in a "latest" package feed. The generated (and used) sourcecode is inside the source package and will be archived by the OBS platform (one can even nicely diff versions). The "stable" VM is not built from pharo-vm.git (yet?) so it doesn't show on OBS yet. > > Below are some semi-tested installation notes in case you want to try it out. The binary names are picked to allow to install the 32bit and 64bit VM in parallel. The names currently are: > > - pharo6-32 (32bit version) > - pharo6-64 (64bit version) > - pharo6-32-ui (32bit version with X11 dependencies) > - pharo6-64-ui (64bit version with X11 dependencies) > > > CentOS 6.8: > > # Add the repo > $ yum-config-manager --add-repo http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/C… > > # Install 32bit packages (with X11 dependency for *-ui or not) > > $ yum install pharo6-32-ui.i686 or pharo6-32.i386 > > # Install 64bit packages > > $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64 > > > > CentOS 7 (only 64bit): > > > $ yum-config-manager --add-repo http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/C… > $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64 > > > Debian 8: > > # Add signing key > $ wget -O - http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/D… | apt-key add - > > # Update and install > $ apt update > $ apt install pharo6-32-ui pharo6-64-ui (or pharo6-32 or pharo6-64) > > Ubuntu 14.04 LTS > > # Add signing key > $ wget -O - http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/x… | apt-key add - > > # Update and install > $ apt update > $ apt install pharo6-32-ui pharo6-64-ui > > Ubuntu 16.04 > > # Add signing key > $ wget -O - http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/x… | apt-key add - > > # Update and install > $ apt update > $ apt install pharo6-32-ui pharo6-64-ui

Aug. 21, 2017