[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mikael Djurfeldt
Subject: Re: fixes to goops + light structs + 'u' slots
Date: Tue, 15 Apr 2008 00:16:42 +0200

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:

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.


>  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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]