Re: Implementation of music streams
On 5/15/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: Erik Sandberg schreef: > However, I have found one good alternative, where the stream event has > no unique field. This approach involves a dummy event > "AnnounceContext", which are sent by newly created contexts. These > messages have no musical meaning, and should not be part of any output > file, but you must listen to them if you want to find out about the > context structure. > > I'd suggest that an AnnounceContext event contains a direct reference > to the newly created context, as well as a direct reference to the > CreateContext event. This makes it very clear which CreateContext > events that result in which contexts. > > I like my new design better than my original one, because data is > separated in a more logical way, and because I think it eliminates a > bad hack in create_context. It sounds better, but I'm still not following you completely. Why can't you connect the StreamEvents to the appropriate context in the stream reader? Ie. why does it need the intervention of (dummy) events? The main problem is in the stream writer: Even if you hear a CreateContext event from a context, you don't have a clue how to find the newly created context (except that you can look at the parent's children and find the best match, which isn't robust without a unique value). There is a similar problem in the reader: When the reader sends a CreateContext event, it only knows that the event will trigger a context creation; I don't see a nice way of finding the newly created context without adding a dummy event. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
Erik Sandberg schreef: However, I have found one good alternative, where the stream event has no unique field. This approach involves a dummy event "AnnounceContext", which are sent by newly created contexts. These messages have no musical meaning, and should not be part of any output file, but you must listen to them if you want to find out about the context structure. I'd suggest that an AnnounceContext event contains a direct reference to the newly created context, as well as a direct reference to the CreateContext event. This makes it very clear which CreateContext events that result in which contexts. I like my new design better than my original one, because data is separated in a more logical way, and because I think it eliminates a bad hack in create_context. It sounds better, but I'm still not following you completely. Why can't you connect the StreamEvents to the appropriate context in the stream reader? Ie. why does it need the intervention of (dummy) events? -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
On 5/15/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: 2006/5/15, Erik Sandberg <[EMAIL PROTECTED]>: > On 5/14/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > > 2006/5/14, Erik Sandberg <[EMAIL PROTECTED]>: > > > What should be the value of the 'unique field of a CreateContext event? > > > > When writing, the 'unique field to be written is determined by the file writer. > > OK, so file writers have direct listeners to all contexts then? (I've > implemented it previously using the events_below dispatcher, which is > more convenient) > > I agree it would be nice to get rid of unique. Sorry, I think we're miscommunicating something. Can you explain what the value unique is used for? AFAICS, it's only used for reading and writing streams, and isn't per se necessary inside the context tree. That observation is true. The purpose of unique is to make the reader/writer understand which newly created contexts that are connected to which events. Before a context is created, the parent decides a unique value, with which the child will tag all its events. It's a very clear and easy way to make sure that everyone agrees on which context that belong to which parent, and which stream event that belongs to which context. However, I have found one good alternative, where the stream event has no unique field. This approach involves a dummy event "AnnounceContext", which are sent by newly created contexts. These messages have no musical meaning, and should not be part of any output file, but you must listen to them if you want to find out about the context structure. I'd suggest that an AnnounceContext event contains a direct reference to the newly created context, as well as a direct reference to the CreateContext event. This makes it very clear which CreateContext events that result in which contexts. I like my new design better than my original one, because data is separated in a more logical way, and because I think it eliminates a bad hack in create_context. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
On 5/15/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: Erik Sandberg schreef: >> > Here's my plan on how to front-port music streams to the 2.9 branch. >> > >> > 1. Implement classes Dispatcher, Stream_event, Listener (move modules >> > from my thesis fork) >> > 2. Add dispatchers event_source_, and possibly events_below_, to >> Context >> > class. >> > 3. Make Context::try_music send stream events to the event_source_. > > This step is now finished, patch attached. You can notice some Can you also look my nits regarding warnings and SEND_EVENT_TO_CONTEXT below, and commit if "make web" still works? > additional stuff that has been added as well, which currently is > unused but will be used in future patches. You will notice that this > patch makes lily spit out lots of Junking Event messages, which are > harmless. Can you make sure that in this patch those warnings are surpressed? I don't want to leave lily in a state where it prints bazillions of messages. ok Come to think of it, I don't see why SEND_EVENT_TO_CONTEXT should be a macro. Is there a reason why it can't be a function, except for the ly_symbol2scm() memoization? no, the memoization is the only reason. I can make the code less compact (inserting lots of ly_symbol2scm calls) and do it as a function, if you like. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
Erik Sandberg schreef:
> Here's my plan on how to front-port music streams to the 2.9 branch.
>
> 1. Implement classes Dispatcher, Stream_event, Listener (move modules
> from my thesis fork)
> 2. Add dispatchers event_source_, and possibly events_below_, to
Context
> class.
> 3. Make Context::try_music send stream events to the event_source_.
This step is now finished, patch attached. You can notice some
Can you also look my nits regarding warnings and SEND_EVENT_TO_CONTEXT
below, and commit if "make web" still works?
additional stuff that has been added as well, which currently is
unused but will be used in future patches. You will notice that this
patch makes lily spit out lots of Junking Event messages, which are
harmless.
Can you make sure that in this patch those warnings are surpressed?
I don't want to leave lily in a state where it prints bazillions of
messages.
Regarding SEND_EVENT_TO_CONTEXT(ctx, cl, ...) and EVENT_PROPERTY:
I think the proper unproctect method nowadays is
smob->unprotect()
also wouldn't it be possible to do away with EVENT_PROPERTY, and just do
send_event_to_context (c, ev,
ly_symbol2scm ("key"), val,
ly_symbol2scm ("key2"), val2)
and in the macro do something like
SCM args[] = { __VA_ARGS__ , 0 };
for (int i = 0; args[i]; i+=2)
..
I think that this reads more logically. Come to think of it, I don't see
why SEND_EVENT_TO_CONTEXT should be a macro. Is there a reason why it
can't be a function, except for the ly_symbol2scm() memoization?
If you want to keep the macro, then at least make sure the actual code
body which says
Stream_event *_e_ = new Stream_event (ctx, ly_symbol2scm (cl));
ctx->event_source ()->distribute (_e_);
scm_gc_unprotect_object (_e_->self_scm ());
is in a function. That makes debugging a bit easier and reads more
logically.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
2006/5/15, Erik Sandberg <[EMAIL PROTECTED]>: On 5/14/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > 2006/5/14, Erik Sandberg <[EMAIL PROTECTED]>: > > What should be the value of the 'unique field of a CreateContext event? > > When writing, the 'unique field to be written is determined by the file writer. OK, so file writers have direct listeners to all contexts then? (I've implemented it previously using the events_below dispatcher, which is more convenient) I agree it would be nice to get rid of unique. Sorry, I think we're miscommunicating something. Can you explain what the value unique is used for? AFAICS, it's only used for reading and writing streams, and isn't per se necessary inside the context tree. -- Han-Wen Nienhuys [EMAIL PROTECTED] http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
On 5/14/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: 2006/5/14, Erik Sandberg <[EMAIL PROTECTED]>: > What should be the value of the 'unique field of a CreateContext event? When writing, the 'unique field to be written is determined by the file writer. OK, so file writers have direct listeners to all contexts then? (I've implemented it previously using the events_below dispatcher, which is more convenient) I agree it would be nice to get rid of unique. There are however some problems, mainly that the writer needs to figure out which context that the CreateContext event created. The problem can be solved in an unclean way (e.g. look up all child contexts in the context->int map and see which one that isn't already in the lookup), question is what's the Right Way to do it. Hm. One way that feels quite OK is to keep CreateContext as it is, but remove the unique field, and then let newly created contexts signal their creation with a AnnounceContext event, which only contains a reference to the context itself. The AnnounceContext event has no semantics and will not be part of the output file. Instead, only those who are interested in accessing the new context directly (i.e. the one who sent the CreateContext event initially, and the file writer) will listen to the AnnounceContext event. There will be problems if a CreateContext triggers another CreateContext event before the first one reaches the file writer; this is a clear strength of the unique system. But I'm too tired to think about that now. (chronology: 1. CreateContext event is created and dispatched. 2. event arrives to parent context, which creates new context. 3. event arrives to file writer, which must associate the event with the newly created context. other listeners may exist between 2 and 3, which may want to create new contexts; in that case the file writer may receive CreateContext and AnnounceContext events in a strange order). (sorry if I write confusing text. I'm going to sleep now) Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
2006/5/14, Erik Sandberg <[EMAIL PROTECTED]>: > > There's a problem with that: Context creation is triggered by stream > > events, which tell which unique value to use for the new context. So > > the unique value needs to be there before the context has been > > created. > > I don't understand this argument. What should be the value of the 'unique field of a CreateContext event? When writing, the 'unique field to be written is determined by the file writer. When reading, the field indicating the context where any event has to go is as int. This int is mapped to a Context* by a separate lookup table. As you noticed before, nobody looks at the unique field, which suggests to me that it is superfluous. -- Han-Wen Nienhuys [EMAIL PROTECTED] http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
On 5/14/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: Erik Sandberg schreef: >> > This step is now finished, patch attached. You can notice some >> > additional stuff that has been added as well, which currently is >> > unused but will be used in future patches. You will notice that this >> > patch makes lily spit out lots of Junking Event messages, which are >> > harmless. > > so I may apply the patch then? I would like to look over it one more time. OK, tell me when you're done (nothing has changed since the patch I sent in the root of this thread). > There's a problem with that: Context creation is triggered by stream > events, which tell which unique value to use for the new context. So > the unique value needs to be there before the context has been > created. I don't understand this argument. What should be the value of the 'unique field of a CreateContext event? For reading the stream, you need a map mapping, of course. why? unique ints are unique enough for me. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
Erik Sandberg schreef: > This step is now finished, patch attached. You can notice some > additional stuff that has been added as well, which currently is > unused but will be used in future patches. You will notice that this > patch makes lily spit out lots of Junking Event messages, which are > harmless. so I may apply the patch then? I would like to look over it one more time. There's a problem with that: Context creation is triggered by stream events, which tell which unique value to use for the new context. So the unique value needs to be there before the context has been created. I don't understand this argument. For reading the stream, you need a map mapping, of course. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
"Erik Sandberg" <[EMAIL PROTECTED]> writes: > OK, unique in the sense of eq? seems sensible. you mean in the sense of eqv?. http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%25_idx_216 (eq? 2 2) ===> unspecified (eq? #\A #\A) ===> unspecified (let ((n (+ 2 3))) (eq? n n)) ===> unspecified ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
On 5/14/06, Erik Sandberg <[EMAIL PROTECTED]> wrote: > > This step is now finished, patch attached. You can notice some > > additional stuff that has been added as well, which currently is > > unused but will be used in future patches. You will notice that this > > patch makes lily spit out lots of Junking Event messages, which are > > harmless. so I may apply the patch then? > oh btw, there is one thing that strikes about the "unique" member/argument. > > It's type is rather arbitrarily set to int. Isn't it more sensible to > make it an SCM value, and leave it up to the deliverer of the music > stream to assign unique SCM values? OK, unique in the sense of eq? seems sensible. > Second question: the whole concept of unique seems a bit out of place to > me: the number is essentially a marshalling device, making it possible > to refer to a specific context inside a stream, saved as a file, but I > don't see why it should be stored inside the Context struct. I think it > would be more appropriate to generate the numbers via a > >map > > member of the stream writer. There's a problem with that: Context creation is triggered by stream events, which tell which unique value to use for the new context. So the unique value needs to be there before the context has been created. Hm.. this could be worked around by letting newly created context send out confirmation stream events saying which context they belong to, but that would mean that each context creation is represented by two stream events, which must be consecutive. This adds some structure to the music stream, which doesn't belong there imho. An interesting observation is that so far, the context identifier has never been used for anything else than feeding a music stream into a fresh context tree. No translator ever looks at the unique value, for instance. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
> This step is now finished, patch attached. You can notice some > additional stuff that has been added as well, which currently is > unused but will be used in future patches. You will notice that this > patch makes lily spit out lots of Junking Event messages, which are > harmless. so I may apply the patch then? oh btw, there is one thing that strikes about the "unique" member/argument. It's type is rather arbitrarily set to int. Isn't it more sensible to make it an SCM value, and leave it up to the deliverer of the music stream to assign unique SCM values? OK, unique in the sense of eq? seems sensible. Second question: the whole concept of unique seems a bit out of place to me: the number is essentially a marshalling device, making it possible to refer to a specific context inside a stream, saved as a file, but I don't see why it should be stored inside the Context struct. I think it would be more appropriate to generate the numbers via a map member of the stream writer. There's a problem with that: Context creation is triggered by stream events, which tell which unique value to use for the new context. So the unique value needs to be there before the context has been created. Hm.. this could be worked around by letting newly created context send out confirmation stream events saying which context they belong to, but that would mean that each context creation is represented by two stream events, which must be consecutive. This adds some structure to the music stream, which doesn't belong there imho. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
Erik Sandberg schreef: On Tuesday 04 April 2006 20:42, Han-Wen Nienhuys wrote: Erik Sandberg wrote: > Hi, > > Here's my plan on how to front-port music streams to the 2.9 branch. > > 1. Implement classes Dispatcher, Stream_event, Listener (move modules > from my thesis fork) > 2. Add dispatchers event_source_, and possibly events_below_, to Context > class. > 3. Make Context::try_music send stream events to the event_source_. This step is now finished, patch attached. You can notice some additional stuff that has been added as well, which currently is unused but will be used in future patches. You will notice that this patch makes lily spit out lots of Junking Event messages, which are harmless. oh btw, there is one thing that strikes about the "unique" member/argument. It's type is rather arbitrarily set to int. Isn't it more sensible to make it an SCM value, and leave it up to the deliverer of the music stream to assign unique SCM values? Second question: the whole concept of unique seems a bit out of place to me: the number is essentially a marshalling device, making it possible to refer to a specific context inside a stream, saved as a file, but I don't see why it should be stored inside the Context struct. I think it would be more appropriate to generate the numbers via a map member of the stream writer. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Implementation of music streams
On Tuesday 04 April 2006 20:42, Han-Wen Nienhuys wrote: Erik Sandberg wrote: > Hi, > > Here's my plan on how to front-port music streams to the 2.9 branch. > > 1. Implement classes Dispatcher, Stream_event, Listener (move modules > from my thesis fork) > 2. Add dispatchers event_source_, and possibly events_below_, to Context > class. > 3. Make Context::try_music send stream events to the event_source_. This step is now finished, patch attached. You can notice some additional stuff that has been added as well, which currently is unused but will be used in future patches. You will notice that this patch makes lily spit out lots of Junking Event messages, which are harmless. -- Erik event-source.diff Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
