Smalltalk › Squeak › Squeak - Dev

Logging from the Compiler

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

Frank Shearar-3

Logging from the Compiler

Compiler depends on System because changing stuff - adding methods,
changing classes, etc. - sends messages to SystemChangeNotifier
uniqueInstance.

While convenient, it (a) is inflexible and (b) causes a cycle. The
correct relationship is that System uses Compiler.

With that in mind, _a_ solution to this problem is to log things
through a callback/registration mechanism of some kind. If you care
about logging, you create a Compiler, say "log here" and off you go.
(This means that you remove the log: part of a lot of methods in
Compiler - if you don't have a logger/loggers attached, nothing
happens, rather than logThis ifTrue: [] blocks. (Because you by
default have a null logger.))

Thoughts? Other possible approaches?

frank

Tobias Pape

Re: Logging from the Compiler

On 08.12.2013, at 23:46, Frank Shearar <[hidden email]> wrote:

> Compiler depends on System because changing stuff - adding methods,
> changing classes, etc. - sends messages to SystemChangeNotifier
> uniqueInstance.
>
> While convenient, it (a) is inflexible and (b) causes a cycle. The
> correct relationship is that System uses Compiler.
>
> With that in mind, _a_ solution to this problem is to log things
> through a callback/registration mechanism of some kind. If you care
> about logging, you create a Compiler, say "log here" and off you go.
> (This means that you remove the log: part of a lot of methods in
> Compiler - if you don't have a logger/loggers attached, nothing
> happens, rather than logThis ifTrue: [] blocks. (Because you by
> default have a null logger.))
>
> Thoughts? Other possible approaches?

+1 from skimming your idea.
Best
-Tobias

Chris Muller-3

Re: Logging from the Compiler

In reply to this post by Frank Shearar-3

Move SystemChangeNotifier to Kernel.

Really, it's something not only the Compiler NEEDS, there's also
ClassDescription and ClassOrganizer, and the uses are more than just
incidental.

On Sun, Dec 8, 2013 at 4:46 PM, Frank Shearar <[hidden email]> wrote:

Tobias Pape

Re: Logging from the Compiler

On 09.12.2013, at 01:10, Chris Muller <[hidden email]> wrote:

> Move SystemChangeNotifier to Kernel.
>
> Really, it's something not only the Compiler NEEDS, there's also
> ClassDescription and ClassOrganizer, and the uses are more than just
> incidental.

Well I see it that way:
there is chance, that a Squeak-Image is locked down for deployment,
where compiler, et. al. is absent. Kernel would certainly a package
which would still be there, but packages like Compiler not so.
Do you think, SystemChangeNotifier should be loaded then or not?

Best
-Tobias

signature.asc (1K) Download Attachment

Chris Muller-3

Re: Logging from the Compiler

On Mon, Dec 9, 2013 at 5:44 AM, Tobias Pape <[hidden email]> wrote:

> On 09.12.2013, at 01:10, Chris Muller <[hidden email]> wrote:
>
>> Move SystemChangeNotifier to Kernel.
>>
>> Really, it's something not only the Compiler NEEDS, there's also
>> ClassDescription and ClassOrganizer, and the uses are more than just
>> incidental.
>
> Well I see it that way:
> there is chance, that a Squeak-Image is locked down for deployment,
> where compiler, et. al. is absent. Kernel would certainly a package
> which would still be there, but packages like Compiler not so.
> Do you think, SystemChangeNotifier should be loaded then or not?

Yes, SystemChangeNotifier should still be present because compiling
new methods are not the only kinds of changes it notifies about.
_Removing a method_ from the system is also a change which can signal
the SystemChangeNotifier.

More importantly though, I'd like to ask you, since you imply the
Compiler should be an optional component in the "Core", and a "Core"
image is required to be able to expand and configure itself up to some
vertical purpose from additional packages, how would this be
accomplished without the Compiler in the image? e.g., how to get the
Compiler without the Compiler? (Simply loading bytecodes is not
sufficient for configuration).

IOW, we need to stop ignoring the use-cases for stripping / shrinking...

timrowledge

Re: Logging from the Compiler

On 09-12-2013, at 9:07 AM, Chris Muller <[hidden email]> wrote:
>
> More importantly though, I'd like to ask you, since you imply the
> Compiler should be an optional component in the "Core", and a "Core"
> image is required to be able to expand and configure itself up to some
> vertical purpose from additional packages, how would this be
> accomplished without the Compiler in the image?

Strictly speaking you don’t need the compiler to add code, only to add code that needs, err, compiling. You can, for example add code as an ImageSegment (or at least you used to be able to; does it still work?) or via the mechanism Craig uses in Spoon. One could argue that we are using the image segment /spoon code as a compiler in these cases, but I’d probably have to rap knuckles for imprecision.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LOW: Launch on Warning

Frank Shearar-3

Re: Logging from the Compiler

In reply to this post by Chris Muller-3

On 9 December 2013 17:07, Chris Muller <[hidden email]> wrote:

> On Mon, Dec 9, 2013 at 5:44 AM, Tobias Pape <[hidden email]> wrote:
>> On 09.12.2013, at 01:10, Chris Muller <[hidden email]> wrote:
>>
>>> Move SystemChangeNotifier to Kernel.
>>>
>>> Really, it's something not only the Compiler NEEDS, there's also
>>> ClassDescription and ClassOrganizer, and the uses are more than just
>>> incidental.
>>
>> Well I see it that way:
>> there is chance, that a Squeak-Image is locked down for deployment,
>> where compiler, et. al. is absent. Kernel would certainly a package
>> which would still be there, but packages like Compiler not so.
>> Do you think, SystemChangeNotifier should be loaded then or not?
>
> Yes, SystemChangeNotifier should still be present because compiling
> new methods are not the only kinds of changes it notifies about.
> _Removing a method_ from the system is also a change which can signal
> the SystemChangeNotifier.
>
> More importantly though, I'd like to ask you, since you imply the
> Compiler should be an optional component in the "Core", and a "Core"
> image is required to be able to expand and configure itself up to some
> vertical purpose from additional packages, how would this be
> accomplished without the Compiler in the image? e.g., how to get the
> Compiler without the Compiler? (Simply loading bytecodes is not
> sufficient for configuration).
>
> IOW, we need to stop ignoring the use-cases for stripping / shrinking...

I am unaware of anyone ignoring stripping/shrinking, or their use
cases. I'm pretty sure I've stated several times that I understand why
people might want/need to use it. It's also orthogonal to modularity.
You can happily shrink images that have all classes in the entire
system in a single package. Or an image that has _no_ packages, for
that matter.

But like tim points out, you don't need a compiler to add methods or
classes to the system. And if you can't unload Compiler, how are you
ever going to replace it?

frank

ccrraaiigg

re: Logging from the Compiler

In reply to this post by timrowledge

> Strictly speaking you don’t need the compiler to add code, only to
> add code that needs, err, compiling. You can, for example add code as
> an ImageSegment (or at least you used to be able to; does it still
> work?) or via the mechanism Craig uses in Spoon.

...which is called "imprinting". See [1].

> One could argue that we are using the image segment / spoon code as a
> compiler in these cases, but I’d probably have to rap knuckles for
> imprecision.

Yeah, I'd call that wrong. With imprinting, you're installing code
which was previously compiled somehow. As long as the target execution
environment at the time of execution is compatible with the compilation
environment at the time of compilation, you're good.

-C

[1] http://thiscontext.com/a-detailed-naiad-description

--
Craig Latta
www.netjam.org/resume
+1 510 984 8117
(Skype rings this until 31 January 2014)

Frank Shearar-3

Re: Logging from the Compiler

In reply to this post by Chris Muller-3

On 09 Dec 2013, at 0:10, Chris Muller <[hidden email]> wrote:

> Move SystemChangeNotifier to Kernel.

Well that's certainly a step at least approximately forwards. It's not just SystemChangeNotifier that would need to move though: all of System-Change Notifications and System-Object Events would have to move too.

Which is why I'd prefer something that didn't bloat up Kernel. Because one day we'll have to untangle Kernel, too.

But it does at least rid several packages of their dependency on System.

frank

> Really, it's something not only the Compiler NEEDS, there's also
> ClassDescription and ClassOrganizer, and the uses are more than just
> incidental.
>
>
> On Sun, Dec 8, 2013 at 4:46 PM, Frank Shearar <[hidden email]> wrote:
>> Compiler depends on System because changing stuff - adding methods,
>> changing classes, etc. - sends messages to SystemChangeNotifier
>> uniqueInstance.
>>
>> While convenient, it (a) is inflexible and (b) causes a cycle. The
>> correct relationship is that System uses Compiler.
>>
>> With that in mind, _a_ solution to this problem is to log things
>> through a callback/registration mechanism of some kind. If you care
>> about logging, you create a Compiler, say "log here" and off you go.
>> (This means that you remove the log: part of a lot of methods in
>> Compiler - if you don't have a logger/loggers attached, nothing
>> happens, rather than logThis ifTrue: [] blocks. (Because you by
>> default have a null logger.))
>>
>> Thoughts? Other possible approaches?
>>
>> frank
>>
>

Chris Muller-3

Re: Logging from the Compiler

In reply to this post by Frank Shearar-3

On Mon, Dec 9, 2013 at 12:37 PM, Frank Shearar <[hidden email]> wrote:

> On 9 December 2013 17:07, Chris Muller <[hidden email]> wrote:
>> On Mon, Dec 9, 2013 at 5:44 AM, Tobias Pape <[hidden email]> wrote:
>>> On 09.12.2013, at 01:10, Chris Muller <[hidden email]> wrote:
>>>
>>>> Move SystemChangeNotifier to Kernel.
>>>>
>>>> Really, it's something not only the Compiler NEEDS, there's also
>>>> ClassDescription and ClassOrganizer, and the uses are more than just
>>>> incidental.
>>>
>>> Well I see it that way:
>>> there is chance, that a Squeak-Image is locked down for deployment,
>>> where compiler, et. al. is absent. Kernel would certainly a package
>>> which would still be there, but packages like Compiler not so.
>>> Do you think, SystemChangeNotifier should be loaded then or not?
>>
>> Yes, SystemChangeNotifier should still be present because compiling
>> new methods are not the only kinds of changes it notifies about.
>> _Removing a method_ from the system is also a change which can signal
>> the SystemChangeNotifier.
>>
>> More importantly though, I'd like to ask you, since you imply the
>> Compiler should be an optional component in the "Core", and a "Core"
>> image is required to be able to expand and configure itself up to some
>> vertical purpose from additional packages, how would this be
>> accomplished without the Compiler in the image? e.g., how to get the
>> Compiler without the Compiler? (Simply loading bytecodes is not
>> sufficient for configuration).
>>
>> IOW, we need to stop ignoring the use-cases for stripping / shrinking...
>
> I am unaware of anyone ignoring stripping/shrinking, or their use
> cases.

Tobias was just talking about deploying a production image without the
Compiler -- but didn't mention one way of doing that would be to
simply _remove_ Compiler from the system.

> I'm pretty sure I've stated several times that I understand why
> people might want/need to use it. It's also orthogonal to modularity.

The goals of the two are closely aligned. Starting from a Core and
loading a bunch of small packages is not the only way to get
somewhere.

> You can happily shrink images that have all classes in the entire
> system in a single package. Or an image that has _no_ packages, for
> that matter.

Exactly. When talking about making systems that do real-world work,
the package hierarchy has little to do with anything other than being
a subjectively "organized" collection of behaviors. Hence my desire
for such organization to be geared for humans rather than systems.

Frank Shearar-3

Re: Logging from the Compiler

In reply to this post by Frank Shearar-3

On 9 December 2013 19:34, Frank Shearar <[hidden email]> wrote:
> On 09 Dec 2013, at 0:10, Chris Muller <[hidden email]> wrote:
>
>> Move SystemChangeNotifier to Kernel.
>
> Well that's certainly a step at least approximately forwards. It's not just SystemChangeNotifier that would need to move though: all of System-Change Notifications and System-Object Events would have to move too.
>
> Which is why I'd prefer something that didn't bloat up Kernel. Because one day we'll have to untangle Kernel, too.
>
> But it does at least rid several packages of their dependency on System.

Pulling the thread back to its original topic!

Moving SystemChangeNotifier to Kernel would solve my immediate package
problems, at the cost of
* preserving the inflexible logging
* adding _17_ classes to Kernel.

I would still prefer to make the Compiler "loggable", so you'd inject
whatever logger you wanted. However, that (a) requires someone to
actually do the work and (b) would take quite a while. Oh, and (c)
mucking around with Compiler means being very careful or breaking
things very badly.

So I'm kind've +0.5 about moving SystemChangeNotifier to Kernel. It
_does_ remove a bunch of dependencies on System. (Reminder: depending
on System is only bad^Wproblematic because System depends on too many
other packages. If you're one of these packages, hey, cycle time!)

Step up! Vote!

frank

> frank
>
>> Really, it's something not only the Compiler NEEDS, there's also
>> ClassDescription and ClassOrganizer, and the uses are more than just
>> incidental.
>>
>>
>> On Sun, Dec 8, 2013 at 4:46 PM, Frank Shearar <[hidden email]> wrote:
>>> Compiler depends on System because changing stuff - adding methods,
>>> changing classes, etc. - sends messages to SystemChangeNotifier
>>> uniqueInstance.
>>>
>>> While convenient, it (a) is inflexible and (b) causes a cycle. The
>>> correct relationship is that System uses Compiler.
>>>
>>> With that in mind, _a_ solution to this problem is to log things
>>> through a callback/registration mechanism of some kind. If you care
>>> about logging, you create a Compiler, say "log here" and off you go.
>>> (This means that you remove the log: part of a lot of methods in
>>> Compiler - if you don't have a logger/loggers attached, nothing
>>> happens, rather than logThis ifTrue: [] blocks. (Because you by
>>> default have a null logger.))
>>>
>>> Thoughts? Other possible approaches?
>>>
>>> frank
>>>
>>

Nicolas Cellier

Re: Logging from the Compiler

I don't like it much. It's not really a Kenel thing.

For Compiler, that's very simple, remove the logging facility.
A Compiler is there to Compile and/or Evaluate, and that's well enough.

If you want logging ask any ad-hoc class in the System - Utilities for example (no no! I'm joking).

For all the Kernel classes wanting to trigger some system change events, I don't know.

Maybe it's a sign that System has to be split.
Or we could have kernel methods doing only kernel things, and higher level methods classified in System doing more housekeeping.

Like basicRemoveSelector: (Kernel) vs removeSelector: (System), maybe with better names...

Or Behavior>>removeSelector: (Kernel) ClassDescription>>removeSelector: (System)

2013/12/10 Frank Shearar <[hidden email]>

On 9 December 2013 19:34, Frank Shearar <[hidden email]> wrote:
> On 09 Dec 2013, at 0:10, Chris Muller <[hidden email]> wrote:
>
>> Move SystemChangeNotifier to Kernel.
>
> Well that's certainly a step at least approximately forwards. It's not just SystemChangeNotifier that would need to move though: all of System-Change Notifications and System-Object Events would have to move too.
>
> Which is why I'd prefer something that didn't bloat up Kernel. Because one day we'll have to untangle Kernel, too.
>
> But it does at least rid several packages of their dependency on System.

Pulling the thread back to its original topic!

Moving SystemChangeNotifier to Kernel would solve my immediate package
problems, at the cost of
* preserving the inflexible logging
* adding _17_ classes to Kernel.

I would still prefer to make the Compiler "loggable", so you'd inject
whatever logger you wanted. However, that (a) requires someone to
actually do the work and (b) would take quite a while. Oh, and (c)
mucking around with Compiler means being very careful or breaking
things very badly.

So I'm kind've +0.5 about moving SystemChangeNotifier to Kernel. It
_does_ remove a bunch of dependencies on System. (Reminder: depending
on System is only bad^Wproblematic because System depends on too many
other packages. If you're one of these packages, hey, cycle time!)

Step up! Vote!

frank

> frank
>
>> Really, it's something not only the Compiler NEEDS, there's also
>> ClassDescription and ClassOrganizer, and the uses are more than just
>> incidental.
>>
>>
>> On Sun, Dec 8, 2013 at 4:46 PM, Frank Shearar <[hidden email]> wrote:
>>> Compiler depends on System because changing stuff - adding methods,
>>> changing classes, etc. - sends messages to SystemChangeNotifier
>>> uniqueInstance.
>>>
>>> While convenient, it (a) is inflexible and (b) causes a cycle. The
>>> correct relationship is that System uses Compiler.
>>>
>>> With that in mind, _a_ solution to this problem is to log things
>>> through a callback/registration mechanism of some kind. If you care
>>> about logging, you create a Compiler, say "log here" and off you go.
>>> (This means that you remove the log: part of a lot of methods in
>>> Compiler - if you don't have a logger/loggers attached, nothing
>>> happens, rather than logThis ifTrue: [] blocks. (Because you by
>>> default have a null logger.))
>>>
>>> Thoughts? Other possible approaches?
>>>
>>> frank
>>>
>>

Chris Muller-3

Re: Logging from the Compiler

Moving it to Kernel scratches the immediate dependency itch without
inhibiting any future ideas. There's no rush. There's plenty of time
to think about and discuss changing it into something that can
satisfies everyone's functional and aesthetic needs.

On Tue, Dec 10, 2013 at 3:45 PM, Nicolas Cellier
<[hidden email]> wrote:

> I don't like it much. It's not really a Kenel thing.
> For Compiler, that's very simple, remove the logging facility.
> A Compiler is there to Compile and/or Evaluate, and that's well enough.
> If you want logging ask any ad-hoc class in the System - Utilities for
> example (no no! I'm joking).
>
> For all the Kernel classes wanting to trigger some system change events, I
> don't know.
> Maybe it's a sign that System has to be split.
> Or we could have kernel methods doing only kernel things, and higher level
> methods classified in System doing more housekeeping.
> Like basicRemoveSelector: (Kernel) vs removeSelector: (System), maybe with
> better names...
> Or Behavior>>removeSelector: (Kernel) ClassDescription>>removeSelector:
> (System)
>
>
> 2013/12/10 Frank Shearar <[hidden email]>
>>
>> On 9 December 2013 19:34, Frank Shearar <[hidden email]> wrote:
>> > On 09 Dec 2013, at 0:10, Chris Muller <[hidden email]> wrote:
>> >
>> >> Move SystemChangeNotifier to Kernel.
>> >
>> > Well that's certainly a step at least approximately forwards. It's not
>> > just SystemChangeNotifier that would need to move though: all of
>> > System-Change Notifications and System-Object Events would have to move too.
>> >
>> > Which is why I'd prefer something that didn't bloat up Kernel. Because
>> > one day we'll have to untangle Kernel, too.
>> >
>> > But it does at least rid several packages of their dependency on System.
>>
>> Pulling the thread back to its original topic!
>>
>> Moving SystemChangeNotifier to Kernel would solve my immediate package
>> problems, at the cost of
>> * preserving the inflexible logging
>> * adding _17_ classes to Kernel.
>>
>> I would still prefer to make the Compiler "loggable", so you'd inject
>> whatever logger you wanted. However, that (a) requires someone to
>> actually do the work and (b) would take quite a while. Oh, and (c)
>> mucking around with Compiler means being very careful or breaking
>> things very badly.
>>
>> So I'm kind've +0.5 about moving SystemChangeNotifier to Kernel. It
>> _does_ remove a bunch of dependencies on System. (Reminder: depending
>> on System is only bad^Wproblematic because System depends on too many
>> other packages. If you're one of these packages, hey, cycle time!)
>>
>> Step up! Vote!
>>
>> frank
>>
>> > frank
>> >
>> >> Really, it's something not only the Compiler NEEDS, there's also
>> >> ClassDescription and ClassOrganizer, and the uses are more than just
>> >> incidental.
>> >>
>> >>
>> >> On Sun, Dec 8, 2013 at 4:46 PM, Frank Shearar <[hidden email]>
>> >> wrote:
>> >>> Compiler depends on System because changing stuff - adding methods,
>> >>> changing classes, etc. - sends messages to SystemChangeNotifier
>> >>> uniqueInstance.
>> >>>
>> >>> While convenient, it (a) is inflexible and (b) causes a cycle. The
>> >>> correct relationship is that System uses Compiler.
>> >>>
>> >>> With that in mind, _a_ solution to this problem is to log things
>> >>> through a callback/registration mechanism of some kind. If you care
>> >>> about logging, you create a Compiler, say "log here" and off you go.
>> >>> (This means that you remove the log: part of a lot of methods in
>> >>> Compiler - if you don't have a logger/loggers attached, nothing
>> >>> happens, rather than logThis ifTrue: [] blocks. (Because you by
>> >>> default have a null logger.))
>> >>>
>> >>> Thoughts? Other possible approaches?
>> >>>
>> >>> frank
>> >>>
>> >>
>>
>
>
>
>

Colin Putney-3

Re: Logging from the Compiler

In reply to this post by Frank Shearar-3

On Sun, Dec 8, 2013 at 5:46 PM, Frank Shearar <[hidden email]> wrote:

Compiler depends on System because changing stuff - adding methods,
changing classes, etc. - sends messages to SystemChangeNotifier
uniqueInstance.

While convenient, it (a) is inflexible and (b) causes a cycle. The
correct relationship is that System uses Compiler.

With that in mind, _a_ solution to this problem is to log things
through a callback/registration mechanism of some kind. If you care
about logging, you create a Compiler, say "log here" and off you go.
(This means that you remove the log: part of a lot of methods in
Compiler - if you don't have a logger/loggers attached, nothing
happens, rather than logThis ifTrue: [] blocks. (Because you by
default have a null logger.))

Thoughts? Other possible approaches?

One thing we ought to do is look at what Pharo has done here. IIRC, they got rid of SystemChangeNotifier, and use Announcements instead. That might, or might not, solve the problem at hand, but it if it does, compatibility would be a plus, and it's probably less work than coming up with something new.

Colin

Frank Shearar-3

Re: Logging from the Compiler

In reply to this post by Chris Muller-3

That is largely true, but I have a little voice in my head screaming
"no! no! no!" because the change is just too easy.

So far we have +1.5 from Chris and I, and -1 from Nicolas. Eliot?
Bert? Everyone else?

frank

On 12 December 2013 00:04, Chris Muller <[hidden email]> wrote:

> Moving it to Kernel scratches the immediate dependency itch without
> inhibiting any future ideas. There's no rush. There's plenty of time
> to think about and discuss changing it into something that can
> satisfies everyone's functional and aesthetic needs.
>
> On Tue, Dec 10, 2013 at 3:45 PM, Nicolas Cellier
> <[hidden email]> wrote:
>> I don't like it much. It's not really a Kenel thing.
>> For Compiler, that's very simple, remove the logging facility.
>> A Compiler is there to Compile and/or Evaluate, and that's well enough.
>> If you want logging ask any ad-hoc class in the System - Utilities for
>> example (no no! I'm joking).
>>
>> For all the Kernel classes wanting to trigger some system change events, I
>> don't know.
>> Maybe it's a sign that System has to be split.
>> Or we could have kernel methods doing only kernel things, and higher level
>> methods classified in System doing more housekeeping.
>> Like basicRemoveSelector: (Kernel) vs removeSelector: (System), maybe with
>> better names...
>> Or Behavior>>removeSelector: (Kernel) ClassDescription>>removeSelector:
>> (System)
>>
>>
>> 2013/12/10 Frank Shearar <[hidden email]>
>>>
>>> On 9 December 2013 19:34, Frank Shearar <[hidden email]> wrote:
>>> > On 09 Dec 2013, at 0:10, Chris Muller <[hidden email]> wrote:
>>> >
>>> >> Move SystemChangeNotifier to Kernel.
>>> >
>>> > Well that's certainly a step at least approximately forwards. It's not
>>> > just SystemChangeNotifier that would need to move though: all of
>>> > System-Change Notifications and System-Object Events would have to move too.
>>> >
>>> > Which is why I'd prefer something that didn't bloat up Kernel. Because
>>> > one day we'll have to untangle Kernel, too.
>>> >
>>> > But it does at least rid several packages of their dependency on System.
>>>
>>> Pulling the thread back to its original topic!
>>>
>>> Moving SystemChangeNotifier to Kernel would solve my immediate package
>>> problems, at the cost of
>>> * preserving the inflexible logging
>>> * adding _17_ classes to Kernel.
>>>
>>> I would still prefer to make the Compiler "loggable", so you'd inject
>>> whatever logger you wanted. However, that (a) requires someone to
>>> actually do the work and (b) would take quite a while. Oh, and (c)
>>> mucking around with Compiler means being very careful or breaking
>>> things very badly.
>>>
>>> So I'm kind've +0.5 about moving SystemChangeNotifier to Kernel. It
>>> _does_ remove a bunch of dependencies on System. (Reminder: depending
>>> on System is only bad^Wproblematic because System depends on too many
>>> other packages. If you're one of these packages, hey, cycle time!)
>>>
>>> Step up! Vote!
>>>
>>> frank
>>>
>>> > frank
>>> >
>>> >> Really, it's something not only the Compiler NEEDS, there's also
>>> >> ClassDescription and ClassOrganizer, and the uses are more than just
>>> >> incidental.
>>> >>
>>> >>
>>> >> On Sun, Dec 8, 2013 at 4:46 PM, Frank Shearar <[hidden email]>
>>> >> wrote:
>>> >>> Compiler depends on System because changing stuff - adding methods,
>>> >>> changing classes, etc. - sends messages to SystemChangeNotifier
>>> >>> uniqueInstance.
>>> >>>
>>> >>> While convenient, it (a) is inflexible and (b) causes a cycle. The
>>> >>> correct relationship is that System uses Compiler.
>>> >>>
>>> >>> With that in mind, _a_ solution to this problem is to log things
>>> >>> through a callback/registration mechanism of some kind. If you care
>>> >>> about logging, you create a Compiler, say "log here" and off you go.
>>> >>> (This means that you remove the log: part of a lot of methods in
>>> >>> Compiler - if you don't have a logger/loggers attached, nothing
>>> >>> happens, rather than logThis ifTrue: [] blocks. (Because you by
>>> >>> default have a null logger.))
>>> >>>
>>> >>> Thoughts? Other possible approaches?
>>> >>>
>>> >>> frank
>>> >>>
>>> >>
>>>
>>
>>
>>
>>
>

Eliot Miranda-2

Re: Logging from the Compiler

On Thu, Dec 12, 2013 at 1:59 AM, Frank Shearar <[hidden email]> wrote:

That is largely true, but I have a little voice in my head screaming
"no! no! no!" because the change is just too easy.

So far we have +1.5 from Chris and I, and -1 from Nicolas. Eliot?

I like the Announcements route. SystemChangeNotifier is a dog. Compatibility with Pharo is in the long-term very important (but it has to be a two-way street, and not blind).

Bert? Everyone else?

frank

On 12 December 2013 00:04, Chris Muller <[hidden email]> wrote:
> Moving it to Kernel scratches the immediate dependency itch without
> inhibiting any future ideas. There's no rush. There's plenty of time
> to think about and discuss changing it into something that can
> satisfies everyone's functional and aesthetic needs.
>
> On Tue, Dec 10, 2013 at 3:45 PM, Nicolas Cellier
> <[hidden email]> wrote:
>> I don't like it much. It's not really a Kenel thing.
>> For Compiler, that's very simple, remove the logging facility.
>> A Compiler is there to Compile and/or Evaluate, and that's well enough.
>> If you want logging ask any ad-hoc class in the System - Utilities for
>> example (no no! I'm joking).
>>
>> For all the Kernel classes wanting to trigger some system change events, I
>> don't know.
>> Maybe it's a sign that System has to be split.
>> Or we could have kernel methods doing only kernel things, and higher level
>> methods classified in System doing more housekeeping.
>> Like basicRemoveSelector: (Kernel) vs removeSelector: (System), maybe with
>> better names...
>> Or Behavior>>removeSelector: (Kernel) ClassDescription>>removeSelector:
>> (System)
>>
>>
>> 2013/12/10 Frank Shearar <[hidden email]>
>>>
>>> On 9 December 2013 19:34, Frank Shearar <[hidden email]> wrote:
>>> > On 09 Dec 2013, at 0:10, Chris Muller <[hidden email]> wrote:
>>> >
>>> >> Move SystemChangeNotifier to Kernel.
>>> >
>>> > Well that's certainly a step at least approximately forwards. It's not
>>> > just SystemChangeNotifier that would need to move though: all of
>>> > System-Change Notifications and System-Object Events would have to move too.
>>> >
>>> > Which is why I'd prefer something that didn't bloat up Kernel. Because
>>> > one day we'll have to untangle Kernel, too.
>>> >
>>> > But it does at least rid several packages of their dependency on System.
>>>
>>> Pulling the thread back to its original topic!
>>>
>>> Moving SystemChangeNotifier to Kernel would solve my immediate package
>>> problems, at the cost of
>>> * preserving the inflexible logging
>>> * adding _17_ classes to Kernel.
>>>
>>> I would still prefer to make the Compiler "loggable", so you'd inject
>>> whatever logger you wanted. However, that (a) requires someone to
>>> actually do the work and (b) would take quite a while. Oh, and (c)
>>> mucking around with Compiler means being very careful or breaking
>>> things very badly.
>>>
>>> So I'm kind've +0.5 about moving SystemChangeNotifier to Kernel. It
>>> _does_ remove a bunch of dependencies on System. (Reminder: depending
>>> on System is only bad^Wproblematic because System depends on too many
>>> other packages. If you're one of these packages, hey, cycle time!)
>>>
>>> Step up! Vote!
>>>
>>> frank
>>>
>>> > frank
>>> >
>>> >> Really, it's something not only the Compiler NEEDS, there's also
>>> >> ClassDescription and ClassOrganizer, and the uses are more than just
>>> >> incidental.
>>> >>
>>> >>
>>> >> On Sun, Dec 8, 2013 at 4:46 PM, Frank Shearar <[hidden email]>
>>> >> wrote:
>>> >>> Compiler depends on System because changing stuff - adding methods,
>>> >>> changing classes, etc. - sends messages to SystemChangeNotifier
>>> >>> uniqueInstance.
>>> >>>
>>> >>> While convenient, it (a) is inflexible and (b) causes a cycle. The
>>> >>> correct relationship is that System uses Compiler.
>>> >>>
>>> >>> With that in mind, _a_ solution to this problem is to log things
>>> >>> through a callback/registration mechanism of some kind. If you care
>>> >>> about logging, you create a Compiler, say "log here" and off you go.
>>> >>> (This means that you remove the log: part of a lot of methods in
>>> >>> Compiler - if you don't have a logger/loggers attached, nothing
>>> >>> happens, rather than logThis ifTrue: [] blocks. (Because you by
>>> >>> default have a null logger.))
>>> >>>
>>> >>> Thoughts? Other possible approaches?
>>> >>>
>>> >>> frank
>>> >>>
>>> >>
>>>
>>
>>
>>
>>
>

--
best,

Eliot

Chris Muller-3

Re: Logging from the Compiler

I like the Announcements route. SystemChangeNotifier is a dog. Compatibility with Pharo is in the long-term very important

Freedom from Pharo constraints is even more important.

(but it has to be a two-way street, and not blind).

I don't believe Pharo will ever be interested in a two-way street of compatibility with Squeak. If anything, the opposite. Neither group is interested in feeling constrained by the other. The Pharo fork happened for good reasons.

We should pursue our own wildest imaginations, not follow Pharo. We should steal components of Pharo which offer the kind of functional leverage ratio's appropriate for Squeak.

PS -- None of the above should imply I'm against Announcements. I know nothing about it other than its Listener Pattern le Grande. Hopefully not too heavyweight..

Frank Shearar-3

Re: Logging from the Compiler

On 12 December 2013 19:43, Chris Muller <[hidden email]> wrote:

>> I like the Announcements route. SystemChangeNotifier is a dog.
>> Compatibility with Pharo is in the long-term very important
>
>
> Freedom from Pharo constraints is even more important.
>
>> (but it has to be a two-way street, and not blind).
>
>
> I don't believe Pharo will ever be interested in a two-way street of
> compatibility with Squeak. If anything, the opposite. Neither group is
> interested in feeling constrained by the other. The Pharo fork happened for
> good reasons.
>
> We should pursue our own wildest imaginations, not follow Pharo.

No arguments, but...

> We should
> steal components of Pharo which offer the kind of functional leverage
> ratio's appropriate for Squeak.

... you can't do that without some kind of compatibility. Not without
entirely rewriting stuff, which is kind've missing the point of
stealing.

frank

> PS -- None of the above should imply I'm against Announcements. I know
> nothing about it other than its Listener Pattern le Grande. Hopefully not
> too heavyweight..
>
>
>
>

Nicolas Cellier

Re: Logging from the Compiler

Another path is to contribute to Pharo, you know the best way to predict the future etc...

2013/12/12 Frank Shearar <[hidden email]>

On 12 December 2013 19:43, Chris Muller <[hidden email]> wrote:
>> I like the Announcements route. SystemChangeNotifier is a dog.
>> Compatibility with Pharo is in the long-term very important
>
>
> Freedom from Pharo constraints is even more important.
>
>> (but it has to be a two-way street, and not blind).
>
>
> I don't believe Pharo will ever be interested in a two-way street of
> compatibility with Squeak. If anything, the opposite. Neither group is
> interested in feeling constrained by the other. The Pharo fork happened for
> good reasons.
>
> We should pursue our own wildest imaginations, not follow Pharo.

No arguments, but...

> We should
> steal components of Pharo which offer the kind of functional leverage
> ratio's appropriate for Squeak.

... you can't do that without some kind of compatibility. Not without
entirely rewriting stuff, which is kind've missing the point of
stealing.

frank

> PS -- None of the above should imply I'm against Announcements. I know
> nothing about it other than its Listener Pattern le Grande. Hopefully not
> too heavyweight..
>
>
>
>

Chris Muller-4

Re: Logging from the Compiler

In reply to this post by Frank Shearar-3

On Thu, Dec 12, 2013 at 2:22 PM, Frank Shearar <[hidden email]> wrote:

> On 12 December 2013 19:43, Chris Muller <[hidden email]> wrote:
>>> I like the Announcements route. SystemChangeNotifier is a dog.
>>> Compatibility with Pharo is in the long-term very important
>>
>>
>> Freedom from Pharo constraints is even more important.
>>
>>> (but it has to be a two-way street, and not blind).
>>
>>
>> I don't believe Pharo will ever be interested in a two-way street of
>> compatibility with Squeak. If anything, the opposite. Neither group is
>> interested in feeling constrained by the other. The Pharo fork happened for
>> good reasons.
>>
>> We should pursue our own wildest imaginations, not follow Pharo.
>
> No arguments, but...
>
>> We should
>> steal components of Pharo which offer the kind of functional leverage
>> ratio's appropriate for Squeak.
>
> ... you can't do that without some kind of compatibility. Not without
> entirely rewriting stuff, which is kind've missing the point of
> stealing.

Not rewriting, porting. Which doesn't lose the value of stealing.