Re: Updating library code
> On Oct 23, 2015, at 6:43 AM, Urs Liska wrote: > > How are you dealing with keeping code working and consistent? One simple thing I do, FWIW, is to add a short prefix to all my own functions. For example, instead of "do-something", I'd call it "cn-do-something". That way it’s clear which functions are custom functions, and it effectively removes the chance of naming collisions. -Paul ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Updating library code
[description of the problem of refactoring and code consistency in lilpond libs - snipped ] > So in essence what we need is a convert-ly-like tool for openLilyLib, > either as an independent tool or by somehow hooking into convert-ly > itself. Quite some time ago I opened an issue about this and would now > like to get some opinions, ideas and experiences how *you* deal with the > topic. > > Please reply here or add to > https://github.com/openlilylib/openlilylib/issues/87. In software development this is a well known problem and AFAIA there does not exists a solution to this problem in total. However there are quite a few guidelines to help reducing the issues that may arise. Among them are: - modularisation: whatever sequence of commands is used regularly in various files should be moved into a function/macro. That way any adjustment needs to be done just once and in one place only. - external (from the perspective of a LP installation) functions that are likely to change should be encapsulated in a wrapper function. Again the benefit is that adjustments need to be done just once. - one might wish for function prototypes and/or function signatures in lilypond such that the compiler/parser could better flag illegal use of functions and/or macros. At least for me the current error diagnostics do not always point me to the cause of the error. It sometimes takes me quite some time to understand what actually went wrong (but that may be just me - more experienced lilyponder might have a different mileage) Kind regards, Michael -- Michael Gerdau email: m...@qata.de GPG-keys available on request or at public keyserver signature.asc Description: This is a digitally signed message part. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Updating library code
>From an openLilyLib perspective I have a question for all of you who maintain their personal LilyPond code libraries: How are you dealing with keeping code working and consistent? What I mean is: Syntax changes in LilyPond can be handled (mostly) with convert-ly. But what happens when a) a LilyPond update changes the behaviour of a library function e.g. by making it obsolete or by "shadowing" its name. When re-touching our Fried songs repo I ran into numerous errors that seemed strange initially. But in fact it was quite clear: a number of functions we developed in that project (or integrated when developed by others on this list) have later been incorporated into LilyPond. But while the name of the function usually remained the same the implementation and interface often changed during the process of integration. The result was that our main code didn't work anymore because there *was* a function available of the same name (now from LilyPond) but with a different interface. In effect it was the funny situation that the majority of compilation issues could be solved by simply *removing* code from our library because it wasn't necessary anymore. While this is basically a very good thing to notice it raises the question of code consistency. Even when your functions don't go into LilyPond later you may have or want to change them at any point, presumably leaving your LilyPond files that depend on that library in a non-compiling state. It can be quite frustrating having to update all your existing scores afterwards, especially as that will fall back onto you rather often - until you have eventually revisited all of your scores. We have a similar problem with openLilyLib, and as this is explicitly intended as a *usable* and public infrastructure this really is a problem. As long as you provide a "snippet repository" it is fair to assume that a user can tune a snippet when integrating in her own files, but if it can be accessed through \include there should be a way to handle the issue. So in essence what we need is a convert-ly-like tool for openLilyLib, either as an independent tool or by somehow hooking into convert-ly itself. Quite some time ago I opened an issue about this and would now like to get some opinions, ideas and experiences how *you* deal with the topic. Please reply here or add to https://github.com/openlilylib/openlilylib/issues/87. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user