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

Re: [Pharo-project] Pharo changing the game

by csrabak＠bol.com.br

Em 12/02/2010 12:15, Peter Hugosson-Miller < oldmanlink(a)gmail.com > escreveu: > I know this is probably a stupid question, but rather than miss > something important, I'll take that risk :-p > What do you mean by "automatic initialize"? Â« The only stupid question is one not asked. Â» ;-) -- Cesar Rabak

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by StÃ©phane Ducasse

Hi Peter there is no stupid question! Only people afraid to ask. Stupidity is when you ask three times the same question. In this list we can ask all the stupid question we want. So thanks for taking the risk :) automatic initialize= calling automatically initialize when calling new avoid to have to all the time write Box class>>new ^ super new initialize ; yourself kind of desastrous for newbies. You know after two lectures you have to nearly explain metaclasses, and deep super + method lookup... In Squeak 3.7 we got a chance to have an agreement to have Behavior>> new ^ self basicNew initialize Object>>initialize ^ self and some shortcuting behavior on array to speed up the system. it makes so many things much much nicer. On Feb 12, 2010, at 3:15 PM, Peter Hugosson-Miller wrote: > On Fri, Feb 12, 2010 at 10:30 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. > > I know this is probably a stupid question, but rather than miss something important, I'll take that risk :-p > > What do you mean by "automatic initialize"? > > -- > Cheers, > Peter > _______________________________________________ > 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 Henrik Johansen

Den 12.02.2010 14:52, skrev StÃ©phane Ducasse: >> > Hint: FFI has its own proprietary hardcoded pragma format. > > PS: do you know if FFI declarations are compatible with VW ones or they are > just funky? > FWIW, DLLCC-declarations are not pragma-compatible either, not sure if they're the same as FFI though. In fact, seing as how ExternalMethod depends on inst var indexes, you *can't* annotate DLLCC-methods (AnnotatedMethod adds inst var with pragmas, so can't easily make ExternalMethod a subclass of it). I see it's implemented differently in Squeak/Pharo though, is it possible to do that with FFI? How about Alien? In my mind, that is a loss for external libraries accessing-code which wants to provide a nice way to deal with changing versions (where version is queriable from the library), as it . F.ex. in the case of OpenGL, being able to tag the ExternalMethods with pragmas like <coreMajor: > <coreMinor: > <deprecatedMajor:> <ext: > <nv:>, etc would make it possible to know if an unsuccessfully resolved method was due to not being supported by your driver/hardware, or a coding error somewhere. It would also be easier to programatically build version-compliant interfaces instead of always prividing an Interface with a superset of what is needed/available. Plus, reasoning about which versions of a plugin is required from a piece of code using the interface gets a whole lot easier. Sure, you can do all of the above with dictionaries of which versions include which methods, but upgrading that to support a new version would be a huge pain, wheras with the pragma approach you simply add new annotations for the things which have changed. Cheers, Henry

Feb. 12, 2010

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

by csrabak＠bol.com.br

Except if my analytical skills are impaired by being tired and groggy due a very short sleep I think the solution to this is only a matter of putting: sourceStream peekFor: $+. just before eneg := sourceStream peekFor: $-. in SqNumberParser>>readExponent Did I miss something fundamental? my 0.01999. . . . -- Cesar Rabak Em 12/02/2010 11:44, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: 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 _______________________________________________ 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 Peter Hugosson-Miller

On Fri, Feb 12, 2010 at 10:30 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > 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. > I know this is probably a stupid question, but rather than miss something important, I'll take that risk :-p What do you mean by "automatic initialize"? -- Cheers, Peter

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Lukas Renggli

On 12 February 2010 14:51, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. I agree with you too :-) Lukas > > >> <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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Lukas Renggli

>> 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. The reason given by then was that there are a few (1 or 2) existing users of the FFI package. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Lukas Renggli

> 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. ANSI does not say anything about object initialization, so we can do whatever we want and this is fine. If all Smalltalk would adopt the initialization pattern of Pharo we wouldn't need a WAObject class that calls #initialize on all platforms exactly the same way. Either way, for us it doesn't matter how Pharo (or any other Smalltalk) initializes an object. It is really simple to customize. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 12, 2010

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