Jecel Assumpcao Jr
jecel at merlintec.com
Fri Jun 7 19:44:21 UTC 2002
On Thursday 06 June 2002 17:15, Thorsten wrote:
> If you look into the globals.transporter.fileOut there are 2 methods
> that would maybe help.
> fileOutSiteEffects that method put a script on the end of the file
> out which can be used to do all the initializes.
Ok, though I think the idea is to put stuff in the module's postFileIn
method that can't be handled in any other way, like reading setup
information from the OS for later use.
> fileOutAInitializerOf: c that one creates the initializer string.
> So it would be "easy" to modify the transporter in that way.
The modification should be in the method that I mentioned before so
that not only a direct reference to an object but also the use of an
object in an expression would be considered an ordering constraint.
> So the
> problem with undefined prototypes in initialize statements would be
> fixed, but then you can still have a problem with a defined but
> uninitialized prototype. So when the initialize sequence for that
> prototype will starts it was already copied during the initialize
> sequence of the other prototype.
You will have the same problem if you change things after loading the
module in any case.
> And then we are back to the point that sorting or ordering will not
> help in all cases. The only thing that will help here, is prototypes
> who refer prototypes instead of copies... you remember that
> discussion about defensive programming ;-)
Yes, there is a contradiction between extra safe coding and having
changes be reflected in all interesting places. You can't have both.
This design problem also appears when you have to decide whether to put
a slot in the object itself, in a parent or in an even higher up
ancestor. No matter what choice you make, there will be some future
situation in which it will turn out to have been the wrong choice.
Unfortunately the Transporter forces a certain programming style, so
the choice is already made for you if you need to use it.
> Does anybody know something like BOSS in VisualWorks for Self?
Try "transporter binaryBeamOut scanApplication:" and "transporter
binaryBeamIn readApplication:" and see if they don't what you need.
I have been doing some statistics to see what I can do about binary
modules and so far have had some surprising results. It seems that
"enumerating all" spreads the objects around much more than I would
expect. Checking out how "far" references are (where 0 would mean self,
1 the next object in enumerating all order, -1 the previous object, 2
the object after the next one and so on...) I got that most references
would need between 14 and 18 bits with a far smaller peak at 7 and 8
bits. That is almost the worst possible order. I suspect that if we
divided the objects into modules things would look very different.
It takes the Ultra several hours to go through all the objects, so it
will be a while before I have all the results I need. One option would
be to add memory, but I am thinking of running benchmarks on the Sparc,
the iBook and some PCs to confirm that this is the best alternative. I
am not sure a PC with 6 times the clock would compensate for the lack
of the SIC. A quick test on the iBook showed that I'll have to do some
debugging to run the benchmarks (getnodename seems to be broken on the
Mac OS X, for example).
BTW, thanks for the Droplet tip in the other email.
More information about the Self-interest