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

[Pharo-project] Let's get rid of Core vs. Full
by Marcus Denker April 5, 2011

April 5, 2011

Hi, So finally I have to admit that I am defeated: The way we do the Core vs. Full release does not work. 1) We don't develop the system using the tools that we tell people to use. -> bugs don't get fixed -> there is no pressure on improving the tools -> we can't use the advanced tools while developing the Core. 2) We integrate *far* too late. -> merging in the tools of Dev a week before the big release *will* fail, as they are not tested. 3) As we use Core for Development of Core, it's not a Core. It contains all needed tools, just simplified versions. -> People even expect to be able to shrink it more, which in turn we do not test. 4) Refactoring are only applied to the Core, not to the whole code base. Look at the Sound or Morph Examples... getting them fixed for the release if they are not touched for a year is nearly impossible. 5) Fixing something in the Core is fast. We move *extremely* fast. Getting something fixed for Full can be very difficult. e.g. repositories need to be changed (for a temporary fork), build scripts edited.. it's so hard that it is done far too late. 6) We can not do a release and be done. Release drag over weeks, making announcments (and publicity) impossible. The build server helps a little bitwith some of the problems, but not much... especially as the full build of unstable is mostly not working. So I vote for abandoning Core vs. Dev for 1.3. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

10 19

[Pharo-project] [COTDC] 40#2 - NonReentrantWeakMessageSend
by laurent laffont April 5, 2011

April 5, 2011

Today: NonReentrantWeakMessageSend (ExclusiveWeakMessageSend aborted - no answer) Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

3 3

[Pharo-project] Status of Weak enhancements in Pharo
by Miguel CobÃ¡ April 5, 2011

April 5, 2011

What is the status of the Weak enhancements that were applied to Squeak 4.2 (by Levente and Igor, mainly) and were targeted for inclusion in Pharo? Is there a list of them somewhere? which ones are integrated and which ones are not yet? Other question, is the plan to take the enhancements as they are and apply them on Pharo, that is, the versions in Squeak are the reference or there are conflicting versions in Pharo that are to be keep instead. I remember that some changes were made to Pharo in this regard. Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

2 2

[Pharo-project] syntax highlighting for (stateful) traits (non-local methods)
by Toon Verwaest April 5, 2011

April 5, 2011

Hi all, as you know I'm working on stateful traits using my new classbuilder etc... Now I noticed that methods are highlighted always inside of the context of the class that's active in the class browser. How can I change this? There is already a useful method around to figure out which object it belongs to: SomeClass traitOrClassOfSelector: #aMethod This actually will tell me which trait it comes from. So now I could apply syntax coloring in the context of the trait rather than the class. Since in my implementation state is all private to the trait / class, they should be able to access their own state but not see the state of the other class. This obviously also means that coloring should happen in the correct scope, rather than always in the scope of the class. At the moment the coloring doesn't really make sense ... but then it didn't really matter that much until now. Although if you try to access state in a method coming from a trait, while coding in your IDE you'll probably have the impression you can access your local instvars. I don't really know what the semantics are there... but it seems a bit broken :) cheers, Toon

3 33

Re: [Pharo-project] Issue 3105 in pharo: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet
by pharo＠googlecode.com April 5, 2011

April 5, 2011

Updates: Status: FixProposed Labels: Milestone-1.3 Comment #1 on issue 3105 by marcus.d...(a)gmail.com: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet http://code.google.com/p/pharo/issues/detail?id=3105 fix attached Attachments: KernelCleanDeepCopier.1.cs 713 bytes

1 2

[Pharo-project] Issue 3964 in pharo: Enabling double click on PluggableListMorphOfMany
by pharo＠googlecode.com April 5, 2011

April 5, 2011

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Nautilus New issue 3964 by Benjamin...(a)gmail.com: Enabling double click on PluggableListMorphOfMany http://code.google.com/p/pharo/issues/detail?id=3964 Just copy and paste 2 lines ... Attachments: EnableDoubleClickOnPluggableListMorphOfMany.1.cs 1.9 KB

1 1

[Pharo-project] [update 1.3] #13133
by Marcus Denker April 5, 2011

April 5, 2011

13133 ----- Issue 3955: Better implementation of the MorphTreeMorph auto select Issue 3956: Better implementation of the PluggableListMorphs auto select Issue 3964: Enabling double click on PluggableListMorphOfMany Issue 3105: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Issue 3956 in pharo: Better implementation of the PluggableListMorphs auto select
by pharo＠googlecode.com April 5, 2011

April 5, 2011

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Nautilus New issue 3956 by Benjamin...(a)gmail.com: Better implementation of the PluggableListMorphs auto select http://code.google.com/p/pharo/issues/detail?id=3956 - Refactor - Multi selection fixed when using arrows - When auto search is done, result is printed using secondSelectionColor Attachments: BetterColorForListMorphsSearch.1.cs 9.7 KB

1 1

[Pharo-project] Issue 3955 in pharo: Better implementation of the MorphTreeMorph auto select
by pharo＠googlecode.com April 5, 2011

April 5, 2011

Status: FixProposed Owner: Benjamin...(a)gmail.com CC: aplan...(a)gmail.com Labels: Nautilus Milestone-1.3 New issue 3955 by Benjamin...(a)gmail.com: Better implementation of the MorphTreeMorph auto select http://code.google.com/p/pharo/issues/detail?id=3955 Now use secondarySelectionColor defined by the current theme and the display is done like the selection Attachments: BetterColorForMorphTreeMorphSearch.3.cs 9.5 KB

1 1

[Pharo-project] Issue 3950 in pharo: SequenceableCollection>>#findBinary and friends (wrong exceptionBlock, delegation)
by pharo＠googlecode.com April 5, 2011

April 5, 2011

Status: New Owner: ---- New issue 3950 by sven.van...(a)gmail.com: SequenceableCollection>>#findBinary and friends (wrong exceptionBlock, delegation) http://code.google.com/p/pharo/issues/detail?id=3950 Pharo 1.2 #12333 There is something wrong with how some of the exceptionBlocks of SequenceableCollection>>#findBinary and friends work. Some of them expect no arguments (as most #ifNone: exception blocks do), while others expect 2 arguments here (a low & a high bounds). Delegation among them is also strange as there seem to be two implementations. Some refactoring could be done. Unit tests are also missing. Some users are also vulnerable. As an example, try these: #(1 3 5 7 11 15 23) findBinary: [ :arg | 11 - arg ] #(1 3 5 7 11 15 23) findBinary: [ :arg | 8 - arg ] #(1 3 5 7 11 15 23) findBinary: [ :arg | 11 - arg ] ifNone: [ nil ] #(1 3 5 7 11 15 23) findBinary: [ :arg | 8 - arg ] ifNone: [ nil ] I could propose a fix, but I don't understand the reason behind the strange exception block: how could passing the low/high bounds be useful here ? Sven

1 3