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

Re: [Pharo-project] About float: new chapter looking for reader and contributors

by StÃ©phane Ducasse

On Apr 14, 2011, at 11:31 AM, Nicolas Cellier wrote: > I created a git account last night but must install latex on my mac. you can also just write and I will latex it. There is no problem. > I don't have your rythm :) :) But you are doing a lot of things too. Sometimes I have the impression that I could be more focused and it would be better but the system does not give me this chance. Stef

April 14, 2011

Re: [Pharo-project] isHealthy

by StÃ©phane Ducasse

Ok in fact I should have check do: first and I will change thses users of do: to replace with doValues: because I was following a wrong road because of it. Stef >>> >>> dict array == nil >>> should not happen, but >>> (dict array at: someindex ) == nil >>> is quite normal. >> I do not know I have a do: loop and some elements are nil and break the loop. >> >> Stef > > do: iterates the values in the Dictionary, and yes, it's perfectly valid to have a pair someKey -> nil in the dictionary. > Why you have it (ie who put it there), and if it should be valid in your case, you'd have to figure out :) > > Cheers, > Henry >

April 14, 2011

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

by StÃ©phane Ducasse

Dale so it means that I write what? [] on: NumericError do: [:ex | ] how do I access the rangeError? >> > > Using Sven's hierachy as a starting point and taking some cues from the GemStone exception hierarchy, I would suggest the following (names atarting with # are reasonCodes in the namespace of the parent exception class, instead of a unique class): > > Exception (messageText reasonCode) > Abort > Error > NumericError > #floatingPointException > #rangeError > #naNError > ZeroDivide (dividend) > FileStreamException (fileName) > #fileDoesNotExistException > #fileExistsException (fileClass) > #cannotDeleteFileException > #fileWriteError > #fileReadError ** > #fileClosedException ** > #cannotAccessFileException ** > #readonlyFileException ** > MessageNotUnderstood (message, receiver) > #nonBooleanReceiver (object) > OutOfMemory < handlers?> > ControlInterrupt > Halt > AssertionFailure > BreakPoint > CompileError > SyntaxError ** !exists! (input, position) > #numberFormatException ** > #headlessError ** > TimedOut ** (object, operation, timeout) > VerificationException > IllegalOperation ** (operation, object) > #sizeMismatch (objects) > #subclassResponsibility ** (message, receiver) > #notYetImplemented ** (message, receiver) > #cannotInstanciate ** (class) > #readOnlyObject ** (object) > OutOfFreeSpace ** <handlers?> > #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 ** > > Notification > Admonition > LowMemory ** <this should be a notification not an error> >

April 14, 2011

Re: [Pharo-project] Class Builder for Pharo, was Re: Improving Pharo's Exception Hierarchy

by StÃ©phane Ducasse

On Apr 14, 2011, at 4:12 PM, Toon Verwaest wrote: > Be patient, be patient ;) > > I'm still very busy at the moment, but it'll get there. > > We'll probably have discuss if you want to generate slot and layout objects in the classbuilder, or if you want to replace the instanceVariables array with real layout objects that you keep around. We basically implemented everything around the layout objects and keep this data in all classes; but you'll have to figure out if you want this in Pharo or not. Decide and let me know, I'd say ;) you know the answer (we want slots). After this is more a question of - is the code robust - what are the migration plans - do we schedule that for when Stef

April 14, 2011

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

by Hernan Wilkinson

On Thu, Apr 14, 2011 at 1:38 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > > I think you said it right here: "having classes for all _relevant_ > concepts actually pays off"... > > I do not quite agree on this. Responsibility should be the driver, not the > concepts. > that is a good point > > Alexandre > > > > Related to exceptions, my question is: what are all the different > concepts you have? for example, not finding a Key or not finding a Value are > really different concepts? or is it the same (not finding something) that > depending on the context (finding a value or a key) is what looks like they > are different? if so, then there is only one concept (i.e. not finding an > object), if it is a key or a value is accidental, contextual to what you are > looking for. > > So, I completely agree when you say "having classes for all relevant > concepts"... I think we do not agree on what are the relevant concepts when > we talk about exceptions... > > > > > > Toon > > > > > > On 04/14/2011 01:00 AM, Dale Henrichs wrote: > > On 04/13/2011 02:58 PM, Toon Verwaest wrote: > > Is it such a problem if you duplicate a certain exception class? At the > > moment you'll do the same anyway by not completely writing the exact > > same symbol. > > > > It's a simple matter of namespaces and volume of names ... with a large > open ended namespace you are more likely to have a number of redundant names > with slight differences in spelling showing up in different spots in the > hierarchy...with a logically segmented namespace each segment will have a > manageable number of names and the risk of duplication is reduced ... end of > discussion ... > > > > 10,000 names vs 30 names ... I can easily recognize duplicates in a list > of 30 names ... not so easy in 10,000 ... that is all ... > > > > to attempt to map every possible error condition onto a class will lead > you to 10,000 much quicker than using reasonCodes ... that is all ... > > > > I don't hate classes, it is a _practical_ matter ... if _you_ would > rather manage 10,000 names then I will say that it isn't practical ... I'm > _not_ saying it is _wrong_, just not _practical_. > > > > > > And if the problem is not finding classes anymore, maybe we need a > > better way of organizing the exception classes away from the standard > > classes so that they are as non-intrusive as symbols, but convey more > > information? > > > > And now you've hit the nail on the head ... in order to handle the extra > complexity you need additional tools ... before creating more tools, ask > your self the simple question: "Do I _need_ the additional complexity?" ... > if the answer is yes, then create the tool, if the answer is no, then you > don't need to create a new tool .. > > > > Again, this is a _practical_ matter... > > > > > > self error: #keyNotFound > > does not really give much information; and isn't much more difficult to > > write than: > > KeyNotFoundException new in: self; key: key; signal > > > > From a practical perspective how many exception handlers will be written > to handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look > up that I think might fail ... better than writing an exception handler ... > > > > If there is a real need to write a handler for KeyNotFoundException, then > by all means create the class, but until you actually NEED > KeyNotFoundException, `self error: #keyNotFound` or `NotFoundException > signal: #keyNotFound` will work just fine... > > > > although the second one gives you all the contextual information that > > the first one misses. > > > > _If_ you NEED the additional contextual information. It's just like > writing a framework that no uses ... there's nothing wrong with the idea or > the implementation, it's just that the framework didn't solve a problem that > anyone had... > > > > If you are going to create a class, I think the least it should do is > address an real problem, not an imaginary one. > > > > To say that "if one were to handle the KeyNotFoundException, they will > need the complete context", I prefer to say "Until one needs the complete > context of the KeyNotFoundException, don't bother creating class" > > > > > > What I mean mostly: what about trying to figure out why you want to > > avoid decent exception classes and tackling that problem? > > > > Depends upon what your definition of a decent exception classes is? My > argument is simply that it is not _necessary_ to create a unique class for > every unique error condition ... I think that folks should answer the > question: "Will anyone every write an exception handler for this exception" > before creating the class ... if the answer is yes (or better yet, I am > writing code right now and need that exception) then by all means create the > class. > > > > Maybe we don't want classes but exception objects that can pool data > > together? Maybe a very silly idea: what about just exception "classes" > > that have dictionaries to store enough information? > > > > That would be another way of doing things ... although using exception > classes and reasonCodes is pretty close to all that is needed... > > > > I agree with the notion that it isn't that useful to have a single Error > class and have all errors mapped to it ... on the other hand I don't think > it is particularly useful to have an exception class for every possible > error condition ... the compromise is to provide a smallish hierarchy of > excpetion classes with fairly general structure, provide a means for > uniquely identifying every possible error condition (I think that is > important) and then add new classes to the hierarchy when a demand for the > class is found ... > > > > > > > > > > > > > > > > -- > > HernÃ¡n Wilkinson > > Agile Software Development, Teaching & Coaching > > Mobile: +54 - 911 - 4470 - 7207 > > email: hernan.wilkinson(a)10Pines.com > > site: http://www.10Pines.com > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- *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] Improving Pharo's Exception Hierarchy

by Alexandre Bergel

> I think you said it right here: "having classes for all _relevant_ concepts actually pays off"... I do not quite agree on this. Responsibility should be the driver, not the concepts. Alexandre > Related to exceptions, my question is: what are all the different concepts you have? for example, not finding a Key or not finding a Value are really different concepts? or is it the same (not finding something) that depending on the context (finding a value or a key) is what looks like they are different? if so, then there is only one concept (i.e. not finding an object), if it is a key or a value is accidental, contextual to what you are looking for. > So, I completely agree when you say "having classes for all relevant concepts"... I think we do not agree on what are the relevant concepts when we talk about exceptions... > > > Toon > > > On 04/14/2011 01:00 AM, Dale Henrichs wrote: > On 04/13/2011 02:58 PM, Toon Verwaest wrote: > Is it such a problem if you duplicate a certain exception class? At the > moment you'll do the same anyway by not completely writing the exact > same symbol. > > It's a simple matter of namespaces and volume of names ... with a large open ended namespace you are more likely to have a number of redundant names with slight differences in spelling showing up in different spots in the hierarchy...with a logically segmented namespace each segment will have a manageable number of names and the risk of duplication is reduced ... end of discussion ... > > 10,000 names vs 30 names ... I can easily recognize duplicates in a list of 30 names ... not so easy in 10,000 ... that is all ... > > to attempt to map every possible error condition onto a class will lead you to 10,000 much quicker than using reasonCodes ... that is all ... > > I don't hate classes, it is a _practical_ matter ... if _you_ would rather manage 10,000 names then I will say that it isn't practical ... I'm _not_ saying it is _wrong_, just not _practical_. > > > And if the problem is not finding classes anymore, maybe we need a > better way of organizing the exception classes away from the standard > classes so that they are as non-intrusive as symbols, but convey more > information? > > And now you've hit the nail on the head ... in order to handle the extra complexity you need additional tools ... before creating more tools, ask your self the simple question: "Do I _need_ the additional complexity?" ... if the answer is yes, then create the tool, if the answer is no, then you don't need to create a new tool .. > > Again, this is a _practical_ matter... > > > self error: #keyNotFound > does not really give much information; and isn't much more difficult to > write than: > KeyNotFoundException new in: self; key: key; signal > > From a practical perspective how many exception handlers will be written to handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look up that I think might fail ... better than writing an exception handler ... > > If there is a real need to write a handler for KeyNotFoundException, then by all means create the class, but until you actually NEED KeyNotFoundException, `self error: #keyNotFound` or `NotFoundException signal: #keyNotFound` will work just fine... > > although the second one gives you all the contextual information that > the first one misses. > > _If_ you NEED the additional contextual information. It's just like writing a framework that no uses ... there's nothing wrong with the idea or the implementation, it's just that the framework didn't solve a problem that anyone had... > > If you are going to create a class, I think the least it should do is address an real problem, not an imaginary one. > > To say that "if one were to handle the KeyNotFoundException, they will need the complete context", I prefer to say "Until one needs the complete context of the KeyNotFoundException, don't bother creating class" > > > What I mean mostly: what about trying to figure out why you want to > avoid decent exception classes and tackling that problem? > > Depends upon what your definition of a decent exception classes is? My argument is simply that it is not _necessary_ to create a unique class for every unique error condition ... I think that folks should answer the question: "Will anyone every write an exception handler for this exception" before creating the class ... if the answer is yes (or better yet, I am writing code right now and need that exception) then by all means create the class. > > Maybe we don't want classes but exception objects that can pool data > together? Maybe a very silly idea: what about just exception "classes" > that have dictionaries to store enough information? > > That would be another way of doing things ... although using exception classes and reasonCodes is pretty close to all that is needed... > > I agree with the notion that it isn't that useful to have a single Error class and have all errors mapped to it ... on the other hand I don't think it is particularly useful to have an exception class for every possible error condition ... the compromise is to provide a smallish hierarchy of excpetion classes with fairly general structure, provide a means for uniquely identifying every possible error condition (I think that is important) and then add new classes to the hierarchy when a demand for the class is found ... > > > > > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 14, 2011

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

by Dale Henrichs

On 04/14/2011 05:08 AM, Toon Verwaest 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? > Using Sven's hierachy as a starting point and taking some cues from the GemStone exception hierarchy, I would suggest the following (names atarting with # are reasonCodes in the namespace of the parent exception class, instead of a unique class): Exception (messageText reasonCode) Abort Error NumericError #floatingPointException #rangeError #naNError ZeroDivide (dividend) FileStreamException (fileName) #fileDoesNotExistException #fileExistsException (fileClass) #cannotDeleteFileException #fileWriteError #fileReadError ** #fileClosedException ** #cannotAccessFileException ** #readonlyFileException ** MessageNotUnderstood (message, receiver) #nonBooleanReceiver (object) OutOfMemory < handlers?> ControlInterrupt Halt AssertionFailure BreakPoint CompileError SyntaxError ** !exists! (input, position) #numberFormatException ** #headlessError ** TimedOut ** (object, operation, timeout) VerificationException IllegalOperation ** (operation, object) #sizeMismatch (objects) #subclassResponsibility ** (message, receiver) #notYetImplemented ** (message, receiver) #cannotInstanciate ** (class) #readOnlyObject ** (object) OutOfFreeSpace ** <handlers?> #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 ** Notification Admonition LowMemory ** <this should be a notification not an error>

April 14, 2011

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

by Miguel CobÃ¡

El jue, 14-04-2011 a las 08:50 -0700, Dale Henrichs escribiÃ³: > For the Exception framework I think the following guidelines should apply: > > 1. Each unique error _should_ be uniquely identified and the current > mechanism of providing a string argument to the #error: message is > not sufficient. > 2. Specific handlers will not be written for most errors, so it isn't > absolutely necessary to create a unique exception class for all > errors > 3. If specific handlers exist (doing string parsing now) or there is a > reasonable case made that specific handlers are likely to written, > then a unique exception class should be created. > 4. reasonCodes (within the namespace of an exception class or > subhierarcy) can be used to uniquely identify an error condition, > when a unique class isn't called for. > 5. In the fullness of time, if a case is found where a reasonCode > should be turned into a unique exception class, then the class > should be created. > > These guidelines should help keep the Exception hierarchy as small as is > needed, but allow expansion as well. > > Keep in mind that the primary purpose of the Exception is to allow code > to be written that automates the handling of the exception. Developers > don't need Exceptions to debug/develop applications ... the debugger > provides all of the information that a developer needs ...So the > exception is there when a developer cannot look at the stack and must > write code to report the error to a log, an end user, or take corrective > action .... for an error report, the exception class and reasonCode is > sufficient information for a developer to go back to the code and > determine the call site ... > Very well put. I think that those guidelines will permit to evolve the current Exception framework in Pharo and avoid ending with an over-engineered and commite-dictated set of seldom used exception classes. Thanks Dale -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 14, 2011

Re: [Pharo-project] Document on UIBuilder Tool

by Mariano Martinez Peck

On Wed, Apr 13, 2011 at 8:02 PM, sourav roy <sourav_pharo(a)in.com> wrote: > Hi all, > > Hi. > Can any suggest me some documents on- > 1.UIBuilder Tool > There was a recent thread in the mailing list. http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=12948… > 2.UI/Morph Class > 3.Database Connection Programming using Pharo. > DBXTalk: www.squeakdbx.org For more options, you can see: http://book.pharo-project.org/book/PharoTools/ and most from here : http://www.seaside.st/documentation/persistence are not seaside only.. Cheers mariano > > Thanks&Regards, > Sourav Roy > Bangalore-India > > > > Get Yourself a cool, short *(a)in.com* Email ID now!<http://mail.in.com/mails/new_reg.php?utm_source=invite&utm_medium=outgoing> > -- Mariano http://marianopeck.wordpress.com

April 14, 2011

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

by pharo＠googlecode.com

Comment #4 on issue 4018 by alexandr...(a)gmail.com: Color class enhancement http://code.google.com/p/pharo/issues/detail?id=4018 A new version of ColorEnh.2.cs without the mondrian method category. Thanks Torsten for seeing this. Attachments: ColorEnh.2.cs 1.6 KB

April 14, 2011