At Mon, 29 Aug 2005 00:52:17 +0200, Han-Wen Nienhuys wrote: > > ned Kristof Bastiaensen wrote: > > Hi, > > <snip> > > > > I'd appriciate an answer for these issues. > > Hi, > > I'm somewhat reluctant to add the code, since it is a large body of code > that I don't understand well enough to deal with bugreports.
I am not sure if I could do something about this. Perhaps I could refactor the code a bit to make it clearer to understand. Especially the final part is too complicated. I am considering if some kind of a pattern-matcher could simplify the whole thing. If there are comments that don't make sense, I would gladly modify them. > In addition, the whole design of the part-combiner will be trashed > anyway when we have sensible music stream datastructures (see the > mail in lilypond-devel by Erik S) > That looks interesting. The music-stream datastructure looks to me like an AST (Abstract Syntax Tree) for a compiler. Many functional languages (Haskell, Ocaml, SML) are based on such datatypes, and their type-system makes handling such AST's especially easy, together with other features like pattern-matching on types. I don't see why these ideas affect the part-combiner. The code is already written, and integrating it in the current system would be effortless (just patching it, basicly). Fixing the last bugs would be a bit of an effort, but I had the impression they were just small bugs, and wouldn't require large rewrites of code. > My conditions for integrating this patch are > > - I will need a copyright disclaimer for the code > For me it is ok to add any (open-source) license. I heard that contributors for FSF owned projects need to sign a paper for copyright issues. If that is the case, then I'll fill in the necessary paperwork (if I have the right papers). > - There should be no regressions: ie. if your code should not have bugs > that the old code did not have. > It doesn't have as far as I know (as much as that is possible to say about new code). The regression tests that came with the previous part-combiner will not work anymore, but that is deliberatly. My part-combiner only makes changes (from and to solo, a due, ...) for larger blocks (with a rather complicated algorithm to determine the beginning and end of blocks). That is to prevent to many changes from happening in a short time, making the score more cluttered and less readable. The regression tests are all small fragments, and my part-combiner will likely put the whole fragment apart, a due or solo. There are still bugs in it, but these bugs were also there in the old part-combiner. For example when there are two rests of different length in the beginning of a measure, sometimes it eats the shorter rest, leaving a hole where the shorter rest should have been. I still have a small file with examples that show these bugs. If you would like I could send them to the list. > If you need the code, also consider to add it yourself; \partcombine is > defined in ly/music-functions-init.ly , so it should not be hard to > write a partcombine-init.ly that defines a \myPartcombine and loads a > my-partcombine.scm file. > Ok, I'll probably do that for now. > -- > 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
