Am 10. Februar 2015 05:36:12 MEZ, schrieb Paul Morris <p...@paulwmorris.com>: >Hi Urs, >Good to hear about the recent progress on this. Looks like you have >put a >lot of thought and work into it.
Yes, definitely more than intended ;-) > Your post was a lot to take in, so >here >are just a few thoughts "off the top of my head." > >- What is the plan for existing oll code/content? Will there be a >library >for more "bubbly" code that it would all go into? Or several >libraries? >Or...? As you are "raising the bar" on the expectations of quality, >where >does sharing more sketchy, experimental, or in-progress work go? Everything already present should be moved "somewhere", and this process will lead to an initial set of libraries. The crucial point here is making the creation of a new library a much more deliberate step than the creation of a new folder as it was until now. There should probably one library for uncategorized stuff (e.g. "misc") and one for unstable material (e.g. "staging). > >- In terms of establishing a consistent way to extend LilyPond, I >wonder if >it would make sense to try to leverage scheme modules for this somehow? > Not >sure if that would be a good idea, but it seems worth considering. >Maybe >there would be a way to "wrap" their functionality with a more LilyPond >friendly syntax (sugar)? There is already "scheme-lib" and "general-tools/scheme-wrappers". This should be made more consistent, and I've already exchanged a few thoughts with Jan-Peter about it. > >- Why "ly" for the top level directory? There's some potential there >for >confusion with the LilyPond source code "ly" directory. What about >"oll" >instead? Is this directory temporary/transitional or permanent? It's not carved in stone but I intend it as a permanent solution. The user won't see that once it is in the include path. The toplevel "namespace" would be the library, e.g. \loadModule "scholarly/annotate". My reasoning is that the root directory will eventually have entries like ly, py, tex etc. as entry paths. > >- I'm still getting used to the idea of the libraries being dependent >on >general oll code (for things like setting options, etc.). Part of me >would >like to have them work on their own, although I guess that would still >be >possible for that to happen if the library author/maintainer chose to >do it >that way. Technically it's not more than a common directory and include path. So yes, it would still be pissible to use openLilyLib as a "distribution channel" for a self-contained piece of code. But I think it is a great advantage to have common code. Apart from the infrastructure I already started with there will be more: with all those little helper functions one uses to write one can consider moving it to a shared utility library. I've started that with the functions parsing a rhythmic location originally developed for \annotate. Thanks fir your input. Best Urs > >Cheers, >-Paul > > > >-- >View this message in context: >http://lilypond.1069038.n5.nabble.com/openLilyLib-Fundamental-reorganization-started-tp171605p171684.html >Sent from the User mailing list archive at Nabble.com. > >_______________________________________________ >lilypond-user mailing list >lilypond-user@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-user _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user