Hi Tansel -

Nice to hear from you! This little demo is obviously not complete by any means :-) In the longer term, what I am imagining is more along the lines of projects storing their version and their contents and then (upon loading the project) that project first fetching the 'right' version of the code and afterwards loading its contents. This should work quite well assuming that the underpinnings (basic Squeak version etc) don't change. But even then, just recording that this project was saved with version x.y and may have issue when loaded into version x.z goes a very long way.

Cheers, - Andreas

Tansel Ersavas wrote:

This is great news!

I have always liked projects but my earlier attempts of trying to separate them from images didn't go smooth and I had difficulty moving projects between images. (Anyone remember trying to save projects from within SqueakNews issues?) In hindsight most of them were due to lousy global variables or some complex relationships but even a smarter extraction process that can inform potential problems will go a long way. Mobilization of projects a la Squeakland but on a grander scale will greatly enhance the ability to make "the experience" of being in an object world much more attractive.

Tansel

On 26/11/2009, at 3:25 PM, Andreas Raab wrote:

...

Folks -

I always felt that one of the least used "big ideas" in Squeak is that of projects. Projects are incredibly powerful but have often been severely misunderstood. A Project in Squeak can define an entire environment (MVC, Morphic, Tweak), it can be a modification to an existing environment, it can identify a set of tools to be used in some context and more.

The progress that we've made with refactoring of class Project makes it feasible to illustrate the power of projects. If you install the attached change set in an updated trunk image, you will find a new type of project available - a GamesProject. When you choose this type of project you will notice that it downloads and installs the MorphicGames package that Edgar just announced (thanks Edgar!), sets up the environment with a set of games before launching into it. (note that I didn't go as far as setting up the menu bar with games, removing the tools, sealing the programmer facilities etc. but all of this is possible and should be considered for the various types of projects)

And of course, when we ship the next image, we could actually include a number of such "proto projects" like the GamesProject - it takes a tiny amount of space but makes it very accessible and very visible from an user point of view. As a conseqence, we can hopefully ship the next Squeak version with (proto-)Games, Etoys, VMMaker, Seaside and whatnot projects.

Thoughts?

Cheers,

• Andreas

<GamesProject.st>

Hi Dan!

Hope Argentina was nice!

Dan Ingalls wrote:

Henrik Gedenryd picked up this work and carried it quite a bit farther into the system and sadly things got a bit too incompatible. It was a big frustration for me (and for him++) that we never managed to pull this off to completion.

While "almost" on the subject - did Henrik ever demo his "universal composition" work to you and his refactored implementation of BitBlt which IIRC turned into a very clean pipeline-ish thing with no performance penalty (since the runtime code turned more or less the same)?

We shared a hotel room at that OOPSLA and I recall he wanted to show it to you - but I am not sure he ever got the time. Since his "universal composition" stuff sounded quite intriguing at the time I was just curious to hear if you saw it and have any thoughts on it.

And yes, the Modules 3.3 branch in Squeak history is generally a sad chapter.

I hope, perhaps soon (now that we are again gathering speed to actually move Squeak forward into the future) - we can revisit those ideas and blend them with thoughts in Newspeak etc to see if we can eventually get something that "solves" the whole dependency/modules/packages/namespace arena.

It would be awesome if we could take at least *some* step in this direction.

Lesson learned though: the environment and tools MUST follow at the same time.

I also note that the same lesson has been re-learned regarding Traits...

regards, Göran

PS. Note to others - Henrik Gedenryd is unfortunately not with us anymore, he has passed away, unfortunately all too young.

On Thu, Dec 03, 2009 at 12:53:47PM +0100, St?phane Rollandin wrote:

G?ran Krampe a ?crit :

...

Lesson learned though: the environment and tools MUST follow at the same time.

I also note that the same lesson has been re-learned regarding Traits...

If I remember correctly, Andreas once demonstrated in this list a much simpler implementation of Traits. What about getting rid of the current mostly unused (AFAIK) implementation and replacing it with simpler Traits while having the tools follow ?

What problem are you trying to solve? If we believe that the problem is lack of tools integration, then we should fix that problem.

For whatever reason, nobody seems to care enough about this to do the tools integration work. It is hard to imagine that adding a different (and probably incompatible) implementation of traits would cause the tools integration to happen any faster.

Traits seems to be an interesting experiment, and the folks who care most about it are now working on Pharo images. I think that's an excellent place for the experiment to proceed, and if it turns out to have any useful results then I'm sure there will be interest in updating Squeak tools to take advantage. Meantime, maintaining the the current Traits in Squeak appears to be low effort, given that we adopt any bug fixes that arise from the Pharo work.

Dave

2009/12/3 Stéphane Rollandin lecteur@zogotounga.net

What problem are you trying to solve?

...

well, I have several issues that would be nicely addressed by Traits. the problem I would like to see solved is that of usability of Traits in Squeak. I believe Traits are currently not really usable, by lack of system support (tools, etc.)

For whatever reason, nobody seems to care enough about this to do the

...

tools integration work.

I guess the reason is that the Traits implementors have moved to another project, where they may or may not have better tool support in the near or far future.

It is hard to imagine that adding a different

...

(and probably incompatible) implementation of traits would cause the tools integration to happen any faster.

I'm not talking about adding an incompatible implementation, I just recalled that Andreas once said here that the current implementation is deeply flawed, overly complicated and could be *replaced* by a much better one. I may be wrong here, which is why I asked.

Stef

One issue with the current traits implementation is the cost/benefit ratio. Because it isn't used except in its own implementation it doesn't pay its way. It introduces lots of complexity and doesn't return functionality because it isn't used in the places where it could be. The most important place is the collection hierarchy where a trait-based implementation should in theory produce a much more flexible composable library. See Bill Cook's "Interfaces and specifications for the

Smalltalk-80 collection classes.", from "OOPSLA ’92,". I'm ignorant of the history but I've also read Andrew, Nathanael and Stéphane's "Applying Traits to the Smalltalk Collection Classes" so I don't know why we ended up with just traits applied to the traits implementation and lost traits applied to the collection hierarchy. I'd like to know why. My gut is that it might have broken too much older stuff. If this is right then IMO this is another strong argument for producing small kernels that can load modules. One could imagine a kernel that included traits applied to the collections into which one could load packages. The traits collections kernel and the old collections kernel could exist side-by-side and we could compare, provide migration tools for subclasses of old collections, etc.

Another issue with traits is instance variable access. Newspeak throws away direct inst var access and only uses accessors so its mixins can add instance variables. So in some sense the Squeak traits implementation isn't radical enough. But throwing away inst var accessors really feels like a new language, or at least a new system, because it impacts so many things: at the implementation level the ClassBuilder can and should behave differently, the bytecode set should be different, a JIT should use copy-down, etc; at the class library level one can factor things very differently.

To grapple with the kind of language evolution implied by traits and Newspeak I think we should be working on package-level refactoring that aims at being able to move packages between different languages. It would be great to back-port Vassili's native GUI from Newspeak. It would be great to migrate Andrew, Nathanael and Stéphane's collection classes to Newspeak (or as the Newspeak team is trying to migrate Strongtalk's collection classes). But doing this manually is IMO insane because its labour-intensive and error-prone. Yes, parts of any migration may require intervention in the form of hand-crafted rules for special cases but it can't be a first-order process.

best,

speaking in ignorance of Squeak's recent evolution,

Eliot

Igor: +1. I think the technical plane is in part a function of the social plane. What Traits needs more than anything else is more documentation. Research papers are great, but some tutorials would be useful to newbies like me.

FYI the paper in question mentioning the collections refactoring is here:

http://scg.unibe.ch/archive/papers/Scha02bTraits.pdf

And the rest of the documentation is here:

http://scg.unibe.ch/research/traits

On Thu, Dec 3, 2009 at 11:39 AM, Igor Stasenko siguctua@gmail.com wrote:

2009/12/3 Eliot Miranda eliot.miranda@gmail.com:

...

2009/12/3 Stéphane Rollandin lecteur@zogotounga.net

...

...

What problem are you trying to solve?

well, I have several issues that would be nicely addressed by Traits. the problem I would like to see solved is that of usability of Traits in Squeak. I believe Traits are currently not really usable, by lack of system support (tools, etc.)

...

For whatever reason, nobody seems to care enough about this to do the tools integration work.

I guess the reason is that the Traits implementors have moved to another project, where they may or may not have better tool support in the near or far future.

...

It is hard to imagine that adding a different (and probably incompatible) implementation of traits would cause the tools integration to happen any faster.

I'm not talking about adding an incompatible implementation, I just recalled that Andreas once said here that the current implementation is deeply flawed, overly complicated and could be *replaced* by a much better one. I may be wrong here, which is why I asked.

Stef

One issue with the current traits implementation is the cost/benefit ratio.  Because it isn't used except in its own implementation it doesn't pay its way.  It introduces lots of complexity and doesn't return functionality because it isn't used in the places where it could be.  The most important place is the collection hierarchy where a trait-based implementation should in theory produce a much more flexible composable library.  See Bill Cook's "Interfaces and specifications for the

Smalltalk-80 collection classes.", from "OOPSLA ’92,".  I'm ignorant of the history but I've also read Andrew, Nathanael and Stéphane's "Applying Traits to the Smalltalk Collection Classes" so I don't know why we ended up with just traits applied to the traits implementation and lost traits applied to the collection hierarchy.  I'd like to know why.  My gut is that it might have broken too much older stuff.  If this is right then IMO this is another strong argument for producing small kernels that can load modules.  One could imagine a kernel that included traits applied to the collections into which one could load packages.  The traits collections kernel and the old collections kernel could exist side-by-side and we could compare, provide migration tools for subclasses of old collections, etc.

I agree that currently Traits is not widely adopted and used among developers (be it Collections or something else). I seen couple of times, people saying that it would be cool to use traits for rewriting the Collections classes, but to my knowledge, nobody started with it yet. But i don't agree that there is a bad cost/benefit ratio. I think that problem lies more in social plane (widely adopting & accepting new idea(s)) and only then in technical plane - i.e. maturity level (both implementation and tools). I think that traits has many things to offer to developers, in addition to smalltalk 'standard' as we know it.

...

Another issue with traits is instance variable access.  Newspeak throws away direct inst var access and only uses accessors so its mixins can add instance variables.  So in some sense the Squeak traits implementation isn't radical enough.  But throwing away inst var accessors really feels like a new language, or at least a new system, because it impacts so many things: at the implementation level the ClassBuilder can and should behave differently, the bytecode set should be different, a JIT should use copy-down, etc; at the class library level one can factor things very differently.

There are some quite radical ideas concerning traits, which definitely will feel like a new language:

• with introduction of stateful traits, one could completely eliminate

the class inheritance, by replacing it with trait composition.

...

To grapple with the kind of language evolution implied by traits and Newspeak I think we should be working on package-level refactoring that aims at being able to move packages between different languages.  It would be great to back-port Vassili's native GUI from Newspeak.  It would be great to migrate  Andrew, Nathanael and Stéphane's collection classes to Newspeak (or as the Newspeak team is trying to migrate Strongtalk's collection classes).  But doing this manually is IMO insane because its labour-intensive and error-prone.  Yes, parts of any migration may require intervention in the form of hand-crafted rules for special cases but it can't be a first-order process.

best,

speaking in ignorance of Squeak's recent evolution,

ignorance is a blessing to learn something new, or a curse, if one don't wants to learn :)

...

Eliot

-- Best regards, Igor Stasenko AKA sig.

Stéphane Rollandin wrote:

If I remember correctly, Andreas once demonstrated in this list a much simpler implementation of Traits. What about getting rid of the current mostly unused (AFAIK) implementation and replacing it with simpler Traits while having the tools follow ?

That's a *really* good idea, thanks for reminding me. It'll be such a relief to get rid of all of that needless complexity. Now where did I put that code...

Cheers, - Andreas

2009/12/3 Göran Krampe goran@krampe.se

Lesson learned though: the environment and tools MUST follow at the same time.

I also note that the same lesson has been re-learned regarding Traits...

I don't know that I would necessarily draw the same conclusion. The environment and the tools have evolved over decades with the current Smalltalk meta model. Moving the existing tools and environment forward with things like modularity and traits requires a lot of time and heavy lifting. Perhaps the better approach is to simply chuck the old tools and start over. The approaches to modularity and traits are really new languages and I believe the mistake has been in thinking that these things could be easily grafted on top of the existing Smalltalk meta model, environment and tools.

- Stephen

Michael Haupt wrote:

I'd buy it immediately. Is there a tutorial somewhere that illustrates how to use these facilities?

Not much at this point, partly because there really isn't much to it (yet). The GamesProject is split into three parts: The installation, the standard Morphic project setup and the custom Games setup. In the installation (GamesProject>>install) we detect whether MorphicGames are installed and if not, download and install it (this is pretty adhoc). The default Morphic setup is simply setting up the project like any other project (default background, menu bar etc) - there is plenty of stuff that's still missing here, for example having the ability to customize the menu bar (you could conceivably do that in the custom setup step but then you'd be creating some of these twice). Lastly, the custom setup (GamesProject>>setupProject:) should really (as the comment says) live inside the MorphicGames package so that it can be updated when the Games package gets updated. It can do whatever it wants with the Morphic world, in our case just adding a few thumbnails to launch the game but it could also open some of them by default etc. Lotsa room for fun stuff.

Personally speaking, the biggest outstanding issue with projects (which will start biting us really soon now) is persistence. You can save one of these GamesProjects (whoopsie. or maybe not. it just blew up for me with something that looks like it might be crlf related) but the issue is that the way projects are persisted makes it difficult to ensure the proper dependencies are met (i.e., this needs to be loaded into a GamesProject which already implies that the MorphicGames package will be present etc). And ImageSegments are good for certain things, but as a general purpose long-term persistence mechanism they suck. Simply because by their very nature they can't store abstract descriptions but only the bits of the current implementation used. And if you've ever persisted stuff that you wanted to be able to load a year from now in the face of active development you know the latter is a recipe for disaster.

Anyway, that's where we are now. It's a starting point, not the end of the story.

Cheers, - Andreas

I love this idea of a proto-project, that contains only the knowledge needed to load things as complex as eToys into an image from the internet (or the disk?.) I use projects like crazy. I like to keep the top project pristine for some reason, so I just add a project to it and do all of my work in sub-projects of that.

I would very much like to see better support for filing out projects full of objects and then filing them back into other images (not the same image.) This would make moving from one image to the next less painful.

On Thu, Nov 26, 2009 at 8:38 AM, David T. Lewis lewis@mail.msen.com wrote:

On Wed, Nov 25, 2009 at 08:25:39PM -0800, Andreas Raab wrote:

...

The progress that we've made with refactoring of class Project makes it feasible to illustrate the power of projects. If you install the attached change set in an updated trunk image, you will find a new type of project available - a  GamesProject. When you choose this type of project you will notice that it downloads and installs the MorphicGames package that Edgar just announced (thanks Edgar!)

Wow, I had completely forgotten just how bad I am at playing chess. Thanks for reminding me Edgar!

This works nicely, and an EToysProject seems like another good thing to have. The EToys folks are also keen to get DrGeo integrated into that environment, and perhaps DrGeo warrants a project type in its own right.

Dave