Ok, Goran, I can see when I'm beaten :-)
Since I'm still not interested in taking this as a fixed role, and you've decided it's needed, I don't mind if you and Doug (or someone else) take it up. Heck, I'll even help along occaisonally. While I'm at it, I'll try to subvert it from a "Plan", to a "statement of the Guides perceived best direction for Squeak n.m" :-)
What do I think should happen in 3.6?
I think the most important thing for this version is not to get to a specific goal, but to get a few processes going. Here's a partial list.
* Restart harvesting using the new process, hopefully removing some backlog. * Get the simulator fixes by Craig back in. * Start merging Anthony's work. Run time stuff is a good place to start. * Start merging MCP's work, as they start to send it to us. Same for KCP, except I for one am less aware of what they're working on, and have less of an idea as to whether they'll have something ready to merge anytime soon. * Networking/Streams/Sockets is something where a few people have put in quite a lot of work. Find a way to start merging at least some of this stuff, in small pieces. Ideally, we should do everything possible without breaking networking applications. Then break networking (start raising exceptions instead of dialogs) in 3.7alpha. * SM 1.1
Daniel
goran.hultgren@bluefish.se wrote:
Hi all!
Well, it seems we lost a thread here somewhere. 3.6 is starting up and we really need to have a Plan for it. No, don't say "we need no plan, just a date" because that just isn't true.
We need *both* IMHO. 3.6 is really going to shake things around so I repeat - We Really Do Need A Plan - ok?
Good, now that we have that out of the way :-) we also quickly realize that to get a plan we need someone who crafts it. No, don't say "we don't want somebody telling us what to do" because that isn't the way it should be done.
The plan should of course be worked out on squeak-dev through discussions (as always) but somebody needs to moderate, collect and formulate it. So, without further ado - who takes this assignment?
I have the following suggestions:
- Ned. But Ned is worth so much more doing harvesting (?) or other
complex debugger-digging, and I don't think Ned really "likes" the moderation role! :-)
- Tim. Tim has a lot of good knowledge when it comes to the tougher big
enhancements we have lined up in front of us possibly in part for 3.6 (think Anthony), what do you say Tim?
- Me and Doug. Since Daniel (otherwise an obvious choice) has indicated
that he isn't interested (I got that through "readsay") the last alternative is a combination of me and Doug. We tend to agree on most things and we are already lined up to take this assignment if Ned and Tim says no.
Note: I didn't propose Craig here becuase I think he is busy with Squat etc and not really interested in this. Just a guess.
Ok, so lets be quick here - Ned, Tim or Me+Doug? And please don't start discussing the need for someone doing this - Doug wants someone and he *is* in charge of the update stream so darnit, just accept the fact that we need someone doing this. :-)
As soon as we have this decided the MasterPlanner(s) should probably IMO start a quick "round up" thread on squeak-dev to collect ideas on what 3.6 will/should/could be made of.
regards, Göran _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
goran.hultgren@bluefish.se wrote:
... Ok, so lets be quick here - Ned, Tim or Me+Doug? And please don't start discussing the need for someone doing this - Doug wants someone and he *is* in charge of the update stream so darnit, just accept the fact that we need someone doing this. :-)
Ok, since neither Ned, Tim nor Craig volunteered for this task, I think we should go with the Goran+Doug master planner plan, so we can move forward. I can understand that no one might jump at volunteering for this particular task... it could make one rather unpopular. But if it's going to be Goran+Doug, I can simply blame Goran for any poor decisions. ;-)
As soon as we have this decided the MasterPlanner(s) should probably IMO start a quick "round up" thread on squeak-dev to collect ideas on what 3.6 will/should/could be made of.
Um, yes. You can start that up if you'd like.
One thing about the plan that I think we have agreed on to some extent is the 4-month time period, and the notion that the release date would generally be more firm than the release content. When I proposed this, there was some agreement, and no disagreement. With the First Fridays system, the release date would be August 1st. So, if there are no last-minute disagreements, let's consider this part of the plan as set in stone.
Other than that, I think Daniel's list of items below is a good start. Some items such as the "simulator fixes by Craig" might even be a finer level of granularity than is necessary for a release plan. Most bug fixes do not really need to be in the plan. However, if the simulator fixes are large/significant fixes, then sure, we can include them in the plan.
Items I might add to the list are:
* Apply some number of package removals to the image. (Perhaps you were taking this one for granted.) I don't think we should try to plan exactly which ones will be removed, but we could set a rough goal of a certain number of MB removed from the image, perhaps. * Remove the Apple fonts from the image, and replace them with functionally similar bitmap fonts. We would still need to decide whether this meant the Accufonts, or a move to ISO-8859-1.
- Doug
Daniel Vainsencher wrote:
Ok, Goran, I can see when I'm beaten :-)
Since I'm still not interested in taking this as a fixed role, and you've decided it's needed, I don't mind if you and Doug (or someone else) take it up. Heck, I'll even help along occaisonally. While I'm at it, I'll try to subvert it from a "Plan", to a "statement of the Guides perceived best direction for Squeak n.m" :-)
What do I think should happen in 3.6?
I think the most important thing for this version is not to get to a specific goal, but to get a few processes going. Here's a partial list.
- Restart harvesting using the new process, hopefully removing some
backlog.
- Get the simulator fixes by Craig back in.
- Start merging Anthony's work. Run time stuff is a good place to start.
- Start merging MCP's work, as they start to send it to us. Same for
KCP, except I for one am less aware of what they're working on, and have less of an idea as to whether they'll have something ready to merge anytime soon.
- Networking/Streams/Sockets is something where a few people have put in
quite a lot of work. Find a way to start merging at least some of this stuff, in small pieces. Ideally, we should do everything possible without breaking networking applications. Then break networking (start raising exceptions instead of dialogs) in 3.7alpha.
- SM 1.1
Daniel
goran.hultgren@bluefish.se wrote:
Hi all!
Well, it seems we lost a thread here somewhere. 3.6 is starting up and we really need to have a Plan for it. No, don't say "we need no plan, just a date" because that just isn't true.
We need *both* IMHO. 3.6 is really going to shake things around so I repeat - We Really Do Need A Plan - ok?
Good, now that we have that out of the way :-) we also quickly realize that to get a plan we need someone who crafts it. No, don't say "we don't want somebody telling us what to do" because that isn't the way it should be done.
The plan should of course be worked out on squeak-dev through discussions (as always) but somebody needs to moderate, collect and formulate it. So, without further ado - who takes this assignment?
I have the following suggestions:
- Ned. But Ned is worth so much more doing harvesting (?) or other
complex debugger-digging, and I don't think Ned really "likes" the moderation role! :-)
- Tim. Tim has a lot of good knowledge when it comes to the tougher big
enhancements we have lined up in front of us possibly in part for 3.6 (think Anthony), what do you say Tim?
- Me and Doug. Since Daniel (otherwise an obvious choice) has indicated
that he isn't interested (I got that through "readsay") the last alternative is a combination of me and Doug. We tend to agree on most things and we are already lined up to take this assignment if Ned and Tim says no.
Note: I didn't propose Craig here becuase I think he is busy with Squat etc and not really interested in this. Just a guess.
Ok, so lets be quick here - Ned, Tim or Me+Doug? And please don't start discussing the need for someone doing this - Doug wants someone and he *is* in charge of the update stream so darnit, just accept the fact that we need someone doing this. :-)
As soon as we have this decided the MasterPlanner(s) should probably IMO start a quick "round up" thread on squeak-dev to collect ideas on what 3.6 will/should/could be made of.
regards, Göran _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Howdy all!
(Ahhh, how nice to not discuss licensing issues :-) )
Doug Way dway@riskmetrics.com wrote:
goran.hultgren@bluefish.se wrote:
... Ok, so lets be quick here - Ned, Tim or Me+Doug? And please don't start discussing the need for someone doing this - Doug wants someone and he *is* in charge of the update stream so darnit, just accept the fact that we need someone doing this. :-)
Ok, since neither Ned, Tim nor Craig volunteered for this task, I think we should go with the Goran+Doug master planner plan, so we can move forward. I can understand that no one might jump at volunteering for this particular task... it could make one rather unpopular. But if it's going to be Goran+Doug, I can simply blame Goran for any poor decisions. ;-)
Right! I seem to have some nice Karma right now that I can burn on bad decisions. :-)
You and me it is then... Muuuaahahahaha! (loud evil laughter as the thought sinks in)
As soon as we have this decided the MasterPlanner(s) should probably IMO start a quick "round up" thread on squeak-dev to collect ideas on what 3.6 will/should/could be made of.
Um, yes. You can start that up if you'd like.
I will do that. I will start by scanning all the relevant posts that already have been made on the subject and build a "gross shopping list" which we can pick and choose from. I will also post on squeak-dev that we are currently doing this to encourage postings on the subject.
One thing about the plan that I think we have agreed on to some extent is the 4-month time period, and the notion that the release date would generally be more firm than the release content. When I proposed this, there was some agreement, and no disagreement. With the First Fridays system, the release date would be August 1st. So, if there are no last-minute disagreements, let's consider this part of the plan as set in stone.
Exactly.
Other than that, I think Daniel's list of items below is a good start. Some items such as the "simulator fixes by Craig" might even be a finer level of granularity than is necessary for a release plan. Most bug fixes do not really need to be in the plan. However, if the simulator fixes are large/significant fixes, then sure, we can include them in the plan.
I agree - we don't need to include simple small FIXes, that is definitely not the point of the plan. But I do want us to decide on the bigger issues. And then, as you wrote - the release date will always limit what actually get in, in the end.
Items I might add to the list are:
- Apply some number of package removals to the image. (Perhaps you were
taking this one for granted.) I don't think we should try to plan exactly which ones will be removed, but we could set a rough goal of a certain number of MB removed from the image, perhaps.
- Remove the Apple fonts from the image, and replace them with functionally
similar bitmap fonts. We would still need to decide whether this meant the Accufonts, or a move to ISO-8859-1.
Will collect.
Oh, and yeah:
Daniel Vainsencher wrote:
Ok, Goran, I can see when I'm beaten :-)
Since I'm still not interested in taking this as a fixed role, and you've decided it's needed, I don't mind if you and Doug (or someone else) take it up. Heck, I'll even help along occaisonally. While I'm at
Actually I wasn't proposing this as a "fixed role" (sorry if it sounded like that) - I was merely proposing the role for 3.6. After that someone else may take the wheel! :-)
regards, Göran
I haven't timeto offer much to planning right now since I'm trying to get the VMMaker package (re)done and working on tools to build images to spec and handling Canada paperwork and on and on. In an effort to be helpful, here are comments on current suggestions:-
- Apply some number of package removals to the image. (Perhaps you were
taking this one for granted.) I don't think we should try to plan exactly which ones will be removed, but we could set a rough goal of a certain number of MB removed from the image, perhaps.
Before any goals relating to size, number or whatever we should establish a _quality_ goal. For example, no removal package is much use unless the package can subsequently be installed and actually work. This relates to the problem I'm having right now with filing out a changeset not being even close to filing out the classes individually. Without tools that let package maintainers work sensibly we're going to be in trouble pretty quick.
- Remove the Apple fonts from the image, and replace them with functionally
similar bitmap fonts. We would still need to decide whether this meant the Accufonts, or a move to ISO-8859-1.
Simplest first I'd say. Just get the Apple fonts out and _something_ in. Accufonts seem reasonable to me. One could consider use of TTFs since there are quite a lot of reasonable TTF free fonts around. That would involve some decision on $_ etc. :-(
- Restart harvesting using the new process, hopefully removing some
backlog.
Some explicable process and cleaning up of swiki pages would help here. I tried a week or two ago and got lost in a forest of oldlinks and irelevant pages. And at the end I still didn't understand where to send code I wanted reviewed or to approve.
- Get the simulator fixes by Craig back in.
Yes. THe various fixes he & Anthony worked out get an image running ok. I think a bunch of simulatorclasses for plugins are still needed really.
- Start merging Anthony's work. Run time stuff is a good place to start.
The extra prims are harmless and easy and would allow people to load a normal package effectively. As for the rest, well I still don't really know. Ian needs to be involved but it can be tricky to keep his attention.
- Start merging MCP's work, as they start to send it to us. Same for
KCP, except I for one am less aware of what they're working on, and have less of an idea as to whether they'll have something ready to merge anytime soon.
Yes. Let's encourage decent discussion on these as well.
- Networking/Streams/Sockets is something where a few people have put in
quite a lot of work. Find a way to start merging at least some of this stuff, in small pieces. Ideally, we should do everything possible without breaking networking applications. Then break networking (start raising exceptions instead of dialogs) in 3.7alpha.
Flow? Filename cleanups? There's a boatload of crap to bail out of the boat.
- SM 1.1
tim
On Saturday, April 5, 2003, at 04:28 PM, Tim Rowledge wrote:
- Apply some number of package removals to the image. (Perhaps you
were taking this one for granted.) I don't think we should try to plan exactly which ones will be removed, but we could set a rough goal of a certain number of MB removed from the image, perhaps.
Before any goals relating to size, number or whatever we should establish a _quality_ goal. For example, no removal package is much use unless the package can subsequently be installed and actually work. This relates to the problem I'm having right now with filing out a changeset not being even close to filing out the classes individually. Without tools that let package maintainers work sensibly we're going to be in trouble pretty quick.
Yes, quality of package removals/additions should be more important than making sure we reach a specific target number/size of removals. The size goal for removals could be more of a prediction than a must-have goal.
As far as quality criteria for package removals go, we'd have the usual harvesting criteria as a minimum (externally tested, etc.), which should hopefully cover things like the package addition being installable and generally working.
One other quality criteria for package removals/additions that I was wondering about: Should we have a strict rule that package removals can only remove classes and (class-extension) methods, they cannot overwrite any methods? Conversely, package additions could only add classes and (class-extension) methods, no method overwrites. This would of course often require that some refactoring be done in preparation for the removal, so that registering menus were used, etc. (And we already have a plan that refactorings should be done prior to removal, anyway.) However, having this as a general rule might be unrealistically strict. (?)
- Remove the Apple fonts from the image, and replace them with
functionally similar bitmap fonts. We would still need to decide whether this meant the Accufonts, or a move to ISO-8859-1.
Simplest first I'd say. Just get the Apple fonts out and _something_ in. Accufonts seem reasonable to me. One could consider use of TTFs since there are quite a lot of reasonable TTF free fonts around. That would involve some decision on $_ etc. :-(
I agree that Accufonts seem reasonable. We'd have to agree that the license was acceptable and Squeak compatible (which I think it is, IMO). Even after adding the Accufonts, we could have a move toward supporting ISO-8859-1, as soon as someone did the required work.
- Restart harvesting using the new process, hopefully removing some
backlog.
Some explicable process and cleaning up of swiki pages would help here. I tried a week or two ago and got lost in a forest of oldlinks and irelevant pages. And at the end I still didn't understand where to send code I wanted reviewed or to approve. ...
Yes, I've been meaning to clean these pages up and have a good summary of the process... I will try to get to this ASAP.
- Doug
Hi doug
- Start merging MCP's work, as they start to send it to us. Same for
KCP, except I for one am less aware of what they're working on, and have less of an idea as to whether they'll have something ready to merge anytime soon.
As I mentioned in my previous email all the changes we did so far are simple. Using the method environment where it should be used instead of hardcoding Smalltalk, moving basic UI dependency in a new class SystemNavigation that can be used by all the tools (we fixed all the old calls in the various browsers, but the more we wait to incorporate them the more chance we will have to look at them again. ). Clean subclass calls from Behavior (yes! a class was calling its subclass methods!!!). And more minor inconsistencies such as having only withAllSubclasses in ClassDescription and other things of the same level. Normally everything that is on the wiki page can be merged in the 3.4 image. We were hust waiting for external reviewers before proceeding.
What we are waiting from the guides is what I mentioned in my previous email.
Stef
PS: related to the issues of package removal, I have the impression that having a declarative syntax as the one of Ginsu would solve a lot of problems. Having explicit representation for global variable, pooldeclaration is needed.
Avi's monticello was a first step in that direction may be this could be a goal that the Guides could identify as important for the community and ask whether a group of people want to tackle.
On Saturday, April 5, 2003, at 04:28 PM, Tim Rowledge wrote:
- Restart harvesting using the new process, hopefully removing some
backlog.
Some explicable process and cleaning up of swiki pages would help here. I tried a week or two ago and got lost in a forest of oldlinks and irelevant pages. And at the end I still didn't understand where to send code I wanted reviewed or to approve.
Okay, I finally put together a swiki page outlining what I believe to be the current harvesting process, as was sorted out here on this list recently:
http://minnow.cc.gatech.edu/squeak/3152
Let me know if there are any problems with this. If not, I'll post the page on squeak-dev too. Of course, we can refine the process as we go.
(I used the term "Harvest Master" for my role as update-stream-incorporator. I think Hannes came up with this... I couldn't think of another good term. Maybe "Incorporator"... eh.)
I think I cleaned up most of the related harvesting pages so that they're no longer horribly out of date, and added links between pages where appropriate.
Also, related to Stephane's thread about the Kernel group harvesting, we need to think about how that will fit in with the process outlined above. I think Stephane and Daniel are on the right track... I will try to offer extra suggestions tomorrow, but I'm up way to late here and am about to fall asleep... :-)
- Doug
Hi doug
Is there a special tag for the cleaning changeset. In the past I saw [Refactoring], do there are simply ENH but in general they do no add anything.
Stef
On Monday, April 7, 2003, at 08:17 AM, Doug Way wrote:
On Saturday, April 5, 2003, at 04:28 PM, Tim Rowledge wrote:
- Restart harvesting using the new process, hopefully removing some
backlog.
Some explicable process and cleaning up of swiki pages would help here. I tried a week or two ago and got lost in a forest of oldlinks and irelevant pages. And at the end I still didn't understand where to send code I wanted reviewed or to approve.
Okay, I finally put together a swiki page outlining what I believe to be the current harvesting process, as was sorted out here on this list recently:
http://minnow.cc.gatech.edu/squeak/3152
Let me know if there are any problems with this. If not, I'll post the page on squeak-dev too. Of course, we can refine the process as we go.
(I used the term "Harvest Master" for my role as update-stream-incorporator. I think Hannes came up with this... I couldn't think of another good term. Maybe "Incorporator"... eh.)
I think I cleaned up most of the related harvesting pages so that they're no longer horribly out of date, and added links between pages where appropriate.
Also, related to Stephane's thread about the Kernel group harvesting, we need to think about how that will fit in with the process outlined above. I think Stephane and Daniel are on the right track... I will try to offer extra suggestions tomorrow, but I'm up way to late here and am about to fall asleep... :-)
- Doug
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Prof. Dr. Stéphane DUCASSE http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes
"The best way to predict the future is to invent it..." Alan Kay.
Open Source Smalltalks: http://www.squeak.org, http://www.gnu.org/software/smalltalk/smalltalk.html Free books for Universities at http://www.esug.org/sponsoring/promotionProgram.html Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html
Stephane Ducasse wrote:
Hi doug
Is there a special tag for the cleaning changeset. In the past I saw [Refactoring], there are simply ENH but in general they do no add anything.
We probably should add an official [REFACTOR] or [REF] or similar tag to the list of tags parsed by the SQFIXES page, since it really is separate from [ENH], [FIX], etc. Also add it to the list on http://minnow.cc.gatech.edu/squeak/398.
Sometimes a submission will be a combination of [FIX][REFACTOR] or [ENH][REFACTOR], in which case both tags can be used. But some of the Kernel Cleaning Group's submissions will probably just be pure refactorings.
How about [REFACTOR] as the tag? [REFACTORING] feels too long (much longer than the other tags), and [REF] feels kind of short, although [REF] would probably be okay too.
Does this sound reasonable to you, Bert?
- Doug
Am Montag, 07.04.03 um 21:45 Uhr schrieb Doug Way:
Stephane Ducasse wrote:
Hi doug
Is there a special tag for the cleaning changeset. In the past I saw [Refactoring], there are simply ENH but in general they do no add anything.
We probably should add an official [REFACTOR] or [REF] or similar tag to the list of tags parsed by the SQFIXES page, since it really is separate from [ENH], [FIX], etc. Also add it to the list on http://minnow.cc.gatech.edu/squeak/398.
Sometimes a submission will be a combination of [FIX][REFACTOR] or [ENH][REFACTOR], in which case both tags can be used. But some of the Kernel Cleaning Group's submissions will probably just be pure refactorings.
How about [REFACTOR] as the tag? [REFACTORING] feels too long (much longer than the other tags), and [REF] feels kind of short, although [REF] would probably be okay too.
I strongly accociate REF with "reference" ... how about RFC? Uh, strong association, too. FAC? Could do.
Does this sound reasonable to you, Bert?
No problem here, I can add any tags you want ;-)
Still, I would consider refactorings to be enhancements for readability and maintainability, which are crucial qualities in an authoring environment. So I'd prefer posting these with an [ENH] tag. Also I prefer to have as few tags as possible. Cognitive load, you know ;-)
Anyway, if you want me to add anything, just let me know.
-- Bert
Hi all
After thinking about it I think that having [KCP][ENH] would be the best. Note that while cleaning we are also removing bugs. Such as sending a message isMeta to behavior breaks, or other methods calling method only defined in subclasses.
Is it ok for you?
Stef
On Monday, April 7, 2003, at 11:00 PM, Bert Freudenberg wrote:
Am Montag, 07.04.03 um 21:45 Uhr schrieb Doug Way:
Stephane Ducasse wrote:
Hi doug
Is there a special tag for the cleaning changeset. In the past I saw [Refactoring], there are simply ENH but in general they do no add anything.
We probably should add an official [REFACTOR] or [REF] or similar tag to the list of tags parsed by the SQFIXES page, since it really is separate from [ENH], [FIX], etc. Also add it to the list on http://minnow.cc.gatech.edu/squeak/398.
Sometimes a submission will be a combination of [FIX][REFACTOR] or [ENH][REFACTOR], in which case both tags can be used. But some of the Kernel Cleaning Group's submissions will probably just be pure refactorings.
How about [REFACTOR] as the tag? [REFACTORING] feels too long (much longer than the other tags), and [REF] feels kind of short, although [REF] would probably be okay too.
I strongly accociate REF with "reference" ... how about RFC? Uh, strong association, too. FAC? Could do.
Does this sound reasonable to you, Bert?
No problem here, I can add any tags you want ;-)
Still, I would consider refactorings to be enhancements for readability and maintainability, which are crucial qualities in an authoring environment. So I'd prefer posting these with an [ENH] tag. Also I prefer to have as few tags as possible. Cognitive load, you know ;-)
Anyway, if you want me to add anything, just let me know.
-- Bert
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Prof. Dr. Stéphane DUCASSE http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes
"The best way to predict the future is to invent it..." Alan Kay.
Open Source Smalltalks: http://www.squeak.org, http://www.gnu.org/software/smalltalk/smalltalk.html Free books for Universities at http://www.esug.org/sponsoring/promotionProgram.html Free Online Book at http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html
Stephane Ducasse wrote:
After thinking about it I think that having [KCP][ENH] would be the best.
Sounds fine.
Note that while cleaning we are also removing bugs. Such as sending a message isMeta to behavior breaks, or other methods calling method only defined in subclasses.
Is it ok for you?
That is fine, too. If you can keep the bug fixes in separate changesets from the refactorings, that would be best. Although I realize this is not always possible.
- Doug
Doug Way dway@riskmetrics.com wrote:
(I used the term "Harvest Master" for my role as update-stream-incorporator. I think Hannes came up with this... I couldn't think of another good term. Maybe "Incorporator"... eh.)
Combine Harvester :-) Evokes an image of a nearly unstoppable machine sweeping across the field of offerings, chopping them off at the base and tossing them into the hopper. Which is pretty much the job.
tim
squeakfoundation@lists.squeakfoundation.org
-
Bert Freudenberg -
Daniel Vainsencher -
Doug Way -
goran.hultgren＠bluefish.se -
Stephane Ducasse -
Tim Rowledge