"Joao E. Pereira Jr" <[email protected]> writes: > Many of the tokens parser reads ask for Music object creation so it > calls MY_MUSIC_SYNTAX macro, as this object represents music content > and layout even a one note ly file can lead to a considerable number > of Music objects, so I deduce it plays an importante role in > architecture. A lot of Music objects are created, but is not clear how > they are stored in memory, or which data structure is used to handle > them.
They are of type ly:music?, check out lily/include/music.hh for their structure. > MY_MUSIC_SYNTAX calls are followed by Music::set_property() member > call, and them by Music::unprotect() member which return value is > assigned to grouping semantic value of action. AFAIK set_property > updates mutable_property_alist in the own object and unprotect > releases the object for GC when it becomes unused, even so I'm still > unable to tell how this object can be referred in future. MY_MUSIC_SYNTAX creates protected Music data which will not get garbage collected because of an artificial extra reference to it. After calling unprotect, this reference is gone, and the garbage collector will collect the Scheme object once it can no longer detect any _other_ reference to its SCM descriptor, whether on the stack, or inside of some other SCM object reachable from the stack or otherwise protected. > How parser handles this objects, I mean, where/how it stores Music > objects in memory? It is just an ordinary SCM object (a "smob") and managed by Guile's garbage collector. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
