I want to add some more reasoning to this commit. The commit is intended to fix this issue: http://bugs.squeak.org/view.php?id=7767
My implementation is based on the corresponding Pharo Traits implementation, except for the TraitsComposition>>#printOn: implementation. Do you think it is worth also recreating that behavior?
In general, the most important thing regarding this change is, that this might break older .st or .cs files containing Traits definitions based on the old evaluation order.
Bests Patrick ________________________________________ Von: squeak-dev-bounces@lists.squeakfoundation.org squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von commits@source.squeak.org commits@source.squeak.org Gesendet: Freitag, 20. November 2015 09:52 An: squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Traits-pre.307.mcz
A new version of Traits was added to project The Inbox: http://source.squeak.org/inbox/Traits-pre.307.mcz
==================== Summary ====================
Name: Traits-pre.307 Author: pre Time: 20 November 2015, 2:58:26.562 pm UUID: f0955b2d-775c-4862-85b9-5d6e616cd2e4 Ancestors: Traits-eem.306
This fixes http://bugs.squeak.org/view.php?id=7767 which is about the - and @ operator of Trait compositions ignoring brackets. This implementation uses the normal left to right evaluation order of Smalltalk to avoid confusions about the way trait composition expressions are evaluated.
=============== Diff against Traits-eem.306 ===============
Item was changed: ----- Method: TraitAlias>>printOn: (in category 'operations') ----- printOn: s "Answer the trait composition string (used for class definitions)" + s nextPutAll: '('. s nextPutAll: subject asString. s nextPutAll: ' @ {'. aliases do:[:assoc| s print: assoc] separatedBy:[s nextPutAll:'. ']. s nextPutAll: '}'. + s nextPutAll: ')'.! - !
Item was changed: ----- Method: TraitComposition>>- (in category 'converting') ----- - anArray - "the modifier operators #@ and #- bind stronger than +. - Thus, #@ or #- sent to a sum will only affect the most right summand"
+ self updateTraits: (self traitsCollect: [:aTrait | aTrait - anArray ])! - self addLast: (self removeLast - anArray)!
Item was changed: ----- Method: TraitComposition>>@ (in category 'converting') ----- @ anArrayOfAssociations + + self updateTraits: (self traitsCollect: [:aTrait | aTrait @ anArrayOfAssociations ])! - "the modifier operators #@ and #- bind stronger than +. - Thus, #@ or #- sent to a sum will only affect the most right summand" - - self addLast: (self removeLast @ anArrayOfAssociations)!
Item was added: + ----- Method: TraitComposition>>traitsCollect: (in category 'accessing') ----- + traitsCollect: aBlock + ^self collect: [:each| each traitsDo: aBlock]!
Item was changed: ----- Method: TraitComposition>>traitsDo: (in category 'accessing') ----- traitsDo: aBlock + ^self do: [:each| each traitsDo: aBlock]! - ^self do:[:each| each traitsDo: aBlock]!
Item was added: + ----- Method: TraitComposition>>updateTraits: (in category 'converting') ----- + updateTraits: aCollection + + self + removeAll; + addAll: aCollection!
Item was changed: ----- Method: TraitExclusion>>printOn: (in category 'composition') ----- printOn: aStream "Answer the trait composition string (used for class definitions)" + aStream nextPutAll: '('. aStream nextPutAll: subject asString. aStream nextPutAll: ' - {'. exclusions asArray sort do:[:exc| aStream store: exc] separatedBy:[aStream nextPutAll: '. ']. + aStream nextPutAll: '}'. + aStream nextPutAll: ')'.! - aStream nextPutAll: '}'.!
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage
On Fri, 20 Nov 2015, tim Rowledge wrote:
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
I always considered Traits to be a weak concept. IMHO with less effort, one could have created a stateful deterministic mixin system which would have been superior to Traits.
Andreas has replaced the original Traits implementation with his own "NanoKernel" variant. It's probably the simplest thing that can be considered as Traits.
If you need tools, then you'll have to look somewhere else. The Pharo guys might have come up with something over the years.
I think only Pharo and some related projects use Traits, but even there the use-cases are extremely limited.
Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
Backwards compatibility is the only reason for it to be in the image. In the 4.1 release, it was unloadable. We should check whether it still is. Sadly I have to agree with you on the rest, too.
Levente
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage
On Fri, Nov 20, 2015 at 7:40 PM, tim Rowledge tim@rowledge.org wrote:
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
Yes, it's very hard to maintain half implemented stuff, that lacks documentation and direction. And if people really cared about any of these I guess they would be used somehow. And improved over the years. Very little has happened with either of these.
If these subsystems are just cruft left over and nobody uses them, it would be good to move them out of trunk.
Best, Karl
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage
Concerning Traits I would keep them in trunk for these reasons: - if the package is not in trunk it will rapidly rot - this package can extend cross compatibility with Pharo a bit further I don't know which package really use them though, but that's my feeling
2015-11-20 20:18 GMT+01:00 karl ramberg karlramberg@gmail.com:
On Fri, Nov 20, 2015 at 7:40 PM, tim Rowledge tim@rowledge.org wrote:
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
Yes, it's very hard to maintain half implemented stuff, that lacks documentation and direction. And if people really cared about any of these I guess they would be used somehow. And improved over the years. Very little has happened with either of these.
If these subsystems are just cruft left over and nobody uses them, it would be good to move them out of trunk.
Best, Karl
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage
I would like island to stay also. To me, they are one of the most interesting additions to our base over the recent years. (We use them in Archipelago [*]...)
Best, Robert
[*] http://www.hpi.uni-potsdam.de/swa/publications/media/SecklerHirschfeld_2014_...
On 20 Nov 2015, at 21:54, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Concerning Traits I would keep them in trunk for these reasons:
- if the package is not in trunk it will rapidly rot
- this package can extend cross compatibility with Pharo a bit further
I don't know which package really use them though, but that's my feeling
2015-11-20 20:18 GMT+01:00 karl ramberg karlramberg@gmail.com:
On Fri, Nov 20, 2015 at 7:40 PM, tim Rowledge tim@rowledge.org wrote: Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
Yes, it's very hard to maintain half implemented stuff, that lacks documentation and direction. And if people really cared about any of these I guess they would be used somehow. And improved over the years. Very little has happened with either of these.
If these subsystems are just cruft left over and nobody uses them, it would be good to move them out of trunk.
Best, Karl
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage
-- Robert Hirschfeld hirschfeld@acm.org www.hirschfeld.org
I like traits. I use them for documenting extension points/interfaces:
https://github.com/hpi-swa/vivide/tree/master/repository/Vivide.package/TViO... https://github.com/hpi-swa/vivide/tree/master/repository/Vivide.package/TViM...
Please keep them in the image.
Best, Marcel
-- View this message in context: http://forum.world.st/The-Inbox-Traits-pre-307-mcz-tp4862218p4862318.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
I used them while building up some COBOL software analysis code
http://smalltalkhub.com/#!/~cbc/PetitCobol
I've considered using them elsewhere, but the tools deficit is an issue, yes. You CAN work around the issue with the current tools - it's just not as nice as using the rest of the language.
--cbc
On Fri, Nov 20, 2015 at 12:51 PM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
I like traits. I use them for documenting extension points/interfaces:
https://github.com/hpi-swa/vivide/tree/master/repository/Vivide.package/TViO...
https://github.com/hpi-swa/vivide/tree/master/repository/Vivide.package/TViM...
Please keep them in the image.
Best, Marcel
-- View this message in context: http://forum.world.st/The-Inbox-Traits-pre-307-mcz-tp4862218p4862318.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On Fri, Nov 20, 2015 at 12:40 PM, tim Rowledge tim@rowledge.org wrote:
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
+1. +1. +1 and, +1. Doing the most with the least is the most beautiful and admirable aspect of Squeak. Six reserved words, assignment, and sending messages to objects. That's pretty much it. Those concepts alone form the building blocks of the entire IDE, and still able to push the language with clever hacks like Mixins, Generators, Promises, Futures, WriteBarriers, and Continuations.
Traits, Slots, Islands, Environments and Pragmas never convinced me that they deserve to be part of a language this wonderfully sparse.
The then trade-off would be to make them unloadable, right? ;) Just like anyone can unload *-Deprecated packages. This simplifies maintenance.
Best, Marcel
-- View this message in context: http://forum.world.st/The-Inbox-Traits-pre-307-mcz-tp4862218p4862350.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On Sat, Nov 21, 2015 at 12:00:08AM -0800, marcel.taeumel wrote:
The then trade-off would be to make them unloadable, right? ;) Just like anyone can unload *-Deprecated packages. This simplifies maintenance.
Right. Making these packages reloadable is a very good idea. The idea of just deleting them seems rather unhelpful to me.
Dave
On Sat, Nov 21, 2015 at 5:17 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sat, Nov 21, 2015 at 12:00:08AM -0800, marcel.taeumel wrote:
The then trade-off would be to make them unloadable, right? ;) Just like anyone can unload *-Deprecated packages. This simplifies maintenance.
Right. Making these packages reloadable is a very good idea. The idea of just deleting them seems rather unhelpful to me.
Environments are currently not working and as a consequence blocking use of project/ image segment loading/ unloading.
Karl
Dave
On Sat, Nov 21, 2015 at 06:43:00PM +0100, karl ramberg wrote:
On Sat, Nov 21, 2015 at 5:17 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sat, Nov 21, 2015 at 12:00:08AM -0800, marcel.taeumel wrote:
The then trade-off would be to make them unloadable, right? ;) Just like anyone can unload *-Deprecated packages. This simplifies maintenance.
Right. Making these packages reloadable is a very good idea. The idea of just deleting them seems rather unhelpful to me.
Environments are currently not working and as a consequence blocking use of project/ image segment loading/ unloading.
I am not sure what is involved, but is it because of this?
http://bugs.squeak.org/view.php?id=7814
If so we should try Colin's suggested workaround:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-September/180018...
Dave
The Binding issue is fixed by this.
I'll commit that.
The saved project can not be loaded though,,,
Best, Karl
On Sat, Nov 21, 2015 at 7:28 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sat, Nov 21, 2015 at 06:43:00PM +0100, karl ramberg wrote:
On Sat, Nov 21, 2015 at 5:17 PM, David T. Lewis lewis@mail.msen.com
wrote:
On Sat, Nov 21, 2015 at 12:00:08AM -0800, marcel.taeumel wrote:
The then trade-off would be to make them unloadable, right? ;) Just
like
anyone can unload *-Deprecated packages. This simplifies maintenance.
Right. Making these packages reloadable is a very good idea. The idea
of
just deleting them seems rather unhelpful to me.
Environments are currently not working and as a consequence blocking use
of
project/ image segment loading/ unloading.
I am not sure what is involved, but is it because of this?
http://bugs.squeak.org/view.php?id=7814
If so we should try Colin's suggested workaround:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-September/180018...
Dave
On 11/21/15, Chris Muller asqueaker@gmail.com wrote:
On Fri, Nov 20, 2015 at 12:40 PM, tim Rowledge tim@rowledge.org wrote:
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
+1. +1. +1 and, +1. Doing the most with the least is the most beautiful and admirable aspect of Squeak. Six reserved words, assignment, and sending messages to objects. That's pretty much it. Those concepts alone form the building blocks of the entire IDE, and still able to push the language with clever hacks like Mixins, Generators, Promises, Futures, WriteBarriers, and Continuations.
Traits, Slots, Islands, Environments and Pragmas never convinced me that they deserve to be part of a language this wonderfully sparse.
+1 for removing Universes at the moment. There is no server for them and updating SqueakMap which is done at a modest pace replaces the need for them.
I think this has been discussed before the release of 4.6 and people agreed but at that time it was to late to do it.
--Hannes
On 24 November 2015 at 21:09, H. Hirzel hannes.hirzel@gmail.com wrote:
On 11/21/15, Chris Muller asqueaker@gmail.com wrote:
On Fri, Nov 20, 2015 at 12:40 PM, tim Rowledge tim@rowledge.org wrote:
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
+1. +1. +1 and, +1. Doing the most with the least is the most beautiful and admirable aspect of Squeak. Six reserved words, assignment, and sending messages to objects. That's pretty much it. Those concepts alone form the building blocks of the entire IDE, and still able to push the language with clever hacks like Mixins, Generators, Promises, Futures, WriteBarriers, and Continuations.
Traits, Slots, Islands, Environments and Pragmas never convinced me that they deserve to be part of a language this wonderfully sparse.
+1 for removing Universes at the moment. There is no server for them and updating SqueakMap which is done at a modest pace replaces the need for them.
I was under the impression that Universes _was removed_, like, back in 4.4 or the beginning of the 4.5 cycle, when I was up to my eyeballs in hairy dependencies... Certainly the build processes think so - https://github.com/squeak-smalltalk/squeak-ci/blob/master/package-load-scrip... is the _load script_ for Universes (implying its _unloaded by default_ state).
frank
I think this has been discussed before the release of 4.6 and people agreed but at that time it was to late to do it.
--Hannes
On 20 November 2015 at 18:40, tim Rowledge tim@rowledge.org wrote:
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
There's definitely a pattern there: someone has a great idea for a fairly advanced capability, heroically tries to do all the work solo, or with minimal help from the community, burns out and the work never gets finished.
Traits, or things close enough to traits that you end up splitting hairs to tell them apart, are a core feature of so many languages nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my head), while we let the idea die on the vine, for want of tooling support. And I'm sure Environments will, too.
Sure, if it's not providing value, and no one's willing to do the work, just kill the thing and be done. I'd rather see people pitch in and help _make_ the dang thing a proper part of the system. ("Thing" here applies mostly to Environments, but Islands and Traits too.) But I'm also not going to run around pointing fingers: I'm too burned out to do anything to help, so I'll just shut up now.
frank
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage
Software is hard to make. Even harder to make right. Picking up other peoples projects can be daunting.
Most of these projects are quite difficult and involve almost as much political as technical skills to do. (Political in the sense as to get the community to agree to changes and adapt)
I'm not sure how to proceed.
Best, Karl
On Mon, Nov 23, 2015 at 3:30 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 20 November 2015 at 18:40, tim Rowledge tim@rowledge.org wrote:
Should we keep Traits? It was a neat idea that I was happy to support
but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
Unless there is a compelling reason - and subsequent effort to fill out
support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
There's definitely a pattern there: someone has a great idea for a fairly advanced capability, heroically tries to do all the work solo, or with minimal help from the community, burns out and the work never gets finished.
Traits, or things close enough to traits that you end up splitting hairs to tell them apart, are a core feature of so many languages nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my head), while we let the idea die on the vine, for want of tooling support. And I'm sure Environments will, too.
Sure, if it's not providing value, and no one's willing to do the work, just kill the thing and be done. I'd rather see people pitch in and help _make_ the dang thing a proper part of the system. ("Thing" here applies mostly to Environments, but Islands and Traits too.) But I'm also not going to run around pointing fingers: I'm too burned out to do anything to help, so I'll just shut up now.
frank
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage
Hi Karl,
On 23.11.2015, at 16:45, karl ramberg karlramberg@gmail.com wrote:
Software is hard to make. Even harder to make right. Picking up other peoples projects can be daunting.
Most of these projects are quite difficult and involve almost as much political as technical skills to do. (Political in the sense as to get the community to agree to changes and adapt)
I'm not sure how to proceed.
I have to concur, for every very line.
We should have at least a list of things that people/community think are orphaned… so that we can bail if they are actually not.
Best regards -Tobias
Best, Karl
On Mon, Nov 23, 2015 at 3:30 PM, Frank Shearar frank.shearar@gmail.com wrote: On 20 November 2015 at 18:40, tim Rowledge tim@rowledge.org wrote:
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
There's definitely a pattern there: someone has a great idea for a fairly advanced capability, heroically tries to do all the work solo, or with minimal help from the community, burns out and the work never gets finished.
Traits, or things close enough to traits that you end up splitting hairs to tell them apart, are a core feature of so many languages nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my head), while we let the idea die on the vine, for want of tooling support. And I'm sure Environments will, too.
Sure, if it's not providing value, and no one's willing to do the work, just kill the thing and be done. I'd rather see people pitch in and help _make_ the dang thing a proper part of the system. ("Thing" here applies mostly to Environments, but Islands and Traits too.) But I'm also not going to run around pointing fingers: I'm too burned out to do anything to help, so I'll just shut up now.
frank
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage
On Mon, 23 Nov 2015, Frank Shearar wrote:
On 20 November 2015 at 18:40, tim Rowledge tim@rowledge.org wrote:
Should we keep Traits? It was a neat idea that I was happy to support but it got left unfinished. Where are tools to develop & manage Traits? Where is the usage?
Unless there is a compelling reason - and subsequent effort to fill out support - I suggest we should remove them. Along with Islands. And Universes. And probably Environments too, since that has stalled without becoming a proper part of the system.
There's definitely a pattern there: someone has a great idea for a fairly advanced capability, heroically tries to do all the work solo, or with minimal help from the community, burns out and the work never gets finished.
Traits, or things close enough to traits that you end up splitting hairs to tell them apart, are a core feature of so many languages nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my head), while we let the idea die on the vine, for want of tooling
Traits are complex: they introduce a new kind of Behavior, one which doesn't do anything on its own. If Traits were all Classes and all Classes were Traits, the whole implementation would probably be a lot simpler. Traits are weak: they only provide a way to share stateless methods between classes (methods which can't reference variables). If you Traits were Classes, you could share stateful methods by providing a mapping for variables, the same way you can do it for methods.
support. And I'm sure Environments will, too.
Environments is at a point where it needs complex things to be found out to move forward. The current implementation is incomplete and broken. The reason why we don't face the problems (so often) is that we only use one environment.
Levente
Sure, if it's not providing value, and no one's willing to do the work, just kill the thing and be done. I'd rather see people pitch in and help _make_ the dang thing a proper part of the system. ("Thing" here applies mostly to Environments, but Islands and Traits too.) But I'm also not going to run around pointing fingers: I'm too burned out to do anything to help, so I'll just shut up now.
frank
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IG: Insert Garbage
On Mon, Nov 23, 2015 at 6:30 AM, Frank Shearar frank.shearar@gmail.com wrote:
There's definitely a pattern there: someone has a great idea for a
fairly advanced capability, heroically tries to do all the work solo, or with minimal help from the community, burns out and the work never gets finished.
Traits, or things close enough to traits that you end up splitting
hairs to tell them apart, are a core feature of so many languages nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my head), while we let the idea die on the vine, for want of tooling support. And I'm sure Environments will, too.
Sure, if it's not providing value, and no one's willing to do the work, just kill the thing and be done. I'd rather see people pitch in and help _make_ the dang thing a proper part of the system. ("Thing" here applies mostly to Environments, but Islands and Traits too.) But I'm also not going to run around pointing fingers: I'm too burned out to do anything to help, so I'll just shut up now.
Yup, that about sums it up.
Over the last year or so, I've attempted to resume work on Environments several times only to get discouraged and give up. The "easy" part is done, and what remains is tracing through gnarly legacy code and figuring out where the SystemDictionary assumptions are. It's hard.
The reason I started working on OmniBrowser 10 years ago was because Nathanael Schärli commented that the hardest part of getting the Traits prototype working was adding tool support. The idea was to make a modular tool set that could easily be modified and *make language improvements easier*. That failed. OB ended up being a great IDE once Lukas did the refactoring support, but nobody uses it. I spent years trying to hunt down the underlying reasons for that and remove the obstacles, but in the end, "not exactly like the tools I already know" and "requires installation" proved insurmountable.
This is why I wanted to develop Environments in the trunk and not have it be an optional thing. That worked fairly well, but then I ran into the exact same problem that Nathanael did with Traits.
I really want Environments to succeed. I do. I wrote the cleanest code I could, with tests and comments. I engaged with the community from the beginning and throughout the process trying to build support for the idea and knowledge about the implementation. Eventually, I had to take a break and deal with meatspace things like moving and a new job, but I was determined to get back into it as soon as I could.
After time away from it, though, thinking about Environments fills me with despair. Nobody cares. Nobody wants to make Squeak better. The only thing the Squeak community values is compatibility with Alan's demos, and a version of Etoys that nobody uses. Ok, that's over the top. But to a first approximation it's true. It's why we lost the Pharo folks.
So here's my proposal: let's decide as a community whether we want Environments or not. I pledge to help implement the decision either way. If people want to go back to the classical ST-80 global namespace, I'll help with that. Or we can figure out what would be required for Environments to actually be worth keeping and I'll help work on that too.
Thoughts?
Colin
On Mon, Nov 23, 2015 at 7:50 PM, Colin Putney colin@wiresong.com wrote:
On Mon, Nov 23, 2015 at 6:30 AM, Frank Shearar frank.shearar@gmail.com wrote:
There's definitely a pattern there: someone has a great idea for a
fairly advanced capability, heroically tries to do all the work solo, or with minimal help from the community, burns out and the work never gets finished.
Traits, or things close enough to traits that you end up splitting
hairs to tell them apart, are a core feature of so many languages nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my head), while we let the idea die on the vine, for want of tooling support. And I'm sure Environments will, too.
Sure, if it's not providing value, and no one's willing to do the work, just kill the thing and be done. I'd rather see people pitch in and help _make_ the dang thing a proper part of the system. ("Thing" here applies mostly to Environments, but Islands and Traits too.) But I'm also not going to run around pointing fingers: I'm too burned out to do anything to help, so I'll just shut up now.
Yup, that about sums it up.
Over the last year or so, I've attempted to resume work on Environments several times only to get discouraged and give up. The "easy" part is done, and what remains is tracing through gnarly legacy code and figuring out where the SystemDictionary assumptions are. It's hard.
The reason I started working on OmniBrowser 10 years ago was because Nathanael Schärli commented that the hardest part of getting the Traits prototype working was adding tool support. The idea was to make a modular tool set that could easily be modified and *make language improvements easier*. That failed. OB ended up being a great IDE once Lukas did the refactoring support, but nobody uses it. I spent years trying to hunt down the underlying reasons for that and remove the obstacles, but in the end, "not exactly like the tools I already know" and "requires installation" proved insurmountable.
This is why I wanted to develop Environments in the trunk and not have it be an optional thing. That worked fairly well, but then I ran into the exact same problem that Nathanael did with Traits.
I really want Environments to succeed. I do. I wrote the cleanest code I could, with tests and comments. I engaged with the community from the beginning and throughout the process trying to build support for the idea and knowledge about the implementation. Eventually, I had to take a break and deal with meatspace things like moving and a new job, but I was determined to get back into it as soon as I could.
After time away from it, though, thinking about Environments fills me with despair. Nobody cares. Nobody wants to make Squeak better. The only thing the Squeak community values is compatibility with Alan's demos, and a version of Etoys that nobody uses. Ok, that's over the top. But to a first approximation it's true. It's why we lost the Pharo folks.
So here's my proposal: let's decide as a community whether we want Environments or not. I pledge to help implement the decision either way. If people want to go back to the classical ST-80 global namespace, I'll help with that. Or we can figure out what would be required for Environments to actually be worth keeping and I'll help work on that too.
Thoughts?
Colin
Well, if you are interested in working on it I salute you.
I understand your frustration. Squeak is a ship with many captains. It takes patience and skill to change course. Many have left this community in frustration.
I will help you where I can with this project. But most of the stuff involved are much above my knowledge.
Anyway, I committed workaround you had suggested to a issue with environments the other day :-)
Best, Karl
Doing anything big is a pain, even if you’re being paid to do it, have assigned colleagues that you can direct, and know what you’re doing. Most companies fail miserably at it.
In an open source project you add an entire galaxy of extra pain. Herding cats doesn’t even begin to cover it; if you have a decent group of fans of your idea(s) you still face the problems of lack of time, other interests, arguments and on and on. It is a perfect example why the fantasy of ‘the free market will solve everything!’ is so fatuous.
Traits; I liked the idea, as I said. But I’ve never felt the lack of them, nor worked on anything where I thought “hhmm, a trait would be useful here” and with no support in any tools nor easily accessible documentation that might lead me to a fuller appreciation etc... forget it. The only response we’ve had to offer any idea why we ought to care was Marcel saying he found them a bit useful for documenting something. That isn’t exactly a ringing endorsement.
There is a modestly informative page on the swiki at http://wiki.squeak.org/squeak/538 but it dates back to 2006! The commentary in-image is dismal (as is pretty standard, to our disgrace) and offers nothing I can spot that could encourage me to use them, let alone any pointers on how. There’s nothing I can see to indicate Traits actually being used in-image so there’s nothing that makes me think it worth digging further. The only Trait stuff I can find is in fact in the 311Deprecated-Traits category. 3.11 was quite a while ago. Oh, wait, there is a set of tests that might explain something *if they were damn well documented*
Islands; I can’t find anything about them. The swiki has a few pages of approximately 0 information content. In fact it doesn’t seem like they’re even in the image, so I have no idea.
Environments: I like the idea of namespaces that help avoid class/ivar/message name clashes. I don’t see any info to help me make use of them, or when it might be useful, or how to find them. I see very few comments in code, virtually none for classes, nothing in the tests. Haven’t been able to spot any swiki info either.
Universes; I can’t even see enough info to gain an idea of what they’re for! The only bit I spotted points to stuff on a server that no longer exists and probably hasn’t since ’06.
The software world in general seems to be useless at this; we’re nothing special. There are people out there that think running some parser over a tree of text files and extracting function comments is an adequate way to create a manual! There are others that will claim that the ‘code is self documenting’ which really ought to be a capital crime.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Nullo metro compositum est = It doesn't rhyme.
On Mon, Nov 23, 2015 at 10:50:26AM -0800, Colin Putney wrote:
So here's my proposal: let's decide as a community whether we want Environments or not. I pledge to help implement the decision either way. If people want to go back to the classical ST-80 global namespace, I'll help with that. Or we can figure out what would be required for Environments to actually be worth keeping and I'll help work on that too.
Thoughts?
Colin
I strongly favor keeping Environments in the image and doing whatever is needed to address issues that are currently blocking use of image segments (or whatever other real or perceived problems we may have).
My opinion is based in no small part on Andreas Raab's assessment that Environments is a difficult job done right. I am no expert in this area, but I trust Andreas' judgement a lot in matters like this. A good, elegant solution to a difficult problem is worth the effort to bring to completion, even if it takes us a few years to get it done. Let's stick with it and make it right.
Dave
I want Environments and I want Traits too. You say "Nobody cares. Nobody wants to make Squeak better. The only thing the Squeak community values is compatibility with Alan's demos, and a version of Etoys that nobody uses.". None of those statements are true of my efforts or, as far as I can see, of the significant efforts of the HPI team, or of Tim Rowledge, if Chris Muller or Levente Uzoni, and probably a lot of other folks too.
Squeak is my day to day workhorse. The HOI folks are improving the environment at great velocity. Squeak 5 is ~40% faster than Squeak 4.6. Neither of these things are true because no one cares. Colin, mon brave! Mon pôte. Despair not!
_,,,^..^,,,_ (phone)
On Nov 23, 2015, at 10:50 AM, Colin Putney colin@wiresong.com wrote:
On Mon, Nov 23, 2015 at 6:30 AM, Frank Shearar frank.shearar@gmail.com wrote:
There's definitely a pattern there: someone has a great idea for a fairly advanced capability, heroically tries to do all the work solo, or with minimal help from the community, burns out and the work never gets finished.
Traits, or things close enough to traits that you end up splitting hairs to tell them apart, are a core feature of so many languages nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my head), while we let the idea die on the vine, for want of tooling support. And I'm sure Environments will, too.
Sure, if it's not providing value, and no one's willing to do the work, just kill the thing and be done. I'd rather see people pitch in and help _make_ the dang thing a proper part of the system. ("Thing" here applies mostly to Environments, but Islands and Traits too.) But I'm also not going to run around pointing fingers: I'm too burned out to do anything to help, so I'll just shut up now.
Yup, that about sums it up.
Over the last year or so, I've attempted to resume work on Environments several times only to get discouraged and give up. The "easy" part is done, and what remains is tracing through gnarly legacy code and figuring out where the SystemDictionary assumptions are. It's hard.
The reason I started working on OmniBrowser 10 years ago was because Nathanael Schärli commented that the hardest part of getting the Traits prototype working was adding tool support. The idea was to make a modular tool set that could easily be modified and *make language improvements easier*. That failed. OB ended up being a great IDE once Lukas did the refactoring support, but nobody uses it. I spent years trying to hunt down the underlying reasons for that and remove the obstacles, but in the end, "not exactly like the tools I already know" and "requires installation" proved insurmountable.
This is why I wanted to develop Environments in the trunk and not have it be an optional thing. That worked fairly well, but then I ran into the exact same problem that Nathanael did with Traits.
I really want Environments to succeed. I do. I wrote the cleanest code I could, with tests and comments. I engaged with the community from the beginning and throughout the process trying to build support for the idea and knowledge about the implementation. Eventually, I had to take a break and deal with meatspace things like moving and a new job, but I was determined to get back into it as soon as I could.
After time away from it, though, thinking about Environments fills me with despair. Nobody cares. Nobody wants to make Squeak better. The only thing the Squeak community values is compatibility with Alan's demos, and a version of Etoys that nobody uses. Ok, that's over the top. But to a first approximation it's true. It's why we lost the Pharo folks.
So here's my proposal: let's decide as a community whether we want Environments or not. I pledge to help implement the decision either way. If people want to go back to the classical ST-80 global namespace, I'll help with that. Or we can figure out what would be required for Environments to actually be worth keeping and I'll help work on that too.
Thoughts?
Colin
On Mon, Nov 23, 2015 at 4:57 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
I want Environments and I want Traits too. You say "Nobody cares. Nobody wants to make Squeak better. The only thing the Squeak community values is compatibility with Alan's demos, and a version of Etoys that nobody uses.". None of those statements are true of my efforts or, as far as I can see, of the significant efforts of the HPI team, or of Tim Rowledge, if Chris Muller or Levente Uzoni, and probably a lot of other folks too.
Squeak is my day to day workhorse. The HOI folks are improving the environment at great velocity. Squeak 5 is ~40% faster than Squeak 4.6. Neither of these things are true because no one cares. Colin, mon brave! Mon pôte. Despair not!
Well, I did admit that it was over the top. :-)
I do think Frank had a point, though. Squeak has had many ambitious projects over the years, but they all die because one person can't sustain the necessary effort for the time it takes to get it done, and the community can't pick up the slack. We've got to get better at this.
I'll poke around over the holidays and make a list of Environments issues. Then we can figure out how to tackle them.
Colin
For the sake of maintainability, we should keep them in Trunk, make them unloadable and configure our CI environment to execute all tests *after* unloading them.
We could/should do so for other packages as well. It is not only about having a minimal base system were things can be loaded but about a base system that represents a fair trade-off for maintenance while supporting things to be unloadable. :)
Best, Marcel
-- View this message in context: http://forum.world.st/The-Inbox-Traits-pre-307-mcz-tp4862218p4862942.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Hi Marcel,
On Nov 24, 2015, at 1:12 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
For the sake of maintainability, we should keep them in Trunk, make them unloadable and configure our CI environment to execute all tests *after* unloading them.
+1. And to be clear, run the tests before and after unloading them.
We could/should do so for other packages as well. It is not only about having a minimal base system were things can be loaded but about a base system that represents a fair trade-off for maintenance while supporting things to be unloadable. :)
+1.
Best, Marcel
-- View this message in context: http://forum.world.st/The-Inbox-Traits-pre-307-mcz-tp4862218p4862942.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
_,,,^..^,,,_ (phone)
You say "Nobody cares. Nobody wants to make Squeak better. The only thing the Squeak community values is compatibility with Alan's demos, and a version of Etoys that nobody uses.". None of those statements are true of my efforts or, as far as I can see, of the significant efforts of the HPI team, or of Tim Rowledge, if Chris Muller or Levente Uzoni, and probably a lot of other folks too.
Squeak is my day to day workhorse. The HOI folks are improving the environment at great velocity. Squeak 5 is ~40% faster than Squeak 4.6. Neither of these things are true because no one cares.
+1
And if I may add: the feeling that "nobody cares" is a permeating one. Not many people give feedback about what they care about (me included).
In my case, I definitely have the feeling that nobody cares about anything I ever did in Squeak during about 15 years now, which to day includes: a modular Lisp/Scheme implementation, an extension for functional programming, the upgrading of the Prolog implementation, a vast system for musical composition, and a Space Invader reboot.
It's fortunate I did not do this for glory and fame :)
Even more, I still mostly feel like a complete outsider (probably because I build things on top of Squeak instead of working on the core, and possibly also because I work alone and have no position in industry or academia).
I'm so convinced nobody cares about what I do that stopped long ago sending fixes to bug I encounters: I just fix them in my code. For example, the Saucers game I did has a much faster way of handling morphs, down to modified #addMorph: logic. This could be leveraged, if someone looked at the code. But you cannot command interest.
Well, that's how it is. I have the same experience with Csound people, so I'm pretty sure there is nothing specific to Squeak in these matters. The web is a cold place.
Cheers,
Stef
And if I may add: the feeling that "nobody cares" is a permeating one. Not many people give feedback about what they care about (me included).
In my case, I definitely have the feeling that nobody cares about anything I ever did in Squeak during about 15 years now,
I do! :)
which to day includes: a modular Lisp/Scheme implementation, an extension for functional programming, the upgrading of the Prolog implementation, a vast system for musical composition, and a Space Invader reboot.
No, your stuff helped us tremendously when we reported our progress to the SFC back around that time of the dismal 4.5 Release. But I do not always say so. Nor do you (as you admitted, "me included").
So maybe the shortage is of compliements than caring..? Or a shortage of positive thinking?
It's fortunate I did not do this for glory and fame :)
That's when people make their best stuff..
Even more, I still mostly feel like a complete outsider (probably because I build things on top of Squeak instead of working on the core, and possibly also because I work alone and have no position in industry or academia).
I'm so convinced nobody cares about what I do that stopped long ago sending fixes to bug I encounters: I just fix them in my code. For example, the Saucers game I did has a much faster way of handling morphs, down to modified #addMorph: logic. This could be leveraged, if someone looked at the code. But you cannot command interest.
Well, that's how it is. I have the same experience with Csound people, so I'm pretty sure there is nothing specific to Squeak in these matters. The web is a cold place.
On 25-11-2015, at 12:13 AM, Stéphane Rollandin lecteur@zogotounga.net wrote:
So maybe the shortage is of compliements than caring..? Or a shortage of positive thinking?
Shortage of people actually using the stuff :)
Always a problem, and especially so for open source stuff. Almost all open projects end up with a single contributor and a tiny number of users. It’s just life.
For example Stéphane’s Prolog etc - I’d never be likely to even look at it because nothing about Lisp or Prolog interests me, not being a languages geek and having had nasty experiences when I did try to make some sense of them as an impressionable youth.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IPL: Invent Program Lines
On Tue, Nov 24, 2015 at 11:24 AM, Stéphane Rollandin <lecteur@zogotounga.net
wrote:
You say "Nobody cares.
Nobody wants to make Squeak better. The only thing the Squeak community values is compatibility with Alan's demos, and a version of Etoys that nobody uses.". None of those statements are true of my efforts or, as far as I can see, of the significant efforts of the HPI team, or of Tim Rowledge, if Chris Muller or Levente Uzoni, and probably a lot of other folks too.
Squeak is my day to day workhorse. The HOI folks are improving the environment at great velocity. Squeak 5 is ~40% faster than Squeak 4.6. Neither of these things are true because no one cares.
+1
And if I may add: the feeling that "nobody cares" is a permeating one. Not many people give feedback about what they care about (me included).
In my case, I definitely have the feeling that nobody cares about anything I ever did in Squeak during about 15 years now, which to day includes: a modular Lisp/Scheme implementation, an extension for functional programming, the upgrading of the Prolog implementation, a vast system for musical composition, and a Space Invader reboot.
It's fortunate I did not do this for glory and fame :)
Even more, I still mostly feel like a complete outsider (probably because I build things on top of Squeak instead of working on the core, and possibly also because I work alone and have no position in industry or academia).
I'm so convinced nobody cares about what I do that stopped long ago sending fixes to bug I encounters: I just fix them in my code. For example, the Saucers game I did has a much faster way of handling morphs, down to modified #addMorph: logic. This could be leveraged, if someone looked at the code. But you cannot command interest.
I want to look at the code for the Saucers game. The one I downloaded from you page seemed to be in a locked image and I never got around to ask how to get to the code... So if you have it accessible I'm interested.
Best, Kar
Well, that's how it is. I have the same experience with Csound people, so I'm pretty sure there is nothing specific to Squeak in these matters. The web is a cold place.
Cheers,
Stef
On 11/24/15, karl ramberg karlramberg@gmail.com wrote:
On Tue, Nov 24, 2015 at 11:24 AM, Stéphane Rollandin <lecteur@zogotounga.net
wrote:
You say "Nobody cares.
Nobody wants to make Squeak better. The only thing the Squeak community values is compatibility with Alan's demos, and a version of Etoys that nobody uses.". None of those statements are true of my efforts or, as far as I can see, of the significant efforts of the HPI team, or of Tim Rowledge, if Chris Muller or Levente Uzoni, and probably a lot of other folks too.
Squeak is my day to day workhorse. The HOI folks are improving the environment at great velocity. Squeak 5 is ~40% faster than Squeak 4.6. Neither of these things are true because no one cares.
+1
And if I may add: the feeling that "nobody cares" is a permeating one. Not many people give feedback about what they care about (me included).
In my case, I definitely have the feeling that nobody cares about anything I ever did in Squeak during about 15 years now, which to day includes: a modular Lisp/Scheme implementation, an extension for functional programming, the upgrading of the Prolog implementation, a vast system for musical composition, and a Space Invader reboot.
It's fortunate I did not do this for glory and fame :)
Even more, I still mostly feel like a complete outsider (probably because I build things on top of Squeak instead of working on the core, and possibly also because I work alone and have no position in industry or academia).
I'm so convinced nobody cares about what I do that stopped long ago sending fixes to bug I encounters: I just fix them in my code. For example, the Saucers game I did has a much faster way of handling morphs, down to modified #addMorph: logic. This could be leveraged, if someone looked at the code. But you cannot command interest.
I want to look at the code for the Saucers game. The one I downloaded from you page seemed to be in a locked image and I never got around to ask how to get to the code... So if you have it accessible I'm interested.
Best, Kar
Hello Stephane Is it possible to make it available on SqueakMap?
--Hannes
Well, that's how it is. I have the same experience with Csound people, so I'm pretty sure there is nothing specific to Squeak in these matters. The web is a cold place.
Cheers,
Stef
I want to look at the code for the Saucers game. The one I downloaded from you page seemed to be in a locked image and I never got around to ask how to get to the code... So if you have it accessible I'm interested.
Your can get the code from a link at the bottom of the page. Here's the link anyway: http://www.zogotounga.net/comp/squeak/Saucers1.6.sar
Note that this is for 4.5
Best,
Stef
Ah, thanks :-)
Best, Karl
On Wed, Nov 25, 2015 at 9:17 AM, Stéphane Rollandin lecteur@zogotounga.net wrote:
I want to look at the code for the Saucers game. The one I downloaded
from you page seemed to be in a locked image and I never got around to ask how to get to the code... So if you have it accessible I'm interested.
Your can get the code from a link at the bottom of the page. Here's the link anyway: http://www.zogotounga.net/comp/squeak/Saucers1.6.sar
Note that this is for 4.5
Best,
Stef
On Tue, Nov 24, 2015 at 11:24 AM, Stéphane Rollandin <lecteur@zogotounga.net
wrote:
You say "Nobody cares.
Nobody wants to make Squeak better. The only thing the Squeak community values is compatibility with Alan's demos, and a version of Etoys that nobody uses.". None of those statements are true of my efforts or, as far as I can see, of the significant efforts of the HPI team, or of Tim Rowledge, if Chris Muller or Levente Uzoni, and probably a lot of other folks too.
Squeak is my day to day workhorse. The HOI folks are improving the environment at great velocity. Squeak 5 is ~40% faster than Squeak 4.6. Neither of these things are true because no one cares.
+1
And if I may add: the feeling that "nobody cares" is a permeating one. Not many people give feedback about what they care about (me included).
In my case, I definitely have the feeling that nobody cares about anything I ever did in Squeak during about 15 years now, which to day includes: a modular Lisp/Scheme implementation, an extension for functional programming, the upgrading of the Prolog implementation, a vast system for musical composition, and a Space Invader reboot.
It's fortunate I did not do this for glory and fame :)
Even more, I still mostly feel like a complete outsider (probably because I build things on top of Squeak instead of working on the core, and possibly also because I work alone and have no position in industry or academia).
I'm so convinced nobody cares about what I do that stopped long ago sending fixes to bug I encounters: I just fix them in my code. For example, the Saucers game I did has a much faster way of handling morphs, down to modified #addMorph: logic. This could be leveraged, if someone looked at the code. But you cannot command interest.
Are you not interested becoming a core developer so you can contribute directly to trunk ? I would guess you are qualified, based on the stuff you have produced...
Best, Karl
Well, that's how it is. I have the same experience with Csound people, so I'm pretty sure there is nothing specific to Squeak in these matters. The web is a cold place.
Cheers,
Stef
On Fri, Nov 27, 2015 at 10:24:12AM +0100, St??phane Rollandin wrote:
On Thu, Nov 26, 2015 at 01:04:39PM +0100, karl ramberg wrote:
On Tue, Nov 24, 2015 at 11:24 AM, St??phane Rollandin <lecteur@zogotounga.net wrote:
I'm so convinced nobody cares about what I do that stopped long ago sending fixes to bug I encounters: I just fix them in my code. For example, the Saucers game I did has a much faster way of handling morphs, down to modified #addMorph: logic. This could be leveraged, if someone looked at the code. But you cannot command interest.
Are you not interested becoming a core developer so you can contribute directly to trunk ? I would guess you are qualified, based on the stuff you have produced...
Why not ?
By which I mean: "yes, I'd be honored". Which is more proper I guess...
Hi Stef,
It would be great to have you contributing to trunk. Can I suggest that you start by creating an account for yourself on source.squeak.org, and maybe commit a few of your fixes to the inbox? You have done some remarkable work with Squeak and muO, and it would be really nice to see you involved as a core developer also.
Dave
On Sun, Nov 29, 2015 at 11:59 AM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Nov 27, 2015 at 10:24:12AM +0100, St??phane Rollandin wrote:
On Thu, Nov 26, 2015 at 01:04:39PM +0100, karl ramberg wrote:
On Tue, Nov 24, 2015 at 11:24 AM, St??phane Rollandin <
lecteur@zogotounga.net wrote:
I'm so convinced nobody cares about what I do that stopped long ago sending fixes to bug I encounters: I just fix them in my code. For
example,
the Saucers game I did has a much faster way of handling morphs,
down to
modified #addMorph: logic. This could be leveraged, if someone
looked at
the code. But you cannot command interest.
Are you not interested becoming a core developer so you can contribute directly to trunk ? I would guess you are qualified, based on the stuff you have
produced...
Why not ?
By which I mean: "yes, I'd be honored". Which is more proper I guess...
Hi Stef,
It would be great to have you contributing to trunk. Can I suggest that you start by creating an account for yourself on source.squeak.org, and maybe commit a few of your fixes to the inbox? You have done some remarkable work with Squeak and muO, and it would be really nice to see you involved as a core developer also.
+1 !!
Dave
It would be great to have you contributing to trunk. Can I suggest that you start by creating an account for yourself on source.squeak.org, and maybe commit a few of your fixes to the inbox?
Ok, I now have an account at source.squeak.org (initials spfa)
Stef
squeak-dev@lists.squeakfoundation.org