Jecel Assumpcao Jr
jecel at merlintec.com
Thu Jun 6 15:44:02 UTC 2002
On Wednesday 05 June 2002 15:03, Thorsten Dittmar wrote:
> I'm not sure if I do some thing wrong or if it is a bug.
It is a bug.
> Here the situation:
> I have a module with 2 prototypes (b and c).
> Prototype b has a slot named x.
> I use the annotation mechanism to initialize x as a copy of c.
> So far so good... Now file out the module and use bootstrap read:
> 'filename' From: 'dictionary' to file it in.
> I will get an error because x can not be initialized because the
> prototype c is not installed at all at this moment.
The problem is that the module created the objects in the wrong order.
I tried this and got the same error as you did, and then I did it again
but with the objects named "f" and "e" instead of "b" and "c" and it
worked as it should.
If you look at the object "transporter fileOut slotSorter" (specially
in the method 'topoSortFrom:Path:IfCycle:') you will see that though it
starts out with a simple alphabetical order for the top slots in a
module, it makes a great effort to find all dependencies and reorder
things to fix them. Unfortunately it doesn't seem to handle this
(rather common) case.
> Maybe I misused the annotation mechanism. Of course I know a
> workaround, but I want to know what the right way for the not so
> uncommon situation is.
One workaround is to choose top level names so things fileOut in the
right order. To get back a module that would otherwise be lost you
might want to edit the .self in a text editor, though this is a lot of
work and the problem will reappear the next time you save the module.
I ran into this myself when working in tinySelf 1 back in 1997, which
was one of the reasons I never finished debugging it. On the other
hand, I wrote several other applications and my trainees did too and
none of them had this problem. It depends on luck (what your objects
are named) and style (whether you use "InitializeTo:" annotations or
More information about the Self-interest