Re: fixes to goops + light structs + 'u' slots

[Mikael Djurfeldt]

2008/4/14, Andy Wingo <address@hidden>:
I> have shied away from GOOPS internals in the past, but every time I have
> a brush with them I learn something interesting.

You're very kind.  It's in large parts not easily readable code.

>  What is your perspective regarding <foreign-slot>? I wrote a bit about
>  what I did recently in Guile-Gnome here:
>
>    http://wingolog.org/archives/2008/04/11/allocate-memory-part-of-n

Sorry for not having time right now to look into this.

>  I define a class with a foreign slot like this:
>
>  guile> (use-modules (oop goops))
>  guile> (define-class <foo> () (bar #:class <foreign-slot>))
>  guile> (define x (make <foo>))
>  guile> (slot-set! x 'bar 45)
>  guile> (slot-set! x 'bar 450000000000000000000)
>
>  Backtrace:
>  In current input:
>    6: 0* [slot-set! #<<foo> b7dbaa60> bar {450000000000000000000}]
>
>  <unnamed port>:6:1: In procedure slot-set! in expression (slot-set! x (quote 
> bar) ...):
>  <unnamed port>:6:1: Value out of range 0 to 4294967295: 450000000000000000000
>  ABORT: (out-of-range)
>
>  Is this designed to work? It seems that all is still not right,
>  @slot-ref (only used in accessors, not in slot-ref) accesses the slot as
>  a SCM regardless of whether is is a 'u' slot or a 'p' slot. I suppose
>  that part of the dispatch/compilation needs to be made more
>  sophisticated.

Right.  That part of the implementation is not finished.  The
compilation of accessors is in goops.scm.

Another part, which is also not finished (or wasn't when I left) is
parts of the metaobject protocol.  I had some specific ideas how the
MOP part should be completed, which I hope I left somewhere in the
workbook repository.

>  >  Also, SMOB-based accessors would
>  > be more heavyweight with regard to class creation and memory
>  > consumption than the current solution.
>
> Regarding memory consumption. Currently, structs are double-cells: one
>  word for the vtable, one for the data, one empty, and one for the
>  "STRUCT_GC_CHAIN", used (please correct me) during GC to ensure that
>  structs are freed before their vtables.
>
>  This seems to be to be a waste of memory in instances, in that they
>  occupy 4 words when they only need 2. Is it not possible to avoid this?
>  I have puzzled over this for a number of hours, but have not really come
>  up with anything that seems workable, given our lazy incremental
>  sweeping. I suppose another bitvector for structs in the cards would
>  work; you could run through it at the end of marking, and mark all
>  structs' vtables.

I wash my hands.  :-)  When I left, structs where two words.  Not that
I don't appreciate the new garbage collector.

>  > In any case, *please* always benchmark changes like this against previous 
> code.
>
> Will work on some benchmarking, I am very interested to see how some of
>  the method dispatch and compilation code works.

Thanks!

>  ps. I'm happy to see you around!

Ahh, I'm sorry that I'm actually only a ghost.  Have to focus on other
stuff right now, but I'm still a Guile user!