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

[Pharo-project] [ANN] Seattle Smalltalk Users Group

by Casey Ransberger

A while back I asked if anyone on the squeak-dev list was in the greater Seattle area and wanted to meet up. I did get a few responses. Thanks to those who wrote back, and I apologize for the delay. I'm starting this up in part to create a venue here where Smalltalk isn't automatically out as off-topic. The idea is that it's about Smalltalk and anything remotely related to Smalltalk. In fact I'd really like this to be open to everyone who can be respectful to other people. The rest is just a bunch of implementation detail! So if you're in the neighborhood, and you think you might like to meet up with some like minded people on a regular basis, do pop over and add yourself to the list. I figure I'll work out a schedule if and when I have signups, but in general it will probably be early evenings on Wednesdays, maybe once a month to begin with. The site is here: http://www.meetup.com/Seattle-Smalltalk-Users-Group/ If anyone here is on the vwnc list and would like to pass my message along there, or anywhere else it might reach Smalltalkers in the Seattle area, I'd be much obliged! -- Casey Ransberger

April 13, 2011

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

by Camillo Bruni

Perfect, I ll be there to bang heads ;). So without "Exception" pre- or suffix seems to be nice. However I don't see the need of using symbols over real classes. This feels indeed like going to stone age of error handling, thats what you have polymorphism and ExceptionSets for. Anyway, the main idea is to make single exceptions recognizable and not just use one single, basically meaningless, exception type. best regards, Camillo Bruni On 2011-04-13, at 21:22, Sven Van Caekenberghe wrote: > Thanks a lot everybody for the reactions, this could become a nice discussion next Friday. > All points raised are valid, I would like simple names and a compact multipurpose hierarchy too. > > On 13 Apr 2011, at 19:39, Dale Henrichs wrote: > >> Some thoughts from an old man (started programming before exceptions of any kind were available:) ... >> >> In the old days, error numbers had a place in the universe ... error numbers of a certain range indicated specific errors and the "error handlers" could check for a range or a specific error ... >> >> Today I think there is still a place for the notion of "error numbers". >> >> In Smalltalk I would use Symbols instead of numbers, but the idea would be to use a concrete exception class to identify broad categories of error conditions (i.e., FileStreamError) and a symbolic "reason code" to indicate the specific error (i.e., #fileDoesNotExist, #fileExists, #cannotDelete, etc.), that way an error handler can be written for FileStreamError and then specific action take with respect to which "reason code" is involved, if such action is needed. >> >> The main advantage of using reasonCodes over using a "class per error condition" is that you can reduce the size of the Exception hierarchy to a manageable size (GemStone has hundreds of error conditions, so we've resorted to using "reason codes" to manage the size of the hierarchy). >> >> As Hernan hints, more often than not it is important to be very specific about the error condition when signalling an error (a unique error message per "per reason code" would be desirable), but the there are very few places where the handler is going to be that specific ... >> >> In other words, if it is likely that programmers in the course of using an application will be writing specific error handlers to distinguish between the KeyNotFound and ValueNotFound condition, then classes should be created, otherwise, the NotFoundException could be implemented with three reason codes: #keyNotFound, #valueNotFound, and #elementNotFound and you'd get the best of both worlds, explicit information at the signalling site and a much smaller and more manageable Exception class hierarchy. >> >> Dale >> >> On 04/13/2011 10:15 AM, Hernan Wilkinson wrote: >>> I think it is not a good idea to use the prefix Exception. We do not use >>> the word "exception" in real life, so we should not do it on our systems. >>> About the proposed hierarchy, the problem with having specific >>> exceptions is that they are important for those who catch them, not for >>> those who signal them. For example, besides the name, what is the >>> difference between KeyNotFound or ValueNotFound? none. So, I think that >>> the exception hierarchy should be grown from it uses, not created based >>> on how or where they are signaled. >>> >>> my 2 cents :-) >>> >>> On Wed, Apr 13, 2011 at 1:55 PM, Miguel CobÃ¡ <miguel.coba(a)gmail.com >>> <mailto:miguel.coba@gmail.com>> wrote: >>> >>> El miÃ©, 13-04-2011 a las 14:52 +0200, Camillo Bruni escribiÃ³: >>> >>>> And as Mariano pointed out, there should be a convention on the >>>> naming: I am still not sure about suffixing the exception classes >>> with >>>> "Exception", but I guess this is a good thing to do. Though I >>> must say >>>> that I omitted it so far ;) and just put the verb there, but that can >>>> be easily changed. >>> >>> I would say no to suffixes. Analogous to announcements, they shouldn't >>> have the suffix. The name should be descriptive enough and intention >>> revealing that the suffix isn't needed in most cases. For example, I >>> think that >>> >>> DividedByZero >>> >>> is better than >>> >>> DividedByZeroException >>> >>> and no information is lost with the sorter name. Instead, DivideByZero >>> isn't clear enough to indicate that is a event that happened. >>> >>> What do you think? >>> >>> -- >>> Miguel CobÃ¡ >>> http://twitter.com/MiguelCobaMtz >>> http://miguel.leugim.com.mx >>> >>> >>> >>> >>> >>> >>> >>> -- >>> *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 13, 2011

Re: [Pharo-project] [COTDC] 47 - TAssertable

by laurent laffont

On Tue, Apr 12, 2011 at 10:14 PM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > Today: TAssertable > Is it used ? Could not find any reference. Laurent. > > 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 >

April 13, 2011

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

by Sven Van Caekenberghe

Thanks a lot everybody for the reactions, this could become a nice discussion next Friday. All points raised are valid, I would like simple names and a compact multipurpose hierarchy too. On 13 Apr 2011, at 19:39, Dale Henrichs wrote: > Some thoughts from an old man (started programming before exceptions of any kind were available:) ... > > In the old days, error numbers had a place in the universe ... error numbers of a certain range indicated specific errors and the "error handlers" could check for a range or a specific error ... > > Today I think there is still a place for the notion of "error numbers". > > In Smalltalk I would use Symbols instead of numbers, but the idea would be to use a concrete exception class to identify broad categories of error conditions (i.e., FileStreamError) and a symbolic "reason code" to indicate the specific error (i.e., #fileDoesNotExist, #fileExists, #cannotDelete, etc.), that way an error handler can be written for FileStreamError and then specific action take with respect to which "reason code" is involved, if such action is needed. > > The main advantage of using reasonCodes over using a "class per error condition" is that you can reduce the size of the Exception hierarchy to a manageable size (GemStone has hundreds of error conditions, so we've resorted to using "reason codes" to manage the size of the hierarchy). > > As Hernan hints, more often than not it is important to be very specific about the error condition when signalling an error (a unique error message per "per reason code" would be desirable), but the there are very few places where the handler is going to be that specific ... > > In other words, if it is likely that programmers in the course of using an application will be writing specific error handlers to distinguish between the KeyNotFound and ValueNotFound condition, then classes should be created, otherwise, the NotFoundException could be implemented with three reason codes: #keyNotFound, #valueNotFound, and #elementNotFound and you'd get the best of both worlds, explicit information at the signalling site and a much smaller and more manageable Exception class hierarchy. > > Dale > > On 04/13/2011 10:15 AM, Hernan Wilkinson wrote: >> I think it is not a good idea to use the prefix Exception. We do not use >> the word "exception" in real life, so we should not do it on our systems. >> About the proposed hierarchy, the problem with having specific >> exceptions is that they are important for those who catch them, not for >> those who signal them. For example, besides the name, what is the >> difference between KeyNotFound or ValueNotFound? none. So, I think that >> the exception hierarchy should be grown from it uses, not created based >> on how or where they are signaled. >> >> my 2 cents :-) >> >> On Wed, Apr 13, 2011 at 1:55 PM, Miguel CobÃ¡ <miguel.coba(a)gmail.com >> <mailto:miguel.coba@gmail.com>> wrote: >> >> El miÃ©, 13-04-2011 a las 14:52 +0200, Camillo Bruni escribiÃ³: >> >> > And as Mariano pointed out, there should be a convention on the >> > naming: I am still not sure about suffixing the exception classes >> with >> > "Exception", but I guess this is a good thing to do. Though I >> must say >> > that I omitted it so far ;) and just put the verb there, but that can >> > be easily changed. >> >> I would say no to suffixes. Analogous to announcements, they shouldn't >> have the suffix. The name should be descriptive enough and intention >> revealing that the suffix isn't needed in most cases. For example, I >> think that >> >> DividedByZero >> >> is better than >> >> DividedByZeroException >> >> and no information is lost with the sorter name. Instead, DivideByZero >> isn't clear enough to indicate that is a event that happened. >> >> What do you think? >> >> -- >> Miguel CobÃ¡ >> http://twitter.com/MiguelCobaMtz >> http://miguel.leugim.com.mx >> >> >> >> >> >> >> >> -- >> *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 13, 2011

Re: [Pharo-project] Meanwhile, at another vm

by Michael Haupt

Stefan, Am 13.04.2011 um 19:40 schrieb Stephan Eggermont <stephan(a)stack.nl>: > JSR 292 explicitly talks about become: (calls it hotswap) the HotSwap I know is JVM technology introduced in Java 1.4 and is solely about changing method implementations at run-time. I haven't read the JSR, but I'd be amazed if another technology, this time for object identity exchange, would be introduced under the same name. Best, Michael

April 13, 2011

Re: [Pharo-project] Pharo Open Source Smalltalk â Contributors

by laurent laffont

On Wed, Apr 13, 2011 at 8:52 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Laurent can you plase add a link to my blog instead of what is now in my > NAME? > > http://marianopeck.wordpress.com done Laurent. > > > Thanks :) > > > 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 >>> >> >> > > > >

April 13, 2011

Re: [Pharo-project] Pharo Open Source Smalltalk â Contributors

by laurent laffont

On Wed, Apr 13, 2011 at 8:49 PM, Juan Vuletich <juan(a)jvuletich.org> wrote: > Thank you Laurent! Also thanks for the link to Cuis. > > Just a minor detail: my name reads 'Vueltich' instead of 'Vuletich'. > Oups sorry. Fixed. Laurent. > > Cheers, > Juan Vuletich > > laurent laffont wrote: > >> Added ! >> >> Laurent. >> >> >> On Wed, Apr 13, 2011 at 6:45 PM, Juan Vuletich <juan(a)jvuletich.org<mailto: >> 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 <http://www.jvuletich.org>". >> >> >> Thank you. >> >> Cheers, >> Juan Vuletich >> >> >> >

April 13, 2011

Re: [Pharo-project] Pharo Open Source Smalltalk â Contributors

by Mariano Martinez Peck

Laurent can you plase add a link to my blog instead of what is now in my NAME? http://marianopeck.wordpress.com Thanks :) 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 >> > >

April 13, 2011

[Pharo-project] OSProcess and CommandShell

by Casimiro de Almeida Barreto

I'd like to know the state of: OSProcess and CommandShell under pharo. There's a ConfigurationOfOSProcess but there's no ConfigurationOfCommandShell. What's working and what's not working? Best regards CdAB

April 13, 2011

Re: [Pharo-project] Pharo Open Source Smalltalk â Contributors

by laurent laffont

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 >

April 13, 2011