- Pharo-dev - lists.pharo.org

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

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 4017 by marcus.d...(a)gmail.com: CommandLine>>#initialize should not reset registrations http://code.google.com/p/pharo/issues/detail?id=4017 in 13152

April 14, 2011

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

by Hernan Wilkinson

On Thu, Apr 14, 2011 at 10:37 AM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > > On 2011-04-14, at 14:19, Hernan Wilkinson wrote: > > > > > > > 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. > > But right now that is possible by concatenating Exceptions, generating > ExceptionSets, which you could even generate upfront, so complexity-wise it > is the same as using symbols as identifiers in a generic Exception class. > yes of course, but you still have the super-class relationship... anyway, this is not the main issue > > But I agree finding the right balance of how many exception classes to use > is not easy. However, we are still far from that in Pharo..., even worse, > since no one uses explicit error classes no one uses them. As I said, I used them in a system and the conclusion was that you don't need them... a program can do little when an exception is throw to fix the problem (but in very small cases)... they are basically to inform the user that something went wrong and having a good description is more important than having a big exception hierarchy. > And certainly there should be another way to catch errors than just by > relying on the type / class. Sometimes it would be nice to be able to catch > errors depending on the place they were thrown, for instance only handle > exceptions thrown in my own methods / my package... > yes, that is completely true... I would be great to have a mechanism where you could automatically convert exception while the pass subsystems/layers bounderies too... that is a great research topic I think > > And concerning the IDE, we need a lot of improvements there, the current > design and functionality in Pharo at least, resembles more a system from the > 70'ies than a more recent ide. > -- *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

[Pharo-project] Are you a Pharo contributor ??? [WAS] Re: Pharo Open Source Smalltalk â Contributors

by Mariano Martinez Peck

if true...then what are you wainting for? http://www.pharo-project.org/community/contributors Send you data and nice picture :) Seriously, it is important for marketing among other things. Imagine you arrive to a new project...it is good to see that there are several contributing to it. Probably this page is not the best, but is something more. Mariano On Wed, Apr 13, 2011 at 8:18 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Added ! > > Laurent. > > On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich <juan(a)jvuletich.org> wrote: > >> Hi Laurent, >> >> I'd like to be added to >> http://www.pharo-project.org/community/contributors . My picture is >> attached. Description text could be "Contributed the default anti-aliased >> fonts and the SimpleMorphic UI framework. Web page at www.jvuletich.org". >> >> Thank you. >> >> Cheers, >> Juan Vuletich >> > > -- Mariano http://marianopeck.wordpress.com

April 14, 2011

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

by Philippe Marschall

On 04/11/2011 04:10 PM, Sven Van Caekenberghe wrote: > Hi All, > > I have this idea that I would like to discuss on the next Pharo sprint and maybe start to implement if there is some consensus on it. > > It has been mentioned many times before on this list that Object>>#error: should be replaced by signalling specific Exceptions in as many cases as possible (or where it makes sense). Even today, there was http://code.google.com/p/pharo/issues/detail?id=3987 ! > > I think the core system should set the example here, by defining a number of general purpose exceptions and by using them. Going over #error: senders will be a lot of work but can be done in incremental/Pharo steps. > > So I went over the current hierarchy, scanned quickly through their references and some #error: senders by fundamental classes and looked at some other Smalltalks. I came up with the following very rough draft of an extended hierarchy (** marks new exceptions). In between brackets are the instance variables. Of course, we have to discuss about naming, instance variables and opportunities for reuse and inheritance (could be fun). > > I am no expert on exceptions and would certainly like to learn more. I am probably overlooking some aspects. We have to keep this Smalltalk like, flexible, dynamic, not start mimicing other languages. > > Any step in this direction will be an improvement over the current situation. Really using them correctly throughout the system will take some time. Defining the hierarchy could be done rather quickly. Refactoring is always possible later on. > > Exception (messageText) > Abort > Error > ArithemticError > ZeroDivide (dividend) > FloatingPointException > RangeError ** (from, to) > NaNError ** > FileStreamException (fileName) > FileDoesNotExistException (readOnly) > FileExistsException (fileClass) > CannotDeleteFileException > FileWriteError > FileReadError ** > FileClosedException ** > CannotAccessFileException ** > ReadonlyFileException ** > MessageNotUnderstood (message, receiver) > NonBooleanReceiver (object) > OutOfMemory > Halt > AssertionFailure > BreakPoint > SyntaxError ** !exists! (input, position) > NumberFormatException ** > HeadlessError ** > TimedOut ** (object, operation, timeout) > VerificationException > IllegalOperation ** (operation, object) > SizeMismatch (objects) > LowMemory ** (percentageFree) > SubclassResponsibility ** (message, receiver) > NotYetImplemented ** (message, receiver) > CannotInstanciate ** (class) > ReadOnlyObject ** (object) > OutOfFreeSpace ** (object, size) > InvalidArgument ** (message, receiver, argument) > NotIndexable ** (object) > NoKeyedAccess ** (object) > NonIntegerIndex ** (receiver, index) > SubscriptOutOfBounds ** (receiver, index, from, to) > NotFoundException ** (receiver, object) > KeyNotFound ** > ValueNotFound ** > ElementNotFound ** > StreamException (stream) > PositionError ** (index, from, to) > EndOfStream ** > BeginOfStream ** > > All feedback is welcome. PrimitiveFailed for #primitiveFailed would be nice as well. Cheers Philippe

April 14, 2011

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

by pharo＠googlecode.com

Comment #2 on issue 4017 by marcus.d...(a)gmail.com: CommandLine>>#initialize should not reset registrations http://code.google.com/p/pharo/issues/detail?id=4017 in 13152

April 14, 2011

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

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 4020 by marcus.d...(a)gmail.com: Improve cleanUpForRelease and cleanUpForProduction http://code.google.com/p/pharo/issues/detail?id=4020 in 13151

April 14, 2011

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

by Camillo Bruni

On 2011-04-14, at 14:19, Hernan Wilkinson wrote: > > > 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. But right now that is possible by concatenating Exceptions, generating ExceptionSets, which you could even generate upfront, so complexity-wise it is the same as using symbols as identifiers in a generic Exception class. But I agree finding the right balance of how many exception classes to use is not easy. However, we are still far from that in Pharo..., even worse, since no one uses explicit error classes no one uses them. And certainly there should be another way to catch errors than just by relying on the type / class. Sometimes it would be nice to be able to catch errors depending on the place they were thrown, for instance only handle exceptions thrown in my own methods / my package... And concerning the IDE, we need a lot of improvements there, the current design and functionality in Pharo at least, resembles more a system from the 70'ies than a more recent ide.

April 14, 2011

Re: [Pharo-project] Issue 3148 in pharo: Proposal: adding 261 named colors

by pharo＠googlecode.com

Updates: Status: Duplicate Mergedinto: 4018 Comment #3 on issue 3148 by marcus.d...(a)gmail.com: Proposal: adding 261 named colors http://code.google.com/p/pharo/issues/detail?id=3148 (No comment was entered for this change.)

April 14, 2011

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

by pharo＠googlecode.com

Comment #3 on issue 4018 by marcus.d...(a)gmail.com: Color class enhancement http://code.google.com/p/pharo/issues/detail?id=4018 Issue 3148 has been merged into this issue.

April 14, 2011

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

by Marcus Denker

And pleast, please have a look at old tracker entries... http://code.google.com/p/pharo/issues/detail?id=3148 On Apr 14, 2011, at 3:11 PM, pharo(a)googlecode.com wrote: > > Comment #2 on issue 4018 by alexandr...(a)gmail.com: Color class enhancement > http://code.google.com/p/pharo/issues/detail?id=4018 > > XKCDColors, written by Johan Fabry > > Attachments: > XKCDColor.st 12.1 KB > XKCDColorTest.st 458 bytes > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 14, 2011