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

Re: [Pharo-dev] 3.0 git tracker

by Tudor Girba

Hi, Nice. Is there a way to use this infrastructure for other projects? Cheers, Doru On May 18, 2013, at 2:31 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Pharo 3.0 is now properly tracked on github > > - https://github.com/pharo-project/pharo-core > - the update messages are properly shown > - html output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc… > - diff output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc… > - patch output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc… -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

May 18, 2013

3.0 git tracker

by Camillo Bruni

Pharo 3.0 is now properly tracked on github - https://github.com/pharo-project/pharo-core - the update messages are properly shown - html output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc… - diff output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc… - patch output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc…

May 18, 2013

Re: [Pharo-dev] Penelope does not like my email...

by Ciprian Teodorov

Cool... did not know that thanks On Fri, May 17, 2013 at 10:57 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > on gmail address, dots are pointless :) > > If you send a mail at c.i.p.r.i.a.n.t.e.o.d.o.r.o.v(a)gmail.com, you will > receive it :) > As well as ciprianteodorov(a)gmail.com > > Try it :) > > Ben > > On May 17, 2013, at 10:50 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> > wrote: > > Hi guys, > > Some time ago there were some issues with email addresses with dot... are > they solved? > Today I've tried (again) to register with penelope and Invalid email > address. > > My email is: ciprian.teodorov(a)gmail.com > Can I use it or do I have to have a dot-less one? > > cheers, > Ciprian > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro > > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

May 17, 2013

Re: [Pharo-dev] Penelope does not like my email...

by Benjamin

on gmail address, dots are pointless :) If you send a mail at c.i.p.r.i.a.n.t.e.o.d.o.r.o.v(a)gmail.com, you will receive it :) As well as ciprianteodorov(a)gmail.com Try it :) Ben On May 17, 2013, at 10:50 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Hi guys, > > Some time ago there were some issues with email addresses with dot... are they solved? > Today I've tried (again) to register with penelope and Invalid email address. > > My email is: ciprian.teodorov(a)gmail.com > Can I use it or do I have to have a dot-less one? > > cheers, > Ciprian > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro

May 17, 2013

Penelope does not like my email...

by Ciprian Teodorov

Hi guys, Some time ago there were some issues with email addresses with dot... are they solved? Today I've tried (again) to register with penelope and Invalid email address. My email is: ciprian.teodorov(a)gmail.com Can I use it or do I have to have a dot-less one? cheers, Ciprian -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

May 17, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by Igor Stasenko

On 17 May 2013 20:56, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-05-17, at 20:48, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 17 May 2013 09:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> On May 16, 2013, at 11:53 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> On 15 May 2013 09:37, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>> On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> >>>>>> How did you loaded NBOpenGL? >>>>>> For 2.0/3.0 pharo image use >>>>>> (ConfigurationOfNBOpenGL project version: '2.0') load >>>>> >>>>> I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) >>>>> It would be a lot better to make >>>>> >>>>> ConfigurationOfNBOpenGL load. >>>>> >>>> >>>> unless you put a lot of complex logic behind that "load", >>>> it will never work. >>> >>> Why? >>> load should be >>> >>> ConfigurationOfNBOpenGL class>>#load >>> ^ self project stableVersion load. >>> >>> and nothing else >> >> the problem is that #stableVersion for 2.0 >> and #stableVersion for 1.4 may differ >> as well as dependencies.. in 1.4 there is no NB loaded, while 2.0 have >> it by default. > > > you can easily do that: > > stable: spec > <symbolicVersion: #stable > > > spec for: #'pharo1.4' version: '100'. > spec for: #'pharo2.0' version: '200'. > spec for: #'pharo3.0' version: '300'. > thanks. (it is still a case statement, but not so ugly however ;) > > -- Best regards, Igor Stasenko.

May 17, 2013

Re: [Pharo-dev] Small Methods dont need comments , true or myth ?

by Igor Stasenko

On 17 May 2013 18:56, Chris Muller <asqueaker(a)gmail.com> wrote: > On Fri, May 17, 2013 at 6:27 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: >> I really enjoy smalltalk, every small thing that I discover every day. >> >> But there is one thing that really annoys me. The bold claim that small >> functions do not need comments. >> There is of course a level of truth that when a function/methods is well >> formated and follows the common logic >> rules of readable code a comment should not be needed for what it takes 10 >> lines or less of code to explain. >> >> But then that is also an illusion. >> >> The problem is that the code never explains the why. And why can be very >> important in understanding the code. > > You are right that comments should explain the "why" and not the > "what". But not every single tiny little method needs to explain the > "why" of its existence. Do you think hundreds and hundreds of > #initialize methods need to explain themselves with a comment? I > don't. > >> Also a big issue I have with smalltalk in general. All this spaggeti mess I >> see unfold before my eyes in every library I see. >> One method calling another method which calls (excuse me, I should have said >> "sends a message") another and before >> you know you forget where you started and where is the end. Its the >> definition of Code Labyrinth. All this hectic browsing >> around could have been avoided so easily with a single comment. > > Your frustration about use of the Composed Method pattern is due to a > tool shortage, not a shortage of comments. Above, you're talking > about getting "lost" as you trace through senders and implementors. > When each sender/implementor either opens up a whole pane or, in some > cases, a whole new window, then yes, it's very easy to get "lost" and > forget where what you were doing due to following side-tracks. > > That's why I use Squeak's MessageTrace, it handles this better than > anything else in any Smalltalk. It is a "lightweight" way, in terms > of gestures and UI elements, to trace through code without getting > lost. I wish Pharo would consider implementing a tool like this. > So, propose it! How I (or other pharo developers) can consider something, which they never heard about? I joined Squeak in 2006, still never heard about it when using Squeak, not saying about pharo.. I actually get used to use browsers with minimal feature set, because over the years, i used many different images with many (non-working/half-broken) things.. so i developed habit to not even try advanced features :) >> I would like to note here that I am also a big fan of small methods and that >> my question is not related to whether methods >> should be kept small and readable but whether comments are really needed for >> those methods. > > Consulting Kent Beck's book, "Smalltalk Best Practice Patterns", page > 40, on the "Method Comment" pattern. Kent suggests the percentage of > methods that should need commenting is "between 0 and 1 percent." He > continues about why on page 41: > > "Regardless of how well the system as a whole is put together, > the big picture cannot easily be read method by method. There has to > be another way of teaching the reader about the system as a whole." > +1 > That's exactly what MessageTrace does. It shows the "big picture" of > what's going on simply by arrowing up and down through the trace and > reading the code. > > Comments are a human labor. They take time to write and time to > read/ignore. Therefore, too many comments will actually *detract* > from the quality and producitivity of a system if they're redundant, > ambiguous, or sometimes even wrong, and making the code messy and hard > to read. If, instead, we can design good-enough tools to _present_ > the code model in a way that can be easily understood, then we don't > need to labor over writing/reading comments except any more than 1% of > the time. > again, +1 Today, i practicing putting a decent documentation in class comments, describing the "why", "how" and "don't" altogether. > Cheers, > Chris -- Best regards, Igor Stasenko.

May 17, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by Camillo Bruni

On 2013-05-17, at 20:48, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 17 May 2013 09:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> On May 16, 2013, at 11:53 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> On 15 May 2013 09:37, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>> On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>>> How did you loaded NBOpenGL? >>>>> For 2.0/3.0 pharo image use >>>>> (ConfigurationOfNBOpenGL project version: '2.0') load >>>> >>>> I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) >>>> It would be a lot better to make >>>> >>>> ConfigurationOfNBOpenGL load. >>>> >>> >>> unless you put a lot of complex logic behind that "load", >>> it will never work. >> >> Why? >> load should be >> >> ConfigurationOfNBOpenGL class>>#load >> ^ self project stableVersion load. >> >> and nothing else > > the problem is that #stableVersion for 2.0 > and #stableVersion for 1.4 may differ > as well as dependencies.. in 1.4 there is no NB loaded, while 2.0 have > it by default. you can easily do that: stable: spec <symbolicVersion: #stable > spec for: #'pharo1.4' version: '100'. spec for: #'pharo2.0' version: '200'. spec for: #'pharo3.0' version: '300'.

May 17, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by Igor Stasenko

On 17 May 2013 09:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On May 16, 2013, at 11:53 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 15 May 2013 09:37, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> How did you loaded NBOpenGL? >>>> For 2.0/3.0 pharo image use >>>> (ConfigurationOfNBOpenGL project version: '2.0') load >>> >>> I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) >>> It would be a lot better to make >>> >>> ConfigurationOfNBOpenGL load. >>> >> >> unless you put a lot of complex logic behind that "load", >> it will never work. > > Why? > load should be > > ConfigurationOfNBOpenGL class>>#load > ^ self project stableVersion load. > > and nothing else the problem is that #stableVersion for 2.0 and #stableVersion for 1.4 may differ as well as dependencies.. in 1.4 there is no NB loaded, while 2.0 have it by default. > >> That's why i prefer to giving a version numbers. This version of >> config works with 2.0 image, >> and no pain, no surprises. >> Now, when people get used to do "ConfigurationOfNBOpenGL load" >> it is less pain, but just for the next major update of whatever >> infrastructural parts in Pharo. > > again... why? > Because what happens now is that people try to do what is the convention for metacello. Also, that means that by not following the conventions, NBOpenGL will never be able to be loaded through configuration browser :( > hmm, why i cannot specify in config browser that for given version of image use this version of library? >> >> And second, for me, as developer , it is much more helpful to deal >> with problem reports like: >> "this version doesn't loads/works with this version of image" >> instead of "i tried and it doesn't works" :) > > he, I'm sorry, I disagree... > If you as a developer promote a version as a release by assigning a #stable symbolic version to configuration, you know exactly which version the guy is trying to load. > And you will not have the problem "this version does not loads...", which is a consequence of not declaring a version as stable for a platform. Looks to me that the problem you try to avoid is in fact happening because the configuration is not adapted to the convention, not the opposite :) > As proof... lot's of complex project follow the convention (seaside, for example), and nobody has the issue you say. Recently they prepared the configuration for 2.0, and that means that seaside now loads fine in 1.4 and 2.0.... > Okay, then i will ask you to help making it working for 2.0 an 3.0 (we can ignore 1.4 i think). And here again, how you propose to deal with situation that i wanna discontinue support for 1.4 (so , if you do just #load, in 1.4 image it won't work, because latest #stable version does not supports that version of Pharo anymore).. Now if you specify exact version which still supports 1.4 you can load and use it. So, what is your recipe for this situation? Writing case statements? MyConfig>>stableVersion Smalltalk version = 1.4 ifTrue: [ ^ '0.4' ]. Smalltalk version = 2.0 ifTrue: [ ^ '0.8' ]. Smalltalk version = 3.0 ifTrue: [ ^ '1.8' ]. i can do that, if you insist.. but that IMO, defeats purpose of using Metacello. Because once you start with adding ugly if/case statements, they will tend to grow larger and larger over time.. and we end up with something like linux configure scripts.. > cheers, > Esteban > -- Best regards, Igor Stasenko.

May 17, 2013

Re: [Pharo-dev] [update 3.0] #30143

by Marcus Denker

On May 17, 2013, at 6:48 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > it broke the Pharo Kernel 3.0 job: > > ... > > So I'll try to put Opal into the Kernel :-) > Yes, this is the way to goâ¦ we want to make the old compiler unloadable and for that a lot of methods that are now extension methods of compiler have to be movedâ¦. Marcus

May 17, 2013