Cleaning up lava code and unsent messages.
Hi all,
This was an after thought from my previous post. It deserved its own topic.
Lava code is code left over from historical times which has no use in the current image and yet no one is willing to take responsiblity for removing it.
For the record squeak has historically had about one sixth of its messages as unsent methods. Some of which is lava code others of which are examples, probes, utilities and tests.
It would be nice to clean things up so there are no unsent messages. This could be done simply by creating a (pseudo-recursive) message #legitamatelyUnsentMethods (one method say for each class.) That sends for any legitimate examples, etc. Then anything that shows up as unsent would be illegitamate and removeable.
From time to time you would look at the implementors
of the legitamatelyUnsentMethods to clean out what no longer belongs. a legitamatelyUnsentMethods method would be packagable if care were take that it mentions only the unsent methods of that package.
My proposal is that package maintainers should take the responsibility for doing this in their own packages and the release team should reject any code that contains unsent messages. An Sunit test could be provided to check.
I am also hoping to recruit those who would be willing to sort out the unsent messages in core packages and either write legitamatelyUnsentMethods methods for them or flag them as lava code for removal. It is a good way to gain an insight into a lot of squeak code while helping the community.
If this task appeals to you please start it by planting a seed on mantis.
Yours in service and curiosity, --Jeorme Peace
____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Jerome Peace wrote:
Cleaning up lava code and unsent messages.
[snip]
It would be nice to clean things up so there are no unsent messages. This could be done simply by creating a (pseudo-recursive) message #legitamatelyUnsentMethods (one method say for each class.) That sends for any legitimate examples, etc. Then anything that shows up as unsent would be illegitamate and removeable.
Would something like #legitimatelyUnsentMessages be preferable to using Object>>nominallyUnsent? The comment on that method describes it as a mechanism for marking unsent methods which are legitimate and should not be removed.
I am also hoping to recruit those who would be willing to sort out the unsent messages in core packages and either write legitamatelyUnsentMethods methods for them or flag them as lava code for removal. It is a good way to gain an insight into a lot of squeak code while helping the community.
If this task appeals to you please start it by planting a seed on mantis.
Yours in service and curiosity, --Jeorme Peace
I'd be interested in helping with this--what kind of seed on Mantis were you looking for--a specific bug report for a particular unsent message to start with, or something more general? Also, which image version would you recommend starting with--3.9, 3.10,...?
--Ash
ash_logan a écrit :
Jerome Peace wrote:
Cleaning up lava code and unsent messages.
[snip]
It would be nice to clean things up so there are no unsent messages. This could be done simply by creating a (pseudo-recursive) message #legitamatelyUnsentMethods (one method say for each class.) That sends for any legitimate examples, etc. Then anything that shows up as unsent would be illegitamate and removeable.
Would something like #legitimatelyUnsentMessages be preferable to using Object>>nominallyUnsent? The comment on that method describes it as a mechanism for marking unsent methods which are legitimate and should not be removed.
If a message is part of a useful unused API, the best thing is to write a SUnit TestCase as a specification and example of use.
But who decides about usefullness?
Another possibility is to scan SqueakSource and/or other third party code repository to assert use...
I am also hoping to recruit those who would be willing to sort out the unsent messages in core packages and either write legitamatelyUnsentMethods methods for them or flag them as lava code for removal. It is a good way to gain an insight into a lot of squeak code while helping the community.
If this task appeals to you please start it by planting a seed on mantis.
Yours in service and curiosity, --Jeorme Peace
I'd be interested in helping with this--what kind of seed on Mantis were you looking for--a specific bug report for a particular unsent message to start with, or something more general? Also, which image version would you recommend starting with--3.9, 3.10,...?
--Ash
I would start from lattest, and post one entry per message, or eventually group of messages if they are in the same chain.
Atomic changes are more easily incorporated in images.
Nicolas
El 2/22/08 11:01 PM, "Jerome Peace" peace_the_dreamer@yahoo.com escribió:
Cleaning up lava code and unsent messages.
Hi all,
This was an after thought from my previous post. It deserved its own topic.
Lava code is code left over from historical times which has no use in the current image and yet no one is willing to take responsiblity for removing it.
For the record squeak has historically had about one sixth of its messages as unsent methods. Some of which is lava code others of which are examples, probes, utilities and tests.
It would be nice to clean things up so there are no unsent messages. This could be done simply by creating a (pseudo-recursive) message #legitamatelyUnsentMethods (one method say for each class.) That sends for any legitimate examples, etc. Then anything that shows up as unsent would be illegitamate and removeable.
From time to time you would look at the implementors
of the legitamatelyUnsentMethods to clean out what no longer belongs. a legitamatelyUnsentMethods method would be packagable if care were take that it mentions only the unsent methods of that package.
My proposal is that package maintainers should take the responsibility for doing this in their own packages and the release team should reject any code that contains unsent messages. An Sunit test could be provided to check.
I am also hoping to recruit those who would be willing to sort out the unsent messages in core packages and either write legitamatelyUnsentMethods methods for them or flag them as lava code for removal. It is a good way to gain an insight into a lot of squeak code while helping the community.
If this task appeals to you please start it by planting a seed on mantis.
Yours in service and curiosity, --Jeorme Peace
As part of previous Release Team I support Jerome. Also reminds he (and all) Pavel have less unimplemented in his works, so some could be learn and moved to current release.
Because we have one ... Or not ?
Edgar
How about tagging each legitimate unsent method with a pragma? e.g.
myUnsentMethod <unsentByDesign> ^42
You can easily see all of them by using senders of #unsentByDesign (I can't spell "legitamately"...), the tags are close to the method being tagged rather than elsewhere and you don't have to worry about packaging boundaries.
-david
On Mon, Dec 1, 2008 at 2:20 PM, Edgar J. De Cleene < edgardec2001@yahoo.com.ar> wrote:
El 2/22/08 11:01 PM, "Jerome Peace" peace_the_dreamer@yahoo.com escribió:
Cleaning up lava code and unsent messages.
Hi all,
This was an after thought from my previous post. It deserved its own topic.
Lava code is code left over from historical times which has no use in the current image and yet no one is willing to take responsiblity for removing it.
For the record squeak has historically had about one sixth of its messages as unsent methods. Some of which is lava code others of which are examples, probes, utilities and tests.
It would be nice to clean things up so there are no unsent messages. This could be done simply by creating a (pseudo-recursive) message #legitamatelyUnsentMethods (one method say for each class.) That sends for any legitimate examples, etc. Then anything that shows up as unsent would be illegitamate and removeable.
From time to time you would look at the implementors
of the legitamatelyUnsentMethods to clean out what no longer belongs. a legitamatelyUnsentMethods method would be packagable if care were take that it mentions only the unsent methods of that package.
My proposal is that package maintainers should take the responsibility for doing this in their own packages and the release team should reject any code that contains unsent messages. An Sunit test could be provided to check.
I am also hoping to recruit those who would be willing to sort out the unsent messages in core packages and either write legitamatelyUnsentMethods methods for them or flag them as lava code for removal. It is a good way to gain an insight into a lot of squeak code while helping the community.
If this task appeals to you please start it by planting a seed on mantis.
Yours in service and curiosity, --Jeorme Peace
As part of previous Release Team I support Jerome. Also reminds he (and all) Pavel have less unimplemented in his works, so some could be learn and moved to current release.
Because we have one ... Or not ?
Edgar
2008/12/2 David Pennell pennell.david@gmail.com:
How about tagging each legitimate unsent method with a pragma? e.g. myUnsentMethod
<unsentByDesign> ^42
good idea, except maybe naming of pragma.
You can easily see all of them by using senders of #unsentByDesign (I can't spell "legitamately"...), the tags are close to the method being tagged rather than elsewhere and you don't have to worry about packaging boundaries. -david On Mon, Dec 1, 2008 at 2:20 PM, Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
El 2/22/08 11:01 PM, "Jerome Peace" peace_the_dreamer@yahoo.com escribió:
Cleaning up lava code and unsent messages.
Hi all,
This was an after thought from my previous post. It deserved its own topic.
Lava code is code left over from historical times which has no use in the current image and yet no one is willing to take responsiblity for removing it.
For the record squeak has historically had about one sixth of its messages as unsent methods. Some of which is lava code others of which are examples, probes, utilities and tests.
It would be nice to clean things up so there are no unsent messages. This could be done simply by creating a (pseudo-recursive) message #legitamatelyUnsentMethods (one method say for each class.) That sends for any legitimate examples, etc. Then anything that shows up as unsent would be illegitamate and removeable.
From time to time you would look at the implementors
of the legitamatelyUnsentMethods to clean out what no longer belongs. a legitamatelyUnsentMethods method would be packagable if care were take that it mentions only the unsent methods of that package.
My proposal is that package maintainers should take the responsibility for doing this in their own packages and the release team should reject any code that contains unsent messages. An Sunit test could be provided to check.
I am also hoping to recruit those who would be willing to sort out the unsent messages in core packages and either write legitamatelyUnsentMethods methods for them or flag them as lava code for removal. It is a good way to gain an insight into a lot of squeak code while helping the community.
If this task appeals to you please start it by planting a seed on mantis.
Yours in service and curiosity, --Jeorme Peace
As part of previous Release Team I support Jerome. Also reminds he (and all) Pavel have less unimplemented in his works, so some could be learn and moved to current release.
Because we have one ... Or not ?
Edgar
squeak-dev@lists.squeakfoundation.org
-
ash_logan -
David Pennell -
Edgar J. De Cleene -
Igor Stasenko -
Jerome Peace -
nicolas cellier