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

[Pharo-project] Issue 4004 in pharo: Obsolete class references to AutoStart

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 4004 by marcus.d...(a)gmail.com: Obsolete class references to AutoStart http://code.google.com/p/pharo/issues/detail?id=4004 Two methods: #loadUpdateFromServerAtStartup AbstractLauncher class autoStarter ScriptLoader update13147

April 13, 2011

[Pharo-project] Issue 4003 in pharo: Build of Core 1.3 broken because of integration of 13147

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 4003 by marcus.d...(a)gmail.com: Build of Core 1.3 broken because of integration of 13147 http://code.google.com/p/pharo/issues/detail?id=4003 Issue 13147 has some problem: + /builds/builder/build13.sh -i gforgeCore13 -s update -o PharoCore-1.3 Segmentation fault 2031166104 Behavior>allInstancesDo: 2031165968 Behavior>allSubInstancesDo: 2031165876 Behavior>allSubInstances 2031165724 >shutDown: 2031165632 SmalltalkImage>send:toClassesNamedIn:with: 2031165540 BlockClosure>on:do: 2031165448 SmalltalkImage>send:toClassesNamedIn:with: 2031148208 OrderedCollection>do: 2031148116 SmalltalkImage>send:toClassesNamedIn:with: 2031148024 SmalltalkImage>processShutDownList: 2031132380 SmalltalkImage>snapshot:andQuit: 2031132288 UndefinedObject>? 2028739856 WorldState>runStepMethodsIn: 2028739764 PasteUpMorph>runStepMethods 2025422416 WorldState>doOneCycleNowFor: 2025422324 WorldState>doOneCycleFor: 2025422232 PasteUpMorph>doOneCycle 2015335972 >? 2015335880 BlockClosure>? /tmp/hudson2223222193118569935.sh: line 3: 19842 Aborted /builds/builder/build13.sh -i gforgeCore13 -s update -o PharoCore-1.3 Archiving artifacts Enregistrement des r?sultats des tests

April 13, 2011

[Pharo-project] Issue 4002 in pharo: AbstractLauncher needs to be removed

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 4002 by marcus.d...(a)gmail.com: AbstractLauncher needs to be removed http://code.google.com/p/pharo/issues/detail?id=4002 ...make sure to rewrite the SystemSettings references. I think we should remove #readDocumentAtStartup Why would one ever not lead a script that is given as a command line option?

April 13, 2011

[Pharo-project] [update 1.3] #13147

by Marcus Denker

13147 ----- Issue 3818: CommandLine Manager (some cleanup of Undeclared AutoStart will be needed later) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 13, 2011

Re: [Pharo-project] Issue 3818 in pharo: CommandLine Manager

by pharo＠googlecode.com

Updates: Status: Closed Comment #8 on issue 3818 by marcus.d...(a)gmail.com: CommandLine Manager http://code.google.com/p/pharo/issues/detail?id=3818 in 13147

April 13, 2011

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

by Sven Van Caekenberghe

On 13 Apr 2011, at 10:50, Mariano Martinez Peck wrote: > You probably know the PharoByExample chapter on exceptions, > but just in case: https://gforge.inria.fr/frs/download.php/26600/PBE2-Exceptions-2010-03-02.p… Seems like the right kind of preparation, I will reread it. I love written documentation. Thanks! Sven

April 13, 2011

Re: [Pharo-project] Issue 1817 in pharo: [etoy] Should remove project

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #2 on issue 1817 by marcus.d...(a)gmail.com: [etoy] Should remove project http://code.google.com/p/pharo/issues/detail?id=1817 So we can now easily remove Project: the only thing left are some methods on the class side that are already in MorphicUIManager (forwarding there to Project).

April 13, 2011

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

by Mariano Martinez Peck

On Mon, Apr 11, 2011 at 4:10 PM, Sven Van Caekenberghe <sven(a)beta9.be>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. You probably know the PharoByExample chapter on exceptions, but just in case: https://gforge.inria.fr/frs/download.php/26600/PBE2-Exceptions-2010-03-02.p… Cheers Mariano > 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. > > Regards, > > Sven > > > > -- Mariano http://marianopeck.wordpress.com

April 13, 2011

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

by Mariano Martinez Peck

I like the idea. Another thing that we may think about is the exception conventio name... Do the classes need a suffix or not ? which ones? Exception/Error/Warning? when Exception and when Error ? Cheers Mariano On Wed, Apr 13, 2011 at 9:24 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > sven did you get a look at issue 3999 since camillo started. > > http://code.google.com/p/pharo/issues/detail?id=3999 > > Stef > > On Apr 11, 2011, at 4: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. > > > > Regards, > > > > Sven > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 13, 2011

Re: [Pharo-project] Issue 3997 in pharo: Move all code in Morph related the properties, to a trait: TProperties

by pharo＠googlecode.com

Comment #1 on issue 3997 by fernando...(a)gmail.com: Move all code in Morph related the properties, to a trait: TProperties http://code.google.com/p/pharo/issues/detail?id=3997 I made a mistake in the first fix. The TProperties should be plugged into MorphExtension, instead of Morph. Load ONLY the file TPropertiesAddition.2. Disregard previous change sets. Attachments: TPropertiesAddition.2.cs 3.8 KB

April 13, 2011