On Fri, Aug 19, 2011 at 1:38 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 19 August 2011 11:41, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:

...

Hi,

Igor changed some uses of "Transcript" to "Smalltalk tools transcript". Of course it is not bad idea however it has some unwelcome consequences - mainly it cannot work on images that have no tools and Pharo Kernel and most of derived images have no ToolRegistry at all. Currently it breaks Pharo Kernel job on CI server.

Here are affected methods:

Object>>crLog: {logging} Object>>log: {logging} Object>>logCr: {logging} Object>>logCrTab: {logging}

Of course the simplest way how to fix that is revert previous versions of this methods. However we may use some more general solution where ToolRegistry will be part of the kernel but then we will have to solve questions what tools are default, what to do if the tool class is missing etc.

Is 'Smalltalk' global name part of kernel? If so, then i think SmalltalkImage should be too and ToolRegistry.

Tool registry is just a registry. It doesn't imposing the existance of one or another tool. If tool with given name is missing, then attempt to use it will lead for error.

The question why to have registry for something what is not necessary. Some applications may want to remove tools from the image so to place tools support to the kernel is a regression. The only tool that is required for the Kernel now is Transcript for some Compiler messages etc. I think that there is one much better solution - to remove Transcript dependency from the kernel and for such messages to use UIManager (something like #log: or maybe better #logStream). MorphicUIManager then will use Transcript. -- Pavel

2011/8/19 Pavel Krivanek <pavel.krivanek@gmail.com>:

On Fri, Aug 19, 2011 at 1:38 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 19 August 2011 11:41, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:

...

Hi,

Igor changed some uses of "Transcript" to "Smalltalk tools transcript". Of course it is not bad idea however it has some unwelcome consequences - mainly it cannot work on images that have no tools and Pharo Kernel and most of derived images have no ToolRegistry at all. Currently it breaks Pharo Kernel job on CI server.

Here are affected methods:

Object>>crLog: {logging} Object>>log: {logging} Object>>logCr: {logging} Object>>logCrTab: {logging}

Of course the simplest way how to fix that is revert previous versions of this methods. However we may use some more general solution where ToolRegistry will be part of the kernel but then we will have to solve questions what tools are default, what to do if the tool class is missing etc.

Is 'Smalltalk' global name part of kernel? If so, then i think SmalltalkImage should be too and ToolRegistry.

Tool registry is just a registry. It doesn't imposing the existance of one or another tool. If tool with given name is missing, then attempt to use it will lead for error.

The question why to have registry for something what is not necessary. Some applications may  want to remove tools from the image so to place tools support to the kernel is a regression. The only tool that is required for the Kernel now is Transcript for some Compiler messages etc. I think that there is one much better solution - to remove Transcript dependency from the kernel and for such messages to use UIManager (something like #log: or maybe better #logStream). MorphicUIManager then will use Transcript.

-- Pavel

Then it could be (Smalltalk ui crLog:) instead of (Smalltalk tools transcript...) Or (UIManager deault crLog: ). The question is whether there is any interest in replacing a bunch of ThisOrThatManagerHandlerOrWhatever by a message send, and dispatch all these message to the System (Smalltalk). Nicolas