2008/4/14, Andy Wingo <[EMAIL PROTECTED]>: 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!