Hi
In the context of the Kernel Cleaning Project we are facing problems related to change management. While the idea and the tool provided by diego are cool they do not scale up well. Publishing one change one by one is not fast enough. Then when you have multiple versions of the change changeset, SWiki only shows the last one so this is nearly impossible to roll-back to a previous version (I mean I do not want to be forced to browse the upload directory and guess, I want a real way of managing a version).
So before hacking yet another solution we wanted to know how others are doing. ideally we would like to have a place where all the changes can be versioned at once so we thought of using cvs, but we want that other can contribute so is source forge easy to use, adequate for this project? For supporting external reviewing process we could generate a web page from the files in the cvs. I think that we should have real tools if we want to move fast.
Avi I understood that you used sourceforge for storing SeaSide code. Could you tell us more?
Stef
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
On Sun, 30 Mar 2003, Stephane Ducasse wrote:
Avi I understood that you used sourceforge for storing SeaSide code. Could you tell us more?
I use sourceforge basically just as a public CVS repository. The files managed by CVS are DVS packages, which makes it easy to sync up with other people that are working on it - cvs update followed by a DVS fileIn and your image is up to date. The docs at http://beta4.com/squeak/aubergines/docs/dvs.html describe this process a little more. The DVS fileout format is consistent enough that merges of concurrent modifications don't often have conflicts, and the conflicts that do happen are easy to resolve, so although it ain't ENVY it's worked out pretty well.
However, I'm not sure how well this would work for kernel hacking - it seems like the changes you're making might well involve tricky, order-dependent modifications rather than simple edits of class or method definitions. Hopefully you can get away with having most of your source files being DVS files, with one or two hand-edited changesets that you'll have to take a little more care to merge and so on.
If you need help getting this set up, I'm happy to answer more questions...
Avi
On Sun, Mar 30, 2003 at 11:13:29AM +0200, Stephane Ducasse wrote:
ideally we would like to have a place where all the changes can be versioned at once so we thought of using cvs, but we want that other can contribute so is source forge easy to use, adequate for this project? For supporting external reviewing process we could generate a web page from the files in the cvs. I think that we should have real tools if we want to move fast.
I don't yet know anything about source management in Squeak (not sure what this DVS thing is yet), but some complex projects, like the Linux kernel, are hosted by BitMover (using BitKeeper) rather than Sourceforge. Partly this is because of BitKeeper's superior merging and other facilities (over CVS).
http://www.bitkeeper.com/Hosted.html
Jen
Hi all!
jennyw jennyw@dangerousideas.com wrote:
On Sun, Mar 30, 2003 at 11:13:29AM +0200, Stephane Ducasse wrote:
ideally we would like to have a place where all the changes can be versioned at once so we thought of using cvs, but we want that other can contribute so is source forge easy to use, adequate for this project? For supporting external reviewing process we could generate a web page from the files in the cvs. I think that we should have real tools if we want to move fast.
I don't yet know anything about source management in Squeak (not sure what this DVS thing is yet), but some complex projects, like the Linux kernel, are hosted by BitMover (using BitKeeper) rather than Sourceforge. Partly this is because of BitKeeper's superior merging and other facilities (over CVS).
Yep. Well, Squeak doesn't "play" that well with filebased source management tools. In Squeak we now have DVS which essentially is a "smart" file-in/file-out mechanism which makes it at least practical to use CVS or any other filebased source management tool - but it is still not a perfect fit and will probably never be.
DVS can also be used "by itself" to produce fileouts that can contain both classes and so called "loose methods" and does the "right thing" when a new version is filed-in on top of an old.
So in short - in Squeak you definitely should look at DVS. We all should. :-) As a matter of fact I am moving over to DVS to manage the SqueakMap code itself.
There is also something called Monticello: http://map2.squeakfoundation.org/sm/packagebyname/monticello
Which Avi and the guys started implementing at last OOPSLA. I hope they pick it up again! :-)
regards, Göran
On Mon, Mar 31, 2003 at 09:30:49AM +0100, goran.hultgren@bluefish.se wrote:
Yep. Well, Squeak doesn't "play" that well with filebased source management tools. In Squeak we now have DVS which essentially is a "smart" file-in/file-out mechanism which makes it at least practical to use CVS or any other filebased source management tool - but it is still not a perfect fit and will probably never be.
This isn't so much a suggestion as a potentially dumb question, but ...
If there was an option to filed-out in a directory structure instead of a single file, such as:
category/classname/classdef category/classname/methodcategory/method1 category/classname/methodcategory/method2 etc.
And filed-in in the same manner, wouldn't source control systems be able to handle that better? I know this probably wouldn't work well in CVS (since it doesn't support renames), but with Subversion (successor to CVS), BitKeeper, or a number of more recent CMS systems, it might work better. Or not?
Jen
On Monday 31 March 2003 07:26 am, jennyw wrote:
If there was an option to filed-out in a directory structure instead of a single file, such as:
category/classname/classdef category/classname/methodcategory/method1 category/classname/methodcategory/method2 etc.
And filed-in in the same manner, wouldn't source control systems be able to handle that better? I know this probably wouldn't work well in CVS (since it doesn't support renames), but with Subversion (successor to CVS), BitKeeper, or a number of more recent CMS systems, it might work better. Or not?
This is/was done by at least one such system (I forget the name, though).
DVS does things very simply: it alphabetizes the names of the methods on output. So it diffs pretty well.
On Mon, 31 Mar 2003, Ned Konz wrote:
category/classname/classdef category/classname/methodcategory/method1 category/classname/methodcategory/method2 etc.
And filed-in in the same manner, wouldn't source control systems be able to handle that better? I know this probably wouldn't work well in CVS (since it doesn't support renames), but with Subversion (successor to CVS), BitKeeper, or a number of more recent CMS systems, it might work better. Or not?
This is/was done by at least one such system (I forget the name, though).
CVSTProj, although it used one file per class, not one per method. What I dislike about this approach is that it adds a fair amount of overhead to adding/removing/renaming a class - in at least Subversion and CVS (I've never used BitKeeper), you have to manually notify the versioning system whenever you do one of those things. The only real advantage you get in return is that it's easier to browse the repository - but who wants to look at filed out code anyway? Better to browse it in the image.
Using one file per method certainly eliminates all spurious conflicts, and at one point I did have a file out mode for DVS that did this, but of course this becomes completely infeasible if you have to manually do "cvs add" and "cvs remove" all the time. If anyone knows of a simple tool for CVS that will automatically sync the repository with a working copy in that way, let me know...
As I said earlier, however, the current file out format DVS uses has been tweaked to the point that it's rare to see a conflict unless you radically restructure the class hierarchy (and even then you only get conflicts in the class def'n section of the file).
Avi
Avi Bryant avi@beta4.com wrote: [SNIP]
Using one file per method certainly eliminates all spurious conflicts, and at one point I did have a file out mode for DVS that did this, but of course this becomes completely infeasible if you have to manually do "cvs add" and "cvs remove" all the time. If anyone knows of a simple tool for CVS that will automatically sync the repository with a working copy in that way, let me know...
Well, if I ever get time/lust to finish sqcvs then it would be trivial to do this. :-)
Note: Sqcvs implements most of the CVS pserver protocol but the "killer" is the SSH support. I haven't looked into how that can be done.
regards, Göran
On Mon, 31 Mar 2003 goran.hultgren@bluefish.se wrote:
Note: Sqcvs implements most of the CVS pserver protocol but the "killer" is the SSH support. I haven't looked into how that can be done.
Exactly... without SSH support it's not much use to me, sadly. Now I know CVS uses rsh over SSH, but I'm not totally clear on what that entails. Could something be done with OSProcess?
Avi
My understanding is that CVS uses ssh (and scp?) (the command line tools I mean) to provide this service and doesn't have any knowledge of the ssh protocols itself. Couldn't Sqcvs do the same? At least until such time as someone finds it worth their while to provide full protocol support in Squeak or as a plugin?
Ken
On Mon, 2003-03-31 at 14:49, Avi Bryant wrote:
On Mon, 31 Mar 2003 goran.hultgren@bluefish.se wrote:
Note: Sqcvs implements most of the CVS pserver protocol but the "killer" is the SSH support. I haven't looked into how that can be done.
Exactly... without SSH support it's not much use to me, sadly. Now I know CVS uses rsh over SSH, but I'm not totally clear on what that entails. Could something be done with OSProcess?
Avi
Hi all!
Ken Causey ken@kencausey.com wrote:
My understanding is that CVS uses ssh (and scp?) (the command line tools I mean) to provide this service and doesn't have any knowledge of the ssh protocols itself. Couldn't Sqcvs do the same? At least until such time as someone finds it worth their while to provide full protocol support in Squeak or as a plugin?
Well, AFAIK the normal CVS executable uses RSH or SSH to connect to a server (not scp). I am no Unix guru but I guess it starts a cvs executable on the server side and then simply uses stdin/stdout through the shell to communicate with that "twin".
I have no idea if the communication from that point on is the same as the "pserver" protocol which is documented and that I have implemented. If it *is* then it should be simple to do the same using OSProcess, BUT... then the point of sqcvs sortof fades. Sqcvs is a "Squeak pure" implementation and enables use of CVS from any Squeak enabled platform that has networking in the VM - it already works fine if you can use unencrypted pserver access.
Anyway, I should look up how that works...
regards, Göran
On Mon, 31 Mar 2003 23:25:48 +0100, goran.hultgren@bluefish.se wrote:
Hi all!
Ken Causey ken@kencausey.com wrote:
My understanding is that CVS uses ssh (and scp?) (the command line tools I mean) to provide this service and doesn't have any knowledge of the ssh protocols itself. Couldn't Sqcvs do the same? At least until such time as someone finds it worth their while to provide full protocol support in Squeak or as a plugin?
Well, AFAIK the normal CVS executable uses RSH or SSH to connect to a server (not scp). I am no Unix guru but I guess it starts a cvs executable on the server side and then simply uses stdin/stdout through the shell to communicate with that "twin".
Ok, so RSH and SSH (IIRC) both connect to sshd which does authentication and launches something. SSH is hardwired to default to the remote default shell, RSH takes the something from the command line. Via SSH it would be trivial to do port redirection which would then allow the local CVS to talk "pserver" to the remote one. Running a remote CVS instance and communicating with it over stdio sounds like a more RSH kind of thing, but that is easy enough to accomplish with SSH also.
I have no idea if the communication from that point on is the same as the "pserver" protocol which is documented and that I have implemented. If it *is* then it should be simple to do the same using OSProcess, BUT... then the point of sqcvs sortof fades. Sqcvs is a "Squeak pure" implementation and enables use of CVS from any Squeak enabled platform that has networking in the VM - it already works fine if you can use unencrypted pserver access.
Anyway, I should look up how that works...
regards, Göran
-andrew
On Mon, 31 Mar 2003, Andrew Berg wrote:
Ok, so RSH and SSH (IIRC) both connect to sshd which does authentication and launches something. SSH is hardwired to default to the remote default shell, RSH takes the something from the command line. Via SSH it would be trivial to do port redirection which would then allow the local CVS to talk "pserver" to the remote one. Running a remote CVS instance and communicating with it over stdio sounds like a more RSH kind of thing, but that is easy enough to accomplish with SSH also.
The point here is not to find some arbitrary way of tunneling CVS traffic over SSH, but to be compatible with the way, eg, sourceforge's CVS over SSH works. I don't know the details, but it's whatever the CVS client does when you give it -d:ext:user@host:/path as the cvs root, and when CVS_RSH is set to "ssh". My assumption is that this is, as you say, launching a remote cvs client and communicating over stdio, but what this communucation looks like I have no idea. I'm pretty sure it's not the same as the pserver protocol.
Anyone better informed, or should I look it up? Julian?
Avi
Avi Bryant avi@beta4.com wrote:
On Mon, 31 Mar 2003, Andrew Berg wrote:
Ok, so RSH and SSH (IIRC) both connect to sshd which does authentication and launches something. SSH is hardwired to default to the remote default shell, RSH takes the something from the command line. Via SSH it would be trivial to do port redirection which would then allow the local CVS to talk "pserver" to the remote one. Running a remote CVS instance and communicating with it over stdio sounds like a more RSH kind of thing, but that is easy enough to accomplish with SSH also.
The point here is not to find some arbitrary way of tunneling CVS traffic over SSH, but to be compatible with the way, eg, sourceforge's CVS over SSH works. I don't know the details, but it's whatever the CVS client does when you give it -d:ext:user@host:/path as the cvs root, and when CVS_RSH is set to "ssh". My assumption is that this is, as you say, launching a remote cvs client and communicating over stdio, but what this communucation looks like I have no idea. I'm pretty sure it's not the same as the pserver protocol.
Anyone better informed, or should I look it up? Julian?
I looked it up some more and came to these conclusions:
1. When using RSH/SSH the client does a normal login and then does "bash -c cvs server" - it starts the cvs executable with the argument "server" on the server side. Then I assume it is simply relying on stdin/stdout.
2. It is indeed the same protocol as the pserver protocol apart from not starting with the "I LOVE YOU" authentication handshake. I haven't verified this - quite easy to do, but I read in the docs and it sure sounds like it. (Yiha)
3. SF handles both SSH1 and SSH2.
So, indeed - with using OSProcess and an external ssh executable we should quite easily get sqcvs working over SSH. It would of course be even cooler if someone could whip up an openssl/ssh plugin... :-)
regards, Göran
On Tue, 1 Apr 2003 goran.hultgren@bluefish.se wrote:
So, indeed - with using OSProcess and an external ssh executable we should quite easily get sqcvs working over SSH. It would of course be even cooler if someone could whip up an openssl/ssh plugin... :-)
Except for the issue of the missing handshake, then, we could presumably set up something like netcat to listen on a port and pipe any connections through to ssh. That way we don't need any special plugins and sqcvs can just pretend it's using a pserver on localhost.
Cool.
Avi
The Crypto package at SqueakMap should be able to deal with plenty of this - gee I wish we had our own SSH in Squeak...
Any takers?!
Cheers, - Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Avi Bryant Sent: Monday, March 31, 2003 10:50 PM To: The general-purpose Squeak developers list Subject: Re: Ideas, Experiences required for changes managements
On Mon, 31 Mar 2003 goran.hultgren@bluefish.se wrote:
Note: Sqcvs implements most of the CVS pserver protocol but
the "killer"
is the SSH support. I haven't looked into how that can be done.
Exactly... without SSH support it's not much use to me, sadly. Now I know CVS uses rsh over SSH, but I'm not totally clear on what that entails. Could something be done with OSProcess?
Avi
On Monday 31 March 2003 01:16 pm, Andreas Raab wrote:
The Crypto package at SqueakMap should be able to deal with plenty of this - gee I wish we had our own SSH in Squeak...
Any takers?!
I was just talking (Saturday) with a certain member of this list who works with crypto stuff and said that he had been considering doing SSL in Squeak.
Perhaps he'll volunteer (hint hint)...
Um, yeah. I might even point out who that person is, if those people who are responsible for the Crypto stuff already in Squeak would step forward and help explain to me just what is already there to work with. Him! I mean explain to him!
-andrew
On Mon, 31 Mar 2003 13:20:29 -0800, Ned Konz ned@bike-nomad.com wrote:
On Monday 31 March 2003 01:16 pm, Andreas Raab wrote:
The Crypto package at SqueakMap should be able to deal with plenty of this - gee I wish we had our own SSH in Squeak...
Any takers?!
I was just talking (Saturday) with a certain member of this list who works with crypto stuff and said that he had been considering doing SSL in Squeak.
Perhaps he'll volunteer (hint hint)...
The deeper issue is that Class structure is typically an organization scheme that is orthogonal to a functional/utilitarian scheme.
From a usage/loading point of view, one wishes to manage source code based on the function points that it introduces into the system, rather than *all* of the class structure of *all* of the affected classes.
For example, a well defined framework will commonly extend the behavior of base classes like Object or Collection. Thus, for the purposes of managing functional chunks of code, one almost certainly needs to store and access code based upon a functional capability point of view, rather than a runtime hierarchical structure point of view.
It was for these reasons that SWT used build scripts to load functional elements of the image and used the ginsu module mechanism to handle modules that could contain "loose methods" that extended the behavior of existing classes. It further ensured that each definitional element of code was uniquely defined in the image. This is required to avoid problems of one module "stepping on" definitions from previously loaded modules.
Cheers,
:-}> John Sarkela
On Monday, March 31, 2003, at 07:26 AM, jennyw wrote:
On Mon, Mar 31, 2003 at 09:30:49AM +0100, goran.hultgren@bluefish.se wrote:
Yep. Well, Squeak doesn't "play" that well with filebased source management tools. In Squeak we now have DVS which essentially is a "smart" file-in/file-out mechanism which makes it at least practical to use CVS or any other filebased source management tool - but it is still not a perfect fit and will probably never be.
This isn't so much a suggestion as a potentially dumb question, but ...
If there was an option to filed-out in a directory structure instead of a single file, such as:
category/classname/classdef category/classname/methodcategory/method1 category/classname/methodcategory/method2 etc.
And filed-in in the same manner, wouldn't source control systems be able to handle that better? I know this probably wouldn't work well in CVS (since it doesn't support renames), but with Subversion (successor to CVS), BitKeeper, or a number of more recent CMS systems, it might work better. Or not?
Jen
Hi john
I would like to have your point of view on our work: ClassBox. Modules adapted to class extensions. http://scgwiki.iam.unibe.ch:8080/SCG/559
Note that we use modules (with the idea of scope) while you use module for source code without scoping rules. Soon we hope to have a VM classBox aware :)
On Monday, March 31, 2003, at 06:11 PM, John W.Sarkela wrote:
The deeper issue is that Class structure is typically an organization scheme that is orthogonal to a functional/utilitarian scheme.
From a usage/loading point of view, one wishes to manage source code based on the function points that it introduces into the system, rather than *all* of the class structure of *all* of the affected classes.
For example, a well defined framework will commonly extend the behavior of base classes like Object or Collection. Thus, for the purposes of managing functional chunks of code, one almost certainly needs to store and access code based upon a functional capability point of view, rather than a runtime hierarchical structure point of view.
It was for these reasons that SWT used build scripts to load functional elements of the image and used the ginsu module mechanism to handle modules that could contain "loose methods" that extended the behavior of existing classes. It further ensured that each definitional element of code was uniquely defined in the image. This is required to avoid problems of one module "stepping on" definitions from previously loaded modules.
Cheers,
:-}> John Sarkela
On Monday, March 31, 2003, at 07:26 AM, jennyw wrote:
On Mon, Mar 31, 2003 at 09:30:49AM +0100, goran.hultgren@bluefish.se wrote:
Yep. Well, Squeak doesn't "play" that well with filebased source management tools. In Squeak we now have DVS which essentially is a "smart" file-in/file-out mechanism which makes it at least practical to use CVS or any other filebased source management tool - but it is still not a perfect fit and will probably never be.
This isn't so much a suggestion as a potentially dumb question, but ...
If there was an option to filed-out in a directory structure instead of a single file, such as:
category/classname/classdef category/classname/methodcategory/method1 category/classname/methodcategory/method2 etc.
And filed-in in the same manner, wouldn't source control systems be able to handle that better? I know this probably wouldn't work well in CVS (since it doesn't support renames), but with Subversion (successor to CVS), BitKeeper, or a number of more recent CMS systems, it might work better. Or not?
Jen
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
Hi All,
I've put together a squeak tutorial & documentation for use by teachers in my area (work in progress), as a way of evaluating squeak and finding some good hints to improve novice user interaction, which will hopefully allow this group to make more sophisticated examples as curricula aids.
I would like to add some predefined scripting tiles to the geometry category or in the misc category DoMenuItem.
I tried to use Player Protocol tiles, but I couldn't get them to work. How do they work or is this still in the prototpye stage. I had expected it to work similiar to creating instance variables, or at least create a new scripting tile.
Thanks I'm running Squeak 3.4 image for Windows & MacOSX =============================================================================== Cheryl D. Seals Virginia Polytechnic Institute & State University
When you reach with all you have, nothing is out of range.
McBryde Hall 565 Office 231-3986 102 Lab 231-2756 Home 951-4697
On Monday 31 March 2003 08:40 am, Cheryl Denise Seals wrote:
I tried to use Player Protocol tiles, but I couldn't get them to work. How do they work or is this still in the prototpye stage. I had expected it to work similiar to creating instance variables, or at least create a new scripting tile.
That sounds interesting. How do you get to Player Protocol tiles?
I've found about 3 ways to bring up tiles
Inspect Morph -> Player Protocol tile
On on Morph bring up it's Halo -> Select Debug -> Player Protocol (tiles)
-Cheryl
On Mon, 31 Mar 2003, Ned Konz wrote:
On Monday 31 March 2003 08:40 am, Cheryl Denise Seals wrote:
I tried to use Player Protocol tiles, but I couldn't get them to work. How do they work or is this still in the prototpye stage. I had expected it to work similiar to creating instance variables, or at least create a new scripting tile.
That sounds interesting. How do you get to Player Protocol tiles?
-- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE
On Monday 31 March 2003 09:59 am, Cheryl Denise Seals wrote:
I've found about 3 ways to bring up tiles
Inspect Morph -> Player Protocol tile
On on Morph bring up it's Halo -> Select Debug -> Player Protocol (tiles)
-Cheryl
Ah. Do you have the preference "universalTiles" selected in your project? (note that if you do any scripting in a project using universal tiles, you can't get back to classic tiles in that project).
As I understand it, Universal Tiles are/were an experimental alternative to the Classic Tiles and the straight Smalltalk source code. But I don't know that they've been kept up to date (for instance, I can't add a parameter to a script in the uniTiles mode).
My conclusion has been that if you want to do scripting you're better off using the Classic tiles and switching to text mode when necessary. Now that scripts can take a parameter, user-written scripts can be (almost?) first-class citizens.
Thanks Ned,
I generally use classic tiles (since I like to add parameters) and switch to text mode, which is great for my use but I want to add tiles to categories to add a few methods that I've found useful for novices after doing a small study with about a dozen teachers... Cheryl
On Mon, 31 Mar 2003, Ned Konz wrote:
On Monday 31 March 2003 09:59 am, Cheryl Denise Seals wrote:
I've found about 3 ways to bring up tiles
Inspect Morph -> Player Protocol tile
On on Morph bring up it's Halo -> Select Debug -> Player Protocol (tiles)
-Cheryl
Ah. Do you have the preference "universalTiles" selected in your project? (note that if you do any scripting in a project using universal tiles, you can't get back to classic tiles in that project).
As I understand it, Universal Tiles are/were an experimental alternative to the Classic Tiles and the straight Smalltalk source code. But I don't know that they've been kept up to date (for instance, I can't add a parameter to a script in the uniTiles mode).
My conclusion has been that if you want to do scripting you're better off using the Classic tiles and switching to text mode when necessary. Now that scripts can take a parameter, user-written scripts can be (almost?) first-class citizens.
-- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE
On Monday 31 March 2003 10:31 am, Cheryl Denise Seals wrote:
Thanks Ned,
I generally use classic tiles (since I like to add parameters) and switch to text mode, which is great for my use but I want to add tiles to categories to add a few methods that I've found useful for novices after doing a small study with about a dozen teachers... Cheryl
I've only been able to do this by changing the protocols in normal Smalltalk code.
For an example of how to do this, look at my RCXMorph change set, which is at http://minnow.cc.gatech.edu/squeak/uploads/2412/RCXMorph-nk.1.cs
This may require other change sets from http://minnow.cc.gatech.edu/squeak/2412 to operate.
Basically, the formula is:
* define some new methods in Player to do what you want. These may talk to the costume (the Morph)
* define methods in the appropriate Morph class(es) if necessary to support those Player methods
* define additionsToViewerCategories in your Morph class
* run "Vocabulary initialize"
Bob Arning described this back in 2001 http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-April/019421.htm...
squeak-dev@lists.squeakfoundation.org