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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Pavel Krivanek
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

Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

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

Pavel Krivanek
On 7/30/06, Andreas Raab <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Klaus D. Witzel
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 <[hidden email]> 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
>
>



Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
In reply to this post by Pavel Krivanek
Pavel Krivanek wrote:

> On 7/30/06, Andreas Raab <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Pavel Krivanek
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:

> Pavel Krivanek wrote:
> > On 7/30/06, Andreas Raab <[hidden email]> 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
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Marcus Denker
In reply to this post by Pavel Krivanek

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


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Edgar J. De Cleene
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


Reply | Threaded
Open this post in threaded view
|

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

Marcus Denker

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.
>>
>>
>>      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 ?
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


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Edgar J. De Cleene
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


Reply | Threaded
Open this post in threaded view
|

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

Pavel Krivanek
In reply to this post by Marcus Denker
On 8/2/06, Marcus Denker <[hidden email]> 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.
> >>
> >>
> >>      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 ?
>
> 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

Reply | Threaded
Open this post in threaded view
|

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

Edgar J. De Cleene
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


Reply | Threaded
Open this post in threaded view
|

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

Pavel Krivanek
On 8/2/06, Lic. Edgar J. De Cleene <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Edgar J. De Cleene
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


Reply | Threaded
Open this post in threaded view
|

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

Pavel Krivanek
On 8/2/06, Lic. Edgar J. De Cleene <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Edgar J. De Cleene
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