April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Cog doesn't load anymore in PharoCore1.3 because of the removal of AbstractLauncher

by Mariano Martinez Peck

If Cog really needs it we should create a separate repostiroy like PharoCogSupport and put the class there and add it as a dependency of Cog in ConfigurationOfCog. Another hacky way is to add a #preLoadDoit: in ConfigurationOfCog that does a #compile: of AbstractLauncher Cheers Mariano On Sun, Apr 24, 2011 at 7:37 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > AbstractLauncher was removed in: > http://code.google.com/p/pharo/issues/detail?id=4002 > > Cog has a subclass from AbstractLauncher called CommandLineLauncher, hence, > it cannot be loaded anymore > > CommandLineLauncher has no class comment and no sender. So I have no idea > what it does, nor if it can be removed from cog, nor how to solve this > problem in Pharo. > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

April 24, 2011

[Pharo-project] new template for class empty comments for OB

by StÃ©phane Ducasse

Hi lukas could you add the following in OB for missing template http://code.google.com/p/pharo/issues/detail?id=4090 templateOn: aStream aStream nextPutAll: theClass name; nextPutAll: ' has not been documented yet. The class comment should describe the purpose of the class, its collaborations and its variables. '. aStream nextPutAll: 'We encourage you to fill up the following template.'; cr;cr. aStream nextPutAll: 'Class intention';cr ; tab. aStream nextPutAll: 'I''m doing the following ...';cr;cr. aStream nextPutAll: 'Class collaborations'; cr;tab. aStream nextPutAll: 'I usually do not work in isolation but with the help of ...'; cr ;cr . aStream nextPutAll: 'Class main API'; cr; tab. aStream nextPutAll: 'My main public API is ...'. aStream nextPutAll: 'My subclasses may want to override such specific hooks ...'; cr. aStream nextPutAll: 'Implementation notes';cr. self templateLabel: 'Instance Variables:' class: theClass variables: theClass instVarNames on: aStream. self templateLabel: 'Class Instance Variables:' class: theClass class variables: theClass class instVarNames on: aStream I did the same for the default browser. Stef

April 24, 2011

[Pharo-project] Cog doesn't load anymore in PharoCore1.3 because of the removal of AbstractLauncher

by Mariano Martinez Peck

AbstractLauncher was removed in: http://code.google.com/p/pharo/issues/detail?id=4002 Cog has a subclass from AbstractLauncher called CommandLineLauncher, hence, it cannot be loaded anymore CommandLineLauncher has no class comment and no sender. So I have no idea what it does, nor if it can be removed from cog, nor how to solve this problem in Pharo. Cheers -- Mariano http://marianopeck.wordpress.com

April 24, 2011

Re: [Pharo-project] What is a well documented class?

by Michael Forster

On Sun, Apr 24, 2011 at 11:17 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> Â - each public method belongs to a method category named public* >>> Â - each private method belongs to a method category named private* >> >> Others here may disagree -- and the dreary of legislating and >> enforcing conventions aside -- but I strive (usually with success) to >> move all privately-used methods to one or more delegates. Â One class's >> private method is just another's public??? > > A private method may have to access instances variables. Moving the method to another class may be difficult sometimes. All the more reason to move it! A private method accessing instance variables is just global-variable-oriented spaghetti programming disguised by a class. Such a method is just begging to be moved to a delegate and to accept the instance var values as arguments. >>> Â - other methods are considered as "package visible", meaning that they belong to a category that does not begins with 'private' or 'public' >> >> Again, I sympathise with facing the visibility problem, but I don't >> trust that conventions will be upheld by either end, so I tire of >> following them. Â Replace Pharo/Squeak categories with Newspeak >> modules; replace Pharo/Squeak protocols with traits (stateless, >> please); I'll be the first in line. > > I do not think this should be enforced. It is easy to infer method visibility with a set of well defined scenarios, for example the one that comes in unit tests. You can't infer reliably from such shaky premises, whether they are manifest as conventions or unit tests. Cheers, Mike

April 24, 2011

Re: [Pharo-project] Help updating confs and building Pharo 1.3

by Alexandre Bergel

> Yes, but some packages/projects do NOT have author...so someone needs to do it anyway ;) > And another good thing is to start testing your OWN projects on top of Pharo 1.3 now. Not necessary what is included in the dev. So that we can spot problems right now. Ok. > What are the conf where I am personally involved? Out of my memory there is MemoryMonitor. Is there more? > > > Maybe with Metacello and ProfStef ? > For example, for Metacello, if we need to include the MetacelloBrowser, but do I need to include in the baseline of ConfigurationOfPharo ? I will take care of the bug with ProfStef. Dale prefers to wait a bit before for the browser. So, let's wait. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 24, 2011

Re: [Pharo-project] What is a well documented class?

by Alexandre Bergel

> give a try and see. I think that this is important. Yes it is. > We can even publish something out of it :) That's a side effect that cannot be avoided :-) Alexandre > > On Apr 24, 2011, at 6:17 PM, Alexandre Bergel wrote: > >>>> - each public method belongs to a method category named public* >>>> - each private method belongs to a method category named private* >>> >>> Others here may disagree -- and the dreary of legislating and >>> enforcing conventions aside -- but I strive (usually with success) to >>> move all privately-used methods to one or more delegates. One class's >>> private method is just another's public??? >> >> A private method may have to access instances variables. Moving the method to another class may be difficult sometimes. >> >>>> - other methods are considered as "package visible", meaning that they belong to a category that does not begins with 'private' or 'public' >>> >>> Again, I sympathise with facing the visibility problem, but I don't >>> trust that conventions will be upheld by either end, so I tire of >>> following them. Replace Pharo/Squeak categories with Newspeak >>> modules; replace Pharo/Squeak protocols with traits (stateless, >>> please); I'll be the first in line. >> >> I do not think this should be enforced. It is easy to infer method visibility with a set of well defined scenarios, for example the one that comes in unit tests. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 24, 2011

Re: [Pharo-project] Help updating confs and building Pharo 1.3

by Alexandre Bergel

Hi Mariano, > What I need is that people: > > - update all the confs that are not yet updated to work on Pharo 1.3 > - test them > - report if there are problems. I am not sure how I can help you. I think that this is the responsibility of the author to take care of this. What are the conf where I am personally involved? Out of my memory there is MemoryMonitor. Is there more? It would be cool to have a page that says what are the responsibilities of each of us. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 24, 2011

Re: [Pharo-project] What is a well documented class?

by Schwab,Wilhelm K

Public/private categories would a lot of sense if methods could belong to more than one category. Dolphin allows that, and it's *really* nice. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Sunday, April 24, 2011 12:37 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] What is a well documented class? On Apr 24, 2011, at 6:49 PM, Alexandre Bergel wrote: >> give a try and see. I think that this is important. > > Yes it is. > >> We can even publish something out of it :) > > That's a side effect that cannot be avoided :-) ;-) so even better. > > Alexandre > >> >> On Apr 24, 2011, at 6:17 PM, Alexandre Bergel wrote: >> >>>>> - each public method belongs to a method category named public* >>>>> - each private method belongs to a method category named private* >>>> >>>> Others here may disagree -- and the dreary of legislating and >>>> enforcing conventions aside -- but I strive (usually with success) to >>>> move all privately-used methods to one or more delegates. One class's >>>> private method is just another's public??? >>> >>> A private method may have to access instances variables. Moving the method to another class may be difficult sometimes. >>> >>>>> - other methods are considered as "package visible", meaning that they belong to a category that does not begins with 'private' or 'public' >>>> >>>> Again, I sympathise with facing the visibility problem, but I don't >>>> trust that conventions will be upheld by either end, so I tire of >>>> following them. Replace Pharo/Squeak categories with Newspeak >>>> modules; replace Pharo/Squeak protocols with traits (stateless, >>>> please); I'll be the first in line. >>> >>> I do not think this should be enforced. It is easy to infer method visibility with a set of well defined scenarios, for example the one that comes in unit tests. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

April 24, 2011

Re: [Pharo-project] Error with latest ProfStef in Pharo 1.3

by Alexandre Bergel

ah ah! This is what we have changed during the pharo cast. Laurent, do you want that we have a look at it together? Cheers, Alexandre On 24 Apr 2011, at 11:30, Mariano Martinez Peck wrote: > "Error 'Please use buildTutorialTopicFor: instead'" > > when I try to open it from the menu. > > ProfStefHelpTutorialBuilder >> buildHelpTopicFrom: aHelpTopicDescription > "Start building from the given help topic description" > > ^(self new) > rootToBuildFrom: aHelpTopicDescription; > build; > topicToBuild > > the rpoblem is that #new > > I am using last versions of Pharo1.3 > > -- > Mariano > http://marianopeck.wordpress.com > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 24, 2011

Re: [Pharo-project] What is a well documented class?

by StÃ©phane Ducasse

On Apr 24, 2011, at 6:49 PM, Alexandre Bergel wrote: >> give a try and see. I think that this is important. > > Yes it is. > >> We can even publish something out of it :) > > That's a side effect that cannot be avoided :-) ;-) so even better. > > Alexandre > >> >> On Apr 24, 2011, at 6:17 PM, Alexandre Bergel wrote: >> >>>>> - each public method belongs to a method category named public* >>>>> - each private method belongs to a method category named private* >>>> >>>> Others here may disagree -- and the dreary of legislating and >>>> enforcing conventions aside -- but I strive (usually with success) to >>>> move all privately-used methods to one or more delegates. One class's >>>> private method is just another's public??? >>> >>> A private method may have to access instances variables. Moving the method to another class may be difficult sometimes. >>> >>>>> - other methods are considered as "package visible", meaning that they belong to a category that does not begins with 'private' or 'public' >>>> >>>> Again, I sympathise with facing the visibility problem, but I don't >>>> trust that conventions will be upheld by either end, so I tire of >>>> following them. Replace Pharo/Squeak categories with Newspeak >>>> modules; replace Pharo/Squeak protocols with traits (stateless, >>>> please); I'll be the first in line. >>> >>> I do not think this should be enforced. It is easy to infer method visibility with a set of well defined scenarios, for example the one that comes in unit tests. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

April 24, 2011