Folks -
I've been working on detangling the current tool set from the rest of the system since I wanted to be able to replace the current tool set with something more appropriate for Tweak. It turns out that with a little restructuring of responsibilities this isn't all that hard and so I'm happy to announce the probably only Squeak image in the world which has no programming tools whatsoever (!):
http://www.impara.de/~andreas/iSqueak/3.8/NoTools.zip [6.3MB]
If you grab this image you will find that you won't be able to open a browser, a change sorter, workspace etc. not even a debugger[*1] simply because none of these tools are present.
[*1] Try browsing the sender of some message or a class - you will very quickly notice why I don't like the usage of "AppRegistry default" since it raises completely needless errors when for example trying to browse a class -- compare this with the notifier you get when trying to browse a selector which uses ToolSet's interpretation of "proper" AppRegistry behavior.
However, since this is not very interesting, you can just load the standard tools package from
http://www.impara.de/~andreas/iSqueak/3.8/Tools-ar.17.mcz [450k]
install and use it. And when you're tired of it, simply unload it from Monticello[*]. Needless to say, the tools package does not leave any obsolete classes or undeclared references behind, it comes and goes cleanly.
[*] After unloading execute the code in the left hand panel - it turns out that #unload is not executed when unloading packages from Monticello (we *really* need to fix this!) probably because the #unload method is removed before the class.
But wait, there is more! Since the current tools package is somewhat messy and depends directly on Morphic and MVC I decided to build an alternative which exclusively depends on ToolBuilder. It's called the "PlusTools" (all the names have a "Plus" in the name, e.g., FileListPlus, TestRunnerPlus, ClassBrowserPlus, DebuggerPlus...) and loadable from:
http://www.impara.de/~andreas/iSqueak/3.8/PlusTools-ar.16.mcz [300k]
And of course, you can load and unload both tool sets at the same time if you'd like to. Note that the point of this exercise is not only to be able to replace the tools for Tweak - it is equally to show that a Squeak system can easily come without *any* specific tool support, squeakmap, even monticello (I only left MC in the image because you'd have to load it anyway to get to the tool sets) just as long as you have a way of loading code (e.g., compiler and change management). Therefore there is really no need whatsoever to put all of the programming tools into a "basic" Squeak image.
And finally, the PlusTools should be helpful for further detangling work as they depend on ToolBuilder and not on Morphic or MVC (there might still be a few remnants but that's easily fixable).
For those of you interested, here are the major changes that I did to make the above possible: * Refactoring of ChangeSet and ChangeSorter - all of the actual change set related stuff had to be moved out of ChangeSorter and ChangeSet itself had to be moved over to the System package and out of Tools. * Moving of the breakpoint, tallying, file contents browser (diff etc) out of the Tools (right now all of these are in System) * Introduced FileServiceRegistry to avoid abuse of FileList * Introduced ToolSet AppRegistry to support various tool sets
I also had to do some significant shuffling around between packages to get everything in order and (un-)loadable but most of these changes were non-invasive. If you are interested the full repository is also available at:
http://www.impara.de/~andreas/iSqueak/3.8/NoToolsRepository.zip [32MB]
and contains a few more (already unloaded) packages and fixes going back to the original 3.8 versions from SqF.org.
Cheers, - Andreas
Am 18.07.2005 um 04:17 schrieb Andreas Raab:
Folks -
I've been working on detangling the current tool set from the rest of the system since I wanted to be able to replace the current tool set with something more appropriate for Tweak. It turns out that with a little restructuring of responsibilities this isn't all that hard and so I'm happy to announce the probably only Squeak image in the world which has no programming tools whatsoever (!):
I'm pretty sure there have been images stripped of all tools, and Spoon of course takes that to the extreme. However, being able to comfortably load and unload the tools is a Very Good Thing :)
http://www.impara.de/~andreas/iSqueak/3.8/NoTools.zip [6.3MB]
If you grab this image you will find that you won't be able to open a browser, a change sorter, workspace etc. not even a debugger[*1] simply because none of these tools are present.
That means I should not make any errors? At the moment, for any exception I get an ominous "Syntax Error: Message pattern expected" notifier, followed by a nil>>MNU in the Decompiler, then follows an endless loop of notifiers for UnhandledErrors. Pressing Alt-. freezes the image ater answering the notifier.
[*1] Try browsing the sender of some message or a class - you will very quickly notice why I don't like the usage of "AppRegistry default" since it raises completely needless errors when for example trying to browse a class -- compare this with the notifier you get when trying to browse a selector which uses ToolSet's interpretation of "proper" AppRegistry behavior.
However, since this is not very interesting, you can just load the standard tools package from
http://www.impara.de/~andreas/iSqueak/3.8/Tools-ar.17.mcz [450k]
install and use it.
Hmm, it requests my author initials ... where does that come from?
And when you're tired of it, simply unload it from Monticello[*]. Needless to say, the tools package does not leave any obsolete classes or undeclared references behind, it comes and goes cleanly.
[*] After unloading execute the code in the left hand panel - it turns out that #unload is not executed when unloading packages from Monticello (we *really* need to fix this!) probably because the #unload method is removed before the class.
Done. See attachment. Methods are not removed one-by-one anymore when the whole class is removed.
But wait, there is more! Since the current tools package is somewhat messy and depends directly on Morphic and MVC I decided to build an alternative which exclusively depends on ToolBuilder. It's called the "PlusTools" (all the names have a "Plus" in the name, e.g., FileListPlus, TestRunnerPlus, ClassBrowserPlus, DebuggerPlus...) and loadable from:
http://www.impara.de/~andreas/iSqueak/3.8/PlusTools-ar.16.mcz [300k]
And of course, you can load and unload both tool sets at the same time if you'd like to. Note that the point of this exercise is not only to be able to replace the tools for Tweak - it is equally to show that a Squeak system can easily come without *any* specific tool support, squeakmap, even monticello (I only left MC in the image because you'd have to load it anyway to get to the tool sets) just as long as you have a way of loading code (e.g., compiler and change management). Therefore there is really no need whatsoever to put all of the programming tools into a "basic" Squeak image.
And finally, the PlusTools should be helpful for further detangling work as they depend on ToolBuilder and not on Morphic or MVC (there might still be a few remnants but that's easily fixable).
For those of you interested, here are the major changes that I did to make the above possible:
- Refactoring of ChangeSet and ChangeSorter - all of the actual
change set related stuff had to be moved out of ChangeSorter and ChangeSet itself had to be moved over to the System package and out of Tools.
- Moving of the breakpoint, tallying, file contents browser (diff
etc) out of the Tools (right now all of these are in System)
- Introduced FileServiceRegistry to avoid abuse of FileList
- Introduced ToolSet AppRegistry to support various tool sets
I also had to do some significant shuffling around between packages to get everything in order and (un-)loadable but most of these changes were non-invasive. If you are interested the full repository is also available at:
http://www.impara.de/~andreas/iSqueak/3.8/NoToolsRepository.zip [32MB]
and contains a few more (already unloaded) packages and fixes going back to the original 3.8 versions from SqF.org.
Some more bugs I encountered:
* MessageNotUnderstood: Inspector class>>openOn: * Endless loop in ToolSet class>>explore:
Ah well, fixes attached, too :)
- Bert -
That means I should not make any errors? At the moment, for any exception I get an ominous "Syntax Error: Message pattern expected" notifier, followed by a nil>>MNU in the Decompiler, then follows an endless loop of notifiers for UnhandledErrors. Pressing Alt-. freezes the image ater answering the notifier.
Yeah, there are a few remaining oddities. I think the "message pattern expected" is the (indirect) result of condensing the changes, which sounds odd but there are some strange things going with closures here. The endless loop for unhandled errors is more interesting but I will admit I haven't spent much time making the debugger requests work in reasonable way without the debugger ;-) So there is definitely some stuff left to do.
However, since this is not very interesting, you can just load the standard tools package from
http://www.impara.de/~andreas/iSqueak/3.8/Tools-ar.17.mcz [450k]
install and use it.
Hmm, it requests my author initials ... where does that come from?
I have no idea.
[*] After unloading execute the code in the left hand panel - it turns out that #unload is not executed when unloading packages from Monticello (we *really* need to fix this!) probably because the #unload method is removed before the class.
Done. See attachment. Methods are not removed one-by-one anymore when the whole class is removed.
Ah, great! Thanks.
Some more bugs I encountered:
- MessageNotUnderstood: Inspector class>>openOn:
- Endless loop in ToolSet class>>explore:
Ah well, fixes attached, too :)
Heh, heh, even better ;-)
Cheers, - Andreas
On 18 juil. 05, at 4:17, Andreas Raab wrote:
Folks -
I've been working on detangling the current tool set from the rest of the system since I wanted to be able to replace the current tool set with something more appropriate for Tweak. It turns out that with a little restructuring of responsibilities this isn't all that hard and so I'm happy to announce the probably only Squeak image in the world which has no programming tools whatsoever (!):
sounds exciting....
http://www.impara.de/~andreas/iSqueak/3.8/NoTools.zip [6.3MB]
If you grab this image you will find that you won't be able to open a browser, a change sorter, workspace etc. not even a debugger[*1] simply because none of these tools are present.
[*1] Try browsing the sender of some message or a class - you will very quickly notice why I don't like the usage of "AppRegistry default" since it raises completely needless errors when for example trying to browse a class -- compare this with the notifier you get when trying to browse a selector which uses ToolSet's interpretation of "proper" AppRegistry behavior.
So we will have to fix that. I'm back in town and I will sync with the guys here to have a roadmap. I would like to see how we can push your ToolBuilder changes.
However, since this is not very interesting, you can just load the standard tools package from
http://www.impara.de/~andreas/iSqueak/3.8/Tools-ar.17.mcz [450k]
install and use it. And when you're tired of it, simply unload it from Monticello[*]. Needless to say, the tools package does not leave any obsolete classes or undeclared references behind, it comes and goes cleanly.
This is cool.
[*] After unloading execute the code in the left hand panel - it turns out that #unload is not executed when unloading packages from Monticello (we *really* need to fix this!) probably because the #unload method is removed before the class.
But wait, there is more! Since the current tools package is somewhat messy and depends directly on Morphic and MVC I decided to build an alternative which exclusively depends on ToolBuilder. It's called the "PlusTools" (all the names have a "Plus" in the name, e.g., FileListPlus, TestRunnerPlus, ClassBrowserPlus, DebuggerPlus...) and loadable from:
http://www.impara.de/~andreas/iSqueak/3.8/PlusTools-ar.16.mcz [300k]
Ok so you already did it ;). So I would suggest that we only use this one. :)
And of course, you can load and unload both tool sets at the same time if you'd like to. Note that the point of this exercise is not only to be able to replace the tools for Tweak - it is equally to show that a Squeak system can easily come without *any* specific tool support, squeakmap, even monticello (I only left MC in the image because you'd have to load it anyway to get to the tool sets) just as long as you have a way of loading code (e.g., compiler and change management). Therefore there is really no need whatsoever to put all of the programming tools into a "basic" Squeak image.
I thought that there was a version of MC UI was relying on ToolBuilder.
And finally, the PlusTools should be helpful for further detangling work as they depend on ToolBuilder and not on Morphic or MVC (there might still be a few remnants but that's easily fixable).
For those of you interested, here are the major changes that I did to make the above possible:
- Refactoring of ChangeSet and ChangeSorter - all of the actual
change set related stuff had to be moved out of ChangeSorter and ChangeSet itself had to be moved over to the System package and out of Tools.
I do not have the time right now to look at it but did you change the notification mechanism? I'm curious to see how the decoupling offered by the notification mechanism helps.
- Moving of the breakpoint, tallying, file contents browser (diff
etc) out of the Tools (right now all of these are in System)
- Introduced FileServiceRegistry to avoid abuse of FileList
- Introduced ToolSet AppRegistry to support various tool sets
I also had to do some significant shuffling around between packages to get everything in order and (un-)loadable but most of these changes were non-invasive. If you are interested the full repository is also available at:
http://www.impara.de/~andreas/iSqueak/3.8/NoToolsRepository.zip [32MB]
and contains a few more (already unloaded) packages and fixes going back to the original 3.8 versions from SqF.org.
Cheers,
- Andreas
[*1] Try browsing the sender of some message or a class - you will very quickly notice why I don't like the usage of "AppRegistry default" since it raises completely needless errors when for example trying to browse a class -- compare this with the notifier you get when trying to browse a selector which uses ToolSet's interpretation of "proper" AppRegistry behavior.
So we will have to fix that.
Actually, the above note related to a message that I sent to Squeak-dev about the general use of AppRegistry but it seems like the list is dead for now. I'm attaching it for reference.
http://www.impara.de/~andreas/iSqueak/3.8/PlusTools-ar.16.mcz [300k]
Ok so you already did it ;). So I would suggest that we only use this one. :)
Well, there are a few things missing and originally I needed the PlusTools to figure out how to go about unloading and dealing with the regular tools. The PlusTools *definitely* need some more work, what I've done covers the basics but there are plenty of things that still need to be fixed.
I thought that there was a version of MC UI was relying on ToolBuilder.
Yes, there is. I'm planning to use it for Tweak.
- Refactoring of ChangeSet and ChangeSorter - all of the actual
I do not have the time right now to look at it but did you change the notification mechanism? I'm curious to see how the decoupling offered by the notification mechanism helps.
I simply separated the functionality of dealing with changes from the user interface (ChangeSorter). Mostly it meant moving class methods from ChangeSorter to ChangeSet and then fix patterns like "ChangeSorter changeSetNamed: ..." to use "ChangeSet named: ...".
Cheers, - Andreas
On 18 juil. 05, at 19:58, Andreas Raab wrote:
[*1] Try browsing the sender of some message or a class - you will very quickly notice why I don't like the usage of "AppRegistry default" since it raises completely needless errors when for example trying to browse a class -- compare this with the notifier you get when trying to browse a selector which uses ToolSet's interpretation of "proper" AppRegistry behavior.
So we will have to fix that.
Actually, the above note related to a message that I sent to Squeak- dev about the general use of AppRegistry but it seems like the list is dead for now. I'm attaching it for reference.
There are too much other lists. I would prefer to have only one mailing-list instead of packages,.... because it gives a wrong feeling that nothing is happening.
http://www.impara.de/~andreas/iSqueak/3.8/PlusTools-ar.16.mcz [300k]
Ok so you already did it ;). So I would suggest that we only use this one. :)
Well, there are a few things missing and originally I needed the PlusTools to figure out how to go about unloading and dealing with the regular tools. The PlusTools *definitely* need some more work, what I've done covers the basics but there are plenty of things that still need to be fixed.
I thought that there was a version of MC UI was relying on ToolBuilder.
Yes, there is. I'm planning to use it for Tweak.
- Refactoring of ChangeSet and ChangeSorter - all of the actual
I do not have the time right now to look at it but did you change the notification mechanism? I'm curious to see how the decoupling offered by the notification mechanism helps.
I simply separated the functionality of dealing with changes from the user interface (ChangeSorter). Mostly it meant moving class methods from ChangeSorter to ChangeSet and then fix patterns like "ChangeSorter changeSetNamed: ..." to use "ChangeSet named: ...".
Cheers,
- Andreas
From: Andreas Raab andreas.raab@gmx.de Date: 17 juillet 2005 19:31:35 GMT+02:00 To: The general-purpose Squeak developers list <squeak- dev@lists.squeakfoundation.org> Subject: On AppRegistry and its use
Folks,
I have started to use AppRegistry for a significantly sized project and found and stumbled across a few odditities which I'd like to see addressed.
Most importantly, AppRegistry typically does not provide a user with even a hint about the interface that's expected. If you look at MailSender you can see its interface but for most of the others this is not true. That's problematic since we cannot simply create a new kind of app but rather need to find the original and faithfully copy its interface. If the original's interface changes (such as just happened for MailSender) it breaks other apps (MAPIClient for example) without even so much as a hint that the expected interface for that app has changed.
Secondly, AppRegistry has an obnoxiuous habit of telling the user every time anyone asks that there are "no applications registered". It is possible to ask for the default without that but then the client needs to handle the default choice itself. Thus instead of
(WebBrowser default ifNil: [^self]) doSomething.(resulting in the obnoxious "no webbrowsers registered") one would need to write:
(WebBrowser defaultOrNil == nil and:[WebBrowserregisteredClasses isEmpty]) ifTrue:[^self]. WebBrowser default doSomething.
It seems to me that AppRegistry would be more useful if it weren't used at all with the above "AppRegistry default" pattern but rather by, e.g.,
AppRegistry doSomething.(without the "default") This serves the following purposes:
a) We are required to state the expected protocol for the app so if anyone else wants to implement a new kind of app she knows what is expected.
b) An application can implement the action appropriately depending on what is specifically requested in one of the following ways:
- silently substitute a suitable default if possible, e.g.,
WebBrowser class>>openOn: url self default ifNil:[ ^(StringHolder new contents: url retrieveContents) openLabel: url asString. ]. self default openOn: url.
- Give the user information about the fact it is missing, e.g.,
WebBrowser class>>openOn: url self default ifNil:[^self inform: 'No WebBrowser present']. self default openOn: url.
- raise an error if the requested service is crucial
WebBrowser class>>openUn: url self default ifNil:[^self error: 'Where is the web browser']. self default openOn: url.
c) There is no reason for AppRegistry>>default to give any warning whatsoever. Client code can use "AppRegistry default" to bypass the error handling provided the specific application and therefore the user need not be bothered with all of these notifications.
I had the need for pretty much all of the above and would like to see AppRegistry fixed in the way described above.
Comments?
Cheers,
- Andreas
There are too much other lists. I would prefer to have only one mailing-list instead of packages,.... because it gives a wrong feeling that nothing is happening.
I must admit I prefer the focused discussions that happen to take place on the individual lists. Also I think that if you take the team model seriously, then PR is part of the job of a team leader so I'd expect them to give regular updates. But other than that it feels that some actual work is getting here and you know who is doing it and messages don't get easily lost in the (otherwise unrelated) traffic which is too commonly the case on Squeak-dev.
Cheers, - Andreas
Am 18.07.2005 um 04:17 schrieb Andreas Raab:
I also had to do some significant shuffling around between packages to get everything in order and (un-)loadable but most of these changes were non-invasive. If you are interested the full repository is also available at:
http://www.impara.de/~andreas/iSqueak/3.8/NoToolsRepository.zip [32MB]
and contains a few more (already unloaded) packages and fixes going back to the original 3.8 versions from SqF.org.
So we need someone who folds these changes back into the 3.9 repository... any takers?
Other things on the list
-> NewLook. Adrian and me will integrate that this week. -> The ToolBuilder changes need to be added -> The URI package should be official part of 3.9 (as a package), I think.
As for the changes that used to be in the old 3.9a stream that was abandoned: They are now either on Mantis or in the 3.9a repository, so this is done.
Marcus
Hi marcus
the next two weeks I will be over a dead slow modem.... so no easy merge. If I have some time at the Uni at annecy I will have a look.
http://www.impara.de/~andreas/iSqueak/3.8/NoToolsRepository.zip
Stef
On 1 août 05, at 20:27, Marcus Denker wrote:
Am 18.07.2005 um 04:17 schrieb Andreas Raab:
I also had to do some significant shuffling around between packages to get everything in order and (un-)loadable but most of these changes were non-invasive. If you are interested the full repository is also available at:
http://www.impara.de/~andreas/iSqueak/3.8/NoToolsRepository.zip [32MB]
and contains a few more (already unloaded) packages and fixes going back to the original 3.8 versions from SqF.org.
So we need someone who folds these changes back into the 3.9 repository... any takers?
Other things on the list
-> NewLook. Adrian and me will integrate that this week. -> The ToolBuilder changes need to be added -> The URI package should be official part of 3.9 (as apackage), I think.
As for the changes that used to be in the old 3.9a stream that was abandoned: They are now either on Mantis or in the 3.9a repository, so this is done.
Marcus
I'd be happy to work on this except that for obvious reasons I cannot guarantuee when I'll find time to work on it. Right now I have a few more important things on my plate ;-)
Cheers, - Andreas
Marcus Denker wrote:
Am 18.07.2005 um 04:17 schrieb Andreas Raab:
I also had to do some significant shuffling around between packages to get everything in order and (un-)loadable but most of these changes were non-invasive. If you are interested the full repository is also available at:
http://www.impara.de/~andreas/iSqueak/3.8/NoToolsRepository.zip [32MB]
and contains a few more (already unloaded) packages and fixes going back to the original 3.8 versions from SqF.org.
So we need someone who folds these changes back into the 3.9 repository... any takers?
Other things on the list
-> NewLook. Adrian and me will integrate that this week. -> The ToolBuilder changes need to be added -> The URI package should be official part of 3.9 (as a package), Ithink.
As for the changes that used to be in the old 3.9a stream that was abandoned: They are now either on Mantis or in the 3.9a repository, so this is done.
Marcus
packages@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Marcus Denker -
stéphane ducasse