+*** auxilliary file for caching info.
+
+*** Text_crescendo
+
+*** clean solution for staffsize in items.
+
+*** revise calcideal
+** IDEAS
+*** Output data structures of Mudela in XML/SGML.
+*** create libmudela, or liblily_frontend
+*** move MIDI stuff (including Quantization) to a ANSI C libmidi library.
+*** Spacing_request for manually adjusting spacing
+*** caching breakpoints
+*** used fixedpoint arithmetic for min. energy.
+*** move towards incremental algorithms.
+*** far fetched language ideas
+**** design meta-language like TeX and Metafont
+**** programming/macros input
+*** versioning stuff (cvt mudela, mudela, etc.)
+*** Klavarskribo?
+*** dynamic loading of engravers?
+** SMOBS
+Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
+
+> mcmanus@IDT.NET writes:
+> > > I want different C++ objects (with scheme embedded) to be linked by
+> > > C++ pointers. I want to access these other objects from the Scheme
+> > > code, and I want access to these pointers from C++.
+> >
+> > You can do this with a combination of smob's and primitive functions,
+> > though it may not be be exactly what you wanted. You would have one
+> > smob for each class in your application, and then you would write a
+> > primitive function that would return the objects that are linked to a
+> > base object.
+>
+> And the smob and the C++ class are interlinked? Like
+>
+> class Foo_class {
+> Foo_smob *smob_ptr_;
+> }
+>
+> struct Foo_smob {
+> Foo_class *class_ptr_
+> }
+
+Usually you can get away without having this interlinked structure.
+One piece of information you need when exporting objects to scheme is
+the smob tag for your class. You might store this value (a long) into
+a class static variable, or a file static variable. I'll use a class
+static variable in this example.
+
+I typically use code that works like this (untested code ahead):
+
+class Foo_class {
+ static long *Foo_smob_tag;
+ SCM obj; // representation as a scheme object, description comes later
+}
+
+// call this once on startup
+void init_Foo_class {
+ static scm_smobfuns type_rec;
+
+ type_rec.mark = foo_mark;
+ type_rec.free = foo_free;
+ type_rec.print = foo_display;
+ type_rec.equalp = 0;
+ Foo_class::Foo_smob_tag = new int(scm_new_smob(type_rec));
+}
+
+When you want to export an object to scheme, you put a pointer to the
+object itself in the cdr of the cell, and the tag in the car of the
+cell. The code looks like this:
+
+// Is this a Foo?
+static int
+foo_p(SCM obj)
+{
+ return(SCM_NIMP(obj) && SCM_CAR(obj) == Foo_class::Foo_smob_tag);
+}
+
+// given a Scheme representation, return, a C++ representation
+static Foo_class *
+foo_unbox(SCM obj)
+{
+ return((Foo_class*)SCM_CDR(obj));
+}
+
+// the SCM representation of the object is stored inside itself
+// this will become useful when destructor gets called
+static SCM
+foo_box(Foo_class *foo)
+{
+ SCM_DEFER_INTS;
+ SCM_NEWCELL(foo->obj);
+ SCM_SETCAR(foo->obj, Foo_class::Foo_smob_tag);
+ SCM_SETCDR(foo->obj, (SCM)foo);
+ SCM_ALLOW_INTS;
+ return foo->obj;
+}
+
+> C++ determines life time, so what is the strategy?
+
+What happens now when the destructor gets called? Lets set the cdr to
+NULL, and then check for that in all of the primitive functions that
+use your smob. We'll call this notion 'live'; a scheme object is
+'live' if the C++ representation still exists, it's dead if the C++
+object is gone. You can still have references to dead objects in
+scheme code; it's just an error to use them. This idea is stolen from
+Emacs's handling of buffers ('buffer-live-p' and friends).
+
+Add another function, foo_live_p:
+
+static int
+foo_live_p(SCM obj)
+{
+ return(foo_p(obj) && SCM_CDR(obj) != NULL);
+}
+
+In you destructor, you need to do:
+
+~Foo_class()
+{
+ SCM_CDR(this->obj, NULL);
+}
+
+When writing new primitives, now just check foo_live_p().
+
+I hope the above helps,
+
+-russ
+
+
+--
+"Even if you are on the right track, you'll get run over
+if you just sit there."
+ --Will Rogers (1879-1935)
+
+> I am still muddling along with integrating GUILE in LilyPond, and I
+> have a question. I want to replace an existing C++ implementation of
+> identifier tables by GUILE's code. I've managed to replace
+>
+> Hash_table<String,Identifier*>
+>
+> by
+>
+> Hash_table<SCM, Identifier*>
+>
+> and use interning and GUILE symbols for doing the identifier lookup.
+> But I'd like to use GUILE's hash tables as well, and that's were my
+> question comes in: is there an interface that allows me to iterate
+> through the entries of a GUILE hash table?
+
+I use the following, which should definitely be provided somewhere
+in guile, but isn't, AFAIK:
+
+(define (hash-table-for-each fn ht)
+ (do ((i 0 (+ 1 i)))
+ ((= i (vector-length ht)))
+ (do ((alist (vector-ref ht i) (cdr alist)))
+ ((null? alist) #t)
+ (fn (car (car alist)) (cdr (car alist))))))
+
+(define (hash-table-map fn ht)
+ (do ((i 0 (+ 1 i))
+ (ret-ls '()))
+ ((= i (vector-length ht)) (reverse ret-ls))
+ (do ((alist (vector-ref ht i) (cdr alist)))
+ ((null? alist) #t)
+ (set! ret-ls (cons (fn (car (car alist)) (cdr (car alist))) ret-ls)))))
+
+If you want a C version, you can run the above code through hobbit, or
+tranlate it to C by hand.
+
+-russ
+
+
+--
+"Whenever you find yourself on the side of the majority, it is time to
+pause and reflect."
+ -- Mark Twain