February 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] labeled or labelled?

by Torsten Bergmann

Question to native english speakers, what is correct: a) MyClass labeled: 'foo' b) MyClass labelled: 'foo' for a class MyClass defining an instance variable "label". Me and google would tend to a) but there is a method #labelled: on SystemWindow. Thx T. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Feb. 12, 2010

Re: [Pharo-project] [squeak-dev] Re: The Trunk: Multilingual-ar.87.mcz

by K. K. Subramaniam

On Friday 12 February 2010 02:40:36 pm John M McIntosh wrote: > '1.0e+2' asNumber > returns 1.0 Squeak (Trunk) shows: '1.0e2' asNumber 100 '1.0e+2' asNumber 1.0 :-/ .. Subbu

Feb. 12, 2010

Re: [Pharo-project] ProfStef

by laurent laffont

Hi, May be it's time to decouple ProfStef (the simple workspace one) from Tutorial Browser ? It seems goals are not the same: - ProfStef as a little game to learn Smalltalk, interactive. Stay tiny, simple (..is beautiful :) - Tutorial / Help Browser to be an integrated help system with focused on "easy to write docs" using Danny's great work. What do you think ? Laurent Laffont On Fri, Feb 12, 2010 at 10:46 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > I like the "browser" version of ProfStef more than the simple "workspace" > based version. Especially since it allows us to provide more tutorials > in the dev image just by loading. > > The tutorial browser could be one access point (accessible from world > menu) and is extensible by loading a package with an own tutorial > (like Metacello, ...) > > Unfortunately "ConfigurationOfProfStef" currently only uses > the simple workspace version. > > What's the plan here? > > > A vision for the future: > - a generalized help system maybe similar to what we know from Eclipse > [1], KDE [2], or Windows [3] > - nested tutorials with deeper structure than (currently) one > - the ability to use "help" in a tool which opens a > specific chapter and show people how to use Monticello, TestRunner, ... > - tutorials/help descriptions managed like code > (no pointers to outdated wiki pages from Squeak) > - an active help system with live code samples and maybe based on > a cleaned up Bookmorph? ;) > > We are already halfway there, arent we? > > Thx > T. > > [1] > http://www.ibm.com/developerworks/cn/linux/opensource/os-echelp/eclipse-hel… > [2] > http://www.lrz-muenchen.de/services/compute/linux-cluster/intro/khelpcenter… > [3] http://www.knopf.com/resources/help/screenshots/winhelp2k.gif > > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Lukas Renggli

<summary>My point is that the ANSI standard is **not restrictive**. It does **not prevent** you from inventing a better future. It allows you to do whatever you like. I argue to not break the ANSI standard unnecessarly, but support it and avoid further fritting of the different Smalltalk implementations. If possible, we should also try to adopt APIs of existing functionality in other dialects.</summary> > you mean like nil been able to be put in a set? > I would like to have nil as any other object and I hope that this is in the standard. ANSI does not say anything about that. We are free to do whatever we want. > I would like to have immutability for certain classes (string, point....) > Does the standard says something about it? ANSI does not say anything about that. We are free to do whatever we want. However, since VW already implements immutability, it would probably be beneficial to chose an API that is close to the VW implementation. > My point is that I'm in favor of compatibility but not at the cost of been kept in the 80e > I want to live in the 2020 years. The ANSI standard doesn't say anything about Exceptions or Pragmas either. - Exceptions: Today all Smalltalk platforms support the same exception API, mainly due to the fact that Seaside makes heavy use of some very specific exception features like resumable exceptions, exception sets, nesting exceptions, etc. VA had a very different implementation. Nowadays they do support basically the same protocol as Pharo, thanks to the tests we wrote for Seaside. - Pragmas: In the beginning only VW had pragmas. I implemented the same API for Squeak 3.9. Today all existing Smalltalk platforms support these kind of pragmas. Pragmas and exceptions are suddenly portable, what is a great win. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 12, 2010

[Pharo-project] ProfStef

by Torsten Bergmann

Hi, I like the "browser" version of ProfStef more than the simple "workspace" based version. Especially since it allows us to provide more tutorials in the dev image just by loading. The tutorial browser could be one access point (accessible from world menu) and is extensible by loading a package with an own tutorial (like Metacello, ...) Unfortunately "ConfigurationOfProfStef" currently only uses the simple workspace version. What's the plan here? A vision for the future: - a generalized help system maybe similar to what we know from Eclipse [1], KDE [2], or Windows [3] - nested tutorials with deeper structure than (currently) one - the ability to use "help" in a tool which opens a specific chapter and show people how to use Monticello, TestRunner, ... - tutorials/help descriptions managed like code (no pointers to outdated wiki pages from Squeak) - an active help system with live code samples and maybe based on a cleaned up Bookmorph? ;) We are already halfway there, arent we? Thx T. [1] http://www.ibm.com/developerworks/cn/linux/opensource/os-echelp/eclipse-hel… [2] http://www.lrz-muenchen.de/services/compute/linux-cluster/intro/khelpcenter… [3] http://www.knopf.com/resources/help/screenshots/winhelp2k.gif -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by StÃ©phane Ducasse

another point, what about automatic initialize? At one point in the past VW (eliot) was really for introducing it in VW since it would not cost anything in presence of the JIT. Dolphin people did it on Model but they told me that if they could they would remove it. and this is a really important change to lower the entry level and burden of newcomers. Now because of "compatibility" we have to code without it for me this is a drawback. Do we imagine Seaside could have been invented by VisualAge Smalltalkers (no punt intended)? No because there is no thisContext!!! Sad! My point is what is the price to pay to compatibility. Stef On Feb 12, 2010, at 8:02 AM, Lukas Renggli wrote: >> So yeah, if you're writing a counter application that's probably >> portable. But as soon as you start to do Pier or Magritte you can write >> your own portability classes for everything that Seaside does not need. >> If you're doing a Pier addon like AudioScrobbler or TopFeeder you're >> almost guaranteed that it's not portable. Believe when I say I speak >> from experience and it's really frustrating. > > For the average Smalltalk user the ANSI standard does not matter much. > It only matters for those that want to be able to port libraries > between Smalltalk dialects. I think making portability as easy as > possible should be a major focus of all Smalltalk dialects. There are > simply not enough good libraries available in any Smalltalk > implementation. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 12, 2010

Re: [Pharo-project] [squeak-dev] Re: The Trunk: Multilingual-ar.87.mcz

by John M McIntosh

Also see http://code.google.com/p/pharo/issues/detail?id=1258 '.1' asNumber toss an error in Pharo 1.1 11043 and '1.0e+2' asNumber returns 1.0 yet other I think more knowledgeable people say http://www.wolframalpha.com/input/?i=1.0e%2B2 100 I'd just say any expectations of converting a string to a number in most flavours of Squeak should be viewed with suspicion. On 2010-02-12, at 12:44 AM, Andreas Raab wrote: > Nicolas Cellier wrote: >> This of course fail with Number>>readFrom: >> You can also simply try >> 3r1.1e55 - 3r11.0e54 >> and the SqNumberParser form... >> (SqNumberParser parse: '3r1.1e55') - (SqNumberParser parse: '3r11.0e54') >> Maybe it's time to push the readFrom: changes i already pushed in Pharo... > > Go for it. You're the best expert we have in this area, and I trust your judgment. > > Cheers, > - Andreas > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by StÃ©phane Ducasse

We are not talking only about syntax. you mean like nil been able to be put in a set? I would like to have nil as any other object and I hope that this is in the standard. I would like to have immutability for certain classes (string, point....) Does the standard says something about it? My point is that I'm in favor of compatibility but not at the cost of been kept in the 80e I want to live in the 2020 years. Stef >> So yeah, if you're writing a counter application that's probably >> portable. But as soon as you start to do Pier or Magritte you can write >> your own portability classes for everything that Seaside does not need. >> If you're doing a Pier addon like AudioScrobbler or TopFeeder you're >> almost guaranteed that it's not portable. Believe when I say I speak >> from experience and it's really frustrating. > > For the average Smalltalk user the ANSI standard does not matter much. > It only matters for those that want to be able to port libraries > between Smalltalk dialects. I think making portability as easy as > possible should be a major focus of all Smalltalk dialects. There are > simply not enough good libraries available in any Smalltalk > implementation. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Lukas Renggli

> So yeah, if you're writing a counter application that's probably > portable. But as soon as you start to do Pier or Magritte you can write > your own portability classes for everything that Seaside does not need. > If you're doing a Pier addon like AudioScrobbler or TopFeeder you're > almost guaranteed that it's not portable. Believe when I say I speak > from experience and it's really frustrating. For the average Smalltalk user the ANSI standard does not matter much. It only matters for those that want to be able to port libraries between Smalltalk dialects. I think making portability as easy as possible should be a major focus of all Smalltalk dialects. There are simply not enough good libraries available in any Smalltalk implementation. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Philippe Marschall

On 11.02.2010 21:42, StÃ©phane Ducasse wrote: > pfff.... I should say that kent should have not broken his rule. > Don't blog when you are mad. It gives a bad impression and not only about smalltalk > > > Now what is the solution. > get stuck with a ANSI bad standard? > get with vendors evolution that are not optimal? > > what if we do not like VW Namespace ? > what if we would like to have first class instance variables? > Vendors like parceplace did not really ask the community about the changes they did. > > Now Seaside is developed on pharo and run on nearly all the dialects so there > is a path. It is not easy. Because what we settled for is that every vendor has to rewrite a chunk of Seaside. Because we left out all the non basic stuff like files, sockets, os access, graphics, sound, logging, xml parsing, database access, crypto, .... Seaside itself is not portable, it's simply possible to only load the parts which we assume to be portable. So yeah, if you're writing a counter application that's probably portable. But as soon as you start to do Pier or Magritte you can write your own portability classes for everything that Seaside does not need. If you're doing a Pier addon like AudioScrobbler or TopFeeder you're almost guaranteed that it's not portable. Believe when I say I speak from experience and it's really frustrating. Cheers Philippe

Feb. 12, 2010