Hi all!
So, the report 1 is out and we now want to discuss and finalize Stefs (and crew) roadmap for Squeak 3.9 according to the postings a while back from Stephane and crew. I include below those two postings verbatim. The only thing in the report that affects this is that we want the ToolBuilder package into 3.9.
Let's take a look at this yet again and come to a concluded roadmap within say a week or so. I am now going to take weekend and will probably not be very active until monday. But this todo is on me: http://anakin.bluefish.se/castaways/1
...and I will make sure to vaccum clean this thread and gather the discussion into a proposal during next week. So if you make your voice heard it will definitely have an effect. Just try to keep the postings clear and showing what you support and not - otherwise it will be hard to turn it into some sort of result.
So, let's all take a good look here and discuss these bits. Then we will post a concrete proposal based on all that (trying to reflect the general concensus) and take some last feedback and then we decide it.
regards, Göran
PS. Perhaps our "take" on this roadmap would have been interesting but frankly - we don't have time for that now. Remember, we aren't going to push stuff down your throats - let's discuss it alltogether, just like we always do and take it from there.
------------- Hi all,
<WARNING> Please before replying to this email ask yourself what you did recently for squeak besides sending emails! And as you will see there are a lot of places where you can contribute. </WARNING>
So after a long discussion with the crew here (nathanael, alex, marcus and adrian will agree) we decided not to fork and this will cost us energy and time. But we think that this is worth.
We plan to do the following: we will focus on building 3.9 and take our time and your feedback to do it. We think that april/mai would be a good release date so that we have the time to test and work in pace. (Note also that this will be my last contribution to the community (from today perspective since I do not know where I will living in 5 months from now). So we want to have a really cool 3.9.) BUT BUT BUT we will only focus on what we are good at and we NEED the help of other people to work on the other areas: UI, Morph (PLM), Etoy,
Note that the list after is not fixed since we do not want to push something that will not be ready. For example, we will pay an extreme attention that the traits are fully integrated. Nathanael is planning to help and also would like to for example make sure that he can refactor the collection hierarchy before releasing traits.
We are LOOKING for a lead harvester, and ETOY harvester and a Multimedia one.
3.9 Full
- new multimedia app (Ogg reader?) - YAXO (p) a real one on SqueakSource :) (yes this is a subliminal message :)) - Wonderland back in shape (you see mark there are room) / 3DBalloon - and anything that is valuable for full - GENIE (yes ned we want that) - Connectors (yes yes we want that too) -> ned would it be possible to get access to one your recent Genie image? - but people will have to provide package in MC format (or at least a good sar)
3.9 Basic (the stuff for the developer: not the mini image! ) - Diego look - eCompletion or another package (p) - keybinding cool package (may this one should go in basic as package (p) because the current way of binding key is system wide and not really good) - shout (p) - SqueakMap II (yes we want it) - rbengine (p) this is absolutely not intrusive (ok there are some duplicated functionality but we need it and if a brave soul wants to optimize it will be really possible for now we should not be that warry since the package is self-contained and we are not enough, so we should be productive and then after one guy will fix that if necessary). So simply a package that can be removed but that is needed to code. - services - new preferences pane - traits - new compiler framework (note that according to Scott this should not have an impact on etoy) But again we need a Etoy expert to help. - refactoring of systemDictionary as proposed to get it done once right. Again read again what we wrote and comment. (I think that having SmallltalkImage and SystemDictionary does not make sense to have both) - OB (p?) + browseUnit new version (integrated version). The idea of having OB here is that we want to enable the creation of new tools and deprecate slowly the use of the old browser (which could be packaged but keep alive in case we only want to have one single but gigantic class). - MC in the base image (we all would like to have a mini image and a cool script but for now not having MC in the base image is getting in our way to maintain packages and to also produce a much smaller mini-image, to also learn what we cannot do with MC and ask kindly to MC developers if they can fix the problems we see). Except if of course someone come up with a better idea and code to support that. We would like to avoid to abandon the idea of having packages in basic since we would like to push further the packages curving process.
- We would like also to have a much better support for packages: Package as real entities with support for - resources - meta information - comments - substituing package info (alex is willing to work on that).
We also like the idea of TestServer, so feel free to write tests! May be markus G could be the guy responsible to push them into the stream. Markus? Romain?
Note that for the packages marked as (p) of course we will ask if the package creator is willing to help and feel the pression of having his cool package in Basic. One requirement could be that the code is managed with MC and SqueakSource so that in case of emergency we can get our hands on it :) We ask for feedback, help, testing, ideas....
BUT MORE IMPORTANT: This community needs to structure itself. We would like to be able to pay someone to work half-time on harvesting and improving the system. So we are looking for solutions. Would you be ready to pay for a cool Squeak release? Do not reply to this question now, just look at yourself in the mirror and let us hope that something happen.
Stef, alex, marcs, adrian and nathanael (writing style of Stef ;)))
PS: marcus got totally burnt by the harvesting process and the lack of communication so now he should reenergize himself. So don't expect anything from him, because he is learning to say no :)))
From: ducasse@iam.unibe.ch Subject: A roadmap for 3.9 Date: 9 décembre 2004 13:38:44 GMT+01:00 To: squeak-dev@lists.squeakfoundation.org Reply-To: squeak-dev@lists.squeakfoundation.org
hi all
I have been discussing with marcus/alex and also thinking about that after my remarks on andreas remarks related to changes, interfaces/ cleaning vs changes. So to avoid get frustration from all the parts and to state clearly what is our plan for 3.9 we would like you to read the following and let us know. Depending on the reactions, we (the guys from berne) may decide to produce our own stream, because we must work too ;). But we understand that other people cannot deal with a system changing. But in that case we should draw the consequences.
Our part that we will work on for 3.9 is to get the system improved from a developers point of view. We think that having a good foundation is important for everybody.
The overall idea is to slowly improve one aspect of Squeak: The idea to have a System to build the next System with.
This has lots of consquences, one is that you want the system to be in a shape that e.g., students that are not yet complete Squeak experts can start to do experiments with it on a quite deep level, e.g., change the compiler or add a feature to the Browser. Another aspect is to have a System for research. The Traits project has been hugely successful, but it has shown that Squeak does have real problems if you use it for stuff like that. If Squeak is supposed to be the system of choice for research like this, we need to fix those problems, we need to make sure that the lessons learned from those projects get fed back into the system. (One example is the change-notification that was added to 3.7, it is a direct result of the Traits project)
All this does not mean that 3.9 will only be about that stuff: We surely want to see e.g. the work of Diego beeing included, also any changes that other people would need are welcome.
For our perspective here what we would like to have: we put in (p) the code that will be in external packages, which likely will be "full".
- services - new preferences pane - OB (p?) + browseUnit new version - MC in the base image - rbengine (p) - shout (p) - SqueakMap II (yes we want it) - eCompletion or another package - keybinding - traits - new compiler framework of anthony adapted by marcus to produce not full block. Note that for Etoy the old compiler will still be in the image so from that point of view it should not have an impact. - refactoring of systemDictionary. (see below this point)
We are sure that we forgot something but this is what we have on top of my head.
Now for systemDictionary here is the situation and here is where we would like to be after 3.9
In the past we created SmalltalkImage out of SystemDictionary in the hope to have SystemDictionary be a nice and simple namespace class. Lot of stuff has been put in coherent places (SystemNavigation, SpaceTally, Changeset....) But this will not work since people get used to add stuff there and Smalltalk is a cool name. So the new proposal is the following one and is partly implemented. Note however that it will require from us a lot of work so if you are against it please say it and we will only do it for us.
from a user point of view we want to have: only one class: SmalltalkImage/SystDict for all the image related services (VM pluggins, ....) but the namespace behavior will be delegated to Namespace.
All the previous code referencing Smalltalk will work but with deprecation for the namespace interface.
From the language programmer point of view: there will be a namespace that can be used for experimentation this class will replace the environment class of dan that is now obsolete
We plan to proceed that way: - create a class namespace with a new interface (done) - delegate from systemDictionary to this new class (done but not published) - deprecate all the namespace method of systemDictionary (but we likely want to keep them for some time) - fix all the in image senders of Smalltalk as a namespace to use the new class (using self environment for example). (partly done over the previous years) - merge back SmalltalkImage into SystemDictionary: the idea here is to not have SystemDict as a subclass of Dictionary - have Smalltalk pointing to an instance of this new entity, so that everybody is happy.
Stef and Marcus
The essential answer to this has already been posted by Andreas:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-December/085923....
Especially problematic are the "researchers" items:
1) new compiler framework 2) refactoring of SystemDictionary 3) Traits
Here is what I think about these:
1) I don't want to comment much on the compiler framework, except that I think that it is critical to get this done properly, if it goes in.
2) The ongoing attempt of refactoring SystemDictionary seems to be an odyssey without much planning so far. This is not the right way to do a "refactoring" of a kernel part.
3) Traits is a questionable language extension. It is questionable because language extensions to Smalltalk themselves are questionable.
Here are Squeak's current problems ordered by importance:
1) library 2) speed 3) documentation 4) community organization 5) public relations and awareness 6) language
I am not going to bet on the exact order of 2 to 5 but I think it is clear that "library" is THE problem. Far behind at the end comes "language", simply because Smalltalk is still one of the best, if not the best programming language.
Smalltalk has a remarkable cost-performance ratio. Every addition to the language may worsen this ratio. Yet half of all people tend to ask the question:
- What benefit has the language extension/change?
But this is the wrong question. With this kind of judgement Squeak's way is paved to a concept-overloaded monster like Java.
Instead we should ask:
- What real problem does the language extension/change solve?
A real problem is of course not meant to be the absence of a benefit in a specific situation, the type of advantage the first question is about.
A real problem of a language is one that is ubiquitous when programming in that language, something which occurs literally every line, which really goes straight to the heart of its basic mechanism.
I think it will be really difficult to uncover and to distill such a core problem in Smalltalk and it is my conviction that Traits is not solving such a main problem.
As a consequence I think we should not include Traits into the official release. Instead I guess some people would like to see a specific "researchers edition" of Squeak from the Berne group.
This could be a fork in the sense of Avi's suggestion of having "recurring forks" - tall narrow trees with stubby branches coming off it at every level:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-December/086612....
regards, Martin
On Wed, 23 Feb 2005 00:36:49 +0100, Martin Wirblat sql.mawi@t-link.de wrote:
- The ongoing attempt of refactoring SystemDictionary seems to be an
odyssey without much planning so far. This is not the right way to do a "refactoring" of a kernel part.
I think I'm with you there - I've been hunting around over the new classes, and I haven't found a consistent pattern so far of what sits where. I'm all in favour of cleaning up SystemDictionary (in fact, I'm in favour of cleaning it into oblivion ;)), but it looks like there's no logical structure about what lands where. Definitely a worthwhile goal, but it feels like it needs more direction.
- Traits is a questionable language extension. It is questionable
because language extensions to Smalltalk themselves are questionable.
Well, that's a bit strong, but
- What real problem does the language extension/change solve?
Is indeed the correct question to ask iff we want to brace ourselves against flying off into coolness land (which you assume as a given, I as something to be decided upon)
AFAIK, the real problem Traits attempts to solve is about structuring, and it looks like me that when you're putting 'library' high on the list of itches we should scratch, a cleaner structuring of some ugly bits of the base library's hierarchy seems to be one of the things that Traits can contribute. It would probably become a whole lot easier to reuse code from the base library with a Traitified image (I'm talking from memory here - it's been a while since I read the Traits paper so it might be I'm missing other strong points).
But the proof of the pudding is in the eating, I think. When there's a Traits browser, and the stuff is all a loadable package, people can start using it and see whether it solves real-world problems in a way that makes it worthwhile to adopt it as a core piece of Squeak.
The only thing I'm afraid of is that we're adding too much friction to the process of changing Squeak; as some of the original Smalltalk-80 members have complained, the language has become essentially frozen since it left the laboratory. For 25 years, it looks like we've missed out on opportunities to get this whole OO thingy to higher levels, and I wonder whether that's a good thing. I respect these guys a lot, but I don't think that they invented the final computer language 25 years ago.
[META] Grabbing back to the Debian model - maybe we want to have a three-streams model. Stable, Testing we've got. What we're missing is Unstable, where people are allowed to throw in mostly anything they seem fit. So you can actually work with stuff, see how it behaves, before deciding on whether to move it on to Testing (which is the doorkeeper to Stable, sort of). The Unstable update stream is a good step in this direction, maybe we should make it more prominent and push it a little more? Have some very lightweight 'decision process', maybe a checklist, for adding stuff to Unstable?
How about waiting until the beginning of a release cycle to make a major change like adding Traits? I assume it is likely to bring out a lot of bugs? If we do it at the beginning of a release cycle, then we can take our time and get the bugs out.
Also, how are the Traits tools, at this point? Are there browser updates, etc., so that people can use them like a normal developer instead of imagining what it will be like in the brave future? (Or acting like an icky files+compilers developer? :))
What we're missing is Unstable, where people are allowed to throw in mostly anything they seem fit. So you can actually work with stuff, see how it behaves, before deciding on whether to move it on to Testing (which is the doorkeeper to Stable, sort of). The Unstable update stream is a good step in this direction, maybe we should make it more prominent and push it a little more? Have some very lightweight 'decision process', maybe a checklist, for adding stuff to Unstable?
The only thing we have is unstable, and that's both 3.8 and 3.9. I don't think that having separate 3.9 unstable is what we want in the long run, but whatever.
Debian doesn't make a "stable" release by shipping a Linux kernel that is stable and then saying good luck. They also ship thousands of packages, none of which have a "release critical" bug that is still open on the bug tracker. We don't even have either (a) release critical bugs or (b) a released set of packages.
For (a) someone simply needs to install a suitable bug tracker. We could even use Debian's, I'd think.
For (b), both SqueakMap and Package Universes could be used. Package Universes supports this out of the box: use one universe for development and testing, and one universe for each set of packages. You'd set the policies different for each kind of universe: development universes are wide open to changes, while stable universes require the twelve sacred humpalumphs to gather and perform a 3-day long ritual before a package is allowed to go in.
On SqueakMap, I believe you could use tags, *if* they were adjusted so that any old yahoo can't just add a "stable" tage to a package whenever they like. Alternatively, I think Goran mentioned some sort of compound package that might work: a compound package would be a package that has a list of pointers to other packages.
Anyway, I mean to post more on this eventually, but wanted to toss this out since you mentioned it.
-Lex
On Wed, 23 Feb 2005 23:04:57 -0400, Lex Spoon lex@cc.gatech.edu wrote:
The only thing we have is unstable, and that's both 3.8 and 3.9. I don't think that having separate 3.9 unstable is what we want in the long run, but whatever.
Yeah, but Debian Unstable is more like that ever lasting party from the HHGTTG - there's no such thing as freezing Unstable and moving the whole shebang over to Testing; packages migrate individually from Unstable to Testing. The advantage is that you always have a bleeding edge version with no version tag other than "freakin' bleedin' edge" where you can throw in things that you want to have tested by, well, the freakin' bleeding' edgers.
For (b), both SqueakMap and Package Universes could be used.
Yup. So I'll step out here and act like I'm not a member of the packaging team ;)
Hi fellas!
Trying to pick pieces here to comment. :)
"Lex Spoon" lex@cc.gatech.edu wrote:
How about waiting until the beginning of a release cycle to make a major change like adding Traits? I assume it is likely to bring out a lot of bugs? If we do it at the beginning of a release cycle, then we can take our time and get the bugs out.
That is true, but on the other hand 3.9 is more or less in the "beginning" because not much has gone in since it was opened up - more or less only Diego's look AFAIK.
But this is moot because IMHO, as Cees described in more detail, Traits needs a longer period of digestion IMHO. I mean, when we have a beta of the Traits that is meant to be the Real And True version :) - then we can all play with it and see how it works etc. And then, we can start thinking about including it into the official Basic image.
But this only works if Traits *can* be implemented as a package. I still don't know that. Nathanael?
[SNIP]
What we're missing is Unstable, where people are allowed to throw in mostly anything they seem fit. So you can actually work with stuff, see how it behaves, before deciding on whether to move it on to Testing (which is the doorkeeper to Stable, sort of). The Unstable update stream is a good step in this direction, maybe we should make it more prominent and push it a little more? Have some very lightweight 'decision process', maybe a checklist, for adding stuff to Unstable?
The only thing we have is unstable, and that's both 3.8 and 3.9. I don't think that having separate 3.9 unstable is what we want in the long run, but whatever.
Debian doesn't make a "stable" release by shipping a Linux kernel that is stable and then saying good luck. They also ship thousands of packages, none of which have a "release critical" bug that is still open on the bug tracker. We don't even have either (a) release critical bugs or (b) a released set of packages.
For (a) someone simply needs to install a suitable bug tracker. We could even use Debian's, I'd think.
Mmmm, Mantis is what we have today and... I and others (Ken just formed a Team on the subject) are suggesting that we *temporarily* focus on. Or did you mean some other tool?
For (b), both SqueakMap and Package Universes could be used. Package Universes supports this out of the box: use one universe for development and testing, and one universe for each set of packages. You'd set the policies different for each kind of universe: development universes are wide open to changes, while stable universes require the twelve sacred humpalumphs to gather and perform a 3-day long ritual before a package is allowed to go in.
On SqueakMap, I believe you could use tags, *if* they were adjusted so that any old yahoo can't just add a "stable" tage to a package whenever they like. Alternatively, I think Goran mentioned some sort of compound package that might work: a compound package would be a package that has a list of pointers to other packages.
Yes, or something like that. :) In short - we should merge our work in some suitable way and I am committed to start that by taking a good look at Universes the first thing I do (typically) in the Packages team. Or if we don't merge we should at least make these things play nice and integrate with each other.
So anyway, given a package oriented view here I don't think we need a special update stream for "unstable stuff". Sure, we can still have the unstable stream as a "first front", but generally packages is what we want and then things work out naturally (meaning the maintainers can make their new releases available regardless of how stable they are etc).
Anyway, I mean to post more on this eventually, but wanted to toss this out since you mentioned it.
-Lex
I can create the Packages list for the Packages Team but the moderator should probably be the Team leader. Or what the hell - I can take that moderator crap. Ok, created. :) Please subscribe:
packages-subscribe@discuss.squeakfoundation.org
regards, Göran
That is true, but on the other hand 3.9 is more or less in the "beginning" because not much has gone in since it was opened up - more or less only Diego's look AFAIK.
But this is moot because IMHO, as Cees described in more detail, Traits needs a longer period of digestion IMHO. I mean, when we have a beta of the Traits that is meant to be the Real And True version :) - then we can all play with it and see how it works etc. And then, we can start thinking about including it into the official Basic image.
to my opinion, in three weeks from now traits browsers will be ready. besides that all the rest is working. Even when you recompile a method in a debugger you recompile in the right place (traits or classes).
But this only works if Traits *can* be implemented as a package. I still don't know that. Nathanael?
Why as a package? I do not understand why you are saying that? And tired toooo.
Bootstrapping the kernel is not something that you can do in a package. Or you will complain that traits are not integrated you cannot have the butter and the money for the butter.
Hi Stef!
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote: [SNIP of good sounding status]
But this only works if Traits *can* be implemented as a package. I still don't know that. Nathanael?
Why as a package? I do not understand why you are saying that? And tired toooo.
Sure, we are making you tired - but you will just have to hang in there. :)
What I mean is that if Traits can not be packaged as a package (if for example it is simply too hard to do) - then our choices are much more black and white.
If it *can* be made a package then people that are die-hard negative about Traits can still elect not to use it. They can then use Minimal (you know - the image smaller than Basic) and simply not install Traits into it.
Now, I understand that maintaining Traits as a package is a hard thing to do. It is typically a quite advanced "patch" to the kernel stuff in Squeak. This all depends on how you guys have built it - through various refactorings or through simply modifications.
So the question remains - is Traits plausible to maintain as a package - or is it not? And also of course, if it is - would you be willing? Unless this is so - then this turns into a black and white choice.
Bootstrapping the kernel is not something that you can do in a package. Or you will complain that traits are not integrated you cannot have the butter and the money for the butter.
Well, I want to be absolutely clear on our options here.
regards, Göran
On Thu, 24 Feb 2005 11:00:19 +0100, goran.krampe@bluefish.se wrote:
So the question remains - is Traits plausible to maintain as a package - or is it not? And also of course, if it is - would you be willing? Unless this is so - then this turns into a black and white choice.
I don't think Traits takes away any functionality. If one doesn't want to use them, one doesn't have to.
Yeah, they'd =be there=. But if they give the benefits they seem to, does it make sense to cripple the core to satisfy those who hate them so much they don't want them anywhere in their image? I guess packaging them removes the issue but, yow, that seems like a lot of work (if it's even possible).
Blake blake@kingdomrpg.com wrote:
On Thu, 24 Feb 2005 11:00:19 +0100, goran.krampe@bluefish.se wrote:
So the question remains - is Traits plausible to maintain as a package - or is it not? And also of course, if it is - would you be willing? Unless this is so - then this turns into a black and white choice.
I don't think Traits takes away any functionality. If one doesn't want to use them, one doesn't have to.
Yeah, they'd =be there=. But if they give the benefits they seem to, does it make sense to cripple the core to satisfy those who hate them so much they don't want them anywhere in their image? I guess packaging them removes the issue but, yow, that seems like a lot of work (if it's even possible).
Well, these are the things I want to know :). If we can't have it as a package - and there probably are strong arguments for not having this as a package, I can envision it being hard to maintain that way - then we will have to look hard at what effects it will have - for example for those that wish to ignore it.
regards, Göran
Well, these are the things I want to know :). If we can't have it as a package - and there probably are strong arguments for not having this as a package, I can envision it being hard to maintain that way - then we will have to look hard at what effects it will have - for example for those that wish to ignore it.
Nathanael and adrian will certainly reply in length here. What I can tell you is that it is possible to have traits as package but this is a sweet dream because each time the kernel will changes then you will have to fix traits. You will not be able to get the full power of traits because you will not be able to rethink to core Collection/Stream/UI using morphic then each time you will load the traits package it will just recompile all your image = 30 min of recompilation. Then do you imagine that nathanael or adrian will work on checking drifts over the years especially since this is really simple once in the image (because traits are simple). So a package = slow death but death.
Stef
Hi guys,
Nathanael and adrian will certainly reply in length here. What I can tell you is that it is possible to have traits as package but this is a sweet dream because each time the kernel will changes then you will have to fix traits.
I agree with Stef. While it would be possible to have Traits as a package, I don't think that this is a good idea for several reasons. First, it would mean a lot of care and work to make sure that provide a package that is compatible with newer Squeak releases. More importantly, I think that it kind of defeats the prupose of a langauage extension like traits if it is optional because this means that one cannot take advantage of it in any of the non-optional code.
However, the good news is that even if traits are part of the basic image, people do not have to use and deal with them if they do not want to. So, there really should be no disadvantage/change for people who just want to ignore them. But as I said in my last email, I agree that we should go step by step, and the next step is a beta that allows people to see what it would mean to have traits in the image. I'm sure that this will make things a lot less scary...
Cheers, Nathanael
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of stéphane ducasse Sent: Donnerstag, 24. Februar 2005 13:41 To: The general-purpose Squeak developers list Subject: Re: To Traits Or Not To Traits (Was: Re: Stefs roadmap for 3.9,time to get it nailed down)
Well, these are the things I want to know :). If we can't
have it as a
package - and there probably are strong arguments for not
having this
as a package, I can envision it being hard to maintain that
way - then
we will have to look hard at what effects it will have -
for example
for those that wish to ignore it.
Nathanael and adrian will certainly reply in length here. What I can tell you is that it is possible to have traits as package but this is a sweet dream because each time the kernel will changes then you will have to fix traits. You will not be able to get the full power of traits because you will not be able to rethink to core Collection/Stream/UI using morphic then each time you will load the traits package it will just recompile all your image = 30 min of recompilation. Then do you imagine that nathanael or adrian will work on checking drifts over the years especially since this is really simple once in the image (because traits are simple). So a package = slow death but death.
Stef
Hi Nathanael!
=?iso-8859-1?Q?Nathanael_Sch=E4rli?= n.schaerli@gmx.net wrote:
Hi guys,
Nathanael and adrian will certainly reply in length here. What I can tell you is that it is possible to have traits as package but this is a sweet dream because each time the kernel will changes then you will have to fix traits.
I agree with Stef. While it would be possible to have Traits as a package, I don't think that this is a good idea for several reasons. First, it would mean a lot of care and work to make sure that provide a package that is compatible with newer Squeak releases. More importantly, I think that it kind of defeats the prupose of a langauage extension like traits if it is optional because this means that one cannot take advantage of it in any of the non-optional code.
This is what I thought - I just want to hear it spelled out. :)
However, the good news is that even if traits are part of the basic image, people do not have to use and deal with them if they do not want to. So, there really should be no disadvantage/change for people who just want to ignore them. But as I said in my last email, I agree that
I would like to hear more about that. Let me take the role of a Traits-hater here:
- Can I use the standard libraries and not know about Traits? Before you say "yes" :) think it through, for example, if I edit a method in a class that comes from a Trait (I haven't read all your papers yet, but I did try to print some of it) what happens? Am I editing the Trait? And then I am affecting other classes using it? So I am guessing (just guessing) that people *do* need to know about Traits (if we use them for standard libraries) or else they will get confused. Correct?
- If I don't use Traits and don't use any libraries using Traits (given that no standard libraries use them) and if I... use ordinary browsers etc. What is the effect on me? Does Traits have any effect then at all? Just asking to get a feel for this.
- Does the old tools work if we introduce Traits or do they all break? :)
we should go step by step, and the next step is a beta that allows people to see what it would mean to have traits in the image. I'm sure that this will make things a lot less scary...
Yes, perfect. So can we then decide on that - first a beta (or alpha or whatever you like to put in our hands) - then we take first look, and then probably solicit some feedback from stakeholders.
As a first rough plan. Ok?
Cheers, Nathanael
Cheers, Göran
Hi Göran,
- Can I use the standard libraries and not know about Traits?
Before you say "yes" :) think it through, for example, if I edit a method in a class that comes from a Trait (I haven't read all your papers yet, but I did try to print some of it) what happens?
Absolutely! The idea is that in the regular browser, changing a method in a class that comes from a trait will define a new method that is local to the class and --- according to the semantics of traits --- overrides the method coming from the trait. This means that such an edit has the exact same consequences (i.e., it only affects the class and its subclasses) as if the class were built without any traits at all.
Similarly, if you remove a method in a class that comes form a trait, the method gets "excluded from the composition" (i.e., it is not removed from the trait but only excluded from this particular application of the trait), which means that it has the expected effect for the programmer who does not know (and does not want to know) that the class is in fact built from traits.
Am I editing the Trait? And then I am affecting other classes using it? So I am guessing (just guessing) that people *do* need to know about Traits (if we use them for standard libraries) or else they will get confused. Correct?
No. As I said above, the standard browser hides traits in a completely consistent way. As a consequence, a programmer that does not want to know about traits can use the standad browser, which lets him *view and edit* any code (even if it is built from dozens of nested traits) in the traditional way without ever accidentally affecting any other classes. This is possible thanks to the beauty of the traits model, which features the flattening property (i.e., methods in traits have no special semantics) and allows the composite entity (in this case the class) to make any kind of local changes (such as modifying or removing methods obtained from a trait) without affecting the traits itself. This is also the reason why traits do not suffer from the fragility problems known from mixins and MI.
- If I don't use Traits and don't use any libraries using
Traits (given that no standard libraries use them) and if I... use ordinary browsers etc. What is the effect on me? Does Traits have any effect then at all? Just asking to get a feel for this.
If you are using no libraries that use traits, then traits have absolutely no effect on you, except that there are a handful of additional classes in the kernel (such as Trait, TraitDescription, ClassTrait, etc.) that most people are not interested in anyway.
However, things are even better because, as I explained above, one major advantage of traits is that they have virtually no effect on people who do not want to know about them even if they use libraries built with traits! The only thing to make this work in practice is to tweak some of the existing tools a bit. We have already done this for the traditional System Browser, which displays the code always as if no traits were used and makes sure that also edits behave exactly as if no traits were used (i.e., changes only affect a class and its subclasses but *not* other classes using the same traits).
- Does the old tools work if we introduce Traits or do they all break?
:)
Because all the work is done at composition time (i.e., the method dictionaries of all classes look exactly as if no traits were used) Most of the old tools (such as "implementors of..." and "senders of..." etc.) work just fine. However, we found that for some of them require minor tweaks to get the perfect illusion of a trait-lest image.
What is more work is to design the new tools (such as the trait browser) for the programmers who actually want to know about traits and use them. This is because these tools need to show how classes are built from traits and give the programmer the choice of overriding/removing a trait method in a certain class or actually changing the trait where the method is actually defined. Also, we need to make sure that for those programmers, tools like "implementors of..." and "senders of..." take methods defined in traits into account.
Yes, perfect. So can we then decide on that - first a beta (or alpha or whatever you like to put in our hands) - then we take first look, and then probably solicit some feedback from stakeholders.
Sounds good to me.
Cheers, Nathanael
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of goran.krampe@bluefish.se Sent: Donnerstag, 24. Februar 2005 15:43 To: The general-purpose Squeak developers list Subject: RE: To Traits Or Not To Traits (Was: Re: Stefs roadmap for 3.9,time to get it nailed down)
Hi Nathanael!
=?iso-8859-1?Q?Nathanael_Sch=E4rli?= n.schaerli@gmx.net wrote:
Hi guys,
Nathanael and adrian will certainly reply in length here.
What I can
tell you is that it is possible to have traits as package
but this
is a sweet dream because each time the kernel will
changes then you
will have to fix traits.
I agree with Stef. While it would be possible to have Traits as a package, I don't think that this is a good idea for several
reasons.
First, it would mean a lot of care and work to make sure
that provide
a package that is compatible with newer Squeak releases. More importantly, I think that it kind of defeats the prupose of a langauage extension like traits if it is optional because
this means
that one cannot take advantage of it in any of the
non-optional code.
This is what I thought - I just want to hear it spelled out. :)
However, the good news is that even if traits are part of the basic image, people do not have to use and deal with them if they do not want to. So, there really should be no disadvantage/change
for people
who just want to ignore them. But as I said in my last
email, I agree
that
I would like to hear more about that. Let me take the role of a Traits-hater here:
- Can I use the standard libraries and not know about Traits?
Before you say "yes" :) think it through, for example, if I edit a method in a class that comes from a Trait (I haven't read all your papers yet, but I did try to print some of it) what happens? Am I editing the Trait? And then I am affecting other classes using it? So I am guessing (just guessing) that people *do* need to know about Traits (if we use them for standard libraries) or else they will get confused. Correct?
- If I don't use Traits and don't use any libraries using
Traits (given that no standard libraries use them) and if I... use ordinary browsers etc. What is the effect on me? Does Traits have any effect then at all? Just asking to get a feel for this.
- Does the old tools work if we introduce Traits or do they all break?
:)
we should go step by step, and the next step is a beta that allows people to see what it would mean to have traits in the
image. I'm sure
that this will make things a lot less scary...
Yes, perfect. So can we then decide on that - first a beta (or alpha or whatever you like to put in our hands) - then we take first look, and then probably solicit some feedback from stakeholders.
As a first rough plan. Ok?
Cheers, Nathanael
Cheers, Göran
On Thursday 24 February 2005 7:15 am, Nathanael Schärli wrote:
If you are using no libraries that use traits, then traits have absolutely no effect on you, except that there are a handful of additional classes in the kernel (such as Trait, TraitDescription, ClassTrait, etc.) that most people are not interested in anyway.
There is one effect: your image is larger. For those of us wanting to run embedded systems on memory-constrained devices, this can be an issue.
How much larger does (the absolutely necessary, hard to load as a package, kernel part of) Traits make an image? I'm assuming that the browsers and other tools could be packaged separately, right?
On 24 févr. 05, at 17:13, Ned Konz wrote:
On Thursday 24 February 2005 7:15 am, Nathanael Schärli wrote:
If you are using no libraries that use traits, then traits have absolutely no effect on you, except that there are a handful of additional classes in the kernel (such as Trait, TraitDescription, ClassTrait, etc.) that most people are not interested in anyway.
There is one effect: your image is larger. For those of us wanting to run embedded systems on memory-constrained devices, this can be an issue.
I do not know exactly, but with traits we remove duplicated code since the kernel is bootstrapped. For example, a lot of functionalities are reuse between the new classes and the existing one (classDescription and others).
Also collection could gain a be reduced (nathanael showed in the OOPSLA paper 12% of reuse) but without rewriting everything so we could expect a bit more.
How much larger does (the absolutely necessary, hard to load as a package, kernel part of) Traits make an image?
I do not know we should measure it. Try to get the version oin squeak map and check it.
I'm assuming that the browsers and other tools could be packaged separately, right?
Sure.
Stef
However, the good news is that even if traits are part of the basic image, people do not have to use and deal with them if they do not want to. So, there really should be no disadvantage/change for people who just want to ignore them. But as I said in my last email, I agree that
I would like to hear more about that. Let me take the role of a Traits-hater here:
- Can I use the standard libraries and not know about Traits?
Yes
Before you say "yes" :) think it through, for example, if I edit a method in a class that comes from a Trait (I haven't read all your papers yet, but I did try to print some of it) what happens?
You add a method in your class as usual. Method do not come from traits if you do not use traits. Now if your class uses a trait then you still define a method in your class as normal. Your method simply is the one used instead of the one of the traits.
Why don't you read the papers?
Am I editing the Trait? And then I am affecting other classes using it? So I am guessing (just guessing) that people *do* need to know about Traits (if we use them for standard libraries) or else they will get confused. Correct?
But if you do not want to use traits you do not have to edit them?
Read them and try the squeakmap version.
- If I don't use Traits and don't use any libraries using Traits (given
that no standard libraries use them) and if I... use ordinary browsers etc. What is the effect on me?
Zero
Does Traits have any effect then at all?
Yes zero effect. You can always flatten a class. Why don't you read the paper and try the squeakmap version?
Just asking to get a feel for this.
- Does the old tools work if we introduce Traits or do they all break?
:)
They work. You just have to ignore the traits use for the class. I can teach Smalltalk to first year student without talking about traits as soon as they do not use traits browser. You can introduce traits as saying that this is a group of methods. No more no less. A bit like first class category.
Yes, perfect. So can we then decide on that - first a beta (or alpha or whatever you like to put in our hands)
The beta is out since some months already. The version of squeakmap may not contain certain fixes adrian introduced (like the integration with the debugger: you edit in the debugger a method it goes in the right traits. May be this is not on squeakmap)
- then we take first look, and
then probably solicit some feedback from stakeholders.
Yes please do it, but read the %$%$#$%#X papers and try. We even did an example with complex number to show how we can reuse code
As a first rough plan. Ok?
Yes
Cheers, Nathanael
Cheers, Göran
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote: [SNIP]
- then we take first look, and
then probably solicit some feedback from stakeholders.
Yes please do it, but read the %$%$#$%#X papers and try. We even did an example with complex number to show how we can reuse code
Calm down Stephane - not all Squeakers have the time to read your papers. I will read them - at least some of them - but don't expect all of us to have the time to do that. So some simple questions, no matter how stupid, you will just have to be able to answer here on squeak-dev.
These questions were tailored in order to try to see a little bit, what the effects Traits would have on Traits-haters. I do plan to read the papers - but I also expect to be able to ask a few questions to you guys. Ok?
Anyway, the answers so far look good. Still, given the massive changes here (otherwise you wouldn't argue it being hard to maintain as a package), there is logically a good chance that this will "shine through" even to the Traits haters. I just want you to think hard about that issue.
As a first rough plan. Ok?
Yes
Good.
regards, Göran
Yes please do it, but read the %$%$#$%#X papers and try. We even did an example with complex number to show how we can reuse code
Calm down Stephane - not all Squeakers have the time to read your papers. I will read them - at least some of them - but don't expect all of us to have the time to do that. So some simple questions, no matter how stupid, you will just have to be able to answer here on squeak-dev.
But the model fits in half of a page in the ecoop paper. We spent months on this paper so you should get much more out of reading them that reading my emails. You know we are professional writers and this is not full of greek letters.
So read the ECOOP paper and if you want the OOPSLA one in diagonal It will take you 15 min for the ecoop one and you will know everything you want to know about traits.
http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf
These questions were tailored in order to try to see a little bit, what the effects Traits would have on Traits-haters. I do plan to read the papers - but I also expect to be able to ask a few questions to you guys. Ok?
Sure
Anyway, the answers so far look good. Still, given the massive changes here (otherwise you wouldn't argue it being hard to maintain as a package),
There are not massive but chirurgical and with precision. So you see this is different.
there is logically a good chance that this will "shine through" even to the Traits haters. I just want you to think hard about that issue.
Think think. But you know there is a tool delivering package Squat Mack, SqueakMap and if you click on it you can even load traits and open a changesorter ;) I can do that on emails.
Stef
stéphane ducasse wrote:
Yes please do it, but read the %$%$#$%#X papers and try. We even did an example with complex number to show how we can reuse code
Can you please point me to the papers again? I have looked through them previously, and at the time, I thought Traits would be an excellent addition to Squeak.
Thanks, David
Here are a few links:
General Overview: http://www.iam.unibe.ch/%7Escg/Research/Traits/index.html (links to some key papers on traits)
Overview of Squeak Implementation: http://www.iam.unibe.ch/~schaerli/smalltalk/traits/traitsPrototype.htm (includes very helpful screenshots of traits in action)
SqueakMap: http://map1.squeakfoundation.org/sm/package/0aa65fd8-aabb-4e46-9000-626361dd...
You look at this stuff and have to wonder of Traits might not be a nice arrow to have in the quiver for modularizing the image.
It would be great to get a rough, pseudo coded example from a Traits proponent on what a Traits-based solution might look like for making Networking in Squeak cleaner and more modular (too choose an arbitrary example). Let's say there were 3 competing networking frameworks, call them "StandardNetworking", "RefactoredNetworking", and "Flow". How might a Traits-based solution look for making the competing frameworks pluggable? If, say, FileList2 decided to make the switch from "StandardNetworking" to "Flow", would Traits help?
It might persuade some more people to promote Traits on "The big priority list in the sky" if it looks like it would help with some of the other big priorities.
At any rate, it's easy to see how Traits might provoke some strong feelings.
David P Harris wrote:
stéphane ducasse wrote:
Yes please do it, but read the %$%$#$%#X papers and try. We even did an example with complex number to show how we can reuse code
Can you please point me to the papers again? I have looked through them previously, and at the time, I thought Traits would be an excellent addition to Squeak. Thanks, David
Hi steven
You look at this stuff and have to wonder of Traits might not be a nice arrow to have in the quiver for modularizing the image.
Indeed read the OOPSLA paper and the image containing the refactored library should be around to have a look because nathanael and andrew always told me that it could better if the code would have been designed with traits in mind vs. subclassing hacks.
It would be great to get a rough, pseudo coded example from a Traits proponent on what a Traits-based solution might look like for making Networking in Squeak cleaner and more modular (too choose an arbitrary example). Let's say there were 3 competing networking frameworks, call them "StandardNetworking", "RefactoredNetworking", and "Flow".
Read the OOPSLA paper for that.
How might a Traits-based solution look for making the competing frameworks pluggable?
Traits provide you method categories kind of abstraction with required methods to get the entire method collection working (a bit like an abstract class that you can plug in any class you want).
If, say, FileList2 decided to make the switch from "StandardNetworking" to "Flow", would Traits help?
If both have a nearly similar interface it would work. But this is up front design.
It might persuade some more people to promote Traits on "The big priority list in the sky" if it looks like it would help with some of the other big priorities.
At any rate, it's easy to see how Traits might provoke some strong feelings.
:) Especially since we are working on something else for our research now :) So we do that because we think that this is good for squeak and not only as smart guys with big egos. Because researcher egos are in big papers in prestigious conference not languages with mickey mouse shape. Believe this is like that, else they would be much less researchers on typed-languages. And people would have less this condescending smile when I say that I'm programming in Squeak.
Stef
PS: by the way I hope one of your keybinding goodies will get in 3.9 (I forgot the connection with the keymapper/binding) But having that in the image with a cool emacs bindings would be realllllly coooool
stéphane ducasse wrote:
PS: by the way I hope one of your keybinding goodies will get in 3.9 (I forgot the connection with the keymapper/binding) But having that in the image with a cool emacs bindings would be realllllly coooool
C. David Shaffer did a lot to improve the keymapper stuff, and it's his baby now. If you can't get his involvement, I'll try to help.
Regards, Steve S.
Steven Swerling wrote:
stéphane ducasse wrote:
PS: by the way I hope one of your keybinding goodies will get in 3.9 (I forgot the connection with the keymapper/binding) But having that in the image with a cool emacs bindings would be realllllly coooool
C. David Shaffer did a lot to improve the keymapper stuff, and it's his baby now. If you can't get his involvement, I'll try to help.
Regards, Steve S.
I continue to develop the "Keymapping" package...which I would really have prefered to call Keymapper but that name was taken :-( Inclusion in the image isn't as important to me as having a more organized action framework including global "services" as well as application and morph-specific actions. Then I could hook Keymapping into that framework in a less kludgy way (keyboard shortcuts would trigger actions). This would also permit app developers to provide "default" keybindings which would be used if Keymapping is loaded. This came up on squeak-dev before and Avi and Romain and I discussed it off list a bit. We left it with the idea that services should be tagged in the methods...kind of like pragma mechanism in VisualWorks but avoiding new syntax. We didn't refine the idea any further however. I'm having a hard time keeping up with this mailling list but I think that there are three teams whose work might touch on these ideas: UI design, applications/tools? (don't recall the correct name of this team) and usability. I'm a little slow on the uptake but I hope to join these groups, as appropriate. Maybe Romain can chime in as well since I think his work directly impacts this.
David
Hi david
The simplest one is http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf 15 min to get the model.
Then a good one showing traits at work is OOPSLA 2004 http://www.iam.unibe.ch/~scg/cgi-bin/oobib.cgi? query=nathanael+applying+traits+to+the+collection+hierarchy+oopsla and a fun one on applying traits at the meta level is http://www.iam.unibe.ch/~scg/Archive/Diploma/Lien04a.pdf
you have the master of adrian on bootstrapping squeak http://www.iam.unibe.ch/~scg/Archive/Diploma/Lien04a.pdf
You have one on the browser
http://www.iam.unibe.ch/~scg/cgi-bin/oobib.cgi? query=a+browser+for+incremental+programming+computer+languages
You have one the methodology http://www.iam.unibe.ch/~scg/cgi-bin/oobib.cgi? query=Nathanael+traits+tools+and+methodology
On 24 févr. 05, at 19:31, David P Harris wrote:
stéphane ducasse wrote:
Yes please do it, but read the %$%$#$%#X papers and try. We even did an example with complex number to show how we can reuse code
Can you please point me to the papers again? I have looked through them previously, and at the time, I thought Traits would be an excellent addition to Squeak. Thanks, David
OK, I read the papers. Basically I'm in favour of using Traits; it's a nice concept that seems to have potential to make it easier to build neat classes and keep them neat. Keeping classes neat makes it easier for people to understand the _intent_ of class and thereby keep it on track. I have this theory that the main reason Morphic classes have become such disgusting piles of foetid bytecodes is that almost nobody that has changed them had a clue what was supposed to be happening.
I'm not so sure about the browser UI shown in the papers - using colours like that isn't something I feel very comfortable with for example - but so long as there are tools that actually work they can be improved upon later.
The pervasive use of accessor methods reminds of my dislike of having accessors for everything; it invites C-hacker rape and pillage. The problem is that they are not at all private and so expose the underlying structure of the class to any voyeur. We don't need to go far to see appalling code that abuses such methods and violates all the Laws of Demeter. We need to find a better way to handle this issue; some way to make such methods private in a suitable form would be useful. I suppose we could make a trivial hack by specifying the setter/getter messages to have a name that is always trtGetBlah for example. It would be a little ugly but probably functional enough for a beginning.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim "Bother," said Pooh, reading his bank statement from Barings.
On 24 févr. 05, at 23:28, Tim Rowledge wrote:
OK, I read the papers. Basically I'm in favour of using Traits; it's a nice concept that seems to have potential to make it easier to build neat classes and keep them neat. Keeping classes neat makes it easier for people to understand the _intent_ of class and thereby keep it on track. I have this theory that the main reason Morphic classes have become such disgusting piles of foetid bytecodes is that almost nobody that has changed them had a clue what was supposed to be happening.
I'm not so sure about the browser UI shown in the papers - using colours like that isn't something I feel very comfortable with for example - but so long as there are tools that actually work they can be improved upon later.
Yes (especially since in the version of the browser colors where different on mac and Pc :) This is true that while to model is really simple making a nice browser is challenging. Adrian had a brand new browser but the code analysis was missing. Nathanael is working on that. Using the old browser was quite difficult so we hope that using OB will really help us a lot.
The pervasive use of accessor methods reminds of my dislike of having accessors for everything; it invites C-hacker rape and pillage. The problem is that they are not at all private and so expose the underlying structure of the class to any voyeur. We don't need to go far to see appalling code that abuses such methods and violates all the Laws of Demeter. We need to find a better way to handle this issue; some way to make such methods private in a suitable form would be useful. I suppose we could make a trivial hack by specifying the setter/getter messages to have a name that is always trtGetBlah for example. It would be a little ugly but probably functional enough for a beginning.
Agree there too. We are open to ideas and suggestions.
Now nathanael has a solution but this is not for squeak :) or at least before next 10 years :) (if you still want to know read the new OOPSLA paper (take care this is more research than traits now).
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim "Bother," said Pooh, reading his bank statement from Barings.
On Thursday 24 February 2005 2:00 am, goran.krampe@bluefish.se wrote:
Now, I understand that maintaining Traits as a package is a hard thing to do. It is typically a quite advanced "patch" to the kernel stuff in Squeak. This all depends on how you guys have built it - through various refactorings or through simply modifications.
So the question remains - is Traits plausible to maintain as a package - or is it not? And also of course, if it is - would you be willing? Unless this is so - then this turns into a black and white choice.
It may be that doing some refactorings of Minimal to allow smoother loading of Traits would be possible.
I found that this helped with Connectors.
On 24 févr. 05, at 17:10, Ned Konz wrote:
On Thursday 24 February 2005 2:00 am, goran.krampe@bluefish.se wrote:
Now, I understand that maintaining Traits as a package is a hard thing to do. It is typically a quite advanced "patch" to the kernel stuff in Squeak. This all depends on how you guys have built it - through various refactorings or through simply modifications.
So the question remains - is Traits plausible to maintain as a package - or is it not? And also of course, if it is - would you be willing? Unless this is so - then this turns into a black and white choice.
It may be that doing some refactorings of Minimal to allow smoother loading of Traits would be possible.
the problem is that we are introducing a new hierarchy and changing a bit Behavior so this forces the recompilation of the class hierarchies.
Stef
I found that this helped with Connectors.
-- Ned Konz http://bike-nomad.com/squeak/
For (a) someone simply needs to install a suitable bug tracker. We could even use Debian's, I'd think.
Mmmm, Mantis is what we have today and... I and others (Ken just formed a Team on the subject) are suggesting that we *temporarily* focus on. Or did you mean some other tool?
Mantis is a big step forward for us, but it is not suitable for generating a released set of packages. That's because it does not let you attach bugs to individual packages, and thus there is no way to tell which packgaes are buggy and which are pristine.
Maybe Mantis can be modified for this; if so, that's great. The point is, we don't have it right now.
I don't think it would be hard.... If nothing else, we can probably steal Debian's bug tracker. And anyway, there are loads of bug trackers around. Or, maybe Brent wants a go at a bug tracker that works like this, complete with a Squeaky GUI--that would be marvelous! But whatever we do, we need some sort of bug tracker that can attach bugs to packages.
So anyway, given a package oriented view here I don't think we need a special update stream for "unstable stuff". Sure, we can still have the unstable stream as a "first front", but generally packages is what we want and then things work out naturally (meaning the maintainers can make their new releases available regardless of how stable they are etc).
There is an important point ignored here: We need to release *sets* of packages. Check out the "Why Package Universes Exist" page on the swiki for a long ramble about it, but the idea is: packages are only reliable in the context of other packages. This is because packages interact with each other. If we want to have a *set* of packages that are all reliable with respect to each other, then we need to manage such a set together instead of trying to release one package at a time.
http://minnow.cc.gatech.edu/squeak/3786
An example of not managing this, is RPM hell: you load RPM's from all different RedHat/Mandrake/FedoraCore distributions, and then you end up with an unstable system that can't load any more packages because the dependencies are screwed up. You can go a little forther if you use --nodeps, but eventually your tottery system is doomed. The problem here is not RPM. The problem is that you loaded packages that weren't built with each other in mind.
Packages give a lot of flexibility to the individual maintainers, but it is important not to take that all the way to the extreme of having each package live on an island and being developed completely independently. Packages interact. That's why we load multiple packages into the same image. Packages interact in far more ways than their dependencies can ever truly specify, and they very much interact with things in the base image they are loaded into. No package will have a dependency on whether #new calls #initialize, but it certainly is important!
Along these lines, the image can itself be thought of as a package; it's just a big package, that is maintained using different tools. It should be managed exactly the same way, however. It needs to be developed along with the other packages. And just as you can't make a release of the Tetris package by itself, you can't make a release of an image by itself. You need to release an image plus a set of packages.
Releasing an image by itself is not much good, especially as more and more things are in packages. Developers need not only a stable image, but a stable image plus a lot of goodies at their fingertips.
-Lex
"Lex Spoon" lex@cc.gatech.edu wrote: [SNIP]
So anyway, given a package oriented view here I don't think we need a special update stream for "unstable stuff". Sure, we can still have the unstable stream as a "first front", but generally packages is what we want and then things work out naturally (meaning the maintainers can make their new releases available regardless of how stable they are etc).
There is an important point ignored here: We need to release *sets* of packages.
:) No, I didn't ignore that. I was just saying that the need for an unstable stream is much less in a package oriented world - because then the package maintainer can release new releases without affecting people that do not install those releases. And I am not saying anything about how releases are combined or chosen for installation etc.
With a stream you don't have the choice - you will just have to either don't load updates or eat all the food on the plate. *That* was my point, nothing else. I did not talk about the issue of a coherent set of packages - which we are all aware of - I was talking about the need of an *unstable update stream*.
Check out the "Why Package Universes Exist" page on the swiki for a long ramble about it, but the idea is: packages are only reliable in the context of other packages. This is because packages interact
You know that I know all this. :)
regards, Göran
Am 25.02.2005 um 02:26 schrieb Lex Spoon:
For (a) someone simply needs to install a suitable bug tracker. We could even use Debian's, I'd think.
Mmmm, Mantis is what we have today and... I and others (Ken just formed a Team on the subject) are suggesting that we *temporarily* focus on. Or did you mean some other tool?
Mantis is a big step forward for us, but it is not suitable for generating a released set of packages. That's because it does not let you attach bugs to individual packages, and thus there is no way to tell which packgaes are buggy and which are pristine.
Maybe Mantis can be modified for this; if so, that's great. The point is, we don't have it right now.
I don't think it would be hard.... If nothing else, we can probably steal Debian's bug tracker. And anyway, there are loads of bug trackers around. Or, maybe Brent wants a go at a bug tracker that works like this, complete with a Squeaky GUI--that would be marvelous! But whatever we do, we need some sort of bug tracker that can attach bugs to packages.
We have been (ab-?) using Mantis categories for this. When you report a bug you can select a category which we have named after packages (also, there is a separate "Squeak external packages" project tracking, well, exteranl packages). To see all bugs pertaining to a specific package you need to filter for it.
- Bert -
On Friday 25 February 2005 3:10 am, Bert Freudenberg wrote:
We have been (ab-?) using Mantis categories for this. When you report a bug you can select a category which we have named after packages (also, there is a separate "Squeak external packages" project tracking, well, exteranl packages). To see all bugs pertaining to a specific package you need to filter for it.
It appears that Mantis supports the use of 'custom fields'.
Hi all
Sorry I will not argue again. I do not have the energy. Bye. you WON!
The essential answer to this has already been posted by Andreas:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-December/ 085923.html
Especially problematic are the "researchers" items:
- new compiler framework
- refactoring of SystemDictionary
- Traits
These three items are not about research 1) is needed but may be people do not care that we get UI dependency in parser.
2) I proposed a precise roadmap (now what can I say more than that)
3) it is fun that alan kay mentioned Traits in his turing award talk and that other languages such as Slate, perl, Scala and getting traits and we will not.
Sorry guys, I'm fed up. So I give up. Do what you want. And martin you can have exigence but in that case you should have the money...
Good luck boys
Stef
Here is what I think about these:
- I don't want to comment much on the compiler framework, except that
I think that it is critical to get this done properly, if it goes in.
- The ongoing attempt of refactoring SystemDictionary seems to be an
odyssey without much planning so far. This is not the right way to do a "refactoring" of a kernel part.
- Traits is a questionable language extension. It is questionable
because language extensions to Smalltalk themselves are questionable.
Here are Squeak's current problems ordered by importance:
- library
- speed
- documentation
- community organization
- public relations and awareness
- language
I am not going to bet on the exact order of 2 to 5 but I think it is clear that "library" is THE problem. Far behind at the end comes "language", simply because Smalltalk is still one of the best, if not the best programming language.
Smalltalk has a remarkable cost-performance ratio. Every addition to the language may worsen this ratio. Yet half of all people tend to ask the question:
- What benefit has the language extension/change?
But this is the wrong question. With this kind of judgement Squeak's way is paved to a concept-overloaded monster like Java.
Instead we should ask:
- What real problem does the language extension/change solve?
A real problem is of course not meant to be the absence of a benefit in a specific situation, the type of advantage the first question is about.
A real problem of a language is one that is ubiquitous when programming in that language, something which occurs literally every line, which really goes straight to the heart of its basic mechanism.
I think it will be really difficult to uncover and to distill such a core problem in Smalltalk and it is my conviction that Traits is not solving such a main problem.
As a consequence I think we should not include Traits into the official release. Instead I guess some people would like to see a specific "researchers edition" of Squeak from the Berne group.
This could be a fork in the sense of Avi's suggestion of having "recurring forks" - tall narrow trees with stubby branches coming off it at every level:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-December/ 086612.html
regards, Martin
On Wed, 23 Feb 2005 17:26:41 +0100, stéphane ducasse ducasse@iam.unibe.ch wrote:
Sorry guys, I'm fed up. So I give up. Do what you want.
Ah, so the deal is "either do what Stephane proposes or I'll walk away"? I seriously think that this is not very productive.
People are asking for information here. And that's their good right.
Now, if you could please point me to the latest SqueakMap loadable version of Traits that people can evaluate as "this is what we propose to land into Squeak 3.9", we'd have a basis for discussion. But the latest version is a beta version, and the latest large comment in SqueakMap on Traits, I quote:
"Limitations ----------- - There are still many features missing that are absolutely essential for getting the real "traits experience", but these are mainly related to the UI and IDE. For example: - There are no virtual categories that present the conflicts and glue methods of a composite class/trait. - There is no automatic computation of requirements - There is no information that shows which traits/classes provide or require the currently selected methods - There is no support for turning classes into trait - etc.
- The current UI is just a "minimal placeholder" that allows one to start using/playing with traits. However, many improvements are still missing. - There are known bugs in OmniBrowser (which still is in alpha). - The OmniBrowser updates very slowly.
- No documentation apart from the papers yet."
doesn't exactly invite people to start testing it. And it certainly get's no-one yelling "yes - that's what I want in Squeak 3.9!".
If you don't want to sell, please don't be surprised that no-one buys your product.
So, to get this topic back into something positive instead of whining around, let me put forward a couple of simple questions:
- Is the latest version of Traits on SqueakMap as limited as the above thing says? - If no, could you please update the comments? - If yes, what is needed to remove the limitations? How can people that are interested in getting Traits to an evaluable level cooperate?
Sorry guys, I'm fed up. So I give up. Do what you want.
Ah, so the deal is "either do what Stephane proposes or I'll walk away"? I seriously think that this is not very productive.
Because sending all the time email is productive? Do you think that people working have a time to read all that and do something after.
So I do not have the time to argue again and again and again. I do not have the time to read all the emails people are found to write. If squeakers do not want traits what can I say. Adrian worked hard in his master to reimplement ***everything*** from scratch with nathanael. Adrian is the guy behind SqueakSource and the seaside web site and he has a company selling seaside applications. So his code is quite excellent, but now if people don't give a shit of what we are doing, we will do something else or just keep it for himself.
Have you checked recently the posts of marcus? This indicates a lot to me.
People are asking for information here. And that's their good right.
Martin was not asking for information, he was saying that basically we are researchers and that what we are proposing is idiot or has no value and I do not want to argue with people at this level. Sorry!
Now, if you could please point me to the latest SqueakMap loadable version of Traits that people can evaluate as "this is what we propose to land into Squeak 3.9", we'd have a basis for discussion. But the latest version is a beta version, and the latest large comment in SqueakMap on Traits, I quote:
"Limitations
- There are still many features missing that are absolutely essential
for getting the real "traits experience", but these are mainly related to the UI and IDE. For example:
- There are no virtual categories that present the conflicts and
glue methods of a composite class/trait.
- There is no automatic computation of requirements
- There is no information that shows which traits/classes provide or
require the currently selected methods
There is no support for turning classes into trait
etc.
The current UI is just a "minimal placeholder" that allows one to
start using/playing with traits. However, many improvements are still missing.
There are known bugs in OmniBrowser (which still is in alpha).
The OmniBrowser updates very slowly.
No documentation apart from the papers yet."
doesn't exactly invite people to start testing it. And it certainly get's no-one yelling "yes - that's what I want in Squeak 3.9!".
You mix everything. We always said that we would commit to produce high quality code and environment and if this would not be ready we will not push it. Should I re-say again and again and again. Traits are working fully working with tests. Now the UI is not at the level we would like it to be. But now the point is that we could not work further since we were waiting for new versions of OmniBrowser. So you can see that my proposal for 3.9 is quite coherent.
If you don't want to sell, please don't be surprised that no-one buys your product.
Come on, this is not because recently you show up that we were not working before and paying attention to squeak and related. Since the beginning we always payed attention about what we have been doing. everything is public.
So, to get this topic back into something positive instead of whining around, let me put forward a couple of simple questions:
- Is the latest version of Traits on SqueakMap as limited as the above
thing says?
- If no, could you please update the comments?
- If yes, what is needed to remove the limitations? How can people
that are interested in getting Traits to an evaluable level cooperate?
I will adrian and nathanael reply.
The source is available on SqueakMap since day one. And everybody has always been welcomed. Adrian posted call for feedback long time ago. Look into the archive. Adrian interfaced it with Monticello and the new version of OB because the class browser code is so bad. He boostrapped the kernel but each time a new release of squeak is coming and something change then he has to check again if the changes we had to do on the kernel have to be redone.
We produced the SystemChangeNotifier so that traits can be nicely introduced. Nathanael cleaned the classOrganization so that traits can be introduced easily. We pushed omnibrowser because this is the only way that we can get a new browser for traits. We proposed to give a real definition to canUnderstand in presence of abstract method but people having nothing to do with squeak started to shout.
Now nathanael has been developing a better algorithm for the UI but again as I said if squeakers do not want that I'm sure some people will like it...
Apparently alan is found of traits so there is some hope.
Stef
On Wed, 23 Feb 2005 21:44:24 +0100, stéphane ducasse ducasse@iam.unibe.ch wrote:
Martin was not asking for information, he was saying that basically we are researchers and that what we are proposing is idiot or has no value and I do not want to argue with people at this level. Sorry!
I hear that a lot of you. Martin was just lining out a very sound set of rules *iff* you work under the assumption that Smalltalk/Squeak needs to be as stable as possible. I have never read that he found Traits idiotic, at best he finds them unnecessary and if I recall he was fishing for evidence to the contrary.
You mix everything.
No, I don't. I just emulate Joe Average who loads up SqueakMap, sees Traits, thinks "hey that's this cool stuff from the Berne guys", but finds this comment.
We always said that we would commit to produce high quality code and environment and if this would not be ready we will not push it. Should I re-say again and again and again.
No, you need to say it only once. In the SqueakMap comments, for starters, where chances are higher that people will read it than in any posting on the mailing list.
So you can see that my proposal for 3.9 is quite coherent.
Maybe from your point of view. But can't you understand that outsiders, who haven't got access to full Traits with a souped up OmniBrowser etcetera, nor to the original prototype, are quite skeptical? They have to put a lot of trust in you guys for what amounts to be the first major language chance in quite some time.
And don't understand me wrong - I like Traits. I want it to become usable for everyone, because I think it does solve some genuine problems. I'm just playing the devil's advocate here, attempting to clarify more skeptical viewpoints on Traits.
But - please let's drop this metadiscussion. It eats too much energy and distracts from the stuff that is really important. If you feel like answering my statements above, feel free to do so; I'll however will probably not respond anymore, because this is more important:
Adrian posted call for feedback long time ago.
I'm beginning to get the feeling that general calls for feedback don't work in this community ;)
So one issue to solve is how to get more people looking at Traits, and hopefully working towards a releasable level.
Adrian interfaced it with Monticello and the new version of OB because the class browser code is so bad.
The drawback is that this ties Traits' release schedule to OB's release schedule, not?
He boostrapped the kernel but each time a new release of squeak is coming and something change then he has to check again if the changes we had to do on the kernel have to be redone.
That's of course a problem that will persist as long as Traits ain't "out there".
We proposed to give a real definition to canUnderstand in presence of abstract method but people having nothing to do with squeak started to shout.
Hmm... probably missed that one - do you have a pointer or at least approximate time period about this discussion?
Apparently alan is found of traits so there is some hope.
Heh. Well, Alan is fond of Croquet as well, I assume, but that isn't going to make it land into 3.9 base ;)
Concluding, Stephane - I'm committed to getting Traits into 3.9, 4.0, or whatever. But not by forcing it through everyone's throat. There must be some time to be able to play with the stuff, some time to build up a real world code base with Traits, to have people look at kernel refactorings with Traits, etcetera. All the other good tools that are in the base image have had to go through the same testing and acceptance process: SqueakMap, Monticello, all were available and in use before they were made part of the base image. Traits *must* go through the same process, it's to big to just shove it in. So it's vital to get a production-level version out there ASAP so people can work with it. That's usually the best way to let people make up their minds.
Cees de Groot cg@cdegroot.com wrote:
No, I don't. I just emulate Joe Average who loads up SqueakMap, sees Traits, thinks "hey that's this cool stuff from the Berne guys", but finds this comment.
Yes, there is a lot of this problem. I have paid a lot of attention to Traits, reading the papers and even speaking to Nathanael a bit. I'm very excited about the project, but I am not sure of some things like: what is the tools status, and what are all the stability implications of adding it to Basic? Will it add bugs, or will it sit over in its corner of the image and play nice? I can't tell, even these kind of questions must be obvious to the Berne gang.
These seem like important issues to consider, because it would be a poor choice to make one great change for the future of Squeak, while messing things up for 100 other people. And while these issues must have obvious answers for the Berne folks, please remember that very many people are messing with Squeak. We're not dumb. Just slow. Err, something like that.
-Lex
PS -- Speaking of communication, let's please allow the term "TFNR" die the quiet death it should have died back in November of whatever year it was. Call it something that has a clear meaning, not something that you only understand if you live on the IRC channel and attend every Squeak and Smalltalk event on the planet.
On Wed, 23 Feb 2005 23:30:31 -0400, Lex Spoon lex@cc.gatech.edu wrote:
PS -- Speaking of communication, let's please allow the term "TFNR" die the quiet death it should have died back in November of whatever year it was. Call it something that has a clear meaning, not something that you only understand if you live on the IRC channel and attend every Squeak and Smalltalk event on the planet.
I didn't attent Smalltalk Solutions last year but I *still* understand TFNR... ;)
Seriously: you're right. We should stop making in-crowd-only names. Packace/Responsibility Assignment thingy?
Lex writes:
...let's please allow the term "TFNR" die the quiet death it should have died back in November of whatever year it was.
Cees responds:
Package/Responsibility Assignment thingy?
It seems we've taken to calling it "partitioning".
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
No, you need to say it only once. In the SqueakMap comments, for starters, where chances are higher that people will read it than in any posting on the mailing list.
We will fix that. adrian was far too explicit because half of it is not a problem (documentation;)
Adrian posted call for feedback long time ago.
I'm beginning to get the feeling that general calls for feedback don't work in this community ;)
:)
So one issue to solve is how to get more people looking at Traits, and hopefully working towards a releasable level.
Indeed
The drawback is that this ties Traits' release schedule to OB's release schedule, not?
Not really since adrian extended the normal browser to be able to define traits. But you will not get the hyper fancy features of the original browser of nathanael in the default one but in OB.
He boostrapped the kernel but each time a new release of squeak is coming and something change then he has to check again if the changes we had to do on the kernel have to be redone.
That's of course a problem that will persist as long as Traits ain't "out there".
Yes we redo regularly the work.
We proposed to give a real definition to canUnderstand in presence of abstract method but people having nothing to do with squeak started to shout.
Hmm... probably missed that one - do you have a pointer or at least approximate time period about this discussion?
look for canUnderstand
canUnderstand: is returning true even when there is only self subclassResponsibility in the body and this is a problem Because if you send a message after you get an error which is not what you want. And traits requirements are expressed as self requirement... So some people shouted and they were wrong and that drove us crazy because big mouths were talking as usual.
Apparently alan is found of traits so there is some hope.
Heh. Well, Alan is fond of Croquet as well, I assume, but that isn't going to make it land into 3.9 base ;)
Concluding, Stephane - I'm committed to getting Traits into 3.9, 4.0, or whatever. But not by forcing it through everyone's throat.
This was never our intention this is why EVERYTHING has been public. Nathanael refactored the collection and stream classes this is at OOPSLA so this should be just research! But this is not.
There must be some time to be able to play with the stuff, some time to build up a real world code base with Traits, to have people look at kernel refactorings with Traits, etcetera.
Exactly 3000% correct. We do not that we never did and we do not want to be the guys that fucked up and that 3.9 is a doomed fucked up release by the guys from berne. You see what I mean. Also at the conceptual level I want to be able to use Squeak to teach newbie and this is why I do not want namespaces. So your points are reasonable and we will work hard to arrive to that point. But now our effort can't be just ok this is just research stuff and this is..m,.m.m
All the other good tools that are in the base image have had to go through the same testing and acceptance process: SqueakMap, Monticello, all were available and in use before they were made part of the base image. Traits *must* go through the same process, it's to big to just shove it in. So it's vital to get a production-level version out there ASAP so people can work with it. That's usually the best way to let people make up their minds.
Exact! We never said anything else. Reread the 3.9 roadmap all is there! We ALREADY say it.
Hi fellow Squeakers! (extra cheerful)
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote: [SNIP]
We proposed to give a real definition to canUnderstand in presence of abstract method but people having nothing to do with squeak started to shout.
Hmm... probably missed that one - do you have a pointer or at least approximate time period about this discussion?
look for canUnderstand
canUnderstand: is returning true even when there is only self subclassResponsibility in the body and this is a problem Because if you send a message after you get an error which is not what you want. And traits requirements are expressed as self requirement... So some people shouted and they were wrong and that drove us crazy because big mouths were talking as usual.
I recall that - and I also see the problem. This seems like a simple problem to figure out? Was it never resolved? What was the "wrong" opinion? And if people don't want to touch the canUnderstand:, why can't we have another method doing the Right Thing? :)
Let's resolve this.
[SNIP]
There must be some time to be able to play with the stuff, some time to build up a real world code base with Traits, to have people look at kernel refactorings with Traits, etcetera.
Exactly 3000% correct. We do not that we never did and we do not want to be the guys that fucked up and that 3.9 is a doomed fucked up release by the guys from berne. You see what I mean. Also at the conceptual level I want to be able to use Squeak to teach newbie and this is why I do not want namespaces. So your points are reasonable and we will work hard to arrive to that point. But now our effort can't be just ok this is just research stuff and this is..m,.m.m
Right.
All the other good tools that are in the base image have had to go through the same testing and acceptance process: SqueakMap, Monticello, all were available and in use before they were made part of the base image. Traits *must* go through the same process, it's to big to just shove it in. So it's vital to get a production-level version out there ASAP so people can work with it. That's usually the best way to let people make up their minds.
Exact! We never said anything else. Reread the 3.9 roadmap all is there! We ALREADY say it.
Ok, then I may have misunderstood it - I felt like it was presented as something to decide upon right now. Perhaps we can put it like this instead:
- First you guys make sure there is a beta (or better) available for us to play with. - Then we... hey, why not simply make a Team that investigates it? Look it over, check the code, try it out, see what newbies and oldtimes stumble on, perhaps refine and document based on that, etc. This work ought to be useful in any case. - Go to the stakeholder communities and get their input. - After that we either: 1. Decide it is good to go and we want to have it in the Basic official distro. 2. Decide it is good, but based on other feedback we want to have it as an "optional official" package instead. At least for a while. This would mean it isn't in Basic - but we make sure it is presented as a officially community supported package. If you know what I mean. 3. Decide it is bad and it will have to stay as "any package".
... and if we hurry up we might be able to get this included in 3.9 or else it will be in 4.0 - but that doesn't really matter, now does it? Because the above steps seems something we *do* need to do.
Ok, just a suggestion - how does that sound? Stef? Nathanael?
regards, Göran
Hi Göran and all
... and if we hurry up we might be able to get this included in 3.9 or else it will be in 4.0 - but that doesn't really matter, now does it? Because the above steps seems something we *do* need to do.
Ok, just a suggestion - how does that sound? Stef? Nathanael?
I fully agree with you. It's very important to make sure that Traits (as all the other major tools/improvements) are made available (at least as a beta) so that the "evaluation crew" (and anyone else who is interested) can see it and decide whether it should go into the image.
Therefore, I also agree with Goran that following this process is something we do need to do and if that means that it will postpone it to Squeak 4.0 rather than 3.9, so be it.
But at the same time, I can also understand Stef's concerns. Pushing traits ahead means a lot of work for him and his students (such as Adrian and me ;-). And because traits have a fair amount of dependencies on the kernel, it requires a lot of work just to keep it compatible with each new version of Squeak. So, I can really see why he would like to have it to be in the image as soon as possible.
What makes this worse is that some people really do not understand the difference between research and improving Squeak for the community (which we are of course also part of)! When we invented traits three years ago, this was exciting research and that's why we implemented a prototype that allowed us to do all the cool experiments that were necessary from a scientfic point of view. But this is where the research aspect ended and we could have stopped right there without loosing anything as far as fun and research is concerned. However, we didn't because we thought that traits could be a very useful improvement for the Squeak language and we wanted to make it available to the community. This is why we went throught the hassle of cleaning the kernel and implementing a clean version of traits on top of it, even though this was really "boring engineering work" and was taking away time that we could spend on cooler stuff!
Regarding all this (and knowing Stef's French spirit ;-), even I (a "nice" and calm Swiss) can somehow understand that Stef freaks out when he reads that traits are a "research item" that only serves the purpose of satisfying the urges of some academics.
As a last point, I would like to say that I somtimes wish that people would be a bit more open-minded regarding their judgments of improvements to the Smalltalk language. I think it is very important to keep in mind that humans have a tendency to idealize what they are used to, simply because this is what they know.
Cheers, Nathanael
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of goran.krampe@bluefish.se Sent: Donnerstag, 24. Februar 2005 10:49 To: The general-purpose Squeak developers list Subject: Re: Stefs roadmap for 3.9, time to get it nailed down
Hi fellow Squeakers! (extra cheerful)
=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote: [SNIP]
We proposed to give a real definition to canUnderstand
in presence
of abstract method but people having nothing to do with squeak started to shout.
Hmm... probably missed that one - do you have a pointer
or at least
approximate time period about this discussion?
look for canUnderstand
canUnderstand: is returning true even when there is only self subclassResponsibility in the body and this is a problem Because if you send a message after you get an error which
is not what
you want. And traits requirements are expressed as self requirement... So some people shouted and they were
wrong and
that drove us crazy because big mouths were talking as usual.
I recall that - and I also see the problem. This seems like a simple problem to figure out? Was it never resolved? What was the "wrong" opinion? And if people don't want to touch the canUnderstand:, why can't we have another method doing the Right Thing? :)
Let's resolve this.
[SNIP]
There must be some time to be able to play with the
stuff, some time
to build up a real world code base with Traits, to have
people look at
kernel refactorings with Traits, etcetera.
Exactly 3000% correct. We do not that we never did and we
do not want
to be the guys that fucked up and that 3.9 is a doomed fucked up release by the guys from
berne. You
see what I mean. Also at the conceptual level I want to be able to use Squeak to teach newbie and
this is why I
do not want namespaces. So your points are reasonable and we will work hard to arrive to that point. But now our effort can't be just ok this is just
research stuff
and this is..m,.m.m
Right.
All the other good tools that are in the base image have had to go
through the same testing and acceptance process: SqueakMap, Monticello, all were available and in use before they
were made part
of the base image. Traits *must* go through the same
process, it's to
big to just shove it in. So it's vital to get a production-level version out there ASAP so people can work with it. That's
usually the
best way to let people make up their minds.
Exact! We never said anything else. Reread the 3.9 roadmap all is
there! We
ALREADY say it.
Ok, then I may have misunderstood it - I felt like it was presented as something to decide upon right now. Perhaps we can put it like this instead:
- First you guys make sure there is a beta (or better)
available for us to play with.
- Then we... hey, why not simply make a Team that
investigates it? Look it over, check the code, try it out, see what newbies and oldtimes stumble on, perhaps refine and document based on that, etc. This work ought to be useful in any case.
- Go to the stakeholder communities and get their input.
- After that we either:
- Decide it is good to go and we want to have it in
the Basic official distro. 2. Decide it is good, but based on other feedback we want to have it as an "optional official" package instead. At least for a while. This would mean it isn't in Basic - but we make sure it is presented as a officially community supported package. If you know what I mean. 3. Decide it is bad and it will have to stay as "any package".
... and if we hurry up we might be able to get this included in 3.9 or else it will be in 4.0 - but that doesn't really matter, now does it? Because the above steps seems something we *do* need to do.
Ok, just a suggestion - how does that sound? Stef? Nathanael?
regards, Göran
Hello,
Regarding all this (and knowing Stef's French spirit ;-), even I (a "nice" and calm Swiss) can somehow understand that Stef freaks out when he reads that traits are a "research item" that only serves the purpose of satisfying the urges of some academics.
As a last point, I would like to say that I somtimes wish that people would be a bit more open-minded regarding their judgments of improvements to the Smalltalk language. I think it is very important to keep in mind that humans have a tendency to idealize what they are used to, simply because this is what they know.
I agree with this (not only the first line, but the second paragraph).
I'd skip writing my feeling and reasoning, but I think Traits is good, and should be in the main image.
Just one vote,
-- Yoshiki
I'd skip writing my feeling and reasoning, but I think Traits is good, and should be in the main image.
Just one vote,
You see Yoshiki this is big kick in our ... to make sure that what we will deliver is at the quality we dream about :) and squeakers like you deserve. Else this would be an embarasment for us.
Stef
Hello,
You see Yoshiki this is big kick in our ... to make sure that what we will deliver is at the quality we dream about :) and squeakers like you deserve. Else this would be an embarasment for us.
Not that I'm pretending to be a nice guy. The inquiries from Göran and Cees to you (guys), and the answers from you guys helped me to clarify some of the questions I had.
Also, I'd note again that I also want to have an "official" image that is in "real, real maintainance mode." Just bug fixes. A version that can be used for a basis and reference point.
A version that might be called "3.9" could be something like this, and probably something that could be called 4.x can have somewhat aggressive changes.
-- Yoshiki
You see Yoshiki this is big kick in our ... to make sure that what we will deliver is at the quality we dream about :) and squeakers like you deserve. Else this would be an embarasment for us.
Not that I'm pretending to be a nice guy. The inquiries from Göran and Cees to you (guys), and the answers from you guys helped me to clarify some of the questions I had.
Just ask if you want more.
Also, I'd note again that I also want to have an "official" image that is in "real, real maintainance mode." Just bug fixes. A version that can be used for a basis and reference point.
Me too. I would feel really bad if we would deliver something bad or average.
A version that might be called "3.9" could be something like this, and probably something that could be called 4.x can have somewhat aggressive changes.
You see Yoshiki this is big kick in our ... to make sure that what we will deliver is at the quality we dream about :) and squeakers like you deserve. Else this would be an embarasment for us.
There's certainly nothing to be embarrassed about. I've read the papers well enough to answer a lot of the questions that have come up (like flattening making traits transparent, and that the image could conceivably shrink). For those of you who haven't, it's not a lot of material, and it's good reading.
I first learned to use objects in 1989 or 1990. I've used them subsequently in every job where it was possible to do so. But it only took a few weeks to realize OO's shortcomings. Traits is not a panacaea obviously, but it addresses a lot of those shortcomings--and does so in a way that's (to my eye) compatible with Smalltalk's elegance.
I don't know who Goran's "trait-haters" are but, so far, I haven't seen much feedback from anyone who appears to "get it".
Hi Nathanael!
Just to make this clear, I very well understand that the proposed inclusion of Traits in mainstream Squeak is aimed to serve all users of Squeak and not only researchers. I didn't talk of research items, instead I wrote "researcher's" items. Perhaps I wanted to express with the quotation marks that you are not only researchers but of course members of the community too ;)
Let me further assure you that I know what hard work you and others have invested in Traits and I am also quite sure that from an implementors point of view we are talking about high quality work here.
Unfortunately this has often an unexpected drawback likely being overlooked. Mostly everyone who wants to critically discuss Traits the language extension, hesitates to do so, knowing about the hard work you spent and the hopes you associate with it.
Really unfortunately adding to this is Stephane's bully behavior, so that a discussion about the pros and cons of Traits is endangered to become very single sided, if it starts at all.
To break this silence I jump-started the discussion with an abstract criterion which I consider a good test for a bigger language extension to Smalltalk.
So if you say humans tend to stick to what they know and you would wish to the opposite, my reply is that programmers seem not to be humans - I see languages all over the place which are, as I called it, concept-overloaded, growing with every new version.
My wish would not only to have an open mind but an "over mind". Focussing on some specific thing and becoming enthusiastic may lead the open mind to neglect the bird's eye view asking the question:
What do I gain in the end?
A final word to the ongoing discussion. The question:
Can I switch off Traits and work as if it were not there?
is not the important one. After all we don't want to incorporate Traits just to switch its existence for the programmer off, because that would mean that we shouldn't put it in at all. This is absolutely clear in case there are no core libraries with Traits. If there are, we get the performance hit from the inst var setters and getters. Given that we have the standard core libraries already, why replace them with slower ones when the browsers are "flattening" the traits?
So the more appropriate question is:
Can I program significantly better with Traits or not?
Some very final words about my preliminary reasoning so far:
My judgement about this more appropriate question was based on a purely theoretical basis. I assumed that we could have a traitified Collection hierarchy and I guess Collections are by far the best example of where to use Traits, because they are deeply hierarchical and this hierarchy is also the best example of the "inheritance-maze".
But thinking theoretically I could not imagine if Traits makes it really easier to understand the code or disentangles the "inheritance-maze" somewhat or not.
Furthermore this Collection hierarchy is already there! It is my assumption, that unless I program a similar hierarchical monster like Collections I don't gain much from Traits. I even fear that Traits may lure into programming hierarchical, where a flat structure combined with the normal composition would be the better way to go.
Conclusion: It is surely the right thing to produce somehow an image with Traits, be it the "Berne edition" as a recurring fork or not, so that people can study Traits practically, doing actually a project with Traits.
And then we should hope for an open discussion.
Regards, Martin
Nathanael Schärli wrote:
Hi Göran and all
... and if we hurry up we might be able to get this included in 3.9 or else it will be in 4.0 - but that doesn't really matter, now does it? Because the above steps seems something we *do* need to do.
Ok, just a suggestion - how does that sound? Stef? Nathanael?
I fully agree with you. It's very important to make sure that Traits (as all the other major tools/improvements) are made available (at least as a beta) so that the "evaluation crew" (and anyone else who is interested) can see it and decide whether it should go into the image.
Therefore, I also agree with Goran that following this process is something we do need to do and if that means that it will postpone it to Squeak 4.0 rather than 3.9, so be it.
But at the same time, I can also understand Stef's concerns. Pushing traits ahead means a lot of work for him and his students (such as Adrian and me ;-). And because traits have a fair amount of dependencies on the kernel, it requires a lot of work just to keep it compatible with each new version of Squeak. So, I can really see why he would like to have it to be in the image as soon as possible.
What makes this worse is that some people really do not understand the difference between research and improving Squeak for the community (which we are of course also part of)! When we invented traits three years ago, this was exciting research and that's why we implemented a prototype that allowed us to do all the cool experiments that were necessary from a scientfic point of view. But this is where the research aspect ended and we could have stopped right there without loosing anything as far as fun and research is concerned. However, we didn't because we thought that traits could be a very useful improvement for the Squeak language and we wanted to make it available to the community. This is why we went throught the hassle of cleaning the kernel and implementing a clean version of traits on top of it, even though this was really "boring engineering work" and was taking away time that we could spend on cooler stuff!
Regarding all this (and knowing Stef's French spirit ;-), even I (a "nice" and calm Swiss) can somehow understand that Stef freaks out when he reads that traits are a "research item" that only serves the purpose of satisfying the urges of some academics.
As a last point, I would like to say that I somtimes wish that people would be a bit more open-minded regarding their judgments of improvements to the Smalltalk language. I think it is very important to keep in mind that humans have a tendency to idealize what they are used to, simply because this is what they know.
Cheers, Nathanael
Hi martin
I will summarize it like that. We did our homework: reimplementing everything, refactored hierarchies, thought about browser, navigation, speed integration, got a mailing-list, a new beta version. Cleaned stuff at the same time. We will certainly offer a new version soon so that people can play with it and the new browser. What we propose is concrete, solid, tested (now we may still have bugs but we have tests for that too).
Now do your homework. Read the papers, take the implementation and comments. But we are not in theorical thinking anymore. If you want to kick do it real! Else we will stop to reply and you will complain that we cannot discuss but discussing theorically is not a squeak fashion. :)
Stef
On 24 févr. 05, at 22:46, Martin Wirblat wrote:
Hi Nathanael!
Just to make this clear, I very well understand that the proposed inclusion of Traits in mainstream Squeak is aimed to serve all users of Squeak and not only researchers. I didn't talk of research items, instead I wrote "researcher's" items. Perhaps I wanted to express with the quotation marks that you are not only researchers but of course members of the community too ;)
Let me further assure you that I know what hard work you and others have invested in Traits and I am also quite sure that from an implementors point of view we are talking about high quality work here.
Unfortunately this has often an unexpected drawback likely being overlooked. Mostly everyone who wants to critically discuss Traits the language extension, hesitates to do so, knowing about the hard work you spent and the hopes you associate with it.
Really unfortunately adding to this is Stephane's bully behavior, so that a discussion about the pros and cons of Traits is endangered to become very single sided, if it starts at all.
To break this silence I jump-started the discussion with an abstract criterion which I consider a good test for a bigger language extension to Smalltalk.
So if you say humans tend to stick to what they know and you would wish to the opposite, my reply is that programmers seem not to be humans - I see languages all over the place which are, as I called it, concept-overloaded, growing with every new version.
My wish would not only to have an open mind but an "over mind". Focussing on some specific thing and becoming enthusiastic may lead the open mind to neglect the bird's eye view asking the question:
What do I gain in the end?
A final word to the ongoing discussion. The question:
Can I switch off Traits and work as if it were not there?
is not the important one. After all we don't want to incorporate Traits just to switch its existence for the programmer off, because that would mean that we shouldn't put it in at all. This is absolutely clear in case there are no core libraries with Traits. If there are, we get the performance hit from the inst var setters and getters. Given that we have the standard core libraries already, why replace them with slower ones when the browsers are "flattening" the traits?
So the more appropriate question is:
Can I program significantly better with Traits or not?
Some very final words about my preliminary reasoning so far:
My judgement about this more appropriate question was based on a purely theoretical basis. I assumed that we could have a traitified Collection hierarchy and I guess Collections are by far the best example of where to use Traits, because they are deeply hierarchical and this hierarchy is also the best example of the "inheritance-maze".
But thinking theoretically I could not imagine if Traits makes it really easier to understand the code or disentangles the "inheritance-maze" somewhat or not.
Furthermore this Collection hierarchy is already there! It is my assumption, that unless I program a similar hierarchical monster like Collections I don't gain much from Traits. I even fear that Traits may lure into programming hierarchical, where a flat structure combined with the normal composition would be the better way to go.
Conclusion: It is surely the right thing to produce somehow an image with Traits, be it the "Berne edition" as a recurring fork or not, so that people can study Traits practically, doing actually a project with Traits.
And then we should hope for an open discussion.
Regards, Martin
Nathanael Schärli wrote:
Hi Göran and all
... and if we hurry up we might be able to get this included in 3.9 or else it will be in 4.0 - but that doesn't really matter, now does it? Because the above steps seems something we *do* need to do.
Ok, just a suggestion - how does that sound? Stef? Nathanael?
I fully agree with you. It's very important to make sure that Traits (as all the other major tools/improvements) are made available (at least as a beta) so that the "evaluation crew" (and anyone else who is interested) can see it and decide whether it should go into the image. Therefore, I also agree with Goran that following this process is something we do need to do and if that means that it will postpone it to Squeak 4.0 rather than 3.9, so be it. But at the same time, I can also understand Stef's concerns. Pushing traits ahead means a lot of work for him and his students (such as Adrian and me ;-). And because traits have a fair amount of dependencies on the kernel, it requires a lot of work just to keep it compatible with each new version of Squeak. So, I can really see why he would like to have it to be in the image as soon as possible. What makes this worse is that some people really do not understand the difference between research and improving Squeak for the community (which we are of course also part of)! When we invented traits three years ago, this was exciting research and that's why we implemented a prototype that allowed us to do all the cool experiments that were necessary from a scientfic point of view. But this is where the research aspect ended and we could have stopped right there without loosing anything as far as fun and research is concerned. However, we didn't because we thought that traits could be a very useful improvement for the Squeak language and we wanted to make it available to the community. This is why we went throught the hassle of cleaning the kernel and implementing a clean version of traits on top of it, even though this was really "boring engineering work" and was taking away time that we could spend on cooler stuff! Regarding all this (and knowing Stef's French spirit ;-), even I (a "nice" and calm Swiss) can somehow understand that Stef freaks out when he reads that traits are a "research item" that only serves the purpose of satisfying the urges of some academics. As a last point, I would like to say that I somtimes wish that people would be a bit more open-minded regarding their judgments of improvements to the Smalltalk language. I think it is very important to keep in mind that humans have a tendency to idealize what they are used to, simply because this is what they know. Cheers, Nathanael
On Thu, 24 Feb 2005 22:46:30 +0100, Martin Wirblat sql.mawi@t-link.de wrote:
Furthermore this Collection hierarchy is already there!
What in incredibly weak argument. I think I'll just let it stand here, it's actually too weak to discuss seriously.
...
Ok. Here goes: you are saying "don't touch anything because it's there". Whether it stinks or not. I think that's being absurdly conservative. You have a pile of dirt on your doorstep and you let it smell because it's already there?
Personally, I'm of the opposite persuasion - code smells and bit rot have to be battled with any available means. If the available means don't suffice, make new means. The refactoring of the Collection (and most likely Morphic) hierarchies in itself are for me reason enough to vote for its inclusion into base Squeak (given due process, etcetera), because frankly I don't know of any alternative solution that comes even close if it's about cleaning up these old sores.
Furthermore, by loose induction, I would say that if Traits is able to elegantly deal with these two warts, I think it will prove to be a very productive tool in the average developer's toolchest.
Cees, that what the perfect rip out of context.
I said that I assume that you need to be on something deeply hierarchical to make use of Traits:
"Furthermore this Collection hierarchy is already there! It is my assumption, that unless I program a similar hierarchical monster like Collections I don't gain much from Traits. I even fear that Traits may lure into programming hierarchical, where a flat structure combined with the normal composition would be the better way to go."
If Collections can be refactored so that the code is better understandable it is a plus for Traits (the minus would be the speed loss). If Morphic could be refactored with the help of Traits it would be another plus. Well, looking at Tweak and its more flat structure - the opposite direction! - I doubt that Traits would be a big help in refactoring Morphic. And as I said, it may even lure into the wrong direction...
But all of this was my "preliminary" thinking, and it was not meant to say "don't touch anything because it's there". Your allegation is a bit absurd. I just felt that it is only fair to explain a bit what I thought so far.
Most importantly my "preliminary" thinking should show, that on a pure theoretical basis it is hard to make judgements, that it really would help to have a traitified image, where you get the full "traits feeling" and where you could try out something for real.
Regards, Martin
Cees de Groot wrote:
On Thu, 24 Feb 2005 22:46:30 +0100, Martin Wirblat sql.mawi@t-link.de wrote:
Furthermore this Collection hierarchy is already there!
What in incredibly weak argument. I think I'll just let it stand here, it's actually too weak to discuss seriously.
...
Ok. Here goes: you are saying "don't touch anything because it's there". Whether it stinks or not. I think that's being absurdly conservative. You have a pile of dirt on your doorstep and you let it smell because it's already there?
Personally, I'm of the opposite persuasion - code smells and bit rot have to be battled with any available means. If the available means don't suffice, make new means. The refactoring of the Collection (and most likely Morphic) hierarchies in itself are for me reason enough to vote for its inclusion into base Squeak (given due process, etcetera), because frankly I don't know of any alternative solution that comes even close if it's about cleaning up these old sores.
Furthermore, by loose induction, I would say that if Traits is able to elegantly deal with these two warts, I think it will prove to be a very productive tool in the average developer's toolchest.
but this is fun because this is already a long time ago that we discuss with andreas about traits in Tweak and he was really interested (even if the fact that the main root is quite large and it does not really make sense to create another one, traits could help to structure its role).
On 25 févr. 05, at 12:09, Martin Wirblat wrote:
Well, looking at Tweak and its more flat structure - the opposite direction! - I doubt that Traits would be a big help in refactoring Morphic. And as I said, it may even lure into the wrong direction...
stéphane ducasse wrote:
but this is fun because this is already a long time ago that we discuss with andreas about traits in Tweak and he was really interested (even if the fact that the main root is quite large and it does not really make sense to create another one, traits could help to structure its role).
On 25 févr. 05, at 12:09, Martin Wirblat wrote:
Well, looking at Tweak and its more flat structure - the opposite direction! - I doubt that Traits would be a big help in refactoring Morphic. And as I said, it may even lure into the wrong direction...
If Tweak were built with Traits, that would be indeed a convincing argument.
Regards, Martin
On Fri, 25 Feb 2005 12:09:43 +0100, Martin Wirblat sql.mawi@t-link.de wrote:
that what the perfect rip out of context.
If it was that way, my apologies. I didn't understand it that way.
If Collections can be refactored so that the code is better understandable it is a plus for Traits (the minus would be the speed loss).
It's not an 'if'. It's a fact. I haven't read the original Traits paper for years, but I still remember my excitement about refactoring that beast. Not only will a huge hierarchy be refactored - you'll end up with gobs of reusable code. So, if you want to build a class that has 'Set-ness', you can simply grab the corresponding Trait instead of having to create a Set ivar and delegate all over the place. Set will be reduced of just a sample class that has 'Set-ness'.
Anyway, let's stop flogging this horse, I think we've done an adequate job of killing it. Let's declare concensus on the fact that yes, it looks promising (for some value of 'promising' that differs from skeptical interest to outright enthousiasm), but yes, we need to hold back our final judgement and decision until a new version descents from the Swiss Alps. And personally, I'm eagerly awaiting that version...
On Sat, 26 Feb 2005 10:01:15 +0100, Cees de Groot cg@cdegroot.com wrote:
It's not an 'if'. It's a fact. I haven't read the original Traits paper for years, but I still remember my excitement about refactoring that beast. Not only will a huge hierarchy be refactored - you'll end up with gobs of reusable code. So, if you want to build a class that has 'Set-ness', you can simply grab the corresponding Trait instead of having to create a Set ivar and delegate all over the place. Set will be reduced of just a sample class that has 'Set-ness'.
I don't know why people aren't more excited about that. It kicks ass. It's one of those things where you look at it and just immediately say to yourself, "Yeah. Why didn't we think of this sooner." (Kinda like objects themselves, though in some ways moreso, since traits are kind of like old style function libraries. You could almost see Traits as a concept predating objects, except that objects provide the support structure.)
OK, enough cheerleading, I guess. I just haven't seen anything this exciting in a while. (Maybe aspects, but while I get why aspects are exciting, I have yet to really grasp how they work.)
On Sat, 26 Feb 2005 02:00:14 -0800, Blake blake@kingdomrpg.com wrote:
OK, enough cheerleading, I guess. I just haven't seen anything this exciting in a while. (Maybe aspects, but while I get why aspects are exciting, I have yet to really grasp how they work.)
Well, funny - we've had Aspect/S for years. Does anyone use it? Or are aspects just exciting but less-than-practical for real use?
Cees de Groot wrote: .....
Anyway, let's stop flogging this horse, I think we've done an adequate job of killing it. Let's declare concensus on the fact that yes, it looks promising (for some value of 'promising' that differs from skeptical interest to outright enthousiasm), but yes, we need to hold back our final judgement and decision until a new version descents from the Swiss Alps.
Yes, fully agreed
On Saturday 26 February 2005 1:01 am, Cees de Groot wrote:
If Collections can be refactored so that the code is better understandable it is a plus for Traits (the minus would be the speed loss).
It's not an 'if'. It's a fact. I haven't read the original Traits paper for years, but I still remember my excitement about refactoring that beast. Not only will a huge hierarchy be refactored - you'll end up with gobs of reusable code. So, if you want to build a class that has 'Set-ness', you can simply grab the corresponding Trait instead of having to create a Set ivar and delegate all over the place. Set will be reduced of just a sample class that has 'Set-ness'.
I think that it may be instructive to look at other languages and the way they handle mixins.
Self was already mentioned in the Traits paper, and since Jecel is on the squeak-dev list, I'm not going to attempt to explain how Self does things or how well that works. (I've never used Self, though I did co-author a Perl module that unifies Perl's multiple-dictionary behavior lookup with a slot-based scheme like Self's. If you're interested, it's called 'Class::Prototyped'). Brian Rice can tell us how Slate does things, but I recall that it looks very similar to Self.
Ruby has a single-inheritance scheme much like Smalltalk's, but also adds 'modules' which work almost exactly like including a text file that can hold more behavioral definitions. Of course, since Ruby doesn't require you to pre-declare instance variables, this also lets you have mixins that add instance variables as necessary (though there is no attempt at dealing with or even detecting name conflicts). Modules actually are nicer than text inclusion, as they are first class objects and so support reflection (I forget whether they provide a separate namespace).
In practice, these work like Traits, but without the tool support for analyzing or browsing.
You can mix in a module in any class or module definition. You can also include a module in the definition of a 'singleton' -- objects with unique, anonymous classes (much like the way that Etoy player objects are constructed most of the time).
So, for instance, to make instances of a class able to be enumerable, you mix in the Enumerable module.
This requires you to define at least a method called 'each', which is then used as an iterator by the methods that Enumerable provides:
Enumerable.instance_methods ["select", "each_with_index", "grep", "map", "find_all", "sort_by", "collect", "detect", "max", "to_a", "sort", "partition", "any?", "include?", "reject", "zip", "find", "min", "member?", "entries", "inject", "all?"]
If you want to use, say, 'max', 'min', or 'sort' you'll also have to provide a definition for the comparison operator '<=>'. If you then mix in the Comparable module, you also get the operators that can be built using '<=>'.
Comparable.instance_methods ["between?", "==", ">=", "<", "<=", ">"]
On Sat, 26 Feb 2005 06:10:23 -0800, Ned Konz ned@squeakland.org wrote:
Ruby has a single-inheritance scheme much like Smalltalk's, but also adds 'modules' which work almost exactly like including a text file that can hold more behavioral definitions. Of course, since Ruby doesn't require you to pre-declare instance variables, this also lets you have mixins that add instance variables as necessary (though there is no attempt at dealing with or even detecting name conflicts). Modules actually are nicer than text inclusion, as they are first class objects and so support reflection (I forget whether they provide a separate namespace).
They do - in fact, the idomatic way to define a namespace in Ruby is to create a module, and you import that namespace by mixing the module in to wherever you want to use it. I would describe the mixin semantics as being more like a superclass insertion than like textual inclusion - and, in fact, I'm pretty sure that's how it's implemented. That is, if you have class C subclassed from class B, and you include module M, you end up with single-inheritance lookup along the chain C->M->B. If anyone wants to play with an implementation of these semantics, try my Mixins package on SqueakSource (I don't think it ever made it to SqueakMap).
Avi
On Thursday 24 February 2005 1:46 pm, Martin Wirblat wrote:
Furthermore this Collection hierarchy is already there! It is my assumption, that unless I program a similar hierarchical monster like Collections I don't gain much from Traits. I even fear that Traits may lure into programming hierarchical, where a flat structure combined with the normal composition would be the better way to go.
Actually, I think that the analysis that Traits does can help with converting an overly-inherited (whether by Traits mixins or by straight inheritance) structure into one that is more like a group of collaborating objects.
My reasoning is that the individual traits would be exactly the chunks of behavior that one could (and in many cases should) factor out into a separate object.
So in some sense, seeing the traits serves as a reminder that you have an object with multiple responsibilities, and that some of those responsibilities might be better expressed using another structure.
On 26 févr. 05, at 2:37, Ned Konz wrote:
On Thursday 24 February 2005 1:46 pm, Martin Wirblat wrote:
Furthermore this Collection hierarchy is already there! It is my assumption, that unless I program a similar hierarchical monster like Collections I don't gain much from Traits. I even fear that Traits may lure into programming hierarchical, where a flat structure combined with the normal composition would be the better way to go.
Actually, I think that the analysis that Traits does can help with converting an overly-inherited (whether by Traits mixins or by straight inheritance) structure into one that is more like a group of collaborating objects.
My reasoning is that the individual traits would be exactly the chunks of behavior that one could (and in many cases should) factor out into a separate object.
So in some sense, seeing the traits serves as a reminder that you have an object with multiple responsibilities, and that some of those responsibilities might be better expressed using another structure.
true this is one intention. Traits are interfaces with method definition so they are the basic bricks of building class out of higher abstractions than methods.
Stef
Ned Konz wrote:
On Thursday 24 February 2005 1:46 pm, Martin Wirblat wrote:
Furthermore this Collection hierarchy is already there! It is my assumption, that unless I program a similar hierarchical monster like Collections I don't gain much from Traits. I even fear that Traits may lure into programming hierarchical, where a flat structure combined with the normal composition would be the better way to go.
Actually, I think that the analysis that Traits does can help with converting an overly-inherited (whether by Traits mixins or by straight inheritance) structure into one that is more like a group of collaborating objects.
My reasoning is that the individual traits would be exactly the chunks of behavior that one could (and in many cases should) factor out into a separate object.
So in some sense, seeing the traits serves as a reminder that you have an object with multiple responsibilities, and that some of those responsibilities might be better expressed using another structure.
I assume that you mean this other structure is or could be built of ordinary Smalltalk and for such cases Traits is used only as a "thinking-help" in a two-tiered development process:
1) Do it with Traits 2) At many places, traits are indications that you have done something wrong. Do it differently (without using traits).
Interesting, but a bit indirect :) and as I said perhaps people are not aware of the second part. Thinking abstractly I am really unsure if this is an argument in favor of Traits, it looks like being able to use a trait may put you on the wrong trail.
Regards, Martin
On Saturday 26 February 2005 4:57 am, Martin Wirblat wrote:
I assume that you mean this other structure is or could be built of ordinary Smalltalk
Yes, though Traits *is* "ordinary Smalltalk". That is, it's more of a code-management and code-analysis scheme than anything else. If you look at the definition of a class that uses Traits in an ordinary browser, you can't tell that Traits is being used. You have the same method dictionary, instance variables, etc.
It's just that Traits lets you see and manage the behavioral requirements and related code responsibilities of your classes better.
But instead of copying methods from one class to another with related behavior, Traits lets you have a single copy of the source of the related methods. And it lets you talk about these groups of methods and their relationship to other such groups and classes.
and for such cases Traits is used only as a "thinking-help" in a two-tiered development process:
- Do it with Traits
- At many places, traits are indications that you have done something
wrong. Do it differently (without using traits).
Interesting, but a bit indirect :) and as I said perhaps people are not aware of the second part. Thinking abstractly I am really unsure if this is an argument in favor of Traits, it looks like being able to use a trait may put you on the wrong trail.
Perhaps. I do think that the Traits documentation focuses rather heavily on "re-engineering" or "refactoring" existing code. While this is certainly necessary and helpful, the Traits documentation could stand a better description of how it can be used to write new code and then maintain it.
There is nothing you could write in Traits that couldn't be written by copying methods between classes. It's just that it's much harder to maintain code written in that way. And the automatic analysis and grouping of methods into Traits is a powerful adjunct to (or replacement of) method categories.
Perhaps. I do think that the Traits documentation focuses rather heavily on "re-engineering" or "refactoring" existing code. While this is certainly necessary and helpful, the Traits documentation could stand a better description of how it can be used to write new code and then maintain it.
There is the methology paper ICSE 2004. And the one of ESUG (but we are fed up about writing papers on traits :) since this is not research anymore for us.
There is nothing you could write in Traits that couldn't be written by copying methods between classes. It's just that it's much harder to maintain code written in that way. And the automatic analysis and grouping of methods into Traits is a powerful adjunct to (or replacement of) method categories.
Exact. Compared with mixin, traits offers an explicit conflict resolution, where the composing entity (the class or a trait) has the total control. and this is basically the main difference with mixins and which makes traits more robust to changes.
I assume that you mean this other structure is or could be built of ordinary Smalltalk and for such cases Traits is used only as a "thinking-help" in a two-tiered development process:
no traits are structuring entity there are between class and methods. They are a building block. Because classes as instance creator should be concrete and complete they offer a too big abstraction, hence make reuse difficult. And traits plays this role. They represent intermediate abstractions from which class can be build and support the reuse because can be reused among different classes.
- Do it with Traits
- At many places, traits are indications that you have done something
wrong. Do it differently (without using traits).
I do not believe in the second point. Again this is pure theory: show us a concrete example. If you have to reuse an abstraction over different hierarchies then normally you wrap and delegate or copy and paste, with traits you reuse.
I really do not see why reusing an abstraction would mean that you are doing something wrong.
Interesting, but a bit indirect :) and as I said perhaps people are not aware of the second part. Thinking abstractly I am really unsure if this is an argument in favor of Traits, it looks like being able to use a trait may put you on the wrong trail.
Regards, Martin
sure there is mailing-list on traits since some years already, this is a public mailing-list. traits@iam.unibe.ch so we never said that people should accept traits without saying anything or contributing. We would be more than happy to have people giving feedback. We said that long long time ago.
On 24 févr. 05, at 10:49, goran.krampe@bluefish.se wrote:
- Then we... hey, why not simply make a Team that investigates it? Look
it over, check the code, try it out, see what newbies and oldtimes stumble on, perhaps refine and document based on that, etc. This work ought to be useful in any case.
On Wed, 23 Feb 2005 17:26:41 +0100, stéphane ducasse ducasse@iam.unibe.ch wrote:
- I proposed a precise roadmap (now what can I say more than that)
Well, you could add pointers. How much trouble must I go through, hunting through Google and the squeak-dev archives, to find a bit of text you surely know where to find? I found your original "roadmap for 3.9" mail after a couple of minutes, but that pointed to another mail for the SystemDictionary refactoring. I found some threads on that, but not a final draft.
So could you please repost or point to the final proposal for this so we know what we're talking about and people can compare with with what's there so far in the image?
Thanks,
Cees
this is in the first email of this thread.
On Wed, 23 Feb 2005 17:26:41 +0100, stéphane ducasse ducasse@iam.unibe.ch wrote:
- I proposed a precise roadmap (now what can I say more than that)
Well, you could add pointers. How much trouble must I go through, hunting through Google and the squeak-dev archives, to find a bit of text you surely know where to find? I found your original "roadmap for 3.9" mail after a couple of minutes, but that pointed to another mail for the SystemDictionary refactoring. I found some threads on that, but not a final draft.
So could you please repost or point to the final proposal for this so we know what we're talking about and people can compare with with what's there so far in the image?
Thanks,
Cees
On Wed, 23 Feb 2005 21:46:14 +0100, stéphane ducasse ducasse@iam.unibe.ch wrote:
this is in the first email of this thread.
Thanks - I missed the fact that Goran added that mail of yours as well. Another reason to dislike anything that needs a scrollbar to show up, be it an email or a Smalltalk method body ;).
Well, it's probably simpler and better backwards-compatible than what's there now. It'll piss off users who have switched to SmalltalkImage, etcetera, but so be it. I'm one of them, and I'm quite happy to convert if the core gets better.
Still... it does leave this mess in Smalltalk. Oh well, maybe for later. It doesn't hurt a lot, and we can start TFNR/PI'ing away at it and see what comes out of that without breaking anyone's code.
I'd say do it ;)
Stéphane,
you obviously have some overly strong interest to push Traits into Squeak. The moment someone only dares to start a discussion about it, which btw had been requested by you, you are instantaneously going wild - in a really nasty manner. Have you ever thought what damage you do to collaboration and communication with this mixture of silly blackmailing that you will leave and then always coming back making even more noise?
Your behavior in the last few month' showed clearly that you want to shortcut a discussion about Traits at all. This doesn't look as if you think Traits has it in itself to make it into the Squeak Smalltalk language by means of its own qualities.
Remember, this is a language extension. To expect that people will accept it by just shortly playing around with it, or even without any discussion about it, is a bit ridiculous.
What is wrong with the idea that the Berne group puts up a special edition of the standard Squeak image release? People could study in depth new ideas without time constraints and if it turns out that something like Traits has its general merits they will request inclusion into standard Squeak without being pressured to do so. If they are not requesting such an inclusion, the "recurring fork Berne edition" has its value on its own. Everyone who wishes so can use it.
Think about it!
Regards, Martin
stéphane ducasse wrote:
Hi all
Sorry I will not argue again. I do not have the energy. Bye. you WON!
The essential answer to this has already been posted by Andreas:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-December/ 085923.html
Especially problematic are the "researchers" items:
- new compiler framework
- refactoring of SystemDictionary
- Traits
These three items are not about research
- is needed but may be people do not care that we get UI dependency in
parser.
I proposed a precise roadmap (now what can I say more than that)
it is fun that alan kay mentioned Traits in his turing award talk
and that other languages such as Slate, perl, Scala and getting traits and we will not.
Sorry guys, I'm fed up. So I give up. Do what you want. And martin you can have exigence but in that case you should have the money...
Good luck boys
Stef
Here is what I think about these:
- I don't want to comment much on the compiler framework, except
that I think that it is critical to get this done properly, if it goes in.
- The ongoing attempt of refactoring SystemDictionary seems to be an
odyssey without much planning so far. This is not the right way to do a "refactoring" of a kernel part.
- Traits is a questionable language extension. It is questionable
because language extensions to Smalltalk themselves are questionable.
Here are Squeak's current problems ordered by importance:
- library
- speed
- documentation
- community organization
- public relations and awareness
- language
I am not going to bet on the exact order of 2 to 5 but I think it is clear that "library" is THE problem. Far behind at the end comes "language", simply because Smalltalk is still one of the best, if not the best programming language.
Smalltalk has a remarkable cost-performance ratio. Every addition to the language may worsen this ratio. Yet half of all people tend to ask the question:
- What benefit has the language extension/change?
But this is the wrong question. With this kind of judgement Squeak's way is paved to a concept-overloaded monster like Java.
Instead we should ask:
- What real problem does the language extension/change solve?
A real problem is of course not meant to be the absence of a benefit in a specific situation, the type of advantage the first question is about.
A real problem of a language is one that is ubiquitous when programming in that language, something which occurs literally every line, which really goes straight to the heart of its basic mechanism.
I think it will be really difficult to uncover and to distill such a core problem in Smalltalk and it is my conviction that Traits is not solving such a main problem.
As a consequence I think we should not include Traits into the official release. Instead I guess some people would like to see a specific "researchers edition" of Squeak from the Berne group.
This could be a fork in the sense of Avi's suggestion of having "recurring forks" - tall narrow trees with stubby branches coming off it at every level:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-December/ 086612.html
regards, Martin
Stéphane,
you obviously have some overly strong interest to push Traits into Squeak. The moment someone only dares to start a discussion about it, which btw had been requested by you, you are instantaneously going wild - in a really nasty manner. Have you ever thought what damage you do to collaboration and communication with this mixture of silly blackmailing that you will leave and then always coming back making even more noise? Your behavior in the last few month' showed clearly that you want to shortcut a discussion about Traits at all.
Really? Are you joking? Everything we did is public, we asked for feedback. There is even a mailing-list since years traits@iam.unibe.ch and it is public.
This doesn't look as if you think Traits has it in itself to make it into the Squeak Smalltalk language by means of its own qualities.
huh? What are you talking about? Read nathanael post, please.......
Remember, this is a language extension. To expect that people will accept it by just shortly playing around with it, or even without any discussion about it, is a bit ridiculous.
I guess that you did not read nor opened the image nathanael did when he refactored the complete collection and stream hierarchies Sure this apparently does not count. And Adrian master is to bootstrap the squeak kernel with traits. So I think that you are biased because again everything we did is public.
What is wrong with the idea that the Berne group puts up a special edition of the standard Squeak image release? People could study in depth new ideas without time constraints and if it turns out that something like Traits has its general merits they will request inclusion into standard Squeak without being pressured to do so. If they are not requesting such an inclusion, the "recurring fork Berne edition" has its value on its own. Everyone who wishes so can use it.
Think about it!
As if we would not have thought about it! What do you think? When people react like you, don't think that this would be the easiest path. But do you think that the system you are using is better (may be you cannot judge it) for example all the systemNotification is the foundation to build really powerful tools in the future. But may be this does not count for you. Cleaning the kernel would not have been 10 times faster by simply forking! But for what result? Yes we would be proud or even do not care of our system. We are doing that because we think that squeak could be a really cool language for the next 10 years. But this requires energy and commitment and we showed that in the past. But I ALREADY said that long time ago. I should copy and paste email.
You see I think that a lot of improvements are coming from our team. We spent a lot of time to improve squeak and this is not the case of everybody which can be ok too because not everybody has the time or skills. But at least do not treat us as "researcher" because this word looks strange when you type it.
Instead of having wishes have you downloaded and look at the new compiler for example? Did you give feedback to marcus or to nathanael. Or any other stuff that is not related to your personal goals. Because I and marcus harvested code for stuff I DO NOT CARE AT ALL. Marcus spent a **lot** of time on resurrecting the compiler work of anthony (and everybody will benefit from that) then what have you been doing on your side. And you see now marcus does not even care, which is like a little death inside to my opinion.
You see we did classboxes. Did I say that this should be the package mechanism for Squeak. No! Have you thought why? It is not bad you see we wrote cool research papers and classboxes are cool. Because we are not sure that this is good for Squeak and we do not want to spent the engineering time to make it happen. So now if you think that we are doing the stuff around traits for our egos, you are totally wrong. But you are free to believe it.
Stef
So back work...
Martin Wirblat sql.mawi@t-link.de wrote:
Here are Squeak's current problems ordered by importance:
- library
- speed
- documentation
- community organization
- public relations and awareness
- language
Hmm, let me try. My list would be something like:
1. Stability, including stable sets of packages. 2. Dicing up the shared image into packages. 3. Documentation. 4. Better interfaces to the platform, especially to windowing systems 5. Beefing up the libraries in various ways. 6. Language, namespaces, ... 6. Public relations.
I'd call community organization a means to these other ends, so I didn't explicitly put it on the list. Anyway, we should have just enough organization to make this list get better, and no more. To paraphrase Trygve's suggestion, let's have just enough organization that we can maximize our anarchy. :)
I don't know where to put PR in. It is of only moderate importance to me, but it is important, so I stuck it at the end.
I agree that documentation is important, with the big footnote that this means documentation in a general sense, including things like class comments.
I don't see speed as an issue for us. Why do you put it at the #2 slot? We aren't going to win over users who need a *really* fast program-execution system. On the other hand, I worry that if we think about speed too much, we might mess up some of the things that are great.
And honestly, everything after 2 doesn't seem like a terribly big deal to me. 1-2 seem absolutely critical, if we are to all continue working together.
-Lex
"Lex Spoon" lex@cc.gatech.edu wrote:
Martin Wirblat sql.mawi@t-link.de wrote:
Here are Squeak's current problems ordered by importance:
- library
- speed
I don't see speed as an issue for us. Why do you put it at the #2 slot? We aren't going to win over users who need a *really* fast program-execution system. On the other hand, I worry that if we think about speed too much, we might mess up some of the things that are great.
Well, I see speed as an issue because on a regular seeming basis somebody or other manages to put something in the image that cripples interactive performance. Basic compute speed is really pretty impressive - even on a very slow machine like my 600MHz ARM box - but the UI varies from ok to unusable depending on update level.
OK, so I can hear people telling me to get a real machine (I actually have several, including a dual cpu 1GHz pMac and a 1.5GHz pBook) but honestly, a machine that can hit 29 Dorado on the GreenBook benchmarks really shouldn't have problems making a menu select at decent speed nor a text view type as fast as my ancient arthritic fingers can hit keys. The venerable ActiveBook managed all of 27% Dorado and could do better. Yes, monochrome and yes, no window system to get in the way, but still.
Besides, there are lots of potential Squeak machines with the same cpu and memory system that I have, plus the burden of winCE; think of all those 2/4/600 MHz PDAs out there, yearning for decent software. And don't forget the LinkSys/ASUS NAS boxlets in need of software. We can do better.
And besides (again) with graphics/UI performance improved sensibly we could write Doom in Squeak.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Computers talk to each other worse than their designers do.
tim
with traits there is no performance penalty. Traits are method dictionary and at composition time, the class methodDict gets the methods pointing to the traits methodDict compiledmethod and we use pain normal method lookup. So from an execution point of view traits are flatten at composition time in the classes so NO PENALTY (except that you should use accessors for iv access). For the browser feedback (which is far the most advanced for feedback than normal browser) nathanael designer a good cache algorithm that support incremental addition of method in classes.
Stef
On 24 févr. 05, at 7:01, Tim Rowledge wrote:
"Lex Spoon" lex@cc.gatech.edu wrote:
Martin Wirblat sql.mawi@t-link.de wrote:
Here are Squeak's current problems ordered by importance:
- library
- speed
I don't see speed as an issue for us. Why do you put it at the #2 slot? We aren't going to win over users who need a *really* fast program-execution system. On the other hand, I worry that if we think about speed too much, we might mess up some of the things that are great.
Well, I see speed as an issue because on a regular seeming basis somebody or other manages to put something in the image that cripples interactive performance. Basic compute speed is really pretty impressive - even on a very slow machine like my 600MHz ARM box - but the UI varies from ok to unusable depending on update level.
OK, so I can hear people telling me to get a real machine (I actually have several, including a dual cpu 1GHz pMac and a 1.5GHz pBook) but honestly, a machine that can hit 29 Dorado on the GreenBook benchmarks really shouldn't have problems making a menu select at decent speed nor a text view type as fast as my ancient arthritic fingers can hit keys. The venerable ActiveBook managed all of 27% Dorado and could do better. Yes, monochrome and yes, no window system to get in the way, but still.
Besides, there are lots of potential Squeak machines with the same cpu and memory system that I have, plus the burden of winCE; think of all those 2/4/600 MHz PDAs out there, yearning for decent software. And don't forget the LinkSys/ASUS NAS boxlets in need of software. We can do better.
And besides (again) with graphics/UI performance improved sensibly we could write Doom in Squeak.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Computers talk to each other worse than their designers do.
On Thu, 24 Feb 2005 09:21:52 +0100, stéphane ducasse ducasse@iam.unibe.ch wrote:
with traits there is no performance penalty.
Heh. I don't think Tim was meaning that.
It is bad that Morphic has visible delays.
I recall calculating for my first computer (TRS-80 Model I) how much load it had by making every CPU cycle a second to bring the thing up to human scale (I envisioned a little guy in the machine who could do something every second).
So, in 1 second 1 million cycles (was it a 1MHz Z80? Don't recall), to a human scale that's 1 million seconds to do something - 12 days, correct? A typist with 120 keys per minute, 2 per second, would fire off an astonishing 1 keystroke every 6 days to the little guy. In this time, the little guy had to interpret the keystroke, move it to memory, the screen buffer, and maybe move some bits around to make some space.
Needless to say, the TRS-80 word processor had no trouble at all keeping up with my typing.
So when some 2.5 decades later I have a machine that is THREETHOUSAND TWOHUNDRED times as fast, and I see visible delays and sluggishness in simple user interface elements, something is horribly, terribly wrong.
I do hope, btw, that as a side effect of the Morphic split, we will be able to get back some performance. Original Morphic must have been faster than what's there now, not?
Hi Cees--
Original Morphic must have been faster than what's there now, not?
The comparison I like to make is with Morphic in 3.2. Its performance seemed to peak there.
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
Cees de Groot cg@cdegroot.com wrote:
Date: Thu, 24 Feb 2005 12:25:15 +0100 From: Cees de Groot cg@cdegroot.com Subject: Re: Stefs roadmap for 3.9, time to get it nailed down To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org reply-to: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org
On Thu, 24 Feb 2005 09:21:52 +0100, stphane ducasse ducasse@iam.unibe.ch wrote:
with traits there is no performance penalty.
Heh. I don't think Tim was meaning that.
It is bad that Morphic has visible delays.
AGREED. That performance problem is a real pity. Squeak+Morphic should be kicking butt for PDA applications, but it is hampered by needing several megabytes of memory and a gigaherz of CPU. Squeak could be blowing Perl away, but the startup time just to read() the image file is a killer.
I do hope, btw, that as a side effect of the Morphic split, we will be able to get back some performance. Original Morphic must have been faster than what's there now, not?
Yes, just load an earlier Squeak. I am amazed every time I try it. I can't imagine what is going wrong in newer Squeak's....
-Lex
I do hope, btw, that as a side effect of the Morphic split, we will be able to get back some performance. Original Morphic must have been faster than what's there now, not?
Yes, just load an earlier Squeak. I am amazed every time I try it. I can't imagine what is going wrong in newer Squeak's....
This always happens when you open the door to... improvements ;-).
It isn't anyone's fault, it's just that poor performance doesn't show up as a failed unit test.
In the old days, there were a couple of us who would periodically figure out where UI time was going and do our best to tune things up prior to major releases.
It's looking like a lot of the work for Minimal Morphic is well understood (I know, there's still plenty to do) so I, for one, hereby pledge to spend a bit of time on performance. I think a lot of the others want this too. The more minimal it is, the harder it will be for performance bugs to hide.
One of the sad things is that Morphic gives you much better screen fidelity than MVC (things like windows and background display while growing), but people turn it off for speed. I think by now, we ought to be able to have both fidelity *and* speed.
- Dan
Hi all!
(sorry, this one is also long - but Stefs damn roadmap was long so... :))
Hehe, the silence is thundering. Well, to get things started here are some proposals about 3.9:
- We set the release date to late june. That would at least fit Squeakland I have been told by Michael Rueger, for their summer release in july. Don't know what other stakeholders think, and we could check that. This would give us... 3.5 months?
- We start using release Teams. 3.8 used this (Michael Rueger and gang), and I think it is a very good thing. A Team focused on the release itself, and then after release, it is ended. This is typically about update stream management, decisions, goals, freezing etc. You know - release management! :) And of course help everything along and follow up.
- With 3.9 we should start distributing Minimal as well as Basic and Full. Otherwise we will have trouble adding "nice" packages to Basic, because some people inevitably will not want them. See for example Shout or eCompletion below. Either that, or we have to make packages uninstallable. But I think it is good if we start to materialize Minimal - the current approach of letting Basic be the target of the update stream, and not distributing Minimal is confusing to say the least. Even confusing to us who actually should know how this stuff fits together. ;)
- ToolBuilder, as we said, we really think that ToolBuilder should be in 3.9 - Minimal or Basic (?). No Team leader assigned to make this real yet, but Avi Bryant and Brian Brown have been asked at least, but Avi is in Venice right now. :)
...and here are my *PERSONAL* shoot-from-the-hip thoughts about the stuff in "Stefs roadmap" (if not else my outrageous thoughts might get *someone* to react at least):
We plan to do the following: we will focus on building 3.9 and take our time and your feedback to do it. We think that april/mai would be a good release date so that we have the time to test and work in pace.
Good, then late june is ok too I guess. :)
Note that the list after is not fixed since we do not want to push something that will not be ready. For example, we will pay an extreme attention that the traits are fully integrated.
Does that mean "as a package" (Traits)? Or is it too invasive to have as a package? I like Traits but we need to make it clear what it will mean.
Or in other words - you guys need to explain to us how utterly wonderful, backwards compatible and non-disturbing Traits is so that *everyone* ought to want to embrace it. :)
If it can still be a separate addon package - then the story is of course much different.
Nathanael is planning to help and also would like to for example make sure that he can refactor the collection hierarchy before releasing traits.
We are LOOKING for a lead harvester, and ETOY harvester and a Multimedia one.
Yeah, these things are still open more or less. Now perhaps today we are talking about Teams, but it is essentially the same thing - someone willing.
3.9 Full
- new multimedia app (Ogg reader?)
- YAXO (p) a real one on SqueakSource :) (yes this is a subliminal
message :))
- Wonderland back in shape (you see mark there are room) / 3DBalloon
- and anything that is valuable for full
- GENIE (yes ned we want that)
- Connectors (yes yes we want that too)
-> ned would it be possible to get access to one your recent Genie image?
- but people will have to provide package in MC format (or at least a
good sar)
Just so all know - Wonderland (Balloon3D) is today an orphaned package: http://map1.squeakfoundation.org/sm/packagebyname/balloon3d
Connectors is very cool, might be a good thing to have in Full. The rest I know little about and don't have an opinion on. Well, YAXO seems like an odd package to suggest for Full - reason?
3.9 Basic (the stuff for the developer: not the mini image! )
- Diego look
Already in AFAIK. But needs some work.
- eCompletion or another package (p)
Yes, think so. As described in the beginning of my post - if people don't like it, they can use Minimal and then install only what they want.
- keybinding cool package (may this one should go in basic as package
(p) because the current way of binding key is system wide and not really good)
Dunno. Is it a good thing? :)
- shout (p)
Shout is wonderful. Some people may have a problem with it being slow - but it sure is a huge step forward for us developers. Same thing here - including Shout in Basic implies that we need to distribute Minimal, or else Tim and other users with dog slow machines will get royally annoyed. :)
Either that or make sure Shout screams (couldn't help the pun).
- SqueakMap II (yes we want it)
Yup, a new release - with whatever that means. Dependencies for sure.
- rbengine (p) this is absolutely not intrusive (ok there are some
duplicated functionality but we need it and if a brave soul wants to optimize it will be really possible for now we should not be that warry since the package is self-contained and we are not enough, so we should be productive and then after one guy will fix that if necessary). So simply a package that can be removed but that is needed to code.
Ok... did not follow exactly, RB is not my alley - but this is the ballpark of the Berne Guys - so I trust their judgement.
- services
- new preferences pane
Both those sound fine.
- traits
Ah. This one is more controversial. AFAIK the community hasn't "decided" on Traits.
I personally think, without having seen the latest incarnation, it is a neat technique. But if this is not a package (that you can then avoid using) then we need much more info on what it means before we can decide. And Martin Wirblat's view is in many regards shared by me - even though I want to hear more first. I personally do not belong to the Keep-Squeak-Being-Smalltalk-80-Forever-Faction (not implying Martin does either). :)
Can we get a presentation on the exact effects and predicted benefits/problems solved on introducing Traits?
- new compiler framework (note that according to Scott this should not
have an impact on etoy) But again we need a Etoy expert to help.
Need more info then. But if Scott is right, then go go. :)
- refactoring of systemDictionary as proposed to get it done once
right. Again read again what we wrote and comment. (I think that having SmallltalkImage and SystemDictionary does not make sense to have both)
Ok - this is the stuff described better below.
- OB (p?) + browseUnit new version (integrated version). The idea of
having OB here is that we want to enable the creation of new tools and deprecate slowly the use of the old browser (which could be packaged but keep alive in case we only want to have one single but gigantic class).
This is good stuff. OB is a great thing, and yes, remolding the old stuff so that it can be easily thrown out (he, that sounded easy, right?!) would also be nice. Would like to hear Colin about it.
- MC in the base image (we all would like to have a mini image and a
cool script but for now not having MC in the base image is getting in our way to maintain packages and to also produce a much smaller mini-image, to also learn what we cannot do with MC and ask kindly to MC developers if they can fix the problems we see). Except if of course someone come up with a better idea and code to support that. We would like to avoid to abandon the idea of having packages in basic since we would like to push further the packages curving process.
I agree with having Monticello in Basic - as long as we start distributing Minimal. Not sure if I am missing some logic there, but I think that is what I think. :)
- We would like also to have a much better support for packages:
Package as real entities with support for - resources - meta information - comments - substituing package info (alex is willing to work on that).
There was recently code posted by Alexandre and I want the new proposed "Packages" Team to look at it the Very First Thing we do. Haven't had time to look yet.
We also like the idea of TestServer, so feel free to write tests! May be markus G could be the guy responsible to push them into the stream. Markus? Romain?
Doesn't sound like something we need to decide for 3.9 (test server), I like the idea too.
Note that for the packages marked as (p) of course we will ask if the package creator is willing to help and feel the pression of having his cool package in Basic. One requirement could be that the code is managed with MC and SqueakSource so that in case of emergency we can get our hands on it :)
Yes. Agree.
We ask for feedback, help, testing, ideas....
And now finally you got some feedback. :) And then from the second posting I think this was the only thing not mentioned yet:
- new compiler framework of anthony adapted by marcus to produce
not full block. Note that for Etoy the old compiler will still be in the image so from that point of view it should not have an impact.
Ok, fine.
And then about SystemDictionary:
In the past we created SmalltalkImage out of SystemDictionary in the hope to have SystemDictionary be a nice and simple namespace class. Lot of stuff has been put in coherent places (SystemNavigation, SpaceTally, Changeset....) But this will not work since people get used to add stuff there and Smalltalk is a cool name. So the new proposal is the following one and is partly implemented. Note however that it will require from us a lot of work so if you are against it please say it and we will only do it for us.
from a user point of view we want to have: only one class: SmalltalkImage/SystDict for all the image related services (VM pluggins, ....) but the namespace behavior will be delegated to Namespace.
All the previous code referencing Smalltalk will work but withdeprecation for the namespace interface.
Ok, so the idea is to let "Smalltalk" be the kitchen-sink but move the actual dictionary part of it to "Namespace", correct?
From the language programmer point of view: there will be a namespace that can be used for experimentation this class will replace the environment class of dan that is now obsolete
We plan to proceed that way:
- create a class namespace with a new interface (done)
- delegate from systemDictionary to this new class (done but not
published)
Which makes it still backwards compatible I guess.
- deprecate all the namespace method of systemDictionary (but we
likely want to keep them for some time)
- fix all the in image senders of Smalltalk as a namespace to use the
new class (using self environment for example). (partly done over the previous years)
- merge back SmalltalkImage into SystemDictionary: the idea here is to
not have SystemDict as a subclass of Dictionary
Ok, so no more SmalltalkImage? And what about SystemNavigation? We keep that as is?
- have Smalltalk pointing to an instance of this new entity, so that
everybody is happy.
Ok, I *think* I like this, unless someone can show arguments to the contrary. Just as long as we follow through on it.
Stef and Marcus
regards, Göran
PS. We can of course chop this up in multiple threads when discussing. We will try to distill the discussion into some kind of table as we go. Or better yet, the release Team for 3.9 should take that ball - now... who is ready to take on being release Master for 3.9?!
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
Bert Freudenberg -
Blake -
Cees de Groot -
Craig Latta -
Dan Ingalls -
David P Harris -
David Shaffer -
goran.krampe＠bluefish.se -
Lex Spoon -
Martin Wirblat -
Nathanael Schärli -
Ned Konz -
Steven Swerling -
stéphane ducasse -
Tim Rowledge -
Yoshiki Ohshima