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

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

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

by StÃ©phane Ducasse

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 > > >

April 13, 2011

Re: [Pharo-project] Issue 3984 in pharo: Announcements announced when a test is runned

by pharo＠googlecode.com

Updates: Status: Started Comment #4 on issue 3984 by stephane...(a)gmail.com: Announcements announced when a test is runned http://code.google.com/p/pharo/issues/detail?id=3984 (No comment was entered for this change.)

April 13, 2011

Re: [Pharo-project] Issue 3991 in pharo: use them instead of UITheme current

by pharo＠googlecode.com

Comment #3 on issue 3991 by stephane...(a)gmail.com: use them instead of UITheme current http://code.google.com/p/pharo/issues/detail?id=3991 in 13146

April 13, 2011

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

by StÃ©phane Ducasse

I really interested to see if pharo would run on a JVM. Do you know what smalltalk they are working on? Stef On Apr 12, 2011, at 4:20 PM, Stephan Eggermont wrote: > http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-April/002802.html >

April 13, 2011

Re: [Pharo-project] Issue 3497 in pharo: Monticello Browser, +slice doesn't validate for not selecting any package

by pharo＠googlecode.com

Comment #6 on issue 3497 by damien.c...(a)gmail.com: Monticello Browser, +slice doesn't validate for not selecting any package http://code.google.com/p/pharo/issues/detail?id=3497 I did what Mariano suggested: when the slice creation window is opened and you have to type the issue number and summary, the 'ok' button is getting enabled if and only if there is at least one dirty package selected.

April 13, 2011

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

by laurent laffont

On Tue, Apr 12, 2011 at 6:07 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > Hi guys > > I started to put in shape a chapter on floats based on the numerous > discussions we got over the years. > You can find it on github under the pharo by example book/Floats > For me it's a good candidate for a ProfStef tutorial (text, evaluations, text, ...) Laurent > > > Stef > >

April 13, 2011