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

[Pharo-project] Issue 4020 in pharo: Improve cleanUpForRelease and cleanUpForProduction

by pharo＠googlecode.com

Status: FixProposed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 4020 by marcus.d...(a)gmail.com: Improve cleanUpForRelease and cleanUpForProduction http://code.google.com/p/pharo/issues/detail?id=4020 cleanUpForRelease: - call BitBlt cleanUp Production: - unload Helystem fixed - unload Deprecated12 and Deprecated13 - unload SimpleMorphic Attachments: betterCleanUpMethods.1.cs 4.5 KB

April 14, 2011

[Pharo-project] Issue 4019 in pharo: It should be possible to call CodeLoader>>initialize multiple times

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 4019 by marcus.d...(a)gmail.com: It should be possible to call CodeLoader>>initialize multiple times http://code.google.com/p/pharo/issues/detail?id=4019 It should be possible to call CodeLoader>>initialize multiple times

April 14, 2011

[Pharo-project] Issue 4018 in pharo: Color class enhancement

by pharo＠googlecode.com

Status: Accepted Owner: alexandr...(a)gmail.com New issue 4018 by alexandr...(a)gmail.com: Color class enhancement http://code.google.com/p/pharo/issues/detail?id=4018 The proposed .cs add a couple of useful constant values on the class side of Color. Attachments: ColorEnh.1.cs 1.7 KB

April 14, 2011

[Pharo-project] Issue 4017 in pharo: CommandLine>>#initialize should not reset registrations

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 4017 by marcus.d...(a)gmail.com: CommandLine>>#initialize should not reset registrations http://code.google.com/p/pharo/issues/detail?id=4017 CommandLine>>#initialize should not reset registrations

April 14, 2011

Re: [Pharo-project] Issue 3985 in pharo: Create temporary in debugger does not work for new keyword method

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3985 by marcus.d...(a)gmail.com: Create temporary in debugger does not work for new keyword method http://code.google.com/p/pharo/issues/detail?id=3985 If it's good in 1.3 than it's fixed. (If someone wants to backport to 1.2, sunmit a fix... but we will release 1.3 soon)

April 14, 2011

Re: [Pharo-project] Improving Pharo's Exception Hierarchy

by Hernan Wilkinson

On Thu, Apr 14, 2011 at 9:08 AM, Toon Verwaest <toon.verwaest(a)gmail.com>wrote: > Right, so you confirm the experience of Dale. > > In the case of flagging errors without classes, do you generally just use a > simple symbol, or concatenate strings to convey more details? This last > seems somehow a bad idea... but maybe if it's never caught it's not so > relevant? > I don't understand exactly what you mean... if you are suggesting using error codes over exceptions, no, that is not may point. Exceptions are the right tool to get rid of the repeated/error prone code you create when using error codes, there is not doubt about it. What I'm saying is that from the handling point of view you only need to identify the exception to handle, and matching the class of the exception with identifying the exception is not the only way (I showed another way in a previous mail). Also, categorizing exception types using subclassing does not seem to be a good idea either... it is common use now, but that does not mean it is good. Sometimes you want to categorize exceptions in a different way that your exception class hierarchy forces you, and when that happens it is really a pain. > > cheers, > Toon > > > On 04/14/2011 02:03 PM, Hernan Wilkinson wrote: > >> the problem is not related to technical issues (like how much machine >> memory you save, etc). It is related to knowledge organization... >> If you have two classes that define exactly the same methods, inst var, >> etc, why do you have two instead of one? If you answer is "because of the >> name of the class", remember that names are contextualized to the place >> where they are used... >> I mean, this is easy, just take all the places where exceptions are handle >> in Smalltalk and look what the handlers do with the exceptions. You will see >> that in almost all cases the exceptions are not used at all, the information >> they carry with them is not use at all... so, from a theory point of view it >> looks nice to have a big exception hierarchy but from the practical point of >> view is not only useless but also more difficult to use. >> I build a system that had an exception class base on where they were >> signal and not handled, we end up with around 1100 exceptions... only 3 or 4 >> are handled directly >> > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

April 14, 2011

Re: [Pharo-project] Issue 4015 in pharo: Fix in SmalltalkEditor

by pharo＠googlecode.com

Comment #2 on issue 4015 by Benjamin...(a)gmail.com: Fix in SmalltalkEditor http://code.google.com/p/pharo/issues/detail?id=4015 A new change set, in addition of the previous one Attachments: SmalltalkEditor-modelCurrentSelectedClass.st 839 bytes

April 14, 2011

[Pharo-project] [update 1.3] #13150

by Marcus Denker

13150 ----- Issue 4014: DNU for TestRunner because of #theme Issue 4011: Finder: self is not bound to class -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 14, 2011

Re: [Pharo-project] Issue 4011 in pharo: Finder: self is not bound to class

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 4011 by marcus.d...(a)gmail.com: Finder: self is not bound to class http://code.google.com/p/pharo/issues/detail?id=4011 in 13150

April 14, 2011

Re: [Pharo-project] Issue 4014 in pharo: DNU for TestRunner because of #theme

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 4014 by marcus.d...(a)gmail.com: DNU for TestRunner because of #theme http://code.google.com/p/pharo/issues/detail?id=4014 in 13150

April 14, 2011