Shared variables binding/lookup bug

Peter van Rooijen squeak at vanrooijen.com
Wed Oct 8 20:43:35 UTC 2003


From: <goran.krampe at bluefish.se>
> "Peter van Rooijen \(squeak-dev\)" <squeak at vanrooijen.com> wrote:
> [BIG SNIP]
> > It doesn't take much time to see the source of the problem, which is
> > incorrect name resolution logic during the method compilation process. I
> > would certainly call this a major bug, but I've already said all I want
to
> > say about that now ;-).
>
> Sure, it sounds like a major bug. But still - it is the first time I
> even heard of it!
> So there simply can not have been many people gotten bitten by this.

LOL. What does it mean to be 'bitten' by a bug? If the system won't allow
you to define a class variable with a name that is in the global namespace,
chances are you'll choose another name. Have you then been 'bitten'?

My situation is different because the entire programs have already been
written on various other dialects, so initially I merely need to load them
into Squeak and I don't code them interactively in Squeak. Only after
loading them do I go on to code the Squeak-specific parts interactively in
the process of making all the tests pass on Squeak.

> Te problem here is that if you had posted about this simply a week
> earlier then we could have taken action. We have had both a beta and a
> gamma period. Those periods are there for a reason.
> Yesterday we had the release.

:-). In fact I did post this a week ago! I knew there was a squeak-dev
mailing list, googled for it, found it on Yahoo Groups, subscribed (I
already had an account with Yahoo Groups to use other groups). It all went
fine, but when I posted my post didn't show up. I guess I tried again, and
then I gave up.

Later I found out that you can't actually post to the list using that
mechanism. Perhaps something to take note of. I doubt I am the first one who
has been 'bitten' by this.

> > > However, we should certainly consider the fix for 3.7alpha.  Have you
> > > already submitted a [FIX]?
> >
> > Like I said, I have not. But I would be happy to *if* we agree that this
> > wants fixing.
>
> Of course we agree it wants fixing. BUT... mind you it might already be
> fixed. It sure sounds like a Compiler problem and there is a brand new
> Compiler just waiting to get into 3.7. So the issue might already be
> solved.
>
> Can anyone with the new Compiler check/confirm this? Anthony?

Yes, that would be good to know. Is there a way for me to check this?
Supposing it has not been fixed yet, which version of Squeak should I use to
build the fix? Where should I get that version from? Is it simply a new
image and change log that I can copy over a 3.6-full installation?

> > I have no desire to write the fix, test it, find out how to submit it
(is it
> > okay to send a message to this list with a zipped changeset attached?),
>
> Just use "mail to list" in the changesorter. Dead simple, it does it all
> for you.

Just tell me from which version of Squeak I am supposed to do this, and I
can do it. I note that when I recently read the instructions for bug/fix
reporting, they specified gzip compression. Is that really required or is
zip format acceptable? People like me, who use Windows as their primary OS,
don't usually gzip things. I could of course figure out how to do it, but
would prefer not to if it is not in fact necessary.

> > submit it, to be then told that this is a fundamental change for what is
not
> > a serious problem (because no one complained about it in years), and it
> > might break something (although it should not, it might), so it won't
get
> > in.
>
> Of course it will "get in" - but not in 3.6! Because 3.6 was released
> yesterday.
>
> > After all, a major part of my wanting this corrected is to be able to
run my
> > programs in an undoctored Squeak image. If that is not in the cards, I
might
> > as well make the changes without submitting them as a fix, or simply not
> > bother about my programs running on Squeak.
>
> Come on now, nobody has said we ain't gonna fix it. But we can't
> perpetually keep fixing stuff because then we would never get to a
> release!
>
> If you submit a fix, it will get reviewed and harvested and quite
> shortly pushed out into the 3.7alpha stream.

Help me understand this. Is it the process to have X.Yalpha1, then X.Yalpha2
et cetera?

> > BTW, there is a funny twist to this. I believe the license requires one
to
> > share changes made to certain parts of the system. I don't know exactly
> > which parts of the system qualify, but I would not be surprised if the
parts
> > affected here do infact qualify. Then after that, I don't know what
action
> > constitutes sharing the fix :-).
> >
> > So, I would appreciate some guidance in this respect.
>
> Submit the FIX and behold, it will get in. If it doesn't suck of course.
> :-)

It remains to be seen if it actually needs fixing in 3.7alpha(1?), and then
if I can fix it, because I haven't tried to in any version after 3.5. Give
me a hand here, I would like to contribute, but I don't know the procedures
well enough to be able to be confident of doing it efficiently (e.g.,
avoiding unnecessary work), I fear.

Cheers,

Peter van Rooijen
Amsterdam

P.S. I keep reading about a thing called "SqueakMap". What is it and how do
I use it?



More information about the Squeak-dev mailing list