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

[Pharo-project] Gofer problem installing packages with the same name

by HernÃ¡n Morales Durand

Hi list, I have some issues with Gofer, maybe already known. When I evaluate: Gofer new squeaksource: 'Subjectivity'; package: 'Subjectivity'; load. it seems that Gofer takes the first package named Subjectivity it founds which in this case is http://www.squeaksource.com/Decisionstrategy.html while I wanted to take it from http://www.squeaksource.com/Subjectivity.html (please see the screenshot). After then I've tried to update "Gofer upgrade" for a fix, but it seems it cannot connect to http://source.lukas-renggli.ch and then entered in an endless loop. Any hint? (Using Pharo1.2beta Latest update: #12294) Cheers, -- HernÃ¡n Morales Information Technology Manager, Institute of Veterinary Genetics. National Scientific and Technical Research Council (CONICET). La Plata (1900), Buenos Aires, Argentina. Telephone: +54 (0221) 421-1799. Internal: 422 Fax: 425-7980 or 421-1799.

Jan. 9, 2011

Re: [Pharo-project] Issue 3514 in pharo: Failing Test: NewTextMorphTests.testAcceptContents

by pharo＠googlecode.com

Comment #3 on issue 3514 by stephane.ducasse: Failing Test: NewTextMorphTests.testAcceptContents http://code.google.com/p/pharo/issues/detail?id=3514 Thanks. I need to relax from proposal writing and I will do some integration after.... (but I need to read a phd).

Jan. 9, 2011

[Pharo-project] Pharo sprint @ lille Friday 21 of January

by StÃ©phane Ducasse

Hi guys we will have a pharo sprint at Lille Friday 21 of January. If you want to join let us know that we organize for the food. The sprint will happen in our rooms at LIFL http://rmod.lille.inria.fr/web/pier/contactr/ Stef

Jan. 9, 2011

Re: [Pharo-project] Issue 3514 in pharo: Failing Test: NewTextMorphTests.testAcceptContents

by pharo＠googlecode.com

Updates: Status: Fixed Comment #2 on issue 3514 by aplantec: Failing Test: NewTextMorphTests.testAcceptContents http://code.google.com/p/pharo/issues/detail?id=3514 just make EditableTextMorph understand #enableTextChange EditableTextMorph>>enableTextChange ^ self enabled Fixed SLICE-Issue-3514-Failing-Test-NewTextMorphTeststestAcceptContents

Jan. 9, 2011

Re: [Pharo-project] wiki style help

by Alain Plantec

super then. I open an issue Alain Le 08/01/2011 15:16, StÃ©phane Ducasse a Ã©crit : > Ok I suggest to integrate that in 1.2 because this is important. > > Now let me open a big can of worms but we truly need it. > When you write documentation (I did several experiments with Soup) the documentation in class comment is cool because you to not have to have > " and " and '' ' ' '' '" everytimes you manipulate a string or a comment. > Now you do not want to have huge class comments I would prefer to have a couple of methods and it does not work: you put back the crappy unnestable " > ugly boring.... better not putting comments. > > So I would really like to have > */ this is a nice nestable comment > > "hkjkhhkjh " > 'hkjjkh' > 1 + 2 > > */yet another comment: increbile this is a nested ones: yes you know > Smalltalkers are discovering the world/* > > /* > > As you see stealing the C comment syntax is a plus because everybody knows it. > I remember a discussion on VW about possible syntax to support that. > Before replying to this point thing hard because we need that support. > > Stef > > > On Jan 8, 2011, at 10:15 AM, Alain Plantec wrote: > >> Hi all, >> very cool, thanks Torsten. >> Now, I think it's better to wait 1.3 because 1.2 >> is almost ready ... >> and I would use $! instead of $= as section >> marker to keep Pier compatibility. >> Cheers >> Alain >> Le 07/01/2011 14:16, Torsten Bergmann a Ã©crit : >>> Hi, >>> >>> Nice idea, I like the "wiki help description" for three reasons: >>> >>> - its pragma based AND allows for definition of structured books >>> (so Lukas should be satisfied since he can define content >>> without dependency on help system) >>> >>> - it allows us to reuse existing swiki contents >>> (if the full syntax is supported we can query existing >>> swikis!) >>> >>> So it is a nice idea and would be a good addition. >>> >>> >>> I reworked Alains code to better fit the pluggable architecture >>> of the HelpSystem framework (now using a builder): >>> >>> Use an updated 1.2 core image, code is attached >>> >>> 1. File in "Foo.st" (which defines a simple help description) >>> => no dependency on any help system >>> >>> 2. First I added a registration mechanism (pragma<systemHelp> >>> so one can add own help types to the system help >>> (the one that appears when you open the default help browser) >>> >>> => load "AddToSystemHelpFix.1.cs" >>> => at least this fix should go into Core 1.2, so >>> no ugly hacks are necessary to appear in the >>> default help browser >>> >>> I added a now fixed issue for core 1.2 on: >>> http://code.google.com/p/pharo/issues/detail?id=3511 >>> >>> 3. I reworked Alains code so it uses a WikiStyleHelpBuilder >>> (similar to the other builders) and a WikiStyleHelp as >>> a new help type >>> >>> => see WikiStyleHelp.5.cs >>> => if we agree on this we can integrated it into core too, >>> currently it is in an own class category/package >>> => "HelpBrowser openOn: WikiStyleHelp" >>> will show all contents defined using the wiki style syntax, >>> so only the one defined in class Foo appears >>> => "HelpBrowser open" >>> will show all help in the system (including the ones >>> defined in Foo) >>> => since it uses the new registration mechanism (see 2. above) >>> all these topics will also appear in the help browser >>> that is accessible from the menu >>> >>> I would vote for adding this to core 1.2 too. It's additional, >>> nothing should break. What do you all think... >>> >>> And thanks Alain for the idea and initial code!!! >>> >>> Have fun >>> T. >>> >>> >>> >>> >>> >>> >>> >> >

Jan. 9, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by StÃ©phane Ducasse

Excellent You know what I'm dreaming of (may be this is already in) you get the list of methods in the method list and you start to type and automatically all the methods not matching are greyed out or we only see the methods matching the beginning. Stef On Jan 9, 2011, at 10:26 AM, Johan Brichau wrote: > Andy agreed to pair program it with me, starting next week. Unless someone beats us to it ;-) > > On 09 Jan 2011, at 10:12, StÃ©phane Ducasse wrote: > >> + 1 >> >> does anybody want to implement this hovering excellent idea. >> >> >> On Jan 9, 2011, at 10:02 AM, Johan Brichau wrote: >> >>> And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. >>> We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more.... >> > >

Jan. 9, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by Johan Brichau

Andy agreed to pair program it with me, starting next week. Unless someone beats us to it ;-) On 09 Jan 2011, at 10:12, StÃ©phane Ducasse wrote: > + 1 > > does anybody want to implement this hovering excellent idea. > > > On Jan 9, 2011, at 10:02 AM, Johan Brichau wrote: > >> And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. >> We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more.... >

Jan. 9, 2011

[Pharo-project] 4 days sprints in february

by StÃ©phane Ducasse

Hi guys we are brainstorming with alain plantec to organize a sprint at roscoff (close to brest - excellent sea food). The set up would be: - 21 - 24 of february - this is holiday time here. I will rent a house with the kids there. - we can get access to a room for 450 Euros (break included). - the hosting is 50 Euros per day breakfast included - lunches are about 15 euros. So are some of you interested by participating. We could ask some sponsoring to ESUG. http://maps.google.fr/maps?client=safari&rls=en&q=roscoff&oe=UTF-8&redir_es… http://www.google.fr/images?client=safari&rls=en&q=roscoff&oe=UTF-8&redir_e… Stef

Jan. 9, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by StÃ©phane Ducasse

+ 1 does anybody want to implement this hovering excellent idea. On Jan 9, 2011, at 10:02 AM, Johan Brichau wrote: > And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. > We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more....

Jan. 9, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by Johan Brichau

On 08 Jan 2011, at 23:07, Nicolas Cellier wrote: > You mean something like: > > | collec | > collec := #('foo' 'bar'). > shallowCopy := collec copy. > self assert: collec first == shallowCopy first > > Well, yes those copies are shallow, but what's the difference between > copy, copyFrom:to: first, first: etc... with this respect ? I think Stephan intended to say that the return result of #first is not a copy of (parts of) the receiver. #first is an accessor, not a copy message. And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more.... Johan

Jan. 9, 2011