- Pharo-dev - lists.pharo.org

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

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

by Marcus Denker

On Apr 13, 2011, at 9:32 AM, Philippe Marschall wrote: > On 04/13/2011 09:00 AM, StÃ©phane Ducasse wrote: >> I really interested to see if pharo would run on a JVM. > > Probably not. I mean you all the code relying on primitives, all the > code relying on ByteString having the same memory layout as ByteArray, > all the code relying on the scheduler being non-preemptive, all the > code relying on #become: and so forth. > And does anyone really want a smalltalk without become: ? And how do they do the thisContext magic? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 13, 2011

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

by Philippe Marschall

On 04/13/2011 09:00 AM, StÃ©phane Ducasse wrote: > I really interested to see if pharo would run on a JVM. Probably not. I mean you all the code relying on primitives, all the code relying on ByteString having the same memory layout as ByteArray, all the code relying on the scheduler being non-preemptive, all the code relying on #become: and so forth. Cheers Philippe

April 13, 2011

[Pharo-project] [update 1.3] #13146

by StÃ©phane Ducasse

13146 ----- - Issue 3991: use them instead of UITheme current. Thanks Fernando Olivero. You were faster than me on this one but this is cool since I could review the code faster. Stef

April 13, 2011

[Pharo-project] Fwd: [Seaside] Should I become a Seasider?

by stephane ducasse

we should have that in our success stories. Stef Begin forwarded message: > From: Sven Van Caekenberghe <sven(a)beta9.be> > Date: April 9, 2011 10:25:39 AM GMT+02:00 > To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> > Subject: Re: [Seaside] Should I become a Seasider? > Reply-To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> > > > On 09 Apr 2011, at 09:35, Johan Brichau wrote: > >> Well, to make a long story short, we did exactly that 2 years ago: www.inceptive.be >> Our two core projects are built using Seaside. One of them is already public: www.yesplan.be. The second one is going public by summer. >> >> In one project, we got started explicitly because we were offering a Seaside-based solution. The customer had very bad experiences with traditional software development houses and was explicitly looking for an agile team using a dynamic language to do the job. So, it's fair to say that this was a unique opportunity. However, Seaside and Smalltalk did deliver! In only a single man-year of working hours (not counting the designer), we had produced a working application that other "established" development houses had failed to deliver. Whenever we show the functionality of the application to partnering software producers, they are amazed by the productivity we had gotten. Ah... and it should mention that one person in our team of three had never done any Seaside.... >> >> But, in our second Seaside project, the customers don't care at all what technology is used. They want a good product! And, in my opinion, that is true for many other potential projects we have down the pipeline. For us, Seaside and Smalltalk are powerful tools we can use to leverage a better price and better product in comparison to competitors. In the end, that is what customers want. >> >> In other projects, we are exposed to .net, ios, objective-c, etc... and I generally miss a lot of the power and simplicity of Smalltalk. There is a lot of power in Smalltalk and the Smalltalk community when you look at Gemstone, Seaside, Pharo, Squeak, Visualworks, Cog, etc... ! >> >> There are (of course) occasions when I curse on Smalltalk in general: the lack of (or difficult) interoperability with non-Smalltalk based libraries and the relative small size of Smalltalk libraries is often the biggest hurdle. For every project we intend to do in Smalltalk, we have to carefully analyze the requirements and see if we can meet all of them in the Smalltalk environment. MS-Office interoperability, for example, is a nightmare. >> >> Bottomline: Seaside and Smalltalk are currently our core technologies but not our *only* technologies. You cannot start a business on a single technology and doing business is more than technology.... there are many factors playing a role. > > Yesplan seems very impressive, Johan, this is really looking more and more like a super Success Story. > I absolutely agree with your points/analysis: technology does matter, as does the team, but a great product/solution is the final delivery. > Thanks for sharing all this! > > Sven > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

April 13, 2011