4 Anthony runtime enhancements (split in two - fixes and closures)
There are two packages: ContextCleanupPlus-ajh.zip and ClosureCs-ajh.zip. ContextCleanupPlus cleans up contexts, exceptions, and related classes. You can think of it as part of KCP. I have used it for about a year in my image, and after a few minor updates here and there, things are running very smoothly. I would encourage people to test it just by loading it and going about their normal business. Normal operation will test its low-level changes.
What about the SmaCC license issue?
ContextCleanupPlus does not depend on SmaCC, only ClosureCs does which we can be considered after ContextCleanupPlus. ClosureCs depends on ContextCleanupPlus but not vice versa.
Anthony, for some reason includes in this package myriad changes to existing classes.
Of course, cleanup involves changes to existing classes. If you're talking about the additional protocol I've added to general classes, below are the detailed explanations. I think you will agree they a reasonable, and truly belong as class extensions rather than in user classes where they would be tedious and less reusable. I would not be afraid to add these new protocols especially since they can't affect any existing code. Note, many of the users are in ClosureCs and not in ContextCleanupPlus itself.
Object>>literalEqual: - Do the receiver and argument represent the same literal. Note, two objects can be = but not literalEqual: as in 'anthony' = #anthony, but ('anthony' literalEqual: #anthony) not.
Boolean>>asBit - Return 1 for true, 0 for false.
Class>>becomeClass: otherClass - Become forward the other class and fix up the global dictionary and system organization as well.
Collection>>collectArray: - Same as collect: except always return an array.
CompiledMethod>>headerDescription - Prints out all the components of the header (numArgs, numLiterals, etc) in a readable format.
LargePositiveInteger>>as31BitSmallInt - Keep my 31 bits the same but put them in a SmallInt.
Number>>extend: - Like #to: except designate the length instead of the last.
OrderedCollection>>bottom,top,pop,push,etc. - stack protocol.
SequenceableCollection>>allButFirstDo:,allButLastDo:,atLast:,atLast:put: ,copyGrowBy:copyWithFirst:,detectIndex:,reverseDetect:,slide:by:,with:wi thIndexDo: - Additional methods that are similar to other methods that already exist and should be part of the protocol because they are useful. I bet many of these have been needed in the past but were coded out the long way in the user.
PositionableStream>>back,current,previous,do:,at:,includes: - Added helpful methods for stepping back and looking into the collection itself.
WriteStream>>insert:,removeNext: - Additional manipulation beside appending.
(The last two additions may not seam appropriate for streams if you look at a stream like a pipe. So I could be persuaded to move these to a new class. But the rest I believe are very appropriate for their specified classes.)
Cheers, Anthony
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
On Sat, Jun 21, 2003 at 03:07:41PM -0700, Anthony Hannan wrote:
Of course, cleanup involves changes to existing classes. If you're talking about the additional protocol I've added to general classes, below are the detailed explanations. I think you will agree they a reasonable, and truly belong as class extensions rather than in user classes where they would be tedious and less reusable. I would not be afraid to add these new protocols especially since they can't affect any existing code. Note, many of the users are in ClosureCs and not in ContextCleanupPlus itself.
I vote for adding this. My personal development image has this loaded (last 3 Months) with no problems.
Marcus
Hi anthony
There are two packages: ContextCleanupPlus-ajh.zip and ClosureCs-ajh.zip. ContextCleanupPlus cleans up contexts, exceptions, and related classes. You can think of it as part of KCP. I have used it for about a year in my image, and after a few minor updates here and there, things are running very smoothly. I would encourage people to test it just by loading it and going about their normal business. Normal operation will test its low-level changes.
What about the SmaCC license issue?
ContextCleanupPlus does not depend on SmaCC, only ClosureCs does which we can be considered after ContextCleanupPlus. ClosureCs depends on ContextCleanupPlus but not vice versa.
But ClosuresCs does not depend on SmaCC. It has been generated using SmaCC which is different. I do not need to include bison because I use a parser developed with it. Or there is something wrong. Can you let me know if I'm wrong? Stef
Anthony, for some reason includes in this package myriad changes to existing classes.
Of course, cleanup involves changes to existing classes. If you're talking about the additional protocol I've added to general classes, below are the detailed explanations.
Have you thought of using DVS to mark the extensions that are really linked to Closures, from the ones that should be put into the image? Because this would be nice to follow this practice because this will help us when we will have packages.
I think you will agree they a reasonable, and truly belong as class extensions rather than in user classes where they would be tedious and less reusable. I would not be afraid to add these new protocols especially since they can't affect any existing code. Note, many of the users are in ClosureCs and not in ContextCleanupPlus itself.
Object>>literalEqual: - Do the receiver and argument represent the same literal. Note, two objects can be = but not literalEqual: as in 'anthony' = #anthony, but ('anthony' literalEqual: #anthony) not.
Boolean>>asBit - Return 1 for true, 0 for false.
Class>>becomeClass: otherClass - Become forward the other class and fix up the global dictionary and system organization as well.
Collection>>collectArray: - Same as collect: except always return an array.
This one looks quite strange to me. You are impacting more than 140 classes!!
CompiledMethod>>headerDescription - Prints out all the components of the header (numArgs, numLiterals, etc) in a readable format.
Good, needed
LargePositiveInteger>>as31BitSmallInt - Keep my 31 bits the same but put them in a SmallInt.
Number>>extend: - Like #to: except designate the length instead of the last.
OrderedCollection>>bottom,top,pop,push,etc. - stack protocol.
Sorry but this stuff should not be there. Implement a Stack class. Sure an orderedCollection can be used as a stack but....
Anybody else point of view?
SequenceableCollection>>allButFirstDo:,allButLastDo:,atLast:,atLast:put : ,copyGrowBy:copyWithFirst:,detectIndex:,reverseDetect:,slide:by:,with:w i thIndexDo: - Additional methods that are similar to other methods that already exist and should be part of the protocol because they are useful. I bet many of these have been needed in the past but were coded out the long way in the user.
PositionableStream>>back,current,previous,do:,at:,includes: - Added helpful methods for stepping back and looking into the collection itself.
WriteStream>>insert:,removeNext: - Additional manipulation beside appending.
(The last two additions may not seam appropriate for streams if you look at a stream like a pipe. So I could be persuaded to move these to a new class. But the rest I believe are very appropriate for their specified classes.)
Cheers, Anthony
Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Hi guys!
Stephane Ducasse ducasse@iam.unibe.ch wrote: [SNIP]
But ClosuresCs does not depend on SmaCC. It has been generated using SmaCC which is different. I do not need to include bison because I use a parser developed with it. Or there is something wrong. Can you let me know if I'm wrong? Stef
The problem with the above reasoning is that it assumes people only want/need to *use* the Compiler and not *change* it.
Before we had a Compiler that was written in Squeak - and thus also modifiable in Squeak using Squeak itself (all under Squeak-L).
If we choose to move over to a SmaCC generated Compiler (which of course would be technically great) we will have a Compiler that can not be modified using only Squeak itself. Unless SmaCC gets included into official Squeak of course - which it could if it came under Squeak-L, which it doesn't.
People may think this is a "small" issue. Personally I think it is a quite important issue. Every other little piece of the Squeak image is modifiable by Squeak itself. The VM too - though not to the full extent (you need a C compiler etc). This would suddenly make the Squeak image "non self hosted".
Hopefully we can though still somehow get SmaCC under Squeak-L and the problem would be solved.
Then Stephane wrote comments on the other extensions and I agree to the comments (but I haven't looked at the code) made. Just adding a little method in base classes here and there may seem "innocent" enough but they add up and eventually turns into a mess.
regards, Göran
PS. People may find it tempting to simply drop the "golden rule" sofar that everything in official Squeak should be under Squeak-L. That would probably (as Andrew Greenberg has pointed out multiple times) lead to a legal minefield and be very bad for Squeak.
Hi Göran,
If we choose to move over to a SmaCC generated Compiler (which of course would be technically great) we will have a Compiler that can not be modified using only Squeak itself. Unless SmaCC gets included into official Squeak of course - which it could if it came under Squeak-L, which it doesn't.
How so ? SmallCC can sit anywhere in the world, (even on SqMap ;-) Any one needs to use it, just load it, use it, generate the new compiler, save the new compiler package (everything is a package, right ? ) just don't save the image (what is an image, anyway ;-).
Assuming that it must be in the image, which one ? minimal ? basic ? or kitchen sink ?
Did I miss anything ? Were there even arguments to the effects that SqMap package is still useful when it's not in the image ;-)
People may think this is a "small" issue. Personally I think it is a quite important issue. Every other little piece of the Squeak image is modifiable by Squeak itself.
Luckily that Squeak does have an editor,
The VM too - though not to the full extent (you need a C compiler etc).
otherwise one needs Emacs as well. (or Notepad ;-)
This would suddenly make the Squeak image "non self hosted".
Let Squidders tell the world what 'self hosting' really means ;-)
Cheers,
PhiHo.
----- Original Message ----- From: goran.krampe@bluefish.se To: "Discussing the Squeak Foundation" squeakfoundation@lists.squeakfoundation.org Cc: ajh18@cornell.edu; "Roel Wuyts" wuyts@iam.unibe.ch Sent: Sunday, June 22, 2003 7:08 PM Subject: Re: [Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
Hi guys!
Stephane Ducasse ducasse@iam.unibe.ch wrote: [SNIP]
But ClosuresCs does not depend on SmaCC. It has been generated using SmaCC which is different. I do not need to include bison because I use a parser developed with it. Or there is something wrong. Can you let me know if I'm wrong? Stef
The problem with the above reasoning is that it assumes people only want/need to *use* the Compiler and not *change* it.
Before we had a Compiler that was written in Squeak - and thus also modifiable in Squeak using Squeak itself (all under Squeak-L).
If we choose to move over to a SmaCC generated Compiler (which of course would be technically great) we will have a Compiler that can not be modified using only Squeak itself. Unless SmaCC gets included into official Squeak of course - which it could if it came under Squeak-L, which it doesn't.
People may think this is a "small" issue. Personally I think it is a quite important issue. Every other little piece of the Squeak image is modifiable by Squeak itself. The VM too - though not to the full extent (you need a C compiler etc). This would suddenly make the Squeak image "non self hosted".
Hopefully we can though still somehow get SmaCC under Squeak-L and the problem would be solved.
Then Stephane wrote comments on the other extensions and I agree to the comments (but I haven't looked at the code) made. Just adding a little method in base classes here and there may seem "innocent" enough but they add up and eventually turns into a mess.
regards, Göran
PS. People may find it tempting to simply drop the "golden rule" sofar that everything in official Squeak should be under Squeak-L. That would probably (as Andrew Greenberg has pointed out multiple times) lead to a legal minefield and be very bad for Squeak. _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
On Mon, Jun 23, 2003 at 12:08:54AM +0100, goran.krampe@bluefish.se wrote:
Hi guys!
Stephane Ducasse ducasse@iam.unibe.ch wrote: [SNIP]
But ClosuresCs does not depend on SmaCC. It has been generated using SmaCC which is different. I do not need to include bison because I use a parser developed with it. Or there is something wrong. Can you let me know if I'm wrong? Stef
Unlike bison, which outputs a parser that only requires a C compiler, to run a SmaCC-generated compiler, you need to load the SmaCC runtime package. I couldn't find anything on the SmaCC site that suggests that the license is any different for the SmaCC runtime than for the full SmaCC.
The problem with the above reasoning is that it assumes people only want/need to *use* the Compiler and not *change* it.
Before we had a Compiler that was written in Squeak - and thus also modifiable in Squeak using Squeak itself (all under Squeak-L).
If we choose to move over to a SmaCC generated Compiler (which of course would be technically great) we will have a Compiler that can not be modified using only Squeak itself. Unless SmaCC gets included into official Squeak of course - which it could if it came under Squeak-L, which it doesn't.
People may think this is a "small" issue. Personally I think it is a quite important issue. Every other little piece of the Squeak image is modifiable by Squeak itself. The VM too - though not to the full extent (you need a C compiler etc). This would suddenly make the Squeak image "non self hosted".
Hopefully we can though still somehow get SmaCC under Squeak-L and the problem would be solved.
Has anyone contacted the SmaCC authors and asked? Maybe we can get Alan to ask; it would be tough for a Smalltalker to say no ;-)
Then Stephane wrote comments on the other extensions and I agree to the comments (but I haven't looked at the code) made. Just adding a little method in base classes here and there may seem "innocent" enough but they add up and eventually turns into a mess.
regards, G?ran
PS. People may find it tempting to simply drop the "golden rule" sofar that everything in official Squeak should be under Squeak-L. That would probably (as Andrew Greenberg has pointed out multiple times) lead to a legal minefield and be very bad for Squeak.
Looking at the SCO situation, we would be very stupid to do something like this.
Joshua
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Hi Joshua,
Unlike bison, which outputs a parser that only requires a C compiler, to run a SmaCC-generated compiler, you need to load the SmaCC runtime
package.
I couldn't find anything on the SmaCC site that suggests that the license is any different for the SmaCC runtime than for the full SmaCC.
Thanks, I missed this runtime requirement. I did not look at SmaCC code.
Has anyone contacted the SmaCC authors and asked? Maybe we can get Alan to ask; it would be tough for a Smalltalker to say no ;-)
PS. People may find it tempting to simply drop the "golden rule" sofar that everything in official Squeak should be under Squeak-L. That would probably (as Andrew Greenberg has pointed out multiple times) lead to a legal minefield and be very bad for Squeak.
Looking at the SCO situation, we would be very stupid to do something like this.
OTOH, I felt sickened at the heart when Alan had to appeal to Squeakers to share the fruits of their research.
Cheers,
PhiHo.
----- Original Message ----- From: "Joshua 'Schwa' Gargus" schwa@cc.gatech.edu To: "Discussing the Squeak Foundation" squeakfoundation@lists.squeakfoundation.org Sent: Monday, June 23, 2003 12:23 PM Subject: Re: [Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
On Mon, Jun 23, 2003 at 12:08:54AM +0100, goran.krampe@bluefish.se wrote:
Hi guys!
Stephane Ducasse ducasse@iam.unibe.ch wrote: [SNIP]
But ClosuresCs does not depend on SmaCC. It has been generated using SmaCC which is different. I do not need to include bison because I use a parser developed with it. Or there is something wrong. Can you let me know if I'm wrong? Stef
Unlike bison, which outputs a parser that only requires a C compiler, to run a SmaCC-generated compiler, you need to load the SmaCC runtime
package.
I couldn't find anything on the SmaCC site that suggests that the license is any different for the SmaCC runtime than for the full SmaCC.
The problem with the above reasoning is that it assumes people only want/need to *use* the Compiler and not *change* it.
Before we had a Compiler that was written in Squeak - and thus also modifiable in Squeak using Squeak itself (all under Squeak-L).
If we choose to move over to a SmaCC generated Compiler (which of course would be technically great) we will have a Compiler that can not be modified using only Squeak itself. Unless SmaCC gets included into official Squeak of course - which it could if it came under Squeak-L, which it doesn't.
People may think this is a "small" issue. Personally I think it is a quite important issue. Every other little piece of the Squeak image is modifiable by Squeak itself. The VM too - though not to the full extent (you need a C compiler etc). This would suddenly make the Squeak image "non self hosted".
Hopefully we can though still somehow get SmaCC under Squeak-L and the problem would be solved.
Has anyone contacted the SmaCC authors and asked? Maybe we can get Alan to ask; it would be tough for a Smalltalker to say no ;-)
Then Stephane wrote comments on the other extensions and I agree to the comments (but I haven't looked at the code) made. Just adding a little method in base classes here and there may seem "innocent" enough but they add up and eventually turns into a mess.
regards, G?ran
PS. People may find it tempting to simply drop the "golden rule" sofar that everything in official Squeak should be under Squeak-L. That would probably (as Andrew Greenberg has pointed out multiple times) lead to a legal minefield and be very bad for Squeak.
Looking at the SCO situation, we would be very stupid to do something like this.
Joshua
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
On Mon, Jun 23, 2003 at 12:40:49PM -0400, PhiHo Hoang wrote:
Has anyone contacted the SmaCC authors and asked? Maybe we can get Alan to ask; it would be tough for a Smalltalker to say no ;-)
PS. People may find it tempting to simply drop the "golden rule" sofar that everything in official Squeak should be under Squeak-L. That would probably (as Andrew Greenberg has pointed out multiple times) lead to a legal minefield and be very bad for Squeak.
Looking at the SCO situation, we would be very stupid to do something like this.
OTOH, I felt sickened at the heart when Alan had to appeal to Squeakers to share the fruits of their research.
I don't remember this. What was the context? If it's not much trouble, could you point me at the relevant email?
Also, I don't quite see the connection to my SCO comment; perhaps it is in response to saying no to Alan?
Best, Joshua
Cheers, PhiHo.
Joshua 'Schwa' Gargus wrote:
I don't remember this. What was the context? If it's not much trouble, could you point me at the relevant email?
Hey, is SqueakFoundation got SlashDotted, I couldn't get to the mail archives.
IIRC, it was in the Squeak license thread around the time MobVM, ImageBuilder edition was realeased.
He did not appeal to anyone specificcally, only in general.
I hope I did not put words into Alan's mouth. I also hope he is monitoring this list. :-)
Cheers,
PhiHo.
----- Original Message ----- From: "Joshua 'Schwa' Gargus" schwa@cc.gatech.edu To: "Discussing the Squeak Foundation" squeakfoundation@lists.squeakfoundation.org Sent: Monday, June 23, 2003 1:25 PM Subject: Re: [Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
On Mon, Jun 23, 2003 at 12:40:49PM -0400, PhiHo Hoang wrote:
Has anyone contacted the SmaCC authors and asked? Maybe we can get Alan to ask; it would be tough for a Smalltalker to say no ;-)
PS. People may find it tempting to simply drop the "golden rule"
sofar
that everything in official Squeak should be under Squeak-L. That
would
probably (as Andrew Greenberg has pointed out multiple times) lead
to a
legal minefield and be very bad for Squeak.
Looking at the SCO situation, we would be very stupid to do something like this.
OTOH, I felt sickened at the heart when Alan had to appeal to Squeakers to share the fruits of their research.I don't remember this. What was the context? If it's not much trouble, could you point me at the relevant email?
Also, I don't quite see the connection to my SCO comment; perhaps it is in response to saying no to Alan?
Best, Joshua
Cheers, PhiHo.
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Joshua 'Schwa' Gargus wrote:
On Mon, Jun 23, 2003 at 12:08:54AM +0100, goran.krampe@bluefish.se wrote:
Hi guys!
Stephane Ducasse ducasse@iam.unibe.ch wrote: [SNIP]
But ClosuresCs does not depend on SmaCC. It has been generated using SmaCC which is different. I do not need to include bison because I use a parser developed with it. Or there is something wrong. Can you let me know if I'm wrong? Stef
Unlike bison, which outputs a parser that only requires a C compiler, to run a SmaCC-generated compiler, you need to load the SmaCC runtime package. I couldn't find anything on the SmaCC site that suggests that the license is any different for the SmaCC runtime than for the full SmaCC.
My understanding from discussions on squeak-dev awhile ago is that the SmaCC authors (John Brant) agreed to license the SmaCC runtime under Squeak-L, but not the full SmaCC.
It sounded like they would consider offering the entire SmaCC under Squeak-L, except Squeak-L had a few funny clauses, which gets back to the general Squeak-L issues... perhaps simplifying Squeak-L via sublicensing would also make it more likely that these types of third party packages (in entirety) could be added to Squeak. (See Daniel's summary of the current licensing situation on squeak-dev.)
- Doug Way
Hi goran
But ClosuresCs does not depend on SmaCC. It has been generated using SmaCC which is different. I do not need to include bison because I use a parser developed with it. Or there is something wrong. Can you let me know if I'm wrong? Stef
The problem with the above reasoning is that it assumes people only want/need to *use* the Compiler and not *change* it.
So what you load SmaCC changes it and you get a new one.
Before we had a Compiler that was written in Squeak - and thus also modifiable in Squeak using Squeak itself (all under Squeak-L).
Ok I see your point.
The problem is that john does not understand all the implications of having Smacc SqL, so we are a bit blocked.
I can try to ask him.
If we choose to move over to a SmaCC generated Compiler (which of course would be technically great) we will have a Compiler that can not be modified using only Squeak itself. Unless SmaCC gets included into official Squeak of course - which it could if it came under Squeak-L, which it doesn't.
People may think this is a "small" issue. Personally I think it is a quite important issue. Every other little piece of the Squeak image is modifiable by Squeak itself. The VM too - though not to the full extent (you need a C compiler etc). This would suddenly make the Squeak image "non self hosted".
Hopefully we can though still somehow get SmaCC under Squeak-L and the problem would be solved.
Then Stephane wrote comments on the other extensions and I agree to the comments (but I haven't looked at the code) made. Just adding a little method in base classes here and there may seem "innocent" enough but they add up and eventually turns into a mess.
regards, Göran
PS. People may find it tempting to simply drop the "golden rule" sofar that everything in official Squeak should be under Squeak-L. That would probably (as Andrew Greenberg has pointed out multiple times) lead to a legal minefield and be very bad for Squeak. _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
squeakfoundation@lists.squeakfoundation.org
-
Anthony Hannan -
Doug Way -
goran.krampe＠bluefish.se -
Joshua 'Schwa' Gargus -
Marcus Denker -
PhiHo Hoang -
Stephane Ducasse