- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo changing the game

by Mariano Martinez Peck

On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > It is interesting to note that of course, after this was added to 3.9, > there was > > someone *very hard* arguing that adding Pragmas was a very dumb idea... > > > > Who that person was is left as an exercise to the reader of course ;-) > > Hint: FFI has its own proprietary hardcoded pragma format. It > unnecessary complicates the compiler even when not loaded. Not to > mention that it breaks all tools that have their own parser, such as > RB for example. > And I hate having to write <apicall: in windows and <cdecl: in Unix* I would love to be the same and that someone else takes care, not me (the user). Do you know if there is a reason for this? I imagine that yes. > > 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 StÃ©phane Ducasse

>> >> It is interesting to note that of course, after this was added to 3.9, therae was >> someone *very hard* arguing that adding Pragmas was a very dumb idea... >> >> Who that person was is left as an exercise to the reader of course ;-) > > Hint: FFI has its own proprietary hardcoded pragma format. It > unnecessary complicates the compiler even when not loaded. Not to > mention that it breaks all tools that have their own parser, such as > RB for example. I guess I know who you are talking about. ;D PS: do you know if FFI declarations are compatible with VW ones or they are just funky?

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by StÃ©phane Ducasse

I agree with you lukas but my point is that we should be also cautious about not limiting ourselves because of some reasons. I prefer to see a good idea spread in other smalltalk than abandon/not implemented because not compatible. > <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 > > _______________________________________________ > 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 StÃ©phane Ducasse

On Feb 12, 2010, at 10:56 AM, Lukas Renggli wrote: > <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> Yes >> 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. it will really break your code in other dialect. >> I would like to have immutability for certain classes (string, point....) >> Does the standard says something about it? > However, since VW already implements immutability, it would probably > be beneficial to chose an API that is close to the VW implementation. Yes this is the idea. I hope the interface is good. >> 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. I agree.

Feb. 12, 2010

Re: [Pharo-project] ProfStef

by StÃ©phane Ducasse

+1 but let us be incremental and improve step by step. Stef > And I was just thinking that there may be more value *now* in writing tutorials than in writing a full featured help browser ? > > Laurent Laffont > > > On Fri, Feb 12, 2010 at 11:25 AM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > 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 > > > _______________________________________________ > 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 StÃ©phane Ducasse

in pharo too ;( Sef On Feb 12, 2010, at 12:44 PM, K. K. Subramaniam wrote: > 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 > > _______________________________________________ > 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 StÃ©phane Ducasse

If I remember correctly the discussion we decided to have '.1' squeezeOutNumber returning a number and let '.1' asNumber raises an error. Stef On Feb 12, 2010, at 10:10 AM, John M McIntosh wrote: > 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 > =========================================================================== > > > > > > _______________________________________________ > 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] ProfStef

by laurent laffont

And I was just thinking that there may be more value *now* in writing tutorials than in writing a full featured help browser ? Laurent Laffont On Fri, Feb 12, 2010 at 11:25 AM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > 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

> It is interesting to note that of course, after this was added to 3.9, there was > someone *very hard* arguing that adding Pragmas was a very dumb idea... > > Who that person was is left as an exercise to the reader of course ;-) Hint: FFI has its own proprietary hardcoded pragma format. It unnecessary complicates the compiler even when not loaded. Not to mention that it breaks all tools that have their own parser, such as RB for example. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Marcus Denker

On Feb 12, 2010, at 10:56 AM, Lukas Renggli wrote: > > - 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. > It is interesting to note that of course, after this was added to 3.9, there was someone *very hard* arguing that adding Pragmas was a very dumb idea... Who that person was is left as an exercise to the reader of course ;-) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 12, 2010