From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: fixes to goops + light structs + 'u' slots
Date: Thu, 10 Apr 2008 23:33:13 +0200 [thread overview]
Message-ID: <87zls1bdk6.fsf@gnu.org> (raw)
In-Reply-To: m3skxuvbh3.fsf@pobox.com
Hi Andy!
Andy Wingo <wingo@pobox.com> writes:
> Here are some patches that fix some goops <-> light structs <-> 'u'
> slots interactions. See
> http://article.gmane.org/gmane.lisp.guile.user/6371 for the basic idea
> of where this goes. I'll write more later, but I think that these fixes
> are obviously correct.
Looks good to me, I applied them (with `git-am', which is a nice tool),
along with `NEWS' entries.
> From: Andy Wingo <wingo@unquote.local>
You forgot to set your email address. :-)
> Subject: [PATCH] respect slot allocation, e.g. for <read-only-slot>
>
> * libguile/goops.c (get_slot_value, set_slot_value): In the struct
> allocation case, don't poke the slots array directly -- we should
> go through struct-ref/struct-set! code so that we get the
> permissions and allocation ('u' versus 'p') correct.
This one is of course correct, but I'm concerned about the performance
implications of all this permission checking. `scm_struct_ref ()' is
not trivial, and it's not inlined, etc. Maybe some preprocessing could
be made at vtable creation time so that we don't have to reinterpret the
whole layout string at each ref/set?
> * libguile/struct.c (scm_struct_ref, scm_struct_set_x): "Light" structs
> have no hidden words (members of the SCM_STRUCT_DATA(x) array accessed
> with negative indices). In that case, determine the number of fields
> from the length of the struct layout descriptor. (Most GOOPS instances
> are light structs.)
Is there a simple test case that reproduces this? For instance, are
instances of <class> light structs?
Thanks,
Ludovic.
next prev parent reply other threads:[~2008-04-10 21:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-09 23:45 fixes to goops + light structs + 'u' slots Andy Wingo
2008-04-10 21:33 ` Ludovic Courtès [this message]
2008-04-10 23:42 ` Andy Wingo
2008-04-13 18:47 ` Ludovic Courtès
2008-04-13 19:09 ` Mikael Djurfeldt
2008-04-13 20:42 ` Ludovic Courtès
2008-04-14 21:45 ` Andy Wingo
2008-04-14 22:16 ` Mikael Djurfeldt
2008-04-19 16:28 ` Andy Wingo
2008-04-19 23:07 ` Mikael Djurfeldt
2008-04-20 10:46 ` Andy Wingo
2008-04-14 22:20 ` Mikael Djurfeldt
2008-04-15 22:22 ` Andy Wingo
2008-04-16 6:34 ` Mikael Djurfeldt
2008-04-16 6:52 ` Mikael Djurfeldt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zls1bdk6.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).