Hi all,
There's the new update for my kernel image for Squeak 3.9 (without next packages) http://www.comtalk.net/Squeak/uploads/20/bootstrap7052.zip
If you run "Bootstrap new browseOverrides", you can see list of all changed methods. This image overrides only 122 methods so I hope that it will be quite easy to begin with refactoring of full Squeak (3.10) to minimize the amount of necessary overrides and publish it on Mantis. We should use some special mark (e.g. [KERNELIMAGE]) for such patches or create new project.
The most important refactorings: =======================
- ChangesOrganizer that picks general changes manipulations from the ChangeSorter tool and makes that operations independent on it. Andreas already published similar patch some time ago but it was not accepted.
This invokes overriding of very small set of methods in the kernel but the impact on the full image will be much bigger (but in most cases it will be only renaming from ChangeSorter to ChangesOrganizer)
XxxChangeSetCategory >> reconstituteList XxxChangeSetCategory >> changeSetList XxxChangeSetCategory >> includesChangeSet: XxxChangeSetCategoryWithParameters >> reconstituteList XxxChangeSetCategoryWithParameters >> includesChangeSet: XxxFileStream
fileIntoNewChangeSet
- extend UIManager to make the kernel independent on UI. It's about 30 methods it means to take the current source and create the corresponding code in the MorphicUIManager or MVCUIManager
XxxAbort >> defaultAction XxxBlockCannotReturn >> defaultAction XxxChangeSet class >> promptForDefaultChangeSetDirectoryIfNecessary XxxContextPart >> doPrimitive:method:receiver:args: XxxDisplayScreen
restoreAfter: XxxDisplayScreen >> restore XxxDisplayScreen >>
newDepthNoRestore: XxxDisplayScreen class >> checkForNewScreenSize XxxDisplayText >> composeForm XxxError >> defaultAction XxxEventSensor >> startUp XxxFileDirectory >> rename:toBe: XxxFileDoesNotExistException >> defaultAction XxxFileExistsException
defaultAction XxxHalt >> defaultAction XxxMethodContext >>
cannotReturn: XxxObject >> primitiveError: XxxProcess >> debug:title:full: XxxProgressInitiationException >> defaultAction XxxSmalltalkImage >> snapshot:andQuit:embedded: XxxStandardFileStream class >> fileExistsUserHandling: XxxStrikeFont class >> fromUser: XxxSyntaxErrorNotification >> defaultAction XxxSystemDictionary >> lowSpaceWatcher XxxSystemDictionary >> handleUserInterrupt XxxTextStyle class >> replaceFontsIn:with: XxxUnhandledError >> defaultAction XxxUtilities class >> informUserDuring: XxxUtilities class >> informUser:during: XxxWarning >> defaultAction
So if anybody wants to help with Squeak modularization, this is the right sand to play.
The next step is to discuss the rest of overrides (maybe we should create Mantis record for each).
Then we should create clean package The Rest of Squeak. The phase of its loading is simple because that means only to authomatically create the set of new classes, methods and very small set of overrides. We will need small basic image without all packages that can be safely removed (FFI etc.) for that. The biggest problem is to initialize fully working Morphic world (but we are already able to do that partly).
I expect that then we will be able to create script that will shrink the image to the kernel without self-bootstrapping process. So as the result we may have "our" (not only "my") kernel image. The final basic image will be almost the same as the current image so we will burn no important bridges but we will have well described process of Morphic initialization and (still little messy but usable) kernel (maybe not official for end-users but important part of Squeak development and modularization).
I would like to see it as the main goal for Squeak 3.10. I expect that it may take about two or three months. Your comments?
Cheers, -- Pavel
Pavel Krivanek wrote:
- extend UIManager to make the kernel independent on UI. It's about 30
methods it means to take the current source and create the corresponding code in the MorphicUIManager or MVCUIManager
Ouch. This feels *extremely* wrong to me - you are making a user interface abstraction be responsible for the defaults in exception handling. Bad choice. What is wrong with the current implementations anyway? There is no UI dependency in any of the standard exception classes that I find in 3.9 (a few edge cases like ProgressInitiationException that don't belong into Kernel discounted).
Cheers, - Andreas
On 7/30/06, Andreas Raab andreas.raab@gmx.de wrote:
Pavel Krivanek wrote:
- extend UIManager to make the kernel independent on UI. It's about 30
methods it means to take the current source and create the corresponding code in the MorphicUIManager or MVCUIManager
Ouch. This feels *extremely* wrong to me - you are making a user interface abstraction be responsible for the defaults in exception handling. Bad choice. What is wrong with the current implementations anyway? There is no UI dependency in any of the standard exception classes that I find in 3.9 (a few edge cases like ProgressInitiationException that don't belong into Kernel discounted).
Every UI wants to answer on exceptions by different way (Morphic wants to show some dialog during a warning, console may write only some text without user interaction etc). So somewhere from the exception handler you have to call UIManager. Do you've got any better design?
-- Pavel
Pavel,
the defaultAction in UnhandledError (when the user cannot or does not handle or fails) is
^ ToolSet debugError: exception
ToolSet (or one of its alternatives) can and should decide what/how UI is involved. I was under the impression that this is the current state of art in 3.9?
/Klaus
On Sun, 30 Jul 2006 19:22:01 +0200, Pavel Krivanek wrote:
On 7/30/06, Andreas Raab andreas.raab@gmx.de wrote:
Pavel Krivanek wrote:
- extend UIManager to make the kernel independent on UI. It's about 30
methods it means to take the current source and create the corresponding code in the MorphicUIManager or MVCUIManager
Ouch. This feels *extremely* wrong to me - you are making a user interface abstraction be responsible for the defaults in exception handling. Bad choice. What is wrong with the current implementations anyway? There is no UI dependency in any of the standard exception classes that I find in 3.9 (a few edge cases like ProgressInitiationException that don't belong into Kernel discounted).
Every UI wants to answer on exceptions by different way (Morphic wants to show some dialog during a warning, console may write only some text without user interaction etc). So somewhere from the exception handler you have to call UIManager. Do you've got any better design?
-- Pavel
Pavel Krivanek wrote:
On 7/30/06, Andreas Raab andreas.raab@gmx.de wrote:
Pavel Krivanek wrote:
- extend UIManager to make the kernel independent on UI. It's about 30
methods it means to take the current source and create the corresponding code in the MorphicUIManager or MVCUIManager
Ouch. This feels *extremely* wrong to me - you are making a user interface abstraction be responsible for the defaults in exception handling. Bad choice. What is wrong with the current implementations anyway? There is no UI dependency in any of the standard exception classes that I find in 3.9 (a few edge cases like ProgressInitiationException that don't belong into Kernel discounted).
Every UI wants to answer on exceptions by different way (Morphic wants to show some dialog during a warning, console may write only some text without user interaction etc). So somewhere from the exception handler you have to call UIManager. Do you've got any better design?
It shouldn't be the UI that decides "what" to do (i.e., the policy decision of what to do with certain exceptions). It should be the application context that decides that. In other words, Seaside should decide what to do with exceptions in Seaside and do so regardless of whether it's being run under Morphic, Wx, or MVC. What UIManager does is provide support for "how" to implement the policy decision. So if Seaside decided that it would be appropriate to inform an interactive user about certain exceptions it may *use* UIManager to implement that action, but it is still Seaside which makes the policy decision not a UIManager.
To give another example, the current (3.9) implementation vectors all unhandled exceptions through ToolSet which (if no toolset is installed) uses UIManager to provide the user with information about the exception. In other words, the policy (inform the user) is not part of the user interface - even if morphic is installed, it may not be appropriate to open a debugger. And of course there is nothing in this that says you could not install a command line debugger and use that one, even if you have only a console.
As for a better design, what problem are you trying to solve? Making the kernel UI independent? I see most exceptions fall back to UnhandledError (which is perfectly reasonable) and I see UnhandledError vector through ToolSet. And ToolSet (by default) vectors through UIManager to inform the user. So the solution is already there but what you've done is to move the boundary from the "how" (UIManager being instructed by the policy maker about what to do) to the "what" (UIManager being required to make policy decisions). This is what feels so wrong to me and why I'd rather keep the current scheme unless something more flexible is required. In which case it still shouldn't be vectored through UIManager the way you're proposing it.
If you really, really, want a policy object that can deal with various exceptions, provide an exception handling policy that deals exclusively with exceptions but don't bind it to a particular UI. That EHPolicy may *use* UIManager but don't make it *be* UIManager.
Cheers, - Andreas
Right, ok, I will change it for this kind of methods. Thank you.
I used this approach to have uniform implementation for all exceptions including ProgressInitiationException that is still part of this kernel.
-- Pavel
On 7/30/06, Andreas Raab andreas.raab@gmx.de wrote:
Pavel Krivanek wrote:
On 7/30/06, Andreas Raab andreas.raab@gmx.de wrote:
Pavel Krivanek wrote:
- extend UIManager to make the kernel independent on UI. It's about 30
methods it means to take the current source and create the corresponding code in the MorphicUIManager or MVCUIManager
Ouch. This feels *extremely* wrong to me - you are making a user interface abstraction be responsible for the defaults in exception handling. Bad choice. What is wrong with the current implementations anyway? There is no UI dependency in any of the standard exception classes that I find in 3.9 (a few edge cases like ProgressInitiationException that don't belong into Kernel discounted).
Every UI wants to answer on exceptions by different way (Morphic wants to show some dialog during a warning, console may write only some text without user interaction etc). So somewhere from the exception handler you have to call UIManager. Do you've got any better design?
It shouldn't be the UI that decides "what" to do (i.e., the policy decision of what to do with certain exceptions). It should be the application context that decides that. In other words, Seaside should decide what to do with exceptions in Seaside and do so regardless of whether it's being run under Morphic, Wx, or MVC. What UIManager does is provide support for "how" to implement the policy decision. So if Seaside decided that it would be appropriate to inform an interactive user about certain exceptions it may *use* UIManager to implement that action, but it is still Seaside which makes the policy decision not a UIManager.
To give another example, the current (3.9) implementation vectors all unhandled exceptions through ToolSet which (if no toolset is installed) uses UIManager to provide the user with information about the exception. In other words, the policy (inform the user) is not part of the user interface - even if morphic is installed, it may not be appropriate to open a debugger. And of course there is nothing in this that says you could not install a command line debugger and use that one, even if you have only a console.
As for a better design, what problem are you trying to solve? Making the kernel UI independent? I see most exceptions fall back to UnhandledError (which is perfectly reasonable) and I see UnhandledError vector through ToolSet. And ToolSet (by default) vectors through UIManager to inform the user. So the solution is already there but what you've done is to move the boundary from the "how" (UIManager being instructed by the policy maker about what to do) to the "what" (UIManager being required to make policy decisions). This is what feels so wrong to me and why I'd rather keep the current scheme unless something more flexible is required. In which case it still shouldn't be vectored through UIManager the way you're proposing it.
If you really, really, want a policy object that can deal with various exceptions, provide an exception handling policy that deals exclusively with exceptions but don't bind it to a particular UI. That EHPolicy may *use* UIManager but don't make it *be* UIManager.
Cheers,
- Andreas
On 30.07.2006, at 18:20, Pavel Krivanek wrote:
Hi all,
There's the new update for my kernel image for Squeak 3.9 (without next packages) http://www.comtalk.net/Squeak/uploads/20/bootstrap7052.zip
7052 is broken... please don't use it. It should never have been released.
7048 is the latest working version.
Marcus
Marcus Denker puso en su mail :
7052 is broken... please don't use it. It should never have been released.
7048 is the latest working version.
Marcus
Huuh ? I have a working 7051 from some previous and update fror servers. I have some complains in the pass to 7052 , so I keep 7051. Still don't blow ... Any comments ? Is safer download 7048 again and forget this .image ?
Very thanks.
Edgar
__________________________________________________ Pregunt�. Respond�. Descubr�. Todo lo que quer�as saber, y lo que ni imaginabas, est� en Yahoo! Respuestas (Beta). �Probalo ya! http://www.yahoo.com.ar/respuestas
On 31.07.2006, at 22:29, Lic. Edgar J. De Cleene wrote:
Marcus Denker puso en su mail :
7052 is broken... please don't use it. It should never have been released.
7048 is the latest working version.
MarcusHuuh ? I have a working 7051 from some previous and update fror servers. I have some complains in the pass to 7052 , so I keep 7051. Still don't blow ... Any comments ? Is safer download 7048 again and forget this .image ?
I'm planning to release an image based on 7048.... there is something completely wrong in 7049. It's the effect of doing the _ conversion on everything.
This was a mistake to do, as we are in beta.
So I will take 7048 and apply two or three fixes, and this then will be 3.9gamma
Marcus
Marcus Denker puso en su mail :
I'm planning to release an image based on 7048.... there is something completely wrong in 7049. It's the effect of doing the _ conversion on everything.
This was a mistake to do, as we are in beta.
So I will take 7048 and apply two or three fixes, and this then will be 3.9gamma
Marcus
Ok: Again, very thanks . Wait to gamma
Edgar
__________________________________________________ Pregunt�. Respond�. Descubr�. Todo lo que quer�as saber, y lo que ni imaginabas, est� en Yahoo! Respuestas (Beta). �Probalo ya! http://www.yahoo.com.ar/respuestas
On 8/2/06, Marcus Denker denker@iam.unibe.ch wrote:
On 31.07.2006, at 22:29, Lic. Edgar J. De Cleene wrote:
Marcus Denker puso en su mail :
7052 is broken... please don't use it. It should never have been released.
7048 is the latest working version.
MarcusHuuh ? I have a working 7051 from some previous and update fror servers. I have some complains in the pass to 7052 , so I keep 7051. Still don't blow ... Any comments ? Is safer download 7048 again and forget this .image ?
I'm planning to release an image based on 7048.... there is something completely wrong in 7049. It's the effect of doing the _ conversion on everything.
This was a mistake to do, as we are in beta.
So I will take 7048 and apply two or three fixes, and this then will be 3.9gamma
Marcus
I guess that sources of the kernel for 7052 and 7048 with next patches will be at least very similar so it will no problem to correct mirrors (I'm processing changes in assignments automatically). Thank you.
-- Pavel
Pavel Krivanek puso en su mail :
I guess that sources of the kernel for 7052 and 7048 with next patches will be at least very similar so it will no problem to correct mirrors (I'm processing changes in assignments automatically). Thank you.
-- Pavel
Pavel you are a master !
I take my questioned 7051 , what have yet some of my stuff and do your 7052 shrink. Almost works good, produce a 2.9 image with 487 classes.
If any wish this kernel7051,image, I could put somewhere.
Edgar
__________________________________________________ Pregunt�. Respond�. Descubr�. Todo lo que quer�as saber, y lo que ni imaginabas, est� en Yahoo! Respuestas (Beta). �Probalo ya! http://www.yahoo.com.ar/respuestas
On 8/2/06, Lic. Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
Pavel Krivanek puso en su mail :
I guess that sources of the kernel for 7052 and 7048 with next patches will be at least very similar so it will no problem to correct mirrors (I'm processing changes in assignments automatically). Thank you.
-- Pavel
Pavel you are a master !
I take my questioned 7051 , what have yet some of my stuff and do your 7052 shrink. Almost works good, produce a 2.9 image with 487 classes.
If any wish this kernel7051,image, I could put somewhere.
Edgar
the self-bootstrapping process changes all sources in the system so (in most cases) there is no problem if the image contains something more or is in another version. It should produce 477 classes and traits. Why do you have got 487?
-- Pavel
Pavel Krivanek puso en su mail :
the self-bootstrapping process changes all sources in the system so (in most cases) there is no problem if the image contains something more or is in another version. It should produce 477 classes and traits. Why do you have got 487?
-- Pavel
Because as I said , is a copy of the image what I using for test 3.9 and previous things what I made. Here is the all change set detail All to ScriptLoader-stephaneducasse.291 Plus Tracing Message Browser, a modified SARBuilder and some what I have. The image begins the 7052finalCleanup, but at this points complaints so I halt the procedure. Repeat, the working " Squeak3.9b-7051.image" don't shows any problem (until now). And the resultant "kernel7051" seems like others what I do following your procedure. Wish I test someone ? I ready to do.
Edgar
__________________________________________________ Pregunt�. Respond�. Descubr�. Todo lo que quer�as saber, y lo que ni imaginabas, est� en Yahoo! Respuestas (Beta). �Probalo ya! http://www.yahoo.com.ar/respuestas
On 8/2/06, Lic. Edgar J. De Cleene edgardec2001@yahoo.com.ar wrote:
Pavel Krivanek puso en su mail :
the self-bootstrapping process changes all sources in the system so (in most cases) there is no problem if the image contains something more or is in another version. It should produce 477 classes and traits. Why do you have got 487?
-- Pavel
Because as I said , is a copy of the image what I using for test 3.9 and previous things what I made. Here is the all change set detail All to ScriptLoader-stephaneducasse.291 Plus Tracing Message Browser, a modified SARBuilder and some what I have. The image begins the 7052finalCleanup, but at this points complaints so I halt the procedure. Repeat, the working " Squeak3.9b-7051.image" don't shows any problem (until now). And the resultant "kernel7051" seems like others what I do following your procedure. Wish I test someone ? I ready to do.
Edgar
We need all test green so it would be nice if you will be able to load published SUnit and look at current test failures and errors. You also may take the rest of Squeak and kernel for 7045 and try to continue with correct Morhpic initialization (this process will be the same for newer versions). The advantage is that you must not work in console. I think that we have to start with Preferences. You may take a look at SqueakSource MC repository (KernelImage) and try to make working well. Or you may start with refactoring of bootstrapping environment and split general and image specific parts.
-- Pavel
Pavel Krivanek puso en su mail :
We need all test green so it would be nice if you will be able to load published SUnit and look at current test failures and errors. You also may take the rest of Squeak and kernel for 7045 and try to continue with correct Morhpic initialization (this process will be the same for newer versions). The advantage is that you must not work in console. I think that we have to start with Preferences. You may take a look at SqueakSource MC repository (KernelImage) and try to make working well. Or you may start with refactoring of bootstrapping environment and split general and image specific parts.
-- Pavel
Ok I have some to do. I send any RestOfSqueak "modules" , "pieces" or what results to you. I like research if kernel could grow to a some arbitrary "app"
Edgar
__________________________________________________ Pregunt�. Respond�. Descubr�. Todo lo que quer�as saber, y lo que ni imaginabas, est� en Yahoo! Respuestas (Beta). �Probalo ya! http://www.yahoo.com.ar/respuestas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Klaus D. Witzel -
Lic. Edgar J. De Cleene -
Marcus Denker -
Pavel Krivanek