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

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

by csrabak＠bol.com.br

Not willing to rattle cages, reading this particular set of postings I wonder if its my sole feeling or this kind of code 'leads to' naturally to a screaming need for a CaseOf construct? In the snippet below submitted by Dale if we have some other [expected] numeric errors (a.k.a. 'reasons') you would end up with a very hairy entanglement of ifTrue:[]ifFalse:[], wouldn't you? my 0.01999..... -- Cesar Rabak Em 14/04/2011 15:52, Dale Henrichs < dhenrich(a)vmware.com > escreveu: Stef, For rangeError the code would look like this: [ (NumericError new) reason: #rangeError; signal: 'access out of bounds' ] on: NumericError do: [:ex | ex reasonCode == #rangeError ifTrue: [ "do your thang" ] ifFalse: [ ex pass ]]. Dale On 04/14/2011 11:13 AM, StÃ©phane Ducasse wrote: > 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 ** >> #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 ** >> > >

April 14, 2011

Re: [Pharo-project] Magma

by Elliot Finley

On Thu, Apr 14, 2011 at 1:51 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > FYI: Chris Muller plans to update Magma for Pharo 1.2 > > http://lists.squeakfoundation.org/pipermail/magma/2011-April/001756.html > > We now get more package maintainers to see value in supporting Pharo > and I think this is a good thing If you read that entire message, you'll see that he doesn't intend to support Pharo beyond 1.2 without either A) compensation or B) developers from Pharo to do the support.

April 14, 2011

[Pharo-project] Issue 4023 in pharo: 'Transcript clear' prints 'Transcript' after clearing prior text

by pharo＠googlecode.com

Status: New Owner: ---- New issue 4023 by DougEdmu...(a)gmail.com: 'Transcript clear' prints 'Transcript' after clearing prior text http://code.google.com/p/pharo/issues/detail?id=4023 Pharo image: Pharo | Pharo-core Pharo core version: Pharo1.3a Latest update: #13144 Virtual machine used: PHaro4.1.1 on Win32 Class browser used (if applicable): "SystemBrowser default" Steps to reproduce: 1. Open a transcript 2. Open a workspace. Send some text to transcript, i.e., Transcript show: 'hello'; cr. 3. Type 'Transcript clear.' in workspace Result: All prior text removed, but now the word "Transcript" appears.

April 14, 2011

[Pharo-project] presentation

by Santiago Bragagnolo

Hi Pharo friends, I'm Santiago Bragagnolo from Argentina. (Colleague of some users of this list from Argentina too) I'm currently teaching smalltalk in UTN and getting deep in this amazing world. So, i want to contribute to pharo comunity, fixing issues, developing new features, etc. Ok, how can achive mi goals xD? (too formal? sorry if my english is not enough clear or usual :) ) Greetings. Santiago.

April 14, 2011

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

by Henrik Sperre Johansen

On 14.04.2011 20:52, Dale Henrichs wrote: > Stef, > > For rangeError the code would look like this: > > [ > (NumericError new) > reason: #rangeError; > signal: 'access out of bounds' > ] > on: NumericError > do: [:ex | > ex reasonCode == #rangeError > ifTrue: [ "do your thang" ] > ifFalse: [ ex pass ]]. > > Dale Why not use #tag, which is already ANSI? Cheers, Henry

April 14, 2011

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

by Dale Henrichs

On 04/14/2011 11:38 AM, Sven Van Caekenberghe wrote: > Dale, > > I think I understand some of your points, there based on valid concerns. We should end up with a minimal set of exceptions. The current set was not that large IMHO. But here and there some simplifications are possible. > > Thanks for submitting a concrete alternative hierarchy. > > However, it feels as if the reasons between using a class and a selector are a bit arbitrary. I can't make sense out of it. > > Another thing that hasn't been discussed so far is what data should go in each exception. > > This has to be done on a blackboard with a couple of people. And it won't be finished in one go either, far from it. > > I'll print out your hierarchy as well ! > > Sven Sven, The names with leading $# were intended to be reasonCodes and with no leading $# a class name ... When I editted the list I wasn't thinking very hard:), but I made a best guess based on what I thought the name entailed (and we had touched on some of the same things in our GemStone discussions)...So I wouldn't put much weight on the specifics in my suggestions, I think you get the general idea ... the more important information was in my suggested guidelines ... the decisions should be driven by the needs of the existing Pharo code base both the core and the applications written against the core ... BTW, I fully support what you are trying to do and building a good usable Exception hierarchy is important ... I just wanted to inject a suggestion or two for consideration... Dale

April 14, 2011

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

by Dale Henrichs

Stef, For rangeError the code would look like this: [ (NumericError new) reason: #rangeError; signal: 'access out of bounds' ] on: NumericError do: [:ex | ex reasonCode == #rangeError ifTrue: [ "do your thang" ] ifFalse: [ ex pass ]]. Dale On 04/14/2011 11:13 AM, StÃ©phane Ducasse wrote: > 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] Improving Pharo's Exception Hierarchy

by Sven Van Caekenberghe

Dale, I think I understand some of your points, there based on valid concerns. We should end up with a minimal set of exceptions. The current set was not that large IMHO. But here and there some simplifications are possible. Thanks for submitting a concrete alternative hierarchy. However, it feels as if the reasons between using a class and a selector are a bit arbitrary. I can't make sense out of it. Another thing that hasn't been discussed so far is what data should go in each exception. This has to be done on a blackboard with a couple of people. And it won't be finished in one go either, far from it. I'll print out your hierarchy as well ! Sven On 14 Apr 2011, at 18:07, Dale Henrichs wrote: > 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 20:13 +0200, StÃ©phane Ducasse escribiÃ³: > Dale > > so it means that I write what? > > [] on: NumericError do: [:ex | ] > > how do I access the rangeError? [] on: NumericError do: [ :ex | ex reasonCode "This gets you #rangeError or any other symbol to detail the exception" ] Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 14, 2011

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

by Toon Verwaest

On 04/14/2011 08:09 PM, StÃ©phane Ducasse wrote: > 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 Well for robustness reasons I suggest to start the port with only layouts and 1 type of slot object (the standard slot object). This slot object will in the first phase not influence compilation at all. We can also (in the first phase) keep the class format exactly the same as it was before, to not interfere with existing tools and code. This makes the layouts only metadata that is used by the class builder and the interface between the compiler and classes. The inspector can easily be rewritten to also use the slot metaobjects. If we do it in that format, I can tell you that layouts are stable and so is the migration. I can remove the decompilation/recompilation based on Opal for fast method rewriting for now, if you want to avoid too many dependencies at first and test the whole class builder independent of how methods are updated. This is basically just 1 line of code that needs to be changed so I can easily disable that ... If you give me an exact plan and an image into which I can bootstrap my classbuilder, I can do this first step by myself. Someone with more knowledge of the whole ecosystem could then help me to smooth out the problems. The only thing that isn't working yet atm is the class globals (the class variables), but that isn't really hard; it just needs to be done :) I really didn't care about that part, which is why it isn't there yet. Obviously my suggestion means that you won't have slots yet in the beginning, but I think that's the safest bet for now. The classbuilder works and doesn't introduce new concepts yet. It just cleans up existing code. cheers, Toon

April 14, 2011