- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Solving the documentation problem. Capturing tacit knowledge. Knowledge reuse.

by Adrian Kuhn

Adrian Lienhard <adi@...> writes: > What about using a wiki to gather and edit comments (as suggested by > Stan) and then integrate them in a second step so that they are kept > together with the code (as suggested by Stef)? Just a thought... That gave me an idea, what about structuring that wiki like the discussion pages of wikipedia? That is, the wiki is structured by classes and methods, and in the image the browser shows a [wiki] button for classes and methods everywhere. This decouples publishing of code (functional contributions that you want to have double checked and tested by a core member) from publishing of comments (where like on wikipedia everyone can contribute without much harm). Also no dull work required to review and brush up all the information. Of course, initial effort is setting up a wiki with URLs of form /wiki/classname/methodname and including a button in OB that opens the wiki. --AA

Jan. 1, 2010

Re: [Pharo-project] Pharo-beginner mailing list ?

by Douglas Brebner

On 31/12/2009 00:34, Adrian Kuhn wrote: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > > >> @Adrian: the forum idea is nice but I do not why it did not work for >> Smalltalk. I went to the site you mentioned but I could not get how >> it works. >> > You ask, they answer (or if you are in for points: they ask, you answer). It is > the major *open and free* site for questions & answers regarding programming. > Well, I will not attempt to explain stackoverflow beyond that... > > A general web 2.0 platform can of course not replace a dedicated community > platform. But being present on the *now* web (average time for a answer on SO > is about 2 minutes!) is a must these days. A strategy for the pharo twitter > account might also improve visibility as well as accessibility. Linking to > awesome mailing list or blog posts, both from Pharo, Smalltalk *and* outside, > would be my suggestion. > > Sorry to say, but mailing lists are parent's technology :) > I have to admit I dislike web forums and actually feel they're kinda primitive due to the way you need to go to each of them to keep up instead of having everything come to you in one place. Wasn't one of the points of computers to get rid of manually doing everything yourself like this? ;)

Jan. 1, 2010

Re: [Pharo-project] Pharo testers.... WE NEED YOU!!!

by Miguel CobÃ¡

> So...here is the list, if you offer yourself, it would be cool to know: OS, > VM version, Dev or Web,Â browser you usually work, 32 o 64 bits, > I will then collect this and I will put it in the wiki. > > - Mariano Martinez Peck.Â Mac OS, Squeak 4.2.2beta1U.app,Â Dev, OB, 32 bits > - Stan Shepherd > > > WHO ELSE IS IN THE LIST ?? Me too. - Miguel CobÃ¡, Debian GNU/Linux Squeeze (testing), Pharo0.1 of 16 May 2008 [latest update: #10074], Web, OB, 32 bits > > cheers and happy new year!! > Feliz aÃ±o tambiÃ©n Mariano. Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 1, 2010

Re: [Pharo-project] Utilities >> startUp registration??

by Lukas Renggli

This is used for "Utilities recentMethodSubmissions". Some tools in the image still use it. The #update: part was used by Monticello to track method changes, but is no longer active (but the code is still there). Lukas 2009/12/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > does anybody know if this is of any use? > > > startUp > Â Â Â Â SystemChangeNotifier uniqueInstance notify: self ofAllSystemChangesUsing: #event:. > > > event: anEvent > Â Â Â Â "Hook for SystemChangeNotifier" > > Â Â Â Â (anEvent isCommented and: [anEvent itemKind = SystemChangeNotifier classKind]) > Â Â Â Â Â Â Â Â ifTrue: [self noteMethodSubmission: #Comment forClass: anEvent item]. > Â Â Â Â ((anEvent isAdded or: [anEvent isModified]) and: [anEvent itemKind = SystemChangeNotifier methodKind]) > Â Â Â Â Â Â Â Â ifTrue: [anEvent itemRequestor ifNotNil: [self noteMethodSubmission: anEvent itemSelector forClass: anEvent itemClass]]. > Â Â Â Â ((anEvent isAdded or: [anEvent isModified]) and: [anEvent itemKind = SystemChangeNotifier methodKind]) ifTrue:[ > Â Â Â Â Â Â Â Â InMidstOfFileinNotification signal > Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [Utilities changed: #recentMethodSubmissions]. > Â Â Â Â ]. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 31, 2009

[Pharo-project] [update 1.1] #11130

by StÃ©phane Ducasse

11130 ----- - Cleaning Utilities... yet another step in the right direction

Dec. 31, 2009

[Pharo-project] Utilities >> startUp registration??

by StÃ©phane Ducasse

does anybody know if this is of any use? startUp SystemChangeNotifier uniqueInstance notify: self ofAllSystemChangesUsing: #event:. event: anEvent "Hook for SystemChangeNotifier" (anEvent isCommented and: [anEvent itemKind = SystemChangeNotifier classKind]) ifTrue: [self noteMethodSubmission: #Comment forClass: anEvent item]. ((anEvent isAdded or: [anEvent isModified]) and: [anEvent itemKind = SystemChangeNotifier methodKind]) ifTrue: [anEvent itemRequestor ifNotNil: [self noteMethodSubmission: anEvent itemSelector forClass: anEvent itemClass]]. ((anEvent isAdded or: [anEvent isModified]) and: [anEvent itemKind = SystemChangeNotifier methodKind]) ifTrue:[ InMidstOfFileinNotification signal ifFalse: [Utilities changed: #recentMethodSubmissions]. ].

Dec. 31, 2009

Re: [Pharo-project] Solving the documentation problem. Capturing tacit knowledge. Knowledge reuse.

by StÃ©phane Ducasse

> > I have been 'overriding' the false positives with pragmas, as implemented by > Lukas. Works well, although it would be good if they had a separate area so > they don't become bigger than the code itself. yes this is the problem metadata. Stef

Dec. 31, 2009

[Pharo-project] [update 1.1] #11129

by StÃ©phane Ducasse

11129 ----- - Remove deprecated method from 1.0. Took 10501rc1 checked all the senders of deprecated: and removed the corresponding ones in 1.1

Dec. 31, 2009

Re: [Pharo-project] Solving the documentation problem. Capturing tacit knowledge. Knowledge reuse.

by csrabak＠bol.com.br

+1 Em 31/12/2009 16:30, Adrian Lienhard < adi(a)netstyle.ch > escreveu: What about using a wiki to gather and edit comments (as suggested by Stan) and then integrate them in a second step so that they are kept together with the code (as suggested by Stef)? Just a thought... Cheers Adrian

Dec. 31, 2009

Re: [Pharo-project] Solving the documentation problem. Capturing tacit knowledge. Knowledge reuse.

by csrabak＠bol.com.br

Em 31/12/2009 16:07, Stan Shepherd < stan.shepherd414(a)gmail.com > escreveu: > csrabak wrote: > > > > [snipped] > > > for info, I ran code critics on Lukas's quasi-release > http://www.seaside.st/distributions/Seaside-3.0a5.app.zip which is > essentially web dev without O2 I believe. (Code critics I can't get > to work in web dev) > Taking out spelling, there are about 30000 items flagged, of which > 4802 long methods. > In an ideal world, it would be nice if the whole image passed code > critics. I think that for starters we should put efforts in having this state of "cleanness" in the core image first! > > > - pick one aweek and via the mailing-list make it better and > > - after we integrate it. > Well the one that's entertaining me at the moment is JSObject, but > I imagine people would rather start with a core class?. Stan, Notwithstanding the truth of you assertion, I maintain that every effort it the right direction is a worthy contribution! -- Cesar Rabak

Dec. 31, 2009