[squeak-dev] Re: Toward SqueakCore (including alternative plan)

Frank Shearar frank.shearar at gmail.com
Wed Feb 13 22:32:57 UTC 2013


On 13 February 2013 22:01, Craig Latta <craig at netjam.org> wrote:
>
> Hi Frank--
>
>      Did you mean to send this to squeak-dev, too? It only came to me.

Sorry, that was a slip of the finger, and then I misread headers and
thought you'd only sent it to me. Double d'oh.

>> > With the current technique[1], I don't have to deal with those
>> > issues at all to make minimal object memories. I wrote a variant of
>> > the garbage collector that collects methods not run since a certain
>> > point in time. I reset a mark on all methods, run unit tests for
>> > the stuff I want to keep, and everything else vanishes. It takes a
>> > few seconds.
>>
>> Yep, it's a very neat GC hack. It does mean you _must_ have 100% code
>> coverage or you risk imprinting a broken module.
>
>      Well, imprinting has nothing to do with making a minimal memory.
> There's nothing being transferred to another memory, only garbage being
> collected from a single memory. In this process (which I call
> "dissolving"), if there's no unit test coverage for something, it just
> goes away. Any methods that you happen to run some other way (like all
> the methods involved in the system just sitting there idling,
> headlessly) get retained.

Er yes, you're right. I have actually read most of the Spoon
literature, even if it's not that obvious :/ Yes, I half and half have
a problem with dissolving, just in the sense that if you don't use it
it's gone, only that might be, say, UI wiring.

>> > Before I started doing that, I was ripping things out manually with
>> > a remote browser, so I didn't have to think about most of the
>> > circularities (e.g., breaking the target's GUI was fine because I
>> > wasn't using it).
>>
>> Ok, which means that you didn't really care too much about breaking
>> cycles either because the resulting thing didn't worry about
>> breaking, say, Morphic, or because the resulting module would _eat_
>> the cycle (all things in the cycle go in the module).
>
>      Right, making a minimal system and finding module boundaries are
> two very different problems. You don't need the second for the first.

Right.

>> I'm sure you're aware I have difficulties :) with the all-live-
>> objects approach...
>
>      Well, I've only noticed a lack of interest. I haven't read every
> message ever sent to squeak-dev, though. While you're writing up your
> current thoughts, are there existing messages I can read?

I'm still mulling them over, and I don't want to say something
ill-formed. But I am aware that it's not very fair of me to leave you
hanging! "I'm sure you're aware I have difficulties" because we have
discussed Spoon's tech before - last time was, IIRC, "how can you diff
two arbitrary binary blobs?"

>> > Class references are the basis of the dependency graph...
>>
>> Class references are where the Dependency Browser gets its info.
>
>      Aren't we saying the same thing? :)
>
>> > ...the categories are a distraction. Let's identify the methods
>> > causing reference circularities between classes.

Yes, we are: I saw "categories" and wanted to make sure we were
talking about the same thing.

>> I largely agree re tags, except that right now PackageInfo is the
>> closest we have to something like a module. So a class reference
>> causes a dependency between two clusters of classes, say Network and
>> Tools.
>
>      If we have the raw class dependency data, why do we anything else?
> And we may very well find that the groupings expressed by PackageInfo
> (class category) stuff are wrong anyway...

Well, because PackageInfo is what we have right now. But the
counterargument, for what it's worth, is "then let's correct the
PackageInfo data until they do make sense as modules".

frank


More information about the Squeak-dev mailing list