[Pharo-project] Pharo changing the game
Interesting read (read [2] then [1]), maybe Pharo can change the game ... bye T. [1] http://www.jarober.com/blog/blogView?showComments=true&printTitle=Balkanizat... [2] http://www.threeriversinstitute.org/blog/?p=466 -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02
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. Now if would be better to think that what is the future of smalltalk. - scripting - first class instance variables - new look at the MOP - better modules system - ... and we will not to that with ANSI kind of standardization process. Stef BTW this is fun because when I read the bio of Kent on his recent book I do not see Smalltalk mentioned so this is good to know that he is back to smalltalk :)
Interesting read (read [2] then [1]), maybe Pharo can change the game ...
bye T.
[1] http://www.jarober.com/blog/blogView?showComments=true&printTitle=Balkanizat... [2] http://www.threeriversinstitute.org/blog/?p=466 -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
    get stuck with a ANSI bad standard?
The ANSI standard is not bad. It is minimal, maybe too minimal? But it does not forbid anything like #and:and: or Traits. The ANSI standard gives a minimal common dominator. It is absolutely essential to projects like Monticello, OmniBrowser, SUnit, Seaside, Magritte, Pier, ...
Now Seaside is developed on pharo and run on nearly all the dialects so there is a path. It is not easy.
Because we strictly adhere to the ANSI standard and because we have our own platform layer called Grease. http://blog.fitzell.ca/2010/01/easing-compatibility-with-grease.html Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Now why don;t people want a better smalltalk?
get stuck with a ANSI bad standard?
The ANSI standard is not bad. It is minimal, maybe too minimal? But it does not forbid anything like #and:and: or Traits. The ANSI standard gives a minimal common dominator. It is absolutely essential to projects like Monticello, OmniBrowser, SUnit, Seaside, Magritte, Pier, ...
Now Seaside is developed on pharo and run on nearly all the dialects so there is a path. It is not easy.
Because we strictly adhere to the ANSI standard and because we have our own platform layer called Grease.
http://blog.fitzell.ca/2010/01/easing-compatibility-with-grease.html
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Now why don;t people want a better smalltalk?
Sure, everybody wants a better Smalltalk. The ANSI standard does not make scripting impossible, it does not forbid first class instance variables, it does not forbid a MOP or a module system. The ANSI standard only talks about the basic Smalltalk syntax, Collections, Magnitudes, Streams. That's it. I don't think it is limiting in any way. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Er, maybe I'll rant here since it' seems to me this the day for that. Perhaps flavoured a bit with Ralph's accidental post about cilantro. Should we not be talking about the Smalltalk 2010 ANSI proposal? Why the lock in to the Smalltalk ANSI INCITS 319-1998 (R2002) standard? I think this fits into Stephane's comment about moving forward. On 2010-02-11, at 1:51 PM, Lukas Renggli wrote:
Now why don;t people want a better smalltalk?
Sure, everybody wants a better Smalltalk.
The ANSI standard does not make scripting impossible, it does not forbid first class instance variables, it does not forbid a MOP or a module system.
The ANSI standard only talks about the basic Smalltalk syntax, Collections, Magnitudes, Streams. That's it. I don't think it is limiting in any way.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Thu, Feb 11, 2010 at 3:26 PM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:
Er, maybe I'll rant here since it' seems to me this the day for that. Perhaps flavoured a bit with Ralph's accidental post about cilantro.
Should we not be talking about the Smalltalk 2010 ANSI proposal? Why the lock in to the Smalltalk ANSI INCITS 319-1998 (R2002) standard?
I haven't seen much movement since Bruce kicked it off ( http://openskills.blogspot.com/2007/10/ansi-smalltalk.html). One of the hurdles was the amount of money ANSI wanted for participation in the standard. I for one couldn't afford it and couldn't see how Cadence, my then employer, would fund it. I think that goes for most of the non-vendor community. See Clay Shirky's TED presentation<http://www.ted.com/talks/clay_shirky_on_institutions_versus_collaboration.html>on institutions for why IMO ANSI is a non-starter. ANSI is irrelevant; it meets it's own needs, not the needs of the Smalltalk community. It can only ever create an obsolete standard. We need to design our own standard that meets our needs. If we can design a standard that is relevant the community as a whole will increasingly adhere to it over time, and as that happens it will become more useful, and, because it is defined by us, can evolve over time, both in content and at a meta level in its standards-making processes.
I think this fits into Stephane's comment about moving forward.
IMO, moving forward means finding new forms, not putting a new badge on the same old corpse. We need a sci-fi movie not a zombie movie ;)
On 2010-02-11, at 1:51 PM, Lukas Renggli wrote:
Now why don;t people want a better smalltalk?
Sure, everybody wants a better Smalltalk.
The ANSI standard does not make scripting impossible, it does not forbid first class instance variables, it does not forbid a MOP or a module system.
The ANSI standard only talks about the basic Smalltalk syntax, Collections, Magnitudes, Streams. That's it. I don't think it is limiting in any way.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 12.02.2010 00:26, John M McIntosh wrote:
Er, maybe I'll rant here since it' seems to me this the day for that. Perhaps flavoured a bit with Ralph's accidental post about cilantro.
Should we not be talking about the Smalltalk 2010 ANSI proposal? Why the lock in to the Smalltalk ANSI INCITS 319-1998 (R2002) standard?
Because even very basic things like Strings, Symbols and Numbers are a minefield that behave in slightly different ways. And you won't find out until later. I don't want to know how many weeks we wasted on #seasideString. Cheers Philippe
On Thu, Feb 11, 2010 at 1:28 PM, Lukas Renggli <renggli@gmail.com> wrote:
get stuck with a ANSI bad standard?
The ANSI standard is not bad. It is minimal, maybe too minimal? But it does not forbid anything like #and:and: or Traits. The ANSI standard gives a minimal common dominator. It is absolutely essential to projects like Monticello, OmniBrowser, SUnit, Seaside, Magritte, Pier, ...
I think at best it's a curate's egg<http://en.wikipedia.org/wiki/Curate%27s_egg> . First it's hard to browse and lots of the names are un-Smalltalky. Second, it doesn't standardize Smalltalk, only its core libraries. It's all very well to specify a minimal library, but to leave the vast array of reflective facilities unspecified is, for Smalltalk, a huge mistake. The standard, if it wasn't an attempt at a rubber stamp by the vendors, have included optional sections. So that were an implementation to include execution reflection (thisContext) the standard could define what that looked like, but not require an implementation to include execution reflection. The same goes for run-time class creation and method definition. Third, it isn't an extensible standard. If it were forward looking the standard would have put in place some mechanism for adding to the standard (such as a voting scheme) so that over the years excellent extensions to the base library such as beginsWith: first: et al could be added. It would also have defined the kind of versioning facilities that people need to know what version of the standard they can expect (we recently discussed something similar in the context of Metacello and Grease on the Pharo list). There needs to be a global object which can be queried for version information, what core facilities exist and which don't, etc. All of these lacks really hurt projects like Grease (there have been numerous attempts over the years) because there is a raft of dialect-specific code, and one either has to introduce a new global (SmalltalkVersion) or hang the functionality off existing dialect classes (Smalltalk, System, etc, etc). We need a standard that standardises Smalltalk, not C with Smalltalk syntax. Smalltalk is reflective, dynamic and evolves rapidly. That implies a different kind of standard, not overseen by ANSI, whose objective is self-preservation, not standardisation (see Clay Shirkey; do you know how much money ANSI want for a standards process??). We need a living standard that can evolve. I know it is impractical, if not impossible, to standardize the language-development side of Smalltalk, a standard that could extend to e.g. Newspeak. But this is also pointless. No one needs a standard for blue plane. But we have a string need for a standard that standardises Smalltalk as it is used in the industry; one that supports systems like Seaside. There /is/ mutual self-interest in a standard that can help convergence in agreed-upon functionality, that is open, and that can evolve at the right pace (not too fast, or it has no value, not too slow or it has no relevance). Some bright minds at universities that use VW, Pharo, Squeak and VisualAge could do some really interesting work here. The dialects, including those from the vendors, would surely be willing to pitch in if the standard was what Smalltalk is, malleable, incremental, open, comprehensible. best Eliot
Now Seaside is developed on pharo and run on nearly all the dialects so there
is a path. It is not easy.
Because we strictly adhere to the ANSI standard and because we have our own platform layer called Grease.
http://blog.fitzell.ca/2010/01/easing-compatibility-with-grease.html
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
<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
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.
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
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?
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
On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <renggli@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
On Fri, 12 Feb 2010, Mariano Martinez Peck wrote:
On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <renggli@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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Feb 12, 2010 at 4:21 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Fri, 12 Feb 2010, Mariano Martinez Peck wrote:
On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <renggli@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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 < marianopeck@gmail.com > escreveu: On Fri, Feb 12, 2010 at 4:21 PM, Levente Uzonyi <leves@elte.hu> wrote: On Fri, 12 Feb 2010, Mariano Martinez Peck wrote:
On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <renggli@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 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak@bol.com.br Sent: Friday, February 12, 2010 12:00 PM To: Pharo-project@lists.gforge.inria.fr 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 < marianopeck@gmail.com > escreveu: On Fri, Feb 12, 2010 at 4:21 PM, Levente Uzonyi <leves@elte.hu> wrote: On Fri, 12 Feb 2010, Mariano Martinez Peck wrote:
On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <renggli@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 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
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
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/2/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
On 13 February 2010 03:12, Eagle Offshore <eagleoffshore@mac.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 12 February 2010 14:51, Stéphane Ducasse <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
On Fri, Feb 12, 2010 at 10:30 AM, Stéphane Ducasse < stephane.ducasse@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
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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Feb 12, 2010 at 3:33 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
Em 12/02/2010 12:15, Peter Hugosson-Miller < oldmanlink@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
here is also what I added to the blog entry "Improvements can be as simple as that. Now the first level is to communicate with people and let them know that they can improve if they want. So we will probably fix that in Pharo. If somebody provides a fix it can be fix in 2 min. The goal of pharo is to create an innovative Smalltalk that can be use to make business but also to reinvent Smalltalk. And this will not be done without breaking stuff. We do not want to live in a museum. http://www.pharo-project.org for more information and vision statement."
participants (17)
-
csrabak＠bol.com.br -
Eagle Offshore -
Eliot Miranda -
Henrik Johansen -
Igor Stasenko -
John M McIntosh -
Levente Uzonyi -
Lukas Renggli -
Marcus Denker -
Mariano Martinez Peck -
Martin McClure -
Nicolas Cellier -
Peter Hugosson-Miller -
Philippe Marschall -
Schwab,Wilhelm K -
Stéphane Ducasse -
Torsten Bergmann