Re: Updating library code

[Michael Gerdau]

[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

[Urs Liska]

>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

Re: Updating library code

[Paul Morris]

> 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