----- Original Message ----- 
From: "Andreas Raab" <andreas.raab at gmx.de>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Monday, October 02, 2006 11:18 PM
Subject: Re: About 512 MB changes patch


> Hi Tim -
>
> >> As much as I agree with the idea of reworking CompiledMethod in
> >> general, it seems to me we shouldn't mix up two otherwise unrelated
> >> issues.
> > [snip]
> > Yes, that is plausible and reasonable; except that I *do* think it is
> > way past time to do the CM rework and since to makes it trivial to also
> > clean up the source code representation I consider it a nice synergy.
>
> And it is. However, I question whether to put the two into the same bag.
> I think we can agree that whatever a new compiled method format will be
> like, it'll have a variable representing the source code reference. If
> we know that, then we can discuss what the source reference should
> represent. And that's really all that this discussion should be about.
>
> Having said that, I don't claim that Klaus' proposal is the one that
> necessarily should be adopted - I like it because it's the simplest
> thing I could imagine for starters and it's not so alien that all of the
> client code needs to be changed. That said, there *is* room for
> discussing the alternatives, and if you're unhappy with Klaus' proposal,
> by all means, propose some alternative. All I'm asking for is that we
> don't mix it with the CompiledMethod discussion.
>
> > As I said, Klaus is to be congratulated for coming up with a concrete
> > proposal. I don't think it cleans up anywhere near enough of the mess,
> > but that could be worked on. For example, it appears to me to leave far
> > too much in the way of assumptions about the source pointer being an
> > encrypted integer for real comfort. I made a technically simple but
> > organisationally more complex proposal. It is what it is. If people
> > don't like it, they don't like it.
>
> Well, in that case all I can say is: "Code speaks" ;-) If you still have
> that code from '98 and can update it to work with method properties I'd
> like to see it and I'd like us to have the discussion about which
> approach people like more.
>
> > Perhaps it is not yet time to change the image format and break backward
> > compatability; then again, the 64bit images are not backward compatible,
> > the proposed 3.9 release requires a condensed changes and new sources
> > file (perhaps not if we adopt a source pointer cleanup?) and frankly the
> > place is in a mess that needs cleaning. I'm fairly amazed you haven't
> > been clamouring for such a cleanup for the OLPC work.
>
> We're steering a deliberately conservative course on OLPC. Right now our
> (effectively only) priority is to make sure that eToys work well and
> that we're on track for the first batch of machines.

    In other words, Yet Another Race Against Deadline ?

    What if the first batch of machines won't be ready until Squeak is
    really mature (on its 21st birthday), for that matter, what if there
were
    NO OLPC, what would you guys in the OLPC team do for Squeak ?

> Because of that,
> concerns regarding the representation of source pointers get little
> attention and unless there is some major, major speedup I would veto any


    BURP (Boy, You Are Powerful ;-)

> changes to CompiledMethod for OLPC simply on general principles. We have
> enough issues to deal with as things stand, there is no reason to create
> a bunch of new ones. That's not to say that we shouldn't do the work,
> but OLPC is simply not the place to debug the issues surrounding it.
>

    True!!!

    It's just the place to dump all the garbages hidden underneath eToys???


    Cheers,

    SmallSqueak


    P.S: BTW, does this OLPC eToys use Tweak?