Pharo changing the game
Locked
12
12
Re: Pharo changing the game
 
|
On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <[hidden email]> wrote:
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.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post 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. 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Martinez Peck
>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On 12 February 2010 14:51, Stéphane Ducasse <[hidden email]> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo changing the game
|
|
In reply to this post by Stéphane Ducasse
On Fri, Feb 12, 2010 at 10:30 AM, Stéphane Ducasse <[hidden email]> wrote:
another point, what about automatic initialize? 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo changing the game
|
|
In reply to this post by Stéphane Ducasse
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Peter Hugosson-Miller
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 <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Peter Hugosson-Miller
Em 12/02/2010 12:15, Peter Hugosson-Miller < [hidden email] > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo changing the game
|
|
In reply to this post by Stéphane Ducasse
On Fri, Feb 12, 2010 at 3:33 PM, Stéphane Ducasse <[hidden email]> wrote: Hi Peter Thanks, Stef, Cesar So you're still talking about having the message #initialize being explicitly sent from within the #new method, right up there on Behavior. I definitely like this arrangement: one of the first things I always do is to implement #new that way, as far up as I can in the domain object hierarchy.
For a moment there I imagined you meant some "behind-the-scenes-magic", and that the #initialize send would not be explicit anywhere in the code. Now I can relax again ;-)
-- Cheers, Peter _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Mariano Martinez Peck
On Fri, 12 Feb 2010, Mariano Martinez Peck wrote:
> On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <[hidden email]> 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. AFAIK apicall: uses the stdcall calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#stdcall), while cdecl: uses the cdecl calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl). So it depends on the function's calling convention which you should use (and not the OS). Levente > > >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo changing the game
|
|
On Fri, Feb 12, 2010 at 4:21 PM, Levente Uzonyi <[hidden email]> wrote:
Thanks Levente. I noticed what you said. But it seems that a OS usually takes one of those conventions as default or at least most commonly used. Would be cool to have the default implemented depending in the OS (no need to explicitly say it) and if you don't want it (the default) just put what you want ? Cheers Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Mariano,
Unfortunately the convention is from the library provider not exactly the OS. This is a consequence of all infrastructure in present days be done in C, but in a non distant future you would also see Pascal calling convention. . . I think this aspect would be less important to user (general application programmers [instead of core or 'system' programmers]) if we had already a more complete set of libraries for typical functionality needed in the daily chores. -- Cesar Rabak Em 12/02/2010 14:26, Mariano Martinez Peck < [hidden email] > escreveu: On Fri, Feb 12, 2010 at 4:21 PM, Levente Uzonyi <[hidden email]> wrote: On Fri, 12 Feb 2010, Mariano Martinez Peck wrote: > On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <[hidden email]> 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 > 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. AFAIK apicall: uses the stdcall calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#stdcall), while cdecl: uses the cdecl calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl). So it depends on the function's calling convention which you should use (and not the OS). Thanks Levente. I noticed what you said. But it seems that a OS usually takes one of those conventions as default or at least most commonly used. Would be cool to have the default implemented depending in the OS (no need to explicitly say it) and if you don't want it (the default) just put what you want ? Cheers Mariano Levente > > >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I first heard of the Pascal convention in connection with Windows programming, shortly after the KT extinction. Right or wrong (MS' track record leaves me biased), they did it in the name of efficiency.
It is true that we can certainly use more code for everyday tasks, but that list is somewhat long. It is unrealistic to assume that we could ever provide all needed functionality, nor is Smalltalk code always appropriate on performance grounds, so some type of callout/back facility will be essential. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Friday, February 12, 2010 12:00 PM To: [hidden email] Subject: Re: [Pharo-project] Pharo changing the game Mariano, Unfortunately the convention is from the library provider not exactly the OS. This is a consequence of all infrastructure in present days be done in C, but in a non distant future you would also see Pascal calling convention. . . I think this aspect would be less important to user (general application programmers [instead of core or 'system' programmers]) if we had already a more complete set of libraries for typical functionality needed in the daily chores. -- Cesar Rabak Em 12/02/2010 14:26, Mariano Martinez Peck < [hidden email] > escreveu: On Fri, Feb 12, 2010 at 4:21 PM, Levente Uzonyi <[hidden email]> wrote: On Fri, 12 Feb 2010, Mariano Martinez Peck wrote: > On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <[hidden email]> 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 > 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. AFAIK apicall: uses the stdcall calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#stdcall), while cdecl: uses the cdecl calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl). So it depends on the function's calling convention which you should use (and not the OS). Thanks Levente. I noticed what you said. But it seems that a OS usually takes one of those conventions as default or at least most commonly used. Would be cool to have the default implemented depending in the OS (no need to explicitly say it) and if you don't want it (the default) just put what you want ? Cheers Mariano Levente > > >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote:
> >> 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. The interface in base VW is, I'm afraid, not good, and should not be emulated. However, the WriteBarriers parcel, in preview in VW 7.7, is a start at a better API for this. The basic problem is that the underlying VM "immutability" feature is useful for many things besides immutability. But the API is designed only for immutability, and using it for anything else is very ugly. It was probably a mistake to name the VM feature "immutability" in the first place. It's really "trap on write" and when you get a trap you can do many things -- reject the modification, conditionally allow it, notify then allow... Regards, -Martin _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I think the really tragic thing is that nothing in Smalltalk remains stable.
It would seem to me that in a language that has been around thirty years or so that core data types like numbers, dates, times, and (hopefully, although adoption of unicode was disruptive) strings would be the same across all the dialects. By now, there should be some chunks of the system that we can deem fully mature and then learn to LEAVE ALONE. The 16rff issue is a fine example of an absolutely stupid incompatibility. Just my $.04 -Todd Blanchard _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Send code and it will be fixed in one hour.
Stef > I think the really tragic thing is that nothing in Smalltalk remains stable. > > It would seem to me that in a language that has been around thirty years or so that core data types like numbers, dates, times, and (hopefully, although adoption of unicode was disruptive) strings would be the same across all the dialects. > > By now, there should be some chunks of the system that we can deem fully mature and then learn to LEAVE ALONE. > > The 16rff issue is a fine example of an absolutely stupid incompatibility. > > Just my $.04 > > -Todd Blanchard > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2010/2/13 Stéphane Ducasse <[hidden email]>:
> Send code and it will be fixed in one hour. > > Stef > And you'll break another feature 16r7Fe7. So you have to think twice... Nicolas >> I think the really tragic thing is that nothing in Smalltalk remains stable. >> >> It would seem to me that in a language that has been around thirty years or so that core data types like numbers, dates, times, and (hopefully, although adoption of unicode was disruptive) strings would be the same across all the dialects. >> >> By now, there should be some chunks of the system that we can deem fully mature and then learn to LEAVE ALONE. >> >> The 16rff issue is a fine example of an absolutely stupid incompatibility. >> >> Just my $.04 >> >> -Todd Blanchard >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
It is not a code problem. It is a social/political problem.
On Feb 13, 2010, at 1:52 AM, Stéphane Ducasse wrote: > Send code and it will be fixed in one hour. > > Stef > >> I think the really tragic thing is that nothing in Smalltalk remains stable. >> >> It would seem to me that in a language that has been around thirty years or so that core data types like numbers, dates, times, and (hopefully, although adoption of unicode was disruptive) strings would be the same across all the dialects. >> >> By now, there should be some chunks of the system that we can deem fully mature and then learn to LEAVE ALONE. >> >> The 16rff issue is a fine example of an absolutely stupid incompatibility. >> >> Just my $.04 >> >> -Todd Blanchard >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eagle Offshore
On 13 February 2010 03:12, Eagle Offshore <[hidden email]> wrote:
> I think the really tragic thing is that nothing in Smalltalk remains stable. > Hehe.. and i love smalltalk exactly because of that! Let's not forget that it is hardware, which called 'an early frozen software'. Smalltalk evolves, because IT CAN. ;) But sure, its not hard to find a stable things nowadays - see java with its 'final' stuff :) > It would seem to me that in a language that has been around thirty years or so that core data types like numbers, dates, times, and (hopefully, although adoption of unicode was disruptive) strings would be the same across all the dialects. > > By now, there should be some chunks of the system that we can deem fully mature and then learn to LEAVE ALONE. > > The 16rff issue is a fine example of an absolutely stupid incompatibility. > > Just my $.04 > > -Todd Blanchard > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eagle Offshore
> It is not a code problem. It is a social/political problem. Right now yes: 16rff now is working in pharo as well as Squeak. The question is how much do we put on the table to make what we believe important done. In addition do you prefer an old greyish smalltalk or a new one showing interest and trying to build new stuff? I chose my camp and backward compatibility will not keep pharo in a closet or in a can http://en.wikipedia.org/wiki/Nothing_Safe:_Best_of_the_Box Now people can use VW, Dolphin or VA if they want. I would have prefer that non open source smalltalk show the way (they did partly (parcel, pragma) but I cannot run dolphin on mac or linux, VW nearly missed Seaside....). Now the question is what people do for their dreams. Pharo is not my daily work. I have to do a lot more and other tasks. I work on it every time I can and my goal is to make it cool: first class instance variable, well designed, modular.... Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |