* Re: [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-9-4-72-gb1955b1 [not found] <E1N5STy-0005mm-2g@cvs.savannah.gnu.org> @ 2009-11-05 18:13 ` Ludovic Courtès 2009-11-05 23:35 ` Andy Wingo 0 siblings, 1 reply; 6+ messages in thread From: Ludovic Courtès @ 2009-11-05 18:13 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel Hello Guilers! Here’s a quick review of ‘goops-cleanup’. "Andy Wingo" <wingo@pobox.com> writes: > - Log ----------------------------------------------------------------- > commit b1955b1187eccb9383154942f0353d5cdcfeed99 > Author: Andy Wingo <wingo@pobox.com> > Date: Tue Nov 3 23:59:51 2009 +0100 > [...] > Applicable struct runtime support. Sounds nice. [...] > * libguile/deprecated.h (scm_vtable_index_vtable): Define as a synonym > for scm_vtable_index_self. > (scm_vtable_index_printer): Alias scm_vtable_index_instance_printer. > (scm_struct_i_free): Alias scm_vtable_index_instance_finalize. > (scm_struct_i_flags): Alias scm_vtable_index_flags. IIUC these are no longer negative indices, but why deprecate them? > (SCM_STRUCTF_FLAGS): Be a -1 mask, we have a whole word now. > (SCM_SET_VTABLE_DESTRUCTOR): Implement by hand. Likewise. > Hidden slots. > > * libguile/struct.c (scm_make_struct_layout): Add support for "hidden" > fields, writable fields that are not visible to make-struct. This > allows us to add fields to vtables and not break existing make-struct > invocations. My first reaction was that it may make the struct layout code yet hairier. Would opaque fields be usable for that purpose? In what sense does it attempt to “not break existing make-struct invocations”? [...] > * libguile/struct.h: Lay things out cleaner. There are no more hidden > (negative) words. Names are nicer. The exposition is nicer. But the > basics are the same. The incompatibilities are that <vtable> has more > slots now, and that scm_alloc_struct's signature has changed. The > former is ameliorated by the "hidden" slots mentioned before, and the > latter, well, it was always a very internal thing... Could you eventually make the log slightly more formal, describing the changes more than the feelings? :-) [...] > Remove foreign object implementation. Good. [...] > Clean up goops.h, a little. OK. Besides: + for (i = 0; i < n; i++) + { scm_t_wchar c = scm_i_symbol_ref (layout, i*2); Could you make a pass of GNU Indent or similar, and ‘c-backslash-region’ for macros like ‘SCM_CLASS_CLASS_LAYOUT’? + /* Class objects */ + /* if ((SCM_CLASS_FLAGS (class) & SCM_CLASSF_METACLASS) + && (SCM_SUBCLASSP (class, scm_class_entity_class))) + SCM_SET_CLASS_FLAGS (obj, SCM_VTABLE_FLAG_APPLICABLE); */ Maybe this comment can be removed? + ret = (scm_t_bits)scm_gc_malloc (sizeof (scm_t_bits) * (n_words + 2), "struct"); + /* Now that all platforms support scm_t_uint64, I would think that malloc on + all platforms is required to return 8-byte-aligned blocks. This test will + let us find out quickly though ;-) */ + if (ret & 7) + abort (); Rest assured: libgc returns 8-byte aligned data (otherwise pairs wouldn’t work). See http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/1272 . -typedef void (*scm_t_struct_free) (scm_t_bits * vtable, scm_t_bits * data); +typedef void (*scm_t_struct_finalize) (SCM obj); I’m slightly concerned about the incompatibility. What’s the rationale? (I reckon that passing ‘scm_t_bits’ pointers to user code is not very elegant.) [...] > commit ba33a21a28ceb5cf5a30ca34d4f833b8e3292187 > Author: Andy Wingo <wingo@pobox.com> > Date: Tue Nov 3 22:43:29 2009 +0100 > > actually set all 8 hashsets in classes > > * libguile/goops.c (prep_hashsets): Actually set all 8 hashsets. Doh... > > commit 0fb03157867ae1d12257928f9253c19b267e8ede > Author: Andy Wingo <wingo@pobox.com> > Date: Tue Nov 3 22:41:59 2009 +0100 > > remove goops-local %tag-body > > * libguile/goops.c (scm_sys_tag_body): Remove goops-local hack that is > no longer necessary. > > commit 84dab750a7db5e451b4bc6e49652161d298621a9 > Author: Andy Wingo <wingo@pobox.com> > Date: Tue Nov 3 22:33:22 2009 +0100 > > SCM_VALIDATE_VTABLE tweak > > * libguile/validate.h (SCM_VALIDATE_VTABLE): Simply call > scm_struct_vtable_p. > > commit d427d8386ad5d23332280d60eaef7226620513bf > Author: Andy Wingo <wingo@pobox.com> > Date: Tue Nov 3 22:32:39 2009 +0100 > > fix printing-programs bug > > * module/system/vm/program.scm (write-program): Fix a bug if we couldn't > get a procedure's arity. > > commit 48a69b27398d88dd54965b7584191acf2a974fde > Author: Andy Wingo <wingo@pobox.com> > Date: Tue Nov 3 22:28:26 2009 +0100 > > values.c defines a vtable, not a vtable-vtable > > * libguile/values.c (scm_init_values): Define a vtable, not a > "metaclass". > > commit d8ebd1d41d3cfe0aab118c214dc7db4b0ac3c433 > Author: Andy Wingo <wingo@pobox.com> > Date: Tue Nov 3 22:27:34 2009 +0100 > > srfi-35 properly uses vtable-offset-user > > * module/srfi/srfi-35.scm (condition-type-id): > (condition-type-parent, condition-type-all-fields): Don't ref fixed > struct indices, use vtable-offset-user instead. OK up to here. > commit 635bc2288076acfa5fcd305704d2a95b882fa090 > Author: Andy Wingo <wingo@pobox.com> > Date: Tue Nov 3 22:26:46 2009 +0100 > > fix a structs.test test > > * test-suite/tests/structs.test ("equal?"): Instantiate vtables, not > vtable-vtables. "hello" is not a valid vtable layout. - (let* ((vtable (make-vtable-vtable "pr" 0)) + (let* ((vtable (make-vtable "pr")) Does that mean that "hello" as a layout specifier was not detected as erroneous? Or is there something more subtle going on here? (I’ve always thought that ‘make-vtable-vtable’ has no good raison d’être. The GOOPS/CLOS model has only ‘make’, and it makes perfect sense to have a single procedure to “make things out of meta-things”.) > commit 67d29780cd0288bb8b6825ac9bfe207a3b5192b8 > Author: Andy Wingo <wingo@pobox.com> > Date: Sun Nov 1 21:09:42 2009 +0100 > > remove redundant, unnecessary instance size from struct vtables > > * libguile/struct.h (scm_struct_i_size): Remove this shared field -- I > mean, the slot is still there, but it's only used for flags. > > * libguile/goops.h (SCM_SET_CLASS_INSTANCE_SIZE): > * libguile/goops.c (scm_sys_inherit_magic_x, scm_make_class): Remove > uses and definition of SCM_SET_CLASS_INSTANCE_SIZE. Light structs used > it, but you have that info in the layout; and foreign classes used it, > but that is going away soon anyway :) > > commit 2f145cc2974c1b528fed5e1cc7855d553f084c57 > Author: Andy Wingo <wingo@pobox.com> > Date: Sun Nov 1 20:45:02 2009 +0100 > > fold objects.[ch] into goops.[ch] > > Remove objects.h #includes as appropriate. > > commit 5ea6ce3cde873cb75e4eddd36781182940177d68 > Author: Andy Wingo <wingo@pobox.com> > Date: Sun Nov 1 19:46:27 2009 +0100 > > remove support for "entities" -- a form of applicable struct > > Entities were meant to be a form of applicable struct. Unfortunately, > the implementation is intertwingled with generics. Removing them, for > now, will make it possible to cleanly re-add applicable struct support. Sounds good to me. It seems unlikely that these were used outside of Guile. What do you think? [...] > commit 0dccce8b8ab89c56b0816801b7700d1bed80ee8c > Author: Andy Wingo <wingo@pobox.com> > Date: Sat Oct 31 12:04:53 2009 +0100 > > SCM_GENERIC_METHOD_CACHE macro splits from SCM_ENTITY_PROCEDURE > > * libguile/goops.h (SCM_GENERIC_METHOD_CACHE) > (SCM_SET_GENERIC_METHOD_CACHE): Two new macros; the same as > SCM_[SET_]ENTITY_PROCEDURE, but more reflecting the reality of the > generic hack. > > * libguile/eval.i.c: > * libguile/goops.c: > * libguile/objects.c: > * libguile/vm-i-system.c: Use the new macros when it is appropriate to > do so. > > commit 87af2dfc34cb5228de3574057a277df930581547 > Author: Andy Wingo <wingo@pobox.com> > Date: Sat Oct 31 11:17:12 2009 +0100 > > remove unused things from object.[ch] > > * libguile/objects.h: > * libguile/objects.c (scm_object_procedure): Remove, it was only > compiled with SCM_DEBUG. > > * libguile/objects.h: > * libguile/objects.c (scm_make_class_object, scm_make_subclass_object, > (scm_i_make_class_object, scm_metaclass_standard): Remove also. These > implemented an undocumented object system, and are totally replaced by > GOOPS. > > commit 90dcbb12be64260cb1329c456a4f02900639347d > Author: Andy Wingo <wingo@pobox.com> > Date: Sat Oct 31 00:28:43 2009 +0100 > > remove operators > > commit a1724f53c0e51d5577d8e50d25867abc010991d0 > Author: Andy Wingo <wingo@pobox.com> > Date: Sat Oct 31 00:08:42 2009 +0100 > > generic dispatch in the vm (sorta) > > * libguile/vm-i-system.c (call, goto/args, mv-call): Add a case for > generics, so we can avoid the evaluator in that case. Still have to > cons up a list -- the real solution comes later. > > commit 0108ba52a1da29e6b0f84c6380a5d4b36311a271 > Author: Andy Wingo <wingo@pobox.com> > Date: Thu Oct 29 09:47:00 2009 +0100 > > remove unused struct gc chain macros > > * libguile/struct.h (SCM_STRUCT_GC_CHAIN, SCM_SET_STRUCT_GC_CHAIN): > Remove, no longer necessary given topological finalization, provided > by libGC. > > commit 8fa54cfd403e82ae4818c817036106e9f13e90e3 > Author: Andy Wingo <wingo@pobox.com> > Date: Fri Oct 30 22:21:29 2009 +0100 > > de-inline goops dispatch from the evaluator Perfect! Keep up the good work! Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-9-4-72-gb1955b1 2009-11-05 18:13 ` [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-9-4-72-gb1955b1 Ludovic Courtès @ 2009-11-05 23:35 ` Andy Wingo 2009-11-08 0:41 ` Ludovic Courtès 0 siblings, 1 reply; 6+ messages in thread From: Andy Wingo @ 2009-11-05 23:35 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel Hi, On Thu 05 Nov 2009 19:13, ludo@gnu.org (Ludovic Courtès) writes: > Here’s a quick review of ‘goops-cleanup’. Thanks very much :-)) > "Andy Wingo" <wingo@pobox.com> writes: > >> * libguile/deprecated.h (scm_vtable_index_vtable): Define as a synonym >> for scm_vtable_index_self. >> (scm_vtable_index_printer): Alias scm_vtable_index_instance_printer. >> (scm_struct_i_free): Alias scm_vtable_index_instance_finalize. >> (scm_struct_i_flags): Alias scm_vtable_index_flags. > > IIUC these are no longer negative indices, but why deprecate them? I think they are bad names. scm_vtable_index_vtable sounds nonsensical. scm_vtable_index_printer prints instances, not the vtable itself. scm_struct_i_free is only valid on vtables, and is just a function that runs at finalization time, and doesn't actually free anything. scm_struct_i_flags is only valid on vtables. >> (SCM_STRUCTF_FLAGS): Be a -1 mask, we have a whole word now. >> (SCM_SET_VTABLE_DESTRUCTOR): Implement by hand. > > Likewise. It is now deprecated to access flags through a mask, because the mask is unnecessary. "Destructor" isn't mentioned anywhere else in Guile. >> Hidden slots. >> >> * libguile/struct.c (scm_make_struct_layout): Add support for "hidden" >> fields, writable fields that are not visible to make-struct. This >> allows us to add fields to vtables and not break existing make-struct >> invocations. > > My first reaction was that it may make the struct layout code yet > hairier. Would opaque fields be usable for that purpose? In what sense > does it attempt to “not break existing make-struct invocations”? Imagine you have a vtable vtable with an extra field. The make-struct invocation to make a vtable of that vtable-vtable is (make-struct vtable-vtable layout printer extra-field). Hidden fields allow us to add more fields to e.g. all vtables -- like a name -- without having "extra-field" being interpreted as that extra field. Opaque fields work but they're not readable or writable, which you want a name to be. It's not that bad actually. >> * libguile/struct.h: Lay things out cleaner. There are no more hidden >> (negative) words. Names are nicer. The exposition is nicer. But the >> basics are the same. The incompatibilities are that <vtable> has more >> slots now, and that scm_alloc_struct's signature has changed. The >> former is ameliorated by the "hidden" slots mentioned before, and the >> latter, well, it was always a very internal thing... > > Could you eventually make the log slightly more formal, describing the > changes more than the feelings? :-) I don't know, that was such a big commit that it's hard to separate things... I'll check to see if there's something more useful I can say. > + for (i = 0; i < n; i++) > + { scm_t_wchar c = scm_i_symbol_ref (layout, i*2); > > Could you make a pass of GNU Indent or similar, Ah sorry, it's work's coding style infecting me... > and ‘c-backslash-region’ for macros like ‘SCM_CLASS_CLASS_LAYOUT’? Sure. > + /* Class objects */ > + /* if ((SCM_CLASS_FLAGS (class) & SCM_CLASSF_METACLASS) > + && (SCM_SUBCLASSP (class, scm_class_entity_class))) > + SCM_SET_CLASS_FLAGS (obj, SCM_VTABLE_FLAG_APPLICABLE); */ > > Maybe this comment can be removed? I'm coming back to it :) > + ret = (scm_t_bits)scm_gc_malloc (sizeof (scm_t_bits) * (n_words + 2), "struct"); > + /* Now that all platforms support scm_t_uint64, I would think that malloc on > + all platforms is required to return 8-byte-aligned blocks. This test will > + let us find out quickly though ;-) */ > + if (ret & 7) > + abort (); > > Rest assured: libgc returns 8-byte aligned data Great! Will remove. > -typedef void (*scm_t_struct_free) (scm_t_bits * vtable, scm_t_bits * data); > +typedef void (*scm_t_struct_finalize) (SCM obj); > > I’m slightly concerned about the incompatibility. What’s the rationale? > (I reckon that passing ‘scm_t_bits’ pointers to user code is not very > elegant.) It was never documented, and only used by guile-gnome afaik. Better to change it to do the right thing, then document it :-) I think it should be possible to resuscitate objects too... But that's another topic. > - (let* ((vtable (make-vtable-vtable "pr" 0)) > + (let* ((vtable (make-vtable "pr")) > > Does that mean that "hello" as a layout specifier was not detected as > erroneous? Yes. Later commits cause this to raise an error. > (I’ve always thought that ‘make-vtable-vtable’ has no good raison > d’être. The GOOPS/CLOS model has only ‘make’, and it makes perfect > sense to have a single procedure to “make things out of meta-things”.) A struct is an object. A vtable is a class. A vtable-vtable is a metaclass. Metaclasses are themselves classes; and classes are themselves objects. You need make-vtable-vtable to make a new strange loop at the top, like <class> being an instance of itself. It's confusing a bit, and delightful :) See http://wingolog.org/pub/goops-inline-slots.png. >> remove support for "entities" -- a form of applicable struct >> >> Entities were meant to be a form of applicable struct. Unfortunately, >> the implementation is intertwingled with generics. Removing them, for >> now, will make it possible to cleanly re-add applicable struct support. > > Sounds good to me. It seems unlikely that these were used outside of > Guile. What do you think? I think that's about right. But they correspond to a useful thing -- applicable structs that are not generics. They'll come back, but with a less confusing name. (I hate that name, "entity".) Thanks very much for the review, I'll go through this mail and poke the branch before merging. Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-9-4-72-gb1955b1 2009-11-05 23:35 ` Andy Wingo @ 2009-11-08 0:41 ` Ludovic Courtès 2009-11-21 18:22 ` Andy Wingo 0 siblings, 1 reply; 6+ messages in thread From: Ludovic Courtès @ 2009-11-08 0:41 UTC (permalink / raw) To: guile-devel Hello! Andy Wingo <wingo@pobox.com> writes: > On Thu 05 Nov 2009 19:13, ludo@gnu.org (Ludovic Courtès) writes: [...] >> "Andy Wingo" <wingo@pobox.com> writes: >> >>> * libguile/deprecated.h (scm_vtable_index_vtable): Define as a synonym >>> for scm_vtable_index_self. >>> (scm_vtable_index_printer): Alias scm_vtable_index_instance_printer. >>> (scm_struct_i_free): Alias scm_vtable_index_instance_finalize. >>> (scm_struct_i_flags): Alias scm_vtable_index_flags. >> >> IIUC these are no longer negative indices, but why deprecate them? > > I think they are bad names. scm_vtable_index_vtable sounds nonsensical. > scm_vtable_index_printer prints instances, not the vtable itself. > scm_struct_i_free is only valid on vtables, and is just a function that > runs at finalization time, and doesn't actually free anything. > scm_struct_i_flags is only valid on vtables. OK, I agree. >>> (SCM_STRUCTF_FLAGS): Be a -1 mask, we have a whole word now. >>> (SCM_SET_VTABLE_DESTRUCTOR): Implement by hand. >> >> Likewise. > > It is now deprecated to access flags through a mask, because the mask is > unnecessary. "Destructor" isn't mentioned anywhere else in Guile. OK. >>> Hidden slots. >>> >>> * libguile/struct.c (scm_make_struct_layout): Add support for "hidden" >>> fields, writable fields that are not visible to make-struct. This >>> allows us to add fields to vtables and not break existing make-struct >>> invocations. >> >> My first reaction was that it may make the struct layout code yet >> hairier. Would opaque fields be usable for that purpose? In what sense >> does it attempt to “not break existing make-struct invocations”? > > Imagine you have a vtable vtable with an extra field. The make-struct > invocation to make a vtable of that vtable-vtable is (make-struct > vtable-vtable layout printer extra-field). Hidden fields allow us to add > more fields to e.g. all vtables -- like a name -- without having > "extra-field" being interpreted as that extra field. Understood. And what’s the use case that prompted you to implement this? >> -typedef void (*scm_t_struct_free) (scm_t_bits * vtable, scm_t_bits * data); >> +typedef void (*scm_t_struct_finalize) (SCM obj); (Can you make sure these two type names appear in the log? It makes it easier to search for them.) >> I’m slightly concerned about the incompatibility. What’s the rationale? >> (I reckon that passing ‘scm_t_bits’ pointers to user code is not very >> elegant.) > > It was never documented, and only used by guile-gnome afaik. Better to > change it to do the right thing, then document it :-) I can’t help but think that if guile-gnome uses it, then others might as well use it. Could you make it a separate patch? >> - (let* ((vtable (make-vtable-vtable "pr" 0)) >> + (let* ((vtable (make-vtable "pr")) >> >> Does that mean that "hello" as a layout specifier was not detected as >> erroneous? > > Yes. Later commits cause this to raise an error. Nice. >> (I’ve always thought that ‘make-vtable-vtable’ has no good raison >> d’être. The GOOPS/CLOS model has only ‘make’, and it makes perfect >> sense to have a single procedure to “make things out of meta-things”.) > > A struct is an object. A vtable is a class. A vtable-vtable is a > metaclass. Metaclasses are themselves classes; and classes are > themselves objects. You need make-vtable-vtable to make a new strange > loop at the top, like <class> being an instance of itself. Hmm I don’t see why ‘make-vtable-vtable’ is required to make the loop. But that’s another story. > It's confusing a bit, and delightful :) See > http://wingolog.org/pub/goops-inline-slots.png. Nice diagram! :-) >> Sounds good to me. It seems unlikely that these were used outside of >> Guile. What do you think? > > I think that's about right. But they correspond to a useful thing -- > applicable structs that are not generics. They'll come back, but with a > less confusing name. (I hate that name, "entity".) So do I. Cool, thanks! Ludo’. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-9-4-72-gb1955b1 2009-11-08 0:41 ` Ludovic Courtès @ 2009-11-21 18:22 ` Andy Wingo 2009-11-23 8:05 ` Ken Raeburn 0 siblings, 1 reply; 6+ messages in thread From: Andy Wingo @ 2009-11-21 18:22 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-devel Hi! On Sun 08 Nov 2009 01:41, ludo@gnu.org (Ludovic Courtès) writes: > Andy Wingo <wingo@pobox.com> writes: > >> On Thu 05 Nov 2009 19:13, ludo@gnu.org (Ludovic Courtès) writes: > >>> "Andy Wingo" <wingo@pobox.com> writes: >>> >>>> Hidden slots. >>>> >>>> * libguile/struct.c (scm_make_struct_layout): Add support for "hidden" >>>> fields, writable fields that are not visible to make-struct. This >>>> allows us to add fields to vtables and not break existing make-struct >>>> invocations. >>> >>> My first reaction was that it may make the struct layout code yet >>> hairier. Would opaque fields be usable for that purpose? In what sense >>> does it attempt to “not break existing make-struct invocations”? >> >> Imagine you have a vtable vtable with an extra field. The make-struct >> invocation to make a vtable of that vtable-vtable is (make-struct >> vtable-vtable layout printer extra-field). Hidden fields allow us to add >> more fields to e.g. all vtables -- like a name -- without having >> "extra-field" being interpreted as that extra field. > > Understood. And what’s the use case that prompted you to implement > this? Adding a field to all vtables -- a name. Most all vtables need a name. >>> -typedef void (*scm_t_struct_free) (scm_t_bits * vtable, scm_t_bits * data); >>> +typedef void (*scm_t_struct_finalize) (SCM obj); > > (Can you make sure these two type names appear in the log? It makes it > easier to search for them.) OK. >>> I’m slightly concerned about the incompatibility. What’s the rationale? >>> (I reckon that passing ‘scm_t_bits’ pointers to user code is not very >>> elegant.) >> >> It was never documented, and only used by guile-gnome afaik. Better to >> change it to do the right thing, then document it :-) > > I can’t help but think that if guile-gnome uses it, then others might as > well use it. Could you make it a separate patch? Guile-GNOME only uses it because I grubbed about for months and months and found it. It might be presumptuous, but I really don't think anyone else knew about it. But OK. I will try. I just hate revisiting that commit that I spent so much time on :/ >>> (I’ve always thought that ‘make-vtable-vtable’ has no good raison >>> d’être. The GOOPS/CLOS model has only ‘make’, and it makes perfect >>> sense to have a single procedure to “make things out of meta-things”.) >> >> A struct is an object. A vtable is a class. A vtable-vtable is a >> metaclass. Metaclasses are themselves classes; and classes are >> themselves objects. You need make-vtable-vtable to make a new strange >> loop at the top, like <class> being an instance of itself. > > Hmm I don’t see why ‘make-vtable-vtable’ is required to make the loop. > But that’s another story. CLOS also has inherent metacircularities. >> It's confusing a bit, and delightful :) See >> http://wingolog.org/pub/goops-inline-slots.png. > > Nice diagram! :-) Followed up by http://wingolog.org/archives/2009/11/09/class-redefinition-in-guile :) The branch is finished now, btw. I intend to merge whenever I get time to fix those patches. Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-9-4-72-gb1955b1 2009-11-21 18:22 ` Andy Wingo @ 2009-11-23 8:05 ` Ken Raeburn 2009-11-24 22:29 ` Andy Wingo 0 siblings, 1 reply; 6+ messages in thread From: Ken Raeburn @ 2009-11-23 8:05 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel On Nov 21, 2009, at 13:22, Andy Wingo wrote: >>> It's confusing a bit, and delightful :) See >>> http://wingolog.org/pub/goops-inline-slots.png. >> >> Nice diagram! :-) > > Followed up by > http://wingolog.org/archives/2009/11/09/class-redefinition-in-guile :) Nice description. But, I'm looking at it, and thinking... is that widget update done in a thread-safe manner? Ken ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-9-4-72-gb1955b1 2009-11-23 8:05 ` Ken Raeburn @ 2009-11-24 22:29 ` Andy Wingo 0 siblings, 0 replies; 6+ messages in thread From: Andy Wingo @ 2009-11-24 22:29 UTC (permalink / raw) To: Ken Raeburn; +Cc: guile-devel On Mon 23 Nov 2009 09:05, Ken Raeburn <raeburn@raeburn.org> writes: > On Nov 21, 2009, at 13:22, Andy Wingo wrote: >>>> It's confusing a bit, and delightful :) See >>>> http://wingolog.org/pub/goops-inline-slots.png. >>> >>> Nice diagram! :-) >> >> Followed up by >> http://wingolog.org/archives/2009/11/09/class-redefinition-in-guile :) > > Nice description. > > But, I'm looking at it, and thinking... is that widget update done in a > thread-safe manner? There is a token nod to threadsafety with some locks in goops.c. However I would not be surprised if there were some corner cases. Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-11-24 22:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1N5STy-0005mm-2g@cvs.savannah.gnu.org>
2009-11-05 18:13 ` [Guile-commits] GNU Guile branch, goops-cleanup, created. release_1-9-4-72-gb1955b1 Ludovic Courtès
2009-11-05 23:35 ` Andy Wingo
2009-11-08 0:41 ` Ludovic Courtès
2009-11-21 18:22 ` Andy Wingo
2009-11-23 8:05 ` Ken Raeburn
2009-11-24 22:29 ` Andy Wingo
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).