hi all
I'm surprised not to see development discussion on this mailing-list except craig reports. Do you use another way of communicating?
Then how do you share code and enh do you have a repository?
Stef
Hi Stef--
I'm surprised not to see development discussion on this mailing-list except craig reports. Do you use another way of communicating?
We communicate by direct email, telephone, IM, and the Squeak IRC channel, whichever is most convenient and effective at the moment.
Then how do you share code and enh do you have a repository?
That's one of the things we're building. :) At the moment, I use entire object memories. So far I haven't made my personal object memory available with every snapshot, because it has things in it for other projects, and I'd prefer not to share them with the world yet. This is annoying, of course, and one of the strong motivations I have for making Smalltalk modular. (I am thinking of just making my snapshots available all the time anyway, though.)
Also, we're working on fairly distinct (and large) tasks. Brenda Larcom is working on a version of Flow (Spoon's initial networking framework) which is backward-compatible with earlier versions of Squeak. Matt Hamrick is designing security measures for Spoon. John Dougan is interested in making the virtual machine smaller. Simon Michael, Byron Ellis, Duncan Mak, and Ken Causey have helped test the object memory releases (this is how we found problems with CPU usage in 1a12, for example).
(If any of the above people are no longer working on those tasks, or have more to add, please do chime in. The above is my current understanding.)
Anyway, so far the active tasks have been very large, with relatively infrequent releases. I know this goes against the grain of a typical open-source project, but it's also part of the nature of a large bootstrapping effort.
I encourage anyone who is interested in participating to ask "what can I do?" rather than wait for a lot of talk. We're spending our effort making progress, so that we'll have something meaningful to say when we do talk. :)
The most helpful thing a newcomer to Spoon can do right now is download the most recent release[1], play with it, ask questions about how it works, and suggest improvements in the design (here on the mailing list :).
thanks,
-C
[1] http://ftp.squeak.org/Spoon/spoon1a12.zip
On 9 août 06, at 23:51, Craig Latta wrote:
Hi Stef--
I'm surprised not to see development discussion on this mailing-list except craig reports. Do you use another way of communicating?
We communicate by direct email, telephone, IM, and the Squeak IRC channel, whichever is most convenient and effective at the moment.
Ok so this means that nobody beside you guys can follow. So clearly this is not really an invitation to others. But this is your right. But I cannot learn anything from your discussions. too bad and I cannot judge if I want to invest time.
Then how do you share code and enh do you have a repository?
That's one of the things we're building. :) At the moment, I use entire object memories. So far I haven't made my personal object memory available with every snapshot, because it has things in it for other projects, and I'd prefer not to share them with the world yet. This is annoying, of course, and one of the strong motivations I have for making Smalltalk modular. (I am thinking of just making my snapshots available all the time anyway, though.)
Also, we're working on fairly distinct (and large) tasks. Brenda Larcom is working on a version of Flow (Spoon's initial networking framework) which is backward-compatible with earlier versions of Squeak.
Do you mean that you can load that it is not compatible with latest version?
Matt Hamrick is designing security measures for Spoon. John Dougan is interested in making the virtual machine smaller.
Sounds cool. Do you imply cleaner version?
Simon Michael, Byron Ellis, Duncan Mak, and Ken Causey have helped test the object memory releases (this is how we found problems with CPU usage in 1a12, for example).
I was thinking that it would be good that from time to time you have a look at what we did in 3.9 and before: for example (the unsuccessful cleaning of Smalltalk) because we could then discuss what would be the solutions. But also pragmas and others, new compiler...... I have some doubts that people will want to redo that on top of spoon.
(If any of the above people are no longer working on those tasks, or have more to add, please do chime in. The above is my current understanding.)
Anyway, so far the active tasks have been very large, with relatively infrequent releases. I know this goes against the grain of a typical open-source project, but it's also part of the nature of a large bootstrapping effort.
This basically does not show activity nor transparency so you lose and lurkers too.
I encourage anyone who is interested in participating to ask "what can I do?" rather than wait for a lot of talk. We're spending our effort making progress, so that we'll have something meaningful to say when we do talk. :)
Your implications is idiot but this is your problem not mine. I think that forums are the best way to convince other people to participate. Now if I would not care about spoon I would have just look at the mailing-list and thought that it was a single project where one guy is working and that we do not know where he is going or if we adhere to the goals and resulting designs. But sure I'm talking so I stop.
The most helpful thing a newcomer to Spoon can do right now is download the most recent release[1], play with it, ask questions about how it works, and suggest improvements in the design (here on the mailing list :).
We were discussing with marcus about your idea of removing names from classes and our intuition is that class have a name. the fact that the implementation may not require a name is a different issue. what is sad is that I did not see discussions around these ideas. But again I'm talking.
Stef
I'm surprised not to see development discussion on this mailing-list except craig reports. Do you use another way of communicating?
We communicate by direct email, telephone, IM, and the Squeak IRC channel, whichever is most convenient and effective at the moment.
Ok so this means that nobody beside you guys can follow. So clearly this is not really an invitation to others.
Stef, I must disagree strongly. In the very message to which you just replied, I spelled out very explicitly how people can help. They can download the most recent release[1] and ask questions. They can ask, here in this forum, what they can do to help (e.g., make the VM smaller).
It does take actually interacting with other people to participate in this project right now, rather than just perusing artifacts, that is true. But that hardly means that additional people cannot participate.
Perhaps when we have gotten further with collaboration tools for Spoon, the development style will become more to your liking.
But this is your right. But I cannot learn anything from your discussions.
Stef, I have encouraged all participants to use the Spoon mailing list whenever possible for discussion. Please keep two things in mind about this: I cannot make people do anything, and at times there are more effective means of communication than a mailing list. I will do my best to forward things from other forums.
And you can learn from previous discussions that weren't recapitulated here: you can ask any of us about them!
too bad and I cannot judge if I want to invest time.
What exactly do you need to know in order to make that decision? I'm right here, Stef, I can answer any question you have about this project. Surely the information you desire is attainable. I suggest you come by the Squeak IRC channel so we can discuss this in a live, public, logged forum for all to see. I'm there on weekdays from 1700 to 0200 GMT.
Also, we're working on fairly distinct (and large) tasks. Brenda Larcom is working on a version of Flow (Spoon's initial networking framework) which is backward-compatible with earlier versions of Squeak.
Do you mean that you can load that it is not compatible with latest version?
Brenda is making a version of Flow that is compatible with Squeak 3.2, 3.6, 3.7, 3.8 and 3.9. Please see Brenda's progress report[2].
John Dougan is interested in making the virtual machine smaller.
Sounds cool. Do you imply cleaner version?
By smaller, I mean minimal, just as I am making a minimal version of the object memory. This will undoubtedly be cleaner.
Anyway, so far the active tasks have been very large, with relatively infrequent releases. I know this goes against the grain of a typical open-source project, but it's also part of the nature of a large bootstrapping effort.
This basically does not show activity nor transparency so you lose and lurkers too.
Activity is shown by progress reports to the Spoon mailing list. They aren't as frequent as you would like, but they are there (and they aren't as noisy as, for example, the Squeak list). Some people do realize that there isn't a direct correspondence between voluminous conversation and meaningful activity.
This project is in a stage where participants must be more proactive, and the work is relatively hard. It will not always be this way.
Your implications is idiot but this is your problem not mine.
Stef, you are now being rude. Please keep those sorts of comments to yourself.
Now if I would not care about spoon I would have just look at the mailing-list and thought that it was a single project where one guy is working and that we do not know where he is going or if we adhere to the goals and resulting designs.
In my progress reports, I have stated very clearly where I am going and what my goals are, and discussed many design details.
But sure I'm talking so I stop.
I did not say that all talking is bad, or even that your talking is bad. I said sometimes, for each person, working is more important than talking, so that the talking can be more meaningful.
We were discussing with marcus about your idea of removing names from classes and our intuition is that class have a name.
Note that, in the Spoon implementation, classes still have names. I never said or did anything about "removing names from classes". What's new is how those names are used (or more precisely, how they are used less).
the fact that the implementation may not require a name is a different issue. what is sad is that I did not see discussions around these ideas.
So why didn't you have that discussion here on the Spoon mailing list? :) I encourage you to do so! I invited discussion about this and many other aspects of Spoon on both the Spoon and squeak-dev mailing lists.
But again I'm talking.
Stef, you are being sarcastic. It serves no constructive purpose. Talking is what mailing lists are for, and you know it. Please feel free.
thanks again,
-C
[1] http://ftp.squeak.org/Spoon/spoon1a12.zip
[2]
http://lists.squeakfoundation.org/pipermail/spoon/2006-August/000134.html
post any conservation that you have in the mailing-list else it really gives the impression that you are alone.
My point was not to be sarcastic just shaking the tree to see what is fallen. and to see how to create synergy around spoon. and the first level is creating transparency and visibility.
Note that, in the Spoon implementation, classes still havenames. I never said or did anything about "removing names from classes". What's new is how those names are used (or more precisely, how they are used less).
Ok
the fact that the implementation may not require a name is a different issue. what is sad is that I did not see discussions around these ideas.
So why didn't you have that discussion here on the Spoon mailinglist? :) I encourage you to do so! I invited discussion about this and many other aspects of Spoon on both the Spoon and squeak-dev mailing lists.
Ok here is my suggestion then. - you should have a look at the changes done in the versions until 3.9 since else this will be really difficult to migrate on top of spoon (which I would love) - I cannot really believe in the "people will rewrite what they need" so reusing is important for me. And I would like to avoid to get Spoon been a exotic project. - I will take Spoon kernel as an important help for analyzing the categories and seeing how the packages of 3.9 articulate around them. - Still I have some doubts that working on 3.2 is the best choice.
Stef
Hi Stef--
you should have a look at the changes done in the versions until 3.9 since else this will be really difficult to migrate on top of spoon (which I would love)
Can you be more specific about which changes you mean? In general, I think it'll be easier to adapt changes to Spoon that it is to adapt to other versions of Squeak, since there is less in Spoon to cause conflict (because it's minimal).
I cannot really believe in the "people will rewrite what they need" so reusing is important for me.
I expect that people will get most of the way there by imprinting unit tests from their previous working object memory (in 3.x and earlier). This is the primary motivation for making a Flow release that is compatible with 3.x and earlier. With that we can implement just enough of the remote-messaging support and Naiad in those older systems, so that we can imprint from there onto newer Spoon systems.
Still I have some doubts that working on 3.2 is the best choice.
For making a minimal system, I think it's best to start with the earliest/smallest Squeak possible (i.e., the earliest one that has all desired VM-dependent behavior). Initially, I had hoped that the starting point would be Dan's 2.2 "mini" system, because the object memory part was already pretty small. I only went forward to 3.2 because I wanted the exception-handling and finalization support (even though both of those could be improved-- it's easier this way rather than trying to add them into the minimal system later). If I'm missing some some fundamental VM-dependent support that's been added since 3.2, please let me know what it is.
thanks,
-C
On 11 août 06, at 23:33, Craig Latta wrote:
Hi Stef--
you should have a look at the changes done in the versions until 3.9 since else this will be really difficult to migrate on top of spoon (which I would love)
Can you be more specific about which changes you mean? Ingeneral, I think it'll be easier to adapt changes to Spoon that it is to adapt to other versions of Squeak, since there is less in Spoon to cause conflict (because it's minimal).
pragmas, traits and tons of fixes that were harvested initialize called by new
I cannot really believe in the "people will rewrite what they need" so reusing is important for me.
I expect that people will get most of the way there by imprintingunit tests from their previous working object memory (in 3.x and earlier). This is the primary motivation for making a Flow release that is compatible with 3.x and earlier. With that we can implement just enough of the remote-messaging support and Naiad in those older systems, so that we can imprint from there onto newer Spoon systems.
I hope this will work in reality. There are a lot of work with limited tests and also bootstrapping problem
Still I have some doubts that working on 3.2 is the best choice.
For making a minimal system, I think it's best to start with theearliest/smallest Squeak possible (i.e., the earliest one that has all desired VM-dependent behavior).
I know but.
Initially, I had hoped that the starting point would be Dan's 2.2 "mini" system, because the object memory part was already pretty small. I only went forward to 3.2 because I wanted the exception-handling and finalization support (even though both of those could be improved-- it's easier this way rather than trying to add them into the minimal system later). If I'm missing some some fundamental VM-dependent support that's been added since 3.2, please let me know what it is.
I do not have enough knowledge there. I know that john told me that the event system handling was improved and lot more.
Stef
On 11.08.2006, at 23:33, Craig Latta wrote:
Hi Stef--
you should have a look at the changes done in the versions until 3.9 since else this will be really difficult to migrate on top of spoon (which I would love)
Can you be more specific about which changes you mean? Ingeneral, I think it'll be easier to adapt changes to Spoon that it is to adapt to other versions of Squeak, since there is less in Spoon to cause conflict (because it's minimal).
Will that work with the non-VM, but quite deep image-level changes that we have seen in 3.8/3.9? E.g. the time/date stuff, CompiledMethod format (properties and pragmas) in 3.9, the m17n things, traits.... it would be quite an amazing thing if spoon would "just work" with all this. There were really lots of changes since 3.2...
What is clear is that it would require quite some energy to re-do all that (in the way we would do it now) in a 3.2 Image. I am quite sure that it is so much work that it will never happen. But then Spoon may change the game so much that it's indeed doable...
Marcus
Will that work with the non-VM, but quite deep image-level changes that we have seen in 3.8/3.9? E.g. the time/date stuff,
about time/date change I was (may be wrong) to think that in fact these changes should have just been a nice package and that we keep the old core (knowing its limits) and that people can load chronos/aconcagua or the current one. But this is a side remark. :) A thought I got.
CompiledMethod format (properties and pragmas) in 3.9, the m17n things, traits.... it would be quite an amazing thing if spoon would "just work" with all this. There were really lots of changes since 3.2...
Hi Marcus--
Will [imprinting unit tests] work with the non-VM, but quite deep image-level changes that we have seen in 3.8/3.9?
Yes, I believe so. Imprinting is extremely powerful. Compiled methods (in particular, their literals) are transferred accurately as they are run. I have successfully imprinted the exception-handling support, as well as the ClassBuilder. I think those are very compelling demonstrations.
Spoon may change the game so much that it's indeed doable...
I think that's a good way of putting it.
thanks,
-C
spoon@lists.squeakfoundation.org
-
Craig Latta -
Marcus Denker -
stéphane ducasse