[squeak-dev] Logging from the Compiler

Chris Muller asqueaker at gmail.com
Mon Dec 9 22:08:19 UTC 2013


On Mon, Dec 9, 2013 at 12:37 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 9 December 2013 17:07, Chris Muller <asqueaker at gmail.com> wrote:
>> On Mon, Dec 9, 2013 at 5:44 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>>> On 09.12.2013, at 01:10, Chris Muller <asqueaker at gmail.com> 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.


More information about the Squeak-dev mailing list