Kernel.image update for 7052 and my vision of the next development

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 <[hidden email]> wrote:
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:

Pavel Krivanek wrote:
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 <[hidden email]> wrote:

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:
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 :
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 <[hidden email]> wrote:
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 <[hidden email]> wrote:
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 <[hidden email]> wrote:
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 :
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