; -*- fill-prefix: "    " -*-

  1 [Thu Feb 15 11:40:26 1996, tiggr@tom.es.ele.tue.nl] This file is not a
    ChangeLog, as it does not document changes to sources.  This file is a
    LOG since it documents achievements of tom.

  2 [Thu Feb 15 11:41:23 1996, tiggr@tom.es.ele.tue.nl] Instance variable
    access, multiple inheritance, class messaging, and instance allocation
    and messaging worked yesterday.

  3 [Thu Feb 15 11:42:08 1996, tiggr@tom.es.ele.tue.nl] Class variables
    from class methods work.

  4 [Thu Feb 15 12:45:49 1996, tiggr@tom.es.ele.tue.nl] Class variables
    from instance methods work.

  5 [Sun Feb 18 14:18:04 1996, tiggr@tricky.es.ele.tue.nl] Wrote trt_send
    for the m68k.  A speed test, for a loop with a constant bound of 1e7,
    invoking a single void method with no arguments shows, on a mono turbo
    next station (33MHz 68040) the following times: direct 13.0 sec, send
    15.8 sec.  I can not explain this huge difference.  The overhead of
    the send is an extra jump and a save of d1.  Think think... hmmm... it
    seems d1 needs not to be saved into the stack; this saves a push and a
    pop.  New timing for send is 14.6 sec.  This difference in time
    probably is mostly due to the extra jump.  Basically, we're observing
    the advantage of inling functions in loops which are very tight (and
    long).  I expect the difference in time between direct lookups and
    using trt_send to diminish on average programs; Actually, I expect
    trt_send to be faster in the end, since it avoids spoiling the cache
    with lots of lookup code.

  6 [Mon Feb 19 12:42:54 1996, tiggr@tom.es.ele.tue.nl] Wrote trt_lookup.
    On the same 1e7 loop, on a color turbo next station (33MHz 68040),
    time taken is a stunning 21.3 sec.  Comparing tom speed with
    Objective-C, the same loop with the NeXT runtime (i.e. using send)
    takes 15.2 seconds.  Hmmm... compiling trt and tom with `-g -O3'
    instead of `-g -O' decreases the tom times to (13.1, 19,8, 14.9) using
    direct, lookup, and send, respectively.  Previous times (with -O
    instead of -O3) were (13.0, 21.3, 15.8).  Compiling Objective-C using
    -O3 decreases the time to 15.1.  Thus, tom, when using -flookup-send,
    is slightly faster than Objective-C with the NeXT runtime.

  7 [Mon Feb 19 13:11:07 1996, tiggr@cobra.es.ele.tue.nl] Bweh.
    LTTExtension.m won't let itself compile with 2.7.1 on hppa-hp-hpux :-(

  8 [Mon Feb 19 14:22:30 1996, tiggr@tom.es.ele.tue.nl] The `for' loop now
    correctly compiles.  However, a `for (i = 0; i < 10; i = i + 1)' is
    slower when compiled by tom than when compiled by GCC.  The reason is
    that the code output for tom contains an extra branch.

  9 [Tue Feb 20 01:54:13 1996, tiggr@tricky.es.ele.tue.nl] Implemented
    caching, in a local variable, the pointer, within SELF, to the struct
    defined for an extension holding variables.  This does not matter for
    methods referencing a variable from that struct only once; it does
    matter is said variable is referenced more than once.  For said 1e7
    loop, if the bound is set by a class variable, time taken is 14.8
    seconds (using trt_send on a mono).  Wops.  If the class variable is
    decremented by the loop to 0, the time taken is 14.6.  Cool.

 10 [Tue Feb 20 14:53:15 1996, tiggr@tom.es.ele.tue.nl] Implemented the
    protection of objects pointed to from the stack.  Currently, this is
    rather costly, since all temporary variables end up in a stack slot,
    diminishing the possibilities for eliminating them.  Added a flag to
    otmc: `-fatomic-gc' (default `-fincremental-gc'), to indicate the kind
    of garbage collection the generated code must be able to handle.
    Obviously, -fatomic-gc generates faster code, since in that case, an
    object being put into a local variable does not need to be checked to
    be not white.

 11 [Tue Feb 20 15:20:41 1996, tiggr@tom.es.ele.tue.nl] Implemented the
    marking of objects when assigned to an object's variable (in case the
    former is white and the latter is black).  Obviously, this too is only
    needed if `-fincremental-gc'.

 12 [Tue Feb 20 21:27:46 1996, tiggr@tricky.es.ele.tue.nl] The incremental
    garbage collector, pinched from libtl, with some mods, works.  Speed
    tests show good results, though it should be noted that the dealloc
    method of objects being deallocated is not yet being invoked during a
    sweep, and that the objects being scanned all had only the isa and a
    nil reference for reference variables.  On a mono turbo next station,
    marking is done at a rate of 450k objects per sec.  Sweeping is done
    at about 600k objects per sec (half of which were white).  Note that
    sweep performance is independent of the number of referencing
    variables contained in the objects.  Also note that these numbers very
    much depend on the current phase of the moon.

 13 [Tue Feb 20 23:19:20 1996, tiggr@tricky.es.ele.tue.nl] 1e7 assignments
    of an object to a reference object variable of a non-black object
    takes 6.1 sec (without loop time correction).

 14 [Mon Feb 26 01:19:01 1996, tiggr@tricky.es.ele.tue.nl] Started on
    providing full selector information to the runtime, as the first step
    towards implementing forward and perform.

 15 [Mon Feb 26 14:23:39 1996, tiggr@tom.es.ele.tue.nl] Selector argument
    type information is now provided.  The class structure of foreign
    classes is now correctly output.  Since their class inherits from
    State (foreign classes do not have instances), they still respond to
    `instance (id) alloc'.  Alloc can catch this mistake, since the size
    of the instances is 0, but one can wonder whether the compiler should
    know this, somehow, or that the runtime check suffices.

 16 [Tue Feb 27 16:24:44 1996, tiggr@tom.es.ele.tue.nl] Basic array
    methods work.  This includes `<sometype> <something>AtIndex: int',
    `<sometype> set: <sometype> atIndex: int' (which grows the array if
    inserting at the first index beyond the last index) and `int length'.
    Obviously, some wizardry is still needed to inform the garbage
    collector of these arrays.

 17 [Tue Feb 27 17:27:08 1996, tiggr@tom.es.ele.tue.nl] Objects allocated
    have their ASI (an integer field declared by State, used by the
    garbage collector to colour the objects and by the runtime for some
    other flags) initialized from a value indicated by the class.  This
    field is always 0, except for the ObjectArray, which carries a flag to
    indicate the garbage collector it is scanning an ObjectArray, and that
    it should scan the objects contained in the array.

 18 [Wed Feb 28 11:48:44 1996, tiggr@tom.es.ele.tue.nl] Class messaging
    works.  I'm not sure yet about the syntax; currently `[Foo alloc]'
    invokes the class method `Any alloc' of the class Foo.  But everywhere
    else in tom, `Foo' stands for a reference to an instance of Foo, and,
    actually, the right syntax of class messaging would be `[class (Foo)
    alloc]', with `[Foo alloc]' having no meaning...

 19 [Wed Feb 28 14:56:01 1996, tiggr@tom.es.ele.tue.nl] Type casting
    works.  So does class/instance casting.

 20 [Wed Feb 28 16:48:26 1996, tiggr@tom.es.ele.tue.nl] Full information
    on instance and class variables is provided to the runtime.  I'll be
    needing strings before `int intValueOfVariableNamed: String' can be
    written though.

 21 [Thu Feb 29 18:37:19 1996, tiggr@tom.es.ele.tue.nl] Constant string
    objects work.

 22 [Fri Mar 1 13:11:07 1996, tiggr@tom.es.ele.tue.nl] The resolver
    outputs the declarations to a seperate file, for inclusion into C
    source.  In fact, the runtime can only be built if the resolver has
    already resolved the tom unit.  Also started on auxiliary functions in
    the runtime to support writing tom related functions in C.

 23 [Fri Mar 1 13:21:35 1996, tiggr@tom.es.ele.tue.nl] Wrote a bunch of
    array classes, and array related classes, such as String (which uses
    unicode chars) and ByteString (which uses ascii bytes).  The `int main
    ObjectArray' method (for those not intimate with tom syntax, this is a
    method called `main', which returns an int and which accepts an
    ObjectArray), is now passed an array of byte strings containing the
    arguments we all know well as C's argv.  Except that, of course, the
    zeroth argument is not passed, as it is not an argument.

 24 [Tue Mar 5 00:45:05 1996, tiggr@tricky.es.ele.tue.nl] `hello world'
    compiles, resolves, links and runs :-)

 25 [Tue Mar 5 14:04:51 1996, tiggr@tom.es.ele.tue.nl] Extensions
    (`categories' in Objective-C speak) work.

 26 [Tue Mar 5 17:02:44 1996, tiggr@tom.es.ele.tue.nl] Added a `pointer'
    type.  You can't do much with it in tom, other than passing it around,
    but it is a clean way to store, in tom, pointers which are needed by C
    code.  At least much better than objects (which is impossible) or
    selectors (which can be considered severe mis-use).  Also fixed a few
    bugs, cleaned up a bit, and other general maintenance.  It is time to
    write the interface generator, as it is a pain to keep each interface
    in sync with the implementation.  And the compiler issues an error
    (not just a warning) for discrepancies between the interface and the
    implementation.

 27 [Wed Mar 6 16:45:22 1996, tiggr@tom.es.ele.tue.nl] Started on Number
    class (and the obvious subclasses).  Checked that everything compiles
    on my hppa box, which it does, after some hacking, but something's
    seems wrong with the 2.7.1 GNU runtime, causing class posing not to
    work (or so it seems), so running the compiler there is a problem.
    Tiedied the makefiles, so one can type `make normal', `make profile'
    and `make debug' (the default).  Stared a lot at profiles of the
    compiler and the resolver.  The latter seems to spend almost half its
    time in formac (libtl's equivalent to C's [sf]printf), constructing
    the names of the runtime structures and stuff like that.

 28 [Thu Mar 7 12:58:21 1996, tiggr@tom.es.ele.tue.nl] Both the State
    class and instance inherit the behaviour of the `instance (Common)'.
    The Common class serves no particular purpose; the Common instance
    defines methods which are common to all objects, including class
    objects, such as `address' (which returns an object reference as an
    abstract pointer [see note 26 on pointers]) and `perform::'.

 29 [Thu Mar 7 16:58:19 1996, tiggr@tom.es.ele.tue.nl] Worked on the
    OutputStream and Number classes.  Also on String, which is now an
    abstract superclass of both ByteString (a string for ASCII characters)
    and CharString (which will hold Unicode characters).  Fixed a few
    compiler bugs concerning type and class checking, and checking
    consistency between the interface and implementation

 30 [Fri Mar 8 17:25:18 1996, tiggr@tom.es.ele.tue.nl] Tweaked the garbage
    collection.  If stack marking is done, possibly more than once, at the
    end of the marking phase (instead of stack protection once, before the
    marking phase) the protection of references assigned to a stack local
    variable is not necessary.  This probably saves a lot of time and code
    space.

 31 [Sat Mar 9 14:39:37 1996, tiggr@tricky.es.ele.tue.nl] Fixed default
    ASI values for object arrays, as generated by the resolver.  Fixed
    object array marking bug.  (A lot of bug fixes very often fix triple-X
    comments...)

 32 [Sun Mar 10 22:07:49 1996, tiggr@tricky.es.ele.tue.nl] `nil' is the
    constant non-existing object.  Its type is `All'; All is the class
    which is the subclass of everything else.

 33 [Tue Mar 12 09:19:51 1996, tiggr@tom.es.ele.tue.nl] `perform::' works,
    sort of, but some severe reorganization is needed to make it work for
    tuple return values.

 34 [Wed Mar 13 16:59:16 1996, tiggr@tom.es.ele.tue.nl] Expression
    handling has been partly rewritten.  Instead of bottom-up expression
    handling, the whole expression (from the level of the statement) is
    read and left untyped.  After that, an attempt is made to type the
    expression using a very simple strategy.  Net effect is that the
    return type of a method has become part of the method's prototype.
    Most important effect is that `perform::', in all its incarnations,
    works.

 35 [Thu Mar 14 12:27:21 1996, tiggr@tom.es.ele.tue.nl] `forward::' works.
    It is automatically invoked for every method invoked of an object that
    does not respond to it.  Obviously, straight method invocation can not
    provoke the invocation of forward::, unless one uses perform:: or a
    narrowing cast.  Obviously, you need a different forward for every
    different return type, just like `perform::' needs.  Both `forward::'
    and `perform::' have a selector and an object array as their
    arguments.

 36 [Sun Mar 17 21:41:49 1996, tiggr@tricky.es.ele.tue.nl] Stack reference
    protection structs (`gcpro' structs, for Emacs' source intimi) are no
    longer needed (used), except when desired by the target configuration.
    Instead, the stack, which is assumed to be contiguous, is walked to
    find references.  For this purpose, chunks, from which objects are
    allocated, are allocated from large chunk ranges.  Since only a few of
    these ranges exist, or only 1, preferrably, testing a value for being
    a reference is (can be) very fast.  Registers are also properly
    checked (by inspecting the result of a setjmp).

 37 [Sun Mar 17 22:26:36 1996, tiggr@tricky.es.ele.tue.nl] On the NeXT,
    the chunk range size is 2M, first allocation is on 32M, implying that
    the first chunk range can grow to 32M before a new chunk range needs
    to be created.  Maybe it should simply try to reallocate chunk ranges
    to twice the size each time, (a)voiding the performance knee at 32M.
    However, the current strategy also works on systems with the anonymous
    mmap as a means to allocate memory regions.  I'm not sure if they can
    reallocate...

 38 [Sun Mar 17 22:38:19 1996, tiggr@tricky.es.ele.tue.nl] All operators
    work.  Including implies.  `a -> b' is a shorthand, of course, of
    `!a || b', obviously.  Its intended use is in conditions.
    
 39 [Sun Mar 17 22:47:54 1996, tiggr@tricky.es.ele.tue.nl] `_' is no
    longer a valid first character of an identifier.  The reason is that
    `_' is used a lot in C to provide some sort of hiding in the global
    namespace.  Such hiding is absolutely unnecessary in tom, since each
    class is a proper namespace.

 40 [Tue Mar 19 00:14:52 1996, tiggr@tricky.es.ele.tue.nl] Portability
    day.  Everything now also works on hppa1.1-hp-hpux9.05, apart from a
    few minor things, such as (probably) proper handling of doubles in
    trt_forward, the fact that trt_lookup is being used instead of
    trt_send, and that stack reference marking currently uses the gcpro
    way.

 41 [Tue Mar 19 12:15:59 1996, tiggr@cobra.es.ele.tue.nl] Handling of double
    arguments in forward/perform is now correct on hppa1.1.

 42 [Tue Mar 19 18:24:18 1996, tiggr@cobra.es.ele.tue.nl] Started on `gi',
    the interface generator.  It's almost finished...

 43 [Tue Mar 19 21:55:30 1996, tiggr@viper.es.ele.tue.nl] The interface
    generator is functional, up to the point that it can handle the tom
    unit; at least it's readable for the compiler.

 44 [Thu Mar 21 01:11:24 1996, tiggr@tricky.es.ele.tue.nl] Introduced a
    `dynamic' type, allowed as the return type of a method.  The previous
    hack of `perform::' being special has been converted into the return
    type being dynamic.  For every invocation of a dynamically typed
    method, a selector for the return type involved that invocation is
    created.  All these actual selectors are noted in the info file.  If
    an object does not provide an implementation of such an actual
    selector, the implementation as dictated by the dynamic selector is
    used.

 45 [Thu Mar 21 01:20:38 1996, tiggr@tricky.es.ele.tue.nl] All method
    invocations are now fully typed in the output.  This implies that
    floats are now correctly passed to methods.  In fact, I think all
    typing stuff, including long longs, works, apart from one nasty:
    passing floats through forward/perform.

 46 [Thu Mar 21 01:23:17 1996, tiggr@tricky.es.ele.tue.nl] Fixed the lexer
    with respect to the handling of octal and hexadecimal numbers (syntax
    like C), and of floating point numbers.  1e2 is a float of 100; 1d2 is
    a double of 100.  1d is a double 1.

 47 [Thu Mar 21 12:02:04 1996, tiggr@cobra.es.ele.tue.nl] The dynamic type
    actuall is quite nice.  It is a pity one can't write a dynamically typed
    method in tom, which is to invoke just another dynamically typed method.
    It would be possible, if the selector of the method to be invoked from
    the first method were constructed at run time.  Too much hassle for now.
    Anyway, the quick Array element extraction methods `dynamic elements'
    and `dynamic elements (int, int) (start, num)' do seem to be quite nice.

 48 [Thu Mar 21 13:12:59 1996, tiggr@cobra.es.ele.tue.nl] The method
    dispatch table buckets are now actually shared between all classes and
    meta classes.  For the current 36 classes and 73 selectors, the number
    of buckets, sized 32, is down from 2 * 36 * (73 + 31) / 32 = 216 to 42,
    saving 75%!

 49 [Thu Mar 21 13:31:20 1996, tiggr@cobra.es.ele.tue.nl] With a bucket size
    of 16, instead of 32, the number of buckets is reduced from 2 * 36 * (73
    + 15) / 16 = 360 to 47, saving 88%!

 50 [Thu Mar 21 15:45:02 1996, tiggr@tom.es.ele.tue.nl] Wrote Enumerable,
    Enumerator, and ArrayEnumerator.  The latter can enumerate any array;
    returning the elements boxed (i.e. they're made an object if they
    aren't).

 51 [Thu Mar 21 17:57:26 1996, tiggr@tom.es.ele.tue.nl] Naughty, naughty:
    In conditionals (in while, if, and, slightly modified, in for) the
    expression must have a boolean type, or a tuple type of which the
    first element is a boolean type.  And because the assignment in a
    while loop over an enumerator is quite handy, the condition in while,
    if and for statements may be an assignment in braces.  For example,
    `while {(b, o) = [e next]} { ... }'.  I'm not sure if this is elegant;
    at least it works.

 52 [Fri Mar 22 13:48:22 1996, tiggr@cobra.es.ele.tue.nl] The unit file can
    be generated by the interface generator gi.

 53 [Fri Mar 22 17:02:07 1996, tiggr@tom.es.ele.tue.nl] The expression
    `selector ("string constant")' denotes a selector.  It is a valid
    selector argument to, for instance, `perform::'.  The advantage of
    this construction over the alternative expression `[RunTime
    selectorWithName: some_string]' is that in the first case the selector
    will always exist (since it is registered by the compiler as a
    selector, and thus will be defined by the resolver).  The second case
    could request a selector which does not exist.

 54 [Sun Mar 24 15:43:48 1996, tiggr@tricky.es.ele.tue.nl] The return
    statement comes in two flavours: as the C `return', which implies a
    goto-end-of-this-function, and as the assignment with an empty lhs,
    which only defines the (current notion of the) return value and does
    not jump.  The `return' may be used with or without an expression,
    irrespective of the return type.  This is for code like `= 0;
    return;'.

 55 [Sun Mar 24 21:35:28 1996, tiggr@tricky.es.ele.tue.nl] Wrote the
    methods `valueOfVariableNamed' and `setValue: ofVariableNamed'.  The
    latter could have had 238 variations for every type a variable can
    have, but it actually accepts a `dynamic' argument (which is a new
    feature too; previously, only the return type could be dynamic).

 56 [Sun Mar 24 22:30:20 1996, tiggr@tricky.es.ele.tue.nl] Replaced the
    `foreign "C"' stuff with a simple `extern'.

 57 [Mon Mar 25 00:20:41 1996, tiggr@tricky.es.ele.tue.nl] The right hand
    side of an assignment is cast to the type of the left hand side if the
    involved type is a reference type.  This avoids warnings from the C
    compiler about assignment of incompatible pointer type.  This should
    also be done for the non-ordering comparisons but that's more tricky
    and left as an excercise in the future.

 58 [Mon Mar 25 23:04:05 1996, tiggr@cobra.es.ele.tue.nl] Static variables
    now work.  A static variable is a class variable with a `static'
    qualifier.  Only one copy of this variable is maintained for the
    declaring class and all its subclasses.  This in contrast to regular
    class variables, where each inheriting class receives its own copy.

 59 [Wed Mar 27 09:44:31 1996, tiggr@tom.es.ele.tue.nl] Static variables
    are now fully functional, in that their information is available at
    runtime.

 60 [Wed Mar 27 12:02:18 1996, tiggr@tom.es.ele.tue.nl] For instance and
    class variables declared `public' an accessor method with the same
    name is generated.

 61 [Wed Mar 27 12:44:07 1996, tiggr@tom.es.ele.tue.nl] For instance and
    class variables declared `mutable', a modifier method named
    `set<CapitalizedVariableName>:' is generated.

 62 [Wed Mar 27 18:00:14 1996, tiggr@tom.es.ele.tue.nl] Geert told me to
    write `24 game', so I started out on that.  Didn't do much more than
    writing the simplistic `ByteString intValue' and fixing a huge number
    of, somethimes very large, bugs.

 63 [Fri Mar 29 12:48:46 1996, tiggr@tom.es.ele.tue.nl] Posing works, or
    at least so it seems.

 64 [Sun Mar 31 07:44:22 1996, tiggr@tricky.es.ele.tue.nl] 24-game works,
    at least as far as the original algorithm by Raymond functions (which
    it doesn't).  Michael has written Date, which actually is quite
    excellent.

 65 [Sun Mar 31 16:01:48 1996, tiggr@tricky.es.ele.tue.nl] Added
    constants.  A constant is a named expression, a bit like a
    argumentless cpp macro, with normal scoping rules applying.

 66 [Mon Apr 1 11:23:57 1996, tiggr@cobra.es.ele.tue.nl] Documentation
    (which is comment as far as the compiler is concerned) can be started by
    any html tag or something resembling it, like `<>'.  The doc is closed
    by the corresponding closing tag, like `</>'.

 67 [Mon Apr 1 12:54:53 1996, tiggr@cobra.es.ele.tue.nl] The `void load'
    implementations of all extensions are invoked upon startup.

 68 [Mon Apr 8 17:50:20 1996, tiggr@tricky.es.ele.tue.nl] A proper typing
    scheme has been implemented, at least up to the level that tom and
    24-game can be built.  Incidentally, C-style syntax of array indexing
    now also works.

 69 [Fri Apr 12 18:54:17 1996, tiggr@tom.es.ele.tue.nl] Everything is an
    expression; only variable declarations are not real expressions.

 70 [Tue Apr 16 23:41:09 1996, tiggr@tricky.es.ele.tue.nl] Messaging super
    works.  Protection of methods works (at compile time, not at runtime).
    Fixed bugs, bugs, and more bugs.

 71 [Mon Apr 22 17:05:41 1996, tiggr@tom.es.ele.tue.nl] Been writing a lot
    in the reference manual.

 72 [Thu Apr 25 14:05:40 1996, tiggr@tom.es.ele.tue.nl] Written a lot in
    the manual; renamed lots of things (writing makes one think about
    names).  The most important thing that came up was optional method
    parts in an invocation, which I'm making the compiler understand now.

 73 [Fri Apr 26 14:52:00 1996, tiggr@tom.es.ele.tue.nl] Optional method
    parts work.

 74 [Mon Apr 29 23:56:01 1996, tiggr@tricky.es.ele.tue.nl] Split the tom
    unit into too (really basic stuff) and tom (stuff so basic it is
    needed by the compiler).  Fixed lots of bugs which popped up as a
    result of this split.  Fixed lots of optional method part introduction
    related bugs.

 75 [Tue May 7 09:00:47 1996, tiggr@tricky.es.ele.tue.nl] Wrote a lot of
    docs.  Implemented bind and catch (i.e. conditions in CL speak;
    exceptions but better in ns-objc speak).

 76 [Tue May 7 12:08:36 1996, tiggr@tom.es.ele.tue.nl] Implemented unwind
    (unwind-protect in CL speak).  Exception handling system is now pretty
    complete, functioning, and it seems easy to use.

 77 [Wed May 15 00:41:57 1996, tiggr@tom.es.ele.tue.nl] Announced tom on
    comp.lang.objective-c.

 78 [Thu May 16 23:09:57 1996, tiggr@tricky.es.ele.tue.nl] The return
    value of a method is initialized to the default value for its type.
    That way, if the programmer forgets to set the return value (something
    the compiler should warn about but currently doesn't), results are
    still rather predictable, especially if a forgotten return value is a
    pointer, reference, or selector...

 79 [Sun May 19 23:35:26 1996, tiggr@tricky.es.ele.tue.nl] Been writing
    for the tom unit; started on sensible (Smalltalk-style) collection
    hierarchy.  Fixed some compiler bugs.  The amount of tom source code
    has reached 100k.

 80 [Tue May 21 12:46:47 1996, tiggr@tom.es.ele.tue.nl] True constants
    (i.e. a number) are output to the resolved header file, for use from
    C.

 81 [Tue May 21 16:54:29 1996, tiggr@tom.es.ele.tue.nl] The `load' method
    has been changed to accept a MutableArray as an argument.  This array
    contains the command line arguments; the `load' methods are allowed to
    eat some of them (i.e. act accordingly and remove the argument from
    the array).  The array, as modified by the load methods, is passed to
    main.  The Runtime class uses this facility to allow the user to set
    garbage collection parameters.

 82 [Tue May 21 21:46:21 1996, tiggr@tricky.es.ele.tue.nl] All instances
    employing pointer typed variables have their `gc_mark_elements'
    invoked for marking their elements.  This is already needed for
    ObjectArray (the other arrays do nothing), which used to be a special
    case; now it is just an example of the partial-C implementation of an
    object container.

 83 [Thu May 23 14:52:16 1996, tiggr@tom.es.ele.tue.nl] New classes:
    tom.Set, tom.MutableSet, tom.EqSet, tom.MutableEqSet.  The garbage
    collector maintains the notion of so-called containers.  A container
    is an object which is sent a `gc_container_mark_elements' instead of a
    `gc_mark_elements' to mark its elements.  This method is invoked only
    after the mark phase would normally have finished.  The intention is
    for container objects to remove any elements which have turned white.
    This can be used for unique string tables (which can drop the strings
    no longer in actual use), and the proxy collection of a distributed
    objects connection, to drop any proxies no longer in actual use.

 84 [Fri May 24 18:21:37 1996, tiggr@cobra.es.ele.tue.nl] New classes:
    UniqueString, UniqueByteString, and UniqueCharString.  All strings can
    compare each other (apart from the ByteString v. CharString, since
    mapping tables are not yet available): unique strings compare properly
    against non-unique strings.  Unique strings are held in a container Set
    (this is the test case for the garbage collector's container
    functionality).  The BufferedStream works, unidirectionally (either
    direction).

 85 [Sun May 26 22:55:01 1996, tiggr@tom.es.ele.tue.nl] New classes: Bag,
    MutableBag, Dictionary, MutableDictionary, and HashTable.  The
    latter is an abstract (though containing state, what's the name
    for that?) superclass of the set (key only), bag (key-count
    association), and dictionary (key-value association) classes.

 86 [Mon May 27 16:55:21 1996, tiggr@tricky.es.ele.tue.nl] The resolver
    now correctly sets the instance size in the class object of instances
    with deferred methods to 0.  With this instance size, the runtime will
    refuse to allocate new instances.  The resolver has a new switch,
    `-v-deferred', which causes it to output, for each class and instance,
    the selectors of, declared or inherited, deferred methods.

 87 [Tue May 28 18:09:30 1996, tiggr@tom.es.ele.tue.nl] Been implementing
    more deferred methods to get the examples running again (necessary
    before another stable).  Fixed some problems with the invocation of
    methods to super.

 88 [Thu May 30 17:12:13 1996, tiggr@tom.es.ele.tue.nl] Added EqHashTable.
    Implemented EqSet and MutableEqSet.  The containers are held in such a
    MutableEqSet, which itself is a container too.

 89 [Mon Jun 3 18:15:21 1996, tiggr@tom.es.ele.tue.nl] Started on
    Invocation and InvocationResult classes.

 90 [Wed Jun 5 12:52:30 1996, tiggr@cobra.es.ele.tue.nl] Removed all dollars
    in identifiers used by tom.  This allows it to be used on machines which
    do not allow such$identifiers.  It is needed now for Linux, which
    disallows dollars by default.

 91 [Thu Jun 6 11:49:56 1996, tiggr@woensel.es.ele.tue.nl] TOM works
    on a i586-unknown-linux, thus also on i486 and i386.

 92 [Thu Jun 6 14:04:21 1996, tiggr@woensel.es.ele.tue.nl] TOM uses
    trt_send instead of trt_lookup on i386.

 93 [Thu Jun 6 15:13:21 1996, tiggr@woensel.es.ele.tue.nl] Removed
    usage of the stack reference struct on i386 linux.  It really
    is fast now on a 100MHz Pentium.

 94 [Thu Jun 6 18:43:24 1996, tiggr@cobra.es.ele.tue.nl] HPPA now uses
    trt_send, but not trt_send_super.  Overall speedup is about 10-15%.

 95 [Fri Jun 7 17:49:22 1996, tiggr@micasa.es.ele.tue.nl] TOM works on
    i386-unknown-freebsd2.0.1.  It does not use the fast way of
    protecting objects pointed to from the stack, since FreeBSD's mmap
    is broken.

 96 [Mon Jun 10 17:48:24 1996, tiggr@tricky.es.ele.tue.nl] Started on gp,
    the tom recursive descent LL(1) parser generator.  This'll end up to
    be a complete program written in tom; it'll provide a debugging case
    for, and an incentive to further develop, the tom unit.

 97 [Tue Jun 11 17:23:18 1996, tiggr@cobra.es.ele.tue.nl] While building gp,
    I've reached the 100 classes within a program.  Let's hope 101 won't
    result in a nightmare :-)

 98 [Sat Jun 22 13:45:57 1996, tiggr@tricky.es.ele.tue.nl] Fixed all
    currently known compiler bugs, i.e. the only double-slash CCC comment
    left is the one in tom/All.t describing what double-slash CCC comments
    are all about.

 99 [Sun Jun 23 21:20:30 1996, tiggr@tom.es.ele.tue.nl] Finished the first
    working version of gp, the parser generator.  The syntax is nice (see
    ex/tpt/TestParser.tp), with inherited and synthesized attributes just
    like we were taught at this university.  The generated parser does no
    error recovery at all and gp isn't self-hosting yet, though it is
    powerful enough for that.

100 [Wed Jun 26 02:12:40 1996, tiggr@tricky.es.ele.tue.nl] The resolver
    can output non-resolved information, leaving building the dispatch
    tables to the runtime.  This is needed for dynamic loading, but can
    also be useful during development to keep the running time of the
    resolver down to acceptable numbers.  I do not know yet the impact on
    the runtime startup cost, but we'll see about that later...

101 [Tue Jul 2 16:52:27 1996, tiggr@tom.es.ele.tue.nl] Dynamic loading of
    a unit into another running unit works!  A few constraints are: it
    does not work on linux or freebsd yet (I don't know the dld calls for
    them, and I currently do not have access to them); it only works on
    HPUX when the loaded unit is compiled with `-flookup-lookup' (because
    of a bug in the linker or so it seems; stub code generated by `ld -E'
    of the main executable loops after a correct invocation of trt_send.
    But then again, probably trt_send does something nasty it is not
    allowed to do...); and the main unit must not have been statically
    resolved (i.e. it must have been resolved at runtime; the resolver
    does not yet output all the necessary information correctly).

102 [Wed Jul 3 13:40:38 1996, tiggr@cobra.es.ele.tue.nl] When statically
    resolved, dynamic loading works too.

103 [Thu Jul 4 00:09:32 1996, tiggr@tricky.es.ele.tue.nl] All examples now
    actually work when dynamically resolved---I guess most (if not all)
    dynamic resolution bugs are fixed now.  Time to start measuring the
    overhead of the dynamic resolution.  Actually, the running time of the
    resolver and the subsequent gcc run are reduced by about 80-90% when
    not building the runtime tables.  The runtime startup overhead seems
    to be in the order of a few centiseconds on my turbo next, though I
    haven't mesured this yet.  Actually, now this dynamic resolution is
    implemented, I could support an `+initialize' just like Objective-C
    does.  However, that method won't be invoked when resolving
    statically, and the latter is certainly preferred for production code.

104 [Thu Jul 4 13:50:10 1996, tiggr@cobra.es.ele.tue.nl] Version 0.01!

105 [Tue Jul 9 17:19:28 1996, tiggr@tom.es.ele.tue.nl] Added `tests'
    subdirectory and a simple script to run tests.  Started on too
    networking, to support ggd.  Started on ggd, as a test and breeding
    project for the network functionality of too (and of course tom, trt
    and the development tools).  GGD will be an `internet daemon': it will
    certainly include httpd functionality similar to HDF, but possibly
    more, like ftp, maybe nntp caching, http caching, etc.

106 [Thu Jul 11 01:05:33 1996, tiggr@tom.es.ele.tue.nl] Made a start with
    TCP sockets (both client and server side), and the RunLoop.  GGD is
    accepting connects (ok, it isn't much, but in ggd it is only about 5
    lines of code.  Try that in C).

107 [Tue Aug 6 17:28:12 1996, tiggr@tom.es.ele.tue.nl] I'm back from my
    holidays and started on proper Unicode support.

108 [Wed Aug 7 17:25:51 1996, tiggr@cobra.es.ele.tue.nl] Been busy on
    localization and character encoding and conversion.

109 [Mon Aug 12 13:23:17 1996, tiggr@tom.es.ele.tue.nl] The (Aug 13)
    stable should work more-or-less flawlessly on Linux.

110 [Tue Aug 13 18:30:54 1996, tiggr@tom.es.ele.tue.nl] I'm currently busy
    writing an NNTP server in tom, using Postgres 95 as the database in
    which to store articles.  The database abstraction offered in tom is
    simple; it resembles a subset of EOAdaptorChannel, and everything is
    handled using strings plus arrays and dictionaries of them.

111 [Thu Aug 15 22:43:41 1996, tiggr@cobra.es.ele.tue.nl] Moved a few C
    definitions about so that communication with tom objects from C is
    just as easy as the manual suggests it is.  In fact, I'm using the tom
    tools now from their installed spot instead of straight from the
    source tree.

112 [Fri Aug 16 14:21:59 1996, tiggr@cobra.es.ele.tue.nl] The Runtime now
    implements a `preload' method.  This checks to see if the first option
    to the program is `:help'.  If so, the help methods of all class
    objects are invoked; the intention of this being that they document to
    their argument stream the `:' options they understand.

113 [Tue Aug 20 17:59:36 1996, tiggr@cobra.es.ele.tue.nl] There is a new
    class, `Extension', which brings to tom programs an abstraction for
    the extensions from which the programs are built.  The few things
    currently possible are finding an extension of an object by there name
    (be it inherited or not), and performing on an object the method
    implementation as provided by that extension, irrespective of whether
    that implementation would have been invoke if the selector was invoked
    `normally'.

114 [Wed Aug 21 14:34:23 1996, tiggr@cobra.es.ele.tue.nl] GP, the parser
    generator, now accepts a single synthesized attribute to a terminal to
    mean that the attribute is assigned the `[lex semantics]' value of the
    terminal.  All this for terser grammars...

115 [Thu Aug 29 17:55:21 1996, tiggr@cobra.es.ele.tue.nl] The Meta Unit
    (mu), and Meta Tom (tm), the tom-written replacement for gi, are in
    the works.  The first few words of generated documentation have been
    uttered in HTML.  [Note: tm and mu are currently not part of the tom
    distribution; they are available seperately.]

116 [Tue Sep 3 00:18:57 1996, tiggr@tricky.es.ele.tue.nl] Fixed several
    major bugs in the compiler, and noted others in the ...tom/TODO.
    Still working on gps, mu, and tm...

117 [Thu Sep  5 16:50:03 1996, tiggr@cobra.es.ele.tue.nl] 
    Documentation in HTML format can now be generated from tom sources
    (and will soon appear on http://tom.es.ele.tue.nl:8080/).  The parser
    in the compiler remains the reference parser, since currently the mu
    parser basically is a hack to accomodate tm (the doc generator) and to
    grok the 250k or so of existing tom sources, which it in fact now
    does.  In the future, the mu.ParseTom parser will become the tom
    reference parser, and will be the only (LL1) parser ever to be written
    for tom, if reusability permits :-)

118 [Fri Sep 6 18:04:00 1996, tiggr@cobra.es.ele.tue.nl] Selectors
    resulting from `selector ("i_intValue")' now no longer have their
    typing deduced from their frobnicated name.  It does imply that when
    such a selector is used, a method implementing it must have been seen
    for the output of the compiler not to contain information on which the
    resolver will die, but, currently, all goes well...

119 [Sat Sep 7 21:57:59 1996, tiggr@tom.es.ele.tue.nl] The tom web site
    now has documentation extracted from the sources on-line.  MU and tm
    are available as seperate packages.

120 [Sun Sep  8 16:07:26 1996, tiggr@cobra.es.ele.tue.nl] Version 0.02.

121 [Thu Sep 19 17:52:26 1996, tiggr@cobra.es.ele.tue.nl] Documentation
    can be generated satisfactorily in html and texinfo formats.  The
    latter generates a lot of pages though.  The documentation generator
    is Meta Tom, aka tm, and is written in TOM.

122 [Sun Sep 22 16:45:35 1996, tiggr@tricky.es.ele.tue.nl] Added copying
    methods.  Added a `C' class with methods like malloc, memcmp, etc.

123 [Mon Sep 23 16:15:27 1996, tiggr@cobra.es.ele.tue.nl] TOM now uses the
    fast way of garbage collection on hppa-hp-hpux.  The decrease in code
    size and increase in performance is rather dramatic.

124 [Wed Sep 25 15:40:18 1996, tiggr@tom.es.ele.tue.nl] TOM can run in
    multiple threads (currently on m68k-next-nextstep).

125 [Thu Sep 26 09:06:50 1996, tiggr@tom.es.ele.tue.nl] New classes
    include Thread, Lock, RecursiveLock, and Semaphore.

126 [Fri Sep 27 15:20:05 1996, tiggr@jaguar.ics.ele.tue.nl] TOM runs on
    hppa1.1-hp-hpux10.20 (no multithreading _yet_).

127 [Sat Sep 28 22:23:17 1996, tiggr@tom.es.ele.tue.nl] TOM can run
    multiple threads on supported hpux10 and nextstep targets.  hpux10
    uses pthreads, so porting to other targets should be easy.  Dynamic
    loading will not accept static thread-local variables when multiple
    threads are running, since it is very difficult to guarantee that this
    will work without causing havoc.  (It is possible to support this with
    a big chance of success by, while retaining the runtime lock,
    installing the default dispatch table for every meta and yielding a
    few times, thereby hoping that every thread will end up waiting in
    dtable_install, or some other safe spot.)

128 [Mon Oct 28 17:40:41 1996, tiggr@jaguar.ics.ele.tue.nl] Haven't
    entered much for a long time.  I've been applying TOM to some
    interesting projects (or at least the start of them), one of which is
    TAG (see http://tom.es.ele.tue.nl:8080/tag/).  TOM is maturing in the
    process.  Garbage collection now works in the context of multiple
    threads (not proven, only observed).  String support is getting
    better.  File handling is now complete (no mapped files yet).  Added a
    few collections.  Fixed a few bugs.  Etcetera.

129 [Tue Oct 29 15:44:37 1996, tiggr@jaguar.ics.ele.tue.nl] The unicode
    example program has been vamped to create all necessary tables
    predicate and conversion.  The tables created by it, for Unicode and
    ISO 8859-[1-9], are now part of the TOM distribution.

130 [Fri Nov 1 17:38:22 1996, tiggr@jaguar.ics.ele.tue.nl] Character
    encodings (how to represent a subset of the Unicode characters in a
    byte) are now handled properly by the TOM unit, at least up to
    encoding, decoding, conversion and predicate testing.

131 [Thu Nov 7 17:22:04 1996, tiggr@jaguar.ics.ele.tue.nl] Invocations
    work.  This includes creating, firing, examining the result, and
    retrieving values from it.

132 [Fri Nov 8 12:30:02 1996, tiggr@jaguar.ics.ele.tue.nl] New flag to the
    compiler: `-freadable-c'.  With it, behaviour is as before.  Without
    it (default), the compiler outputs `#' line directives, causing gdb to
    show TOM source instead of the compiled C resulting from it.

133 [Mon Nov 11 16:50:57 1996, tiggr@jaguar.ics.ele.tue.nl] Invocations
    can be curried, either explicitly through `fireWith', or implicitly
    through `forwardSelector arguments' which is invoked by trt_forward,
    before the normal forwarding through `forward::'.

134 [Mon Nov 25 17:18:40 1996, tiggr@jaguar.ics.ele.tue.nl] The syntax has
    been C-ified: the `;' is no longer a separator but a terminator, plus
    compounds (as in `{...}') need no termination.  The main implication
    of this change is that a compound no longer is a straight expression;
    a lot of syntax rules however accept an expression or a compound.  A
    tuple element, for instance, can be a compound, and thus compounds can
    be written as an expression in the GNU C way: `({...})'.

135 [Wed Dec 4 15:19:57 1996, tiggr@cobra.es.ele.tue.nl] The description
    of extensions is no longer generated by the resolver, but by the
    compiler.  This causes a slight increase in compiler running time.
    However, the run time of the resolver, the size of the output file,
    and the runtime of gcc on the output file is cut about 50%.

136 [Sat Dec 14 23:13:35 1996, tiggr@jaguar.ics.ele.tue.nl] Method
    preconditions have been implemented.  By default, these are enabled.
    By specifying `-fno-pre-checks', the compiler will not generate code
    to check the preconditions.  The TOM Runtime class will enable
    precondition checking if the option `:cc-pre' is specified.

137 [Mon Dec 16 16:44:29 1996, tiggr@cobra.es.ele.tue.nl] Installation has
    been changed to install everything within a subtree.  Links from the
    usual places can be made by `make install-links'.

138 [Wed Dec 25 22:55:43 1996, tiggr@tricky.es.ele.tue.nl] Fixed the
    dependency problems with the type declarations in the output of the
    compiler.  Coincidentally reduced the size of the output, for the TOM
    unit, by 18%.

139 [Sat Dec 28 21:52:43 1996, tiggr@tricky.es.ele.tue.nl] Objects can be
    encoded onto and decoded from a stream.  Textual encoding has also
    been written; textual decoding not yet.  Also, selectors and class
    objects are not yet handled, as is coding most of the objects in the
    TOM unit.  Obviously those are next, to be followed by DO, of course.

140 [Sun Dec 29 02:11:20 1996, tiggr@tricky.es.ele.tue.nl] Selectors can
    be encoded and decoded.  Like references to objects and classes, they
    are enumerated (implying less bytes are needed for encoding the second
    and following occurrences).

141 [Thu Jan 2 14:40:07 1997, tiggr@anaconda.es.ele.tue.nl] A new option
    to the Runtime class, `:rt-resource-dir' can be provided to point to
    the directory containing the character encoding and predicate files.
    This is used by the tests to be able to run the tests when TOM has not
    yet been fully installed.

142 [Sat Jan 4 00:41:38 1997, tiggr@viper.es.ele.tue.nl] TOM runs on
    i386-next-nextstep3, thanks to Michael Brouwer <michael@thi.nl>.

143 [Mon Jan 6 22:19:57 1997, tiggr@jaguar.ics.ele.tue.nl] The foundation
    of Distributed Objects (DO) has been laid: simple (oneway) void
    methods and proxy and object passing between two processes works.

144 [Sat Jan 11 13:41:35 1997, tiggr@akebono.ics.ele.tue.nl] configure
    understandard --with-threads={no,pthreads,cthreads}.  When not
    provided, it will try to figure out what to use for itself.  Thread
    code has been removed from the configuration dependent files.

145 [Mon Jan 20 16:24:30 1997, tiggr@akebono.ics.ele.tue.nl] The tools
    accept a new option, `-G', which is the name of a subdirectory to
    visit when traversing the search path.  In addition, it names the
    subdirectory of the current directory in which generated files are
    placed, avoiding clutter of source directories.  The adjusted
    makefiles put all files extended by [oijuc] in subdirectories.

146 [Tue Jan 21 17:10:29 1997, tiggr@akebono.ics.ele.tue.nl]
    Postconditions have been implemented, including the `old' unary
    operator.  Pre- and postconditions defined by a method are not yet
    checked by any methods overriding that method.  The documentation
    generated by tm does not yet contain these conditions (like the
    default arguments which have been existing for a long time now, and
    which are also not yet output in the docs).  The method conditions add
    various `-f' flags to the compiler and `:cc' (`condition checking')
    flags to the Runtime class.  The default behaviour is to generate the
    checking code but disable it at run time.

147 [Fri Jan 24 16:33:12 1997, tiggr@akebono.ics.ele.tue.nl] I've been
    playing with Quantify on HP-UX on otmc, the compiler.  On our K260,
    I've reduced the runtime from 6.9/2.0 (u/s) on mu/tom.t to 5.0/1.2 by
    a few _very_ simple optimizations which are applicable in general to
    program written in (GNU) Objective-C.  (These measurements are not
    precise; they are off by some factor.)

    First, if you often message a class, ask for it once (using
    class_pointer = [Class self]) and use the value returned.  Having
    applied this to various enumerator creation methods, reducing the
    number of invocations to objc_get_class from 5e5 to 1e5, and reducing
    the time spent in that function or its subsidiaries (hasing strings
    and comparing them, in libobjc.a) from 11.04% to 2.23%.  In addition,
    I've introduced an object pointer for every class in ltt and otm,
    reducing the number of invocations to 1.5e4, being 0.04%.  Note that
    this trick does not work if dynamic loading introduces posing classes.
    Also note that TOM does not suffer this problem since every class has
    a pointer to it for messaging the class, and the pointer is patched
    when the class is being posed.

    Second: do not use `conformsTo:' or `isKindOf:' since it costs a lot
    of time.  I haven't eliminated them all, but most of the time you're
    porbably better off using a special method for the class you want to
    test, and provide a category in Object which provides the other answer
    (i.e. NO).

    Third, I've replaced all sets for maintaining super and sub metas of a
    meta by (simple) vectors.  These sets do not grow that large, and
    getting an enumerator just to traverse some collection of a few
    elements is getting expensive.  One of the inheritance checking
    functions took about 10% of the execution time.  I can't remember
    which one it was and I can't find it any either.  Time for finding
    methods (simply on their name parts!) has been reduced from almost 20%
    to 8%.

    One more weird thing happened: while profiling, at one moment in time,
    I observed with the class-object messaging trick that time was down to
    5.0.  After applying more of the same trick, it was back up again to
    5.5!  I can not reproduce how or explain why this happened...

    Anyway, now a lot of enumerators have been eliminated as well, I'm
    currently down to 4.1/0.7, which isn't too bad from 6.9/2.0 for a part
    of an afternoon's worth of effort...  The down side is that the amount
    of time spent in objc_msg_lookup has increased to almost 20%!

    Last remark, timing provided by /bin/time (which is accurate without
    needing to scale time) shows a improvement from 12.1/0.4 to 7.9/0.3

    One final remark, I should remove the `conformsTo:' from [TLString
    compare:].  It currently consumes 7% of the compiler run time...

    One final final remark: the TOM source is right in discerning bzero
    and memset.  The fastest one should always be used on a system.  On
    HP-UX, where tl calls bzero, bzero consumes half the time spent by
    memset on its behalf, i.e. zeroing memory could be 33% faster...

148 [Mon Jan 27 23:15:09 1997, tiggr@akebono.ics.ele.tue.nl] `continue'
    now actually works.

149 [Mon Jan 27 23:53:05 1997, tiggr@akebono.ics.ele.tue.nl] The
    documentation extracted from the source now contains (as it should)
    default arguments and method pre- and postconditions.  A few bugs
    remain to be fixed; I will get to those when I have more time.  The
    docs are part of the distribution.

150 [Tue Feb 4 12:38:46 1997, tiggr@akebono.ics.ele.tue.nl] The return
    value can be given a name (or names in the case of a tuple), as in
    (int, int) (a, b) foo (int, int) (b, c).  For each name in the return
    value names, which does not denote an argument, a local variable of
    the indicated name and type exists in the method body.  The most
    important reason for naming the return value is to be able to refer to
    them in postconditions.  Other implications are that the return value
    can be specified by an assignment in the method body, and that return
    without an expression makes sense and is allowed.  It simply specifies
    to end the method without further affecting the return value.

151 [Tue Feb 4 12:42:32 1997, tiggr@akebono.ics.ele.tue.nl] const
    declarations are now present in the documentation output.  The
    distribution of TOM contains the extracted documentation for the units
    supplied, i.e. tom, too, C, and gps.  See doc/index.html in the
    distribution.

152 [Tue Mar 4 23:07:26 1997, tiggr@akebono.ics.ele.tue.nl] Reimplemented
    the hashtable-based collection classes; their implementation now no
    longer employs any hand-written C code.  (Some features have not yet
    been implemented, such as the Container functionality.  Invocations of
    unimplemented have been inserted to be pointed at this omission when
    needed.)

153 [Wed Mar 19 00:49:26 1997, tiggr@tricky.es.ele.tue.nl] Method pre- and
    postconditions are now `inherited' by overriding methods.  Thus, the
    conditions which are checked for a method are the conditions defined
    by that method and by any method it overrides.

154 [Thu Mar 20 16:42:30 1997, tiggr@akebono.ics.ele.tue.nl] Literal C
    code can be included in TOM code, enclosed in <c> and </c>.  The
    advantage of this setup is that a method can be implemented in C,
    which is necessary for some low-level methods, while the method
    preamble and postamble are emitted by the compiler, including the
    method's pre- and postconditions.  The literal C code can be a top
    expression in a method body (with type void), or reside at the top
    level outside any interface or implementation, useful for #include and
    function definitions.

155 [Thu Apr 17 18:12:05 1997, tiggr@akebono.ics.ele.tue.nl] I recently
    dicovered that the TOM operator priorities are not equal to those in
    C, even though I thought I had copied them quite accurately.  In TOM,
    comparison operators bind less strong than the bitwise operators for
    and, or, and eor.  Even though this is a discrepancy, I think the
    choice made by C was wrong, so I do not think I'll change the way
    things are in TOM right now.  Incidentally, while improving the
    hashing by hashtable and its derivatives, I've implemented the logical
    shift right operator, `>>>'.

156 [Wed Jul 2 23:00:22 1997, tiggr@tricky.es.ele.tue.nl] Coding has been
    slightly overhauled.  It is now multi-coding safe with respect to
    class versions (i.e. it can handle nested or multiple simultaneous
    coding).  Also fixed the omission of not writing out the versions of
    the superclasses of the coded objects, and the mixup caused by the
    inherited non-static version class variable.  In short: it now works.
    [Aside: I'm currently doing an EDA project, exclusively using TOM.
    This will accelerate the maturation of the compiler and libraries.]

157 [Mon Jul 28 17:58:56 1997, tiggr@cobra.ics.ele.tue.nl] I've fixed a
    bunch of bugs in the garbage collector; I am now (almost) confident
    that all bugs preventing proper single-threaded use have been ironed
    out.  In fact, running BIT with a threshold of 10 objects
    (i.e. running the garbage collector after every 10th object is
    allocated) no longer results in any gc-bugs-induced crashes.

158 [Sat Aug 2 07:39:14 1997, tiggr@dev.linuxppc.org] TOM has been ported
    to LinuxPPC.  Apart from the time it took with a flakey debugger to
    discover that va_arg with smaller-than-int types was broken (2 hours),
    the port took only 3.5 hours, including porting libtl and learning to
    read PPC assembly (not that difficult).  (Two things are left to be
    twiddled, being trt_send (which I almost never use since trt_lookup
    allows easier debugging), and float-tuple returns (test 21).)

159 [Tue Aug 12 01:55:14 1997, tiggr@tricky.es.ele.tue.nl] The
    single-connection DO example (ex/gcdo) works, including distributed
    garbage collection for this simple case of one connection at both the
    client and server side, and no third party.  Incidentally, the tom
    unit supports a new option: `:rt-inst'.  This causes a dump of the
    number of allocated direct instances of each class upon exit; a great
    way to debug leaks.  (This dump is always available by invoking
    [Runtime reportNumInstances [stdio err]].)

160 [Tue Jan 6 11:50:08 1998, tiggr@akebono.ics.ele.tue.nl] Lots of major
    changes in the last few weeks, to be itemized below.

161 [Tue Jan 6 11:50:32 1998, tiggr@akebono.ics.ele.tue.nl] GP and GPS
    (the parser generator and its skeleton) were removed from the TOM
    distribution, as was the example using it.  The resolver has been
    renamed to `tomr', the compiler to `tomc'.

162 [Tue Jan 6 11:51:40 1998, tiggr@akebono.ics.ele.tue.nl] The resolver
    and compiler now have a flag `-1' indicating that resolution is to be
    performed on a per-unit basis.  This has several major implications,
    the most important ones being (1) highly reduced compile-resolve-link
    cycle time and (2) TOM units can be made into shared library objects.

163 [Tue Jan 6 11:54:41 1998, tiggr@akebono.ics.ele.tue.nl] The TOM
    makefiles were moved into the TOM distribution.  The TOM units and
    examples use these makefiles, reducing the mess in GNUmakefile.defs
    which previously had to fit both TOM and Objective-C code.

164 [Tue Jan 6 11:58:17 1998, tiggr@akebono.ics.ele.tue.nl] Improved
    configure script.  New `uninstall' target.  The GNUmakefile provides a
    target for a Debian binary distribution (for dselect or dpkg -i).
    (RPMs are next.)

165 [Tue Jan 6 12:06:06 1998, tiggr@akebono.ics.ele.tue.nl] Each unit
    (optionally) comes with a GNUmakefile.unit which can specify
    additional libraries.

166 [Fri Jan 9 12:18:29 1998, tiggr@akebono.ics.ele.tue.nl] TOM units as
    shared libraries works, using GNU libtool.

167 [Fri Jan 9 12:18:58 1998, tiggr@akebono.ics.ele.tue.nl] A stripped
    version of libtl is now part of the TOM distribution, making the
    distribution stand-alone, and the executables significantly smaller.

168 [Mon Jan 12 14:14:56 1998, tiggr@akebono.ics.ele.tue.nl] When building
    TOM with DEBUG_MESSAGE_MONITORING, trt_lookup can monitor messages
    based on the value of the receiver and/or selector.  Several functions
    are provided to add receivers/selectors to watch.  The function
    trt_monitor_match is invoked upon a match.  A breakpoint can be set on
    it to gain control in the debugger.  If no receivers or selectors are
    to be watched, the overhead in the lookup is one if that is not taken.
    If anything is to be watched, this functionality is (infinitely)
    faster than setting a conditional breakpoint on trt_lookup.

169 [Mon Jan 19 13:12:20 1998, tiggr@akebono.ics.ele.tue.nl] New option to
    the compiler, -fcheck-extension-address.  Hope this helps debugging
    early code.

170 [Thu Jan 22 16:25:27 1998, tiggr@xenon.ics.ele.tue.nl] ${srcdir} does
    not need to be `.'.  Thus `mkdir build; cd build; ../configure' works.

171 [Sat Feb 14 23:36:48 1998, tiggr@gerbil.org] The TOM WWW site has been
    moved to http://www.gerbil.org/tom/.

172 [Mon Apr 6 13:26:01 1998, tiggr@gerbil.org] This file is no longer
    being maintained.  Look at the TOM website or subscribe to the TOM
    mailing list to track TOM development.