tinyclos primitive class extension procedures are buggy

[Tony Sidaway]

Chicken's implementation of tinyclos has an excellent facility to extend the primitive classes recognised by tinyclos.

The code is basically sound but there are bugs. For instance:

csi -R srfi-19 -R tinyclos
(define d (make-date 0 1 10 13 20 11 2009 0))
(date? d)
===> #t
(define <date> (new-structure-class "date" 'date))
(class-name (class-of d))
===> "structure"

The correct result is "date".

This is because of a bug in the procedure structure-class-of, which is called by class-of when a primitive object has been found to be a record. The procedure uses the eq? operator to test the actual object instead of looking at the object's structure tag (#sys#slot obj 0).

[Tony Sidaway]

I've fixed that bug but I have found a much more catastrophic one.

(define-record point x y)
(define <point> (new-structure-class "point" 'point))
(define <point2> (new-structure-class "point2" 'point))
Segmentation fault

[Tony Sidaway]

Both of those bugs are now fixed but there is a need for some stress testing of this code.

[felix winkelmann]

Replying to tonysidaway:

Both of those bugs are now fixed but there is a need for some stress testing of this code.

Again, well done. Indeed, some testing would be useful. I wonder, are there some unported chicken-3 eggs yet that might use tinyclos heavily?

[Tony Sidaway]

Last week I checked out all Chicken 3 eggs that are as-yet unported, and I've ported two of them: c3 and vfs. c3 is an alternative class-precedence system and vfs, as you know, is an object-based virtual file system. I've written tests for both eggs and they seem to perform as expected.

The curl egg is something I myself wrote as one of my first attempts at wrapping C code. We have eggs that do the same job just as well or better for most purposes so I don't propose to port it to Chicken 4 unless somebody requests that.

I'm currently writing a very large system that uses tinyclos very heavily indeed. This is how I discovered the primitive class bugs, and I'm also encountering problems related to the generic method system which I will file as a ticket as soon as I know the nature of the problem and whether it would be feasible to fix it. I am using unit tests against both Chicken 3 and Chicken 4 to try to duplicate the bugs there so as to be sure I haven't introduced buggy behavior by my recent changes.

The original Xerox PARC code has also been useful, particularly in the early days, to enable me to understand what is going on inside this very complex system. In some cases I also check behavior against stklos, another implementation based substantially on Gregor Kiczales' code.

One small component of the large system I'm writing--which is related to the mw egg--is a persistent object system built on top of tinyclos and designed to use dbms adapters as the dbms back-end. I may soon release that component as an egg because object persistence can be a generally useful thing to have in any object oriented system and it's comparatively easy to do when you gave a handy MOP available. It's just a matter of getting the design right and the code reasonably stable.

It's designed to achieve much closer integration with tinyclos than sqlite3-tinyclos, which I also plan to port to Chicken 4 soon, and at the same time allow as wide a choice of underlying dbms as possible. Currently we have eggs for postgresql and sqlite but an egg providing odbc and possibly jdbc connections would greatly increase the range.

[felix winkelmann]

I assume this ticket can be closed, then?

[Kon Lovett]

Yes. Done.