lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC 2020 update


From: Urs Liska
Subject: Re: GSoC 2020 update
Date: Wed, 27 May 2020 23:22:35 +0200
User-agent: K-9 Mail for Android

Hi Owen!

Am 27. Mai 2020 22:58:19 MESZ schrieb Owen Lamb <owendlamb@gmail.com>:
>Hi all!
>
>I pushed the new dev/lamb/GSoC-2020 branch to origin yesterday, and it
>appears to be visible on GitLab. I haven't committed anything new yet,
>but
>I will soon. I'll push any commits I make at the end of each work day.
>
>I plan to give updates regularly every Friday. So far I have been
>investigating open-type-font.cc as an entrypoint for changing the
>encoding,
>but I'll have a more detailed report then.
>
>I have a couple questions in the meantime:
>
>I plan to temporarily add the Bravura font to my lilypond branch for
>testing SMuFL throughout the summer. Is there any legal reason not to

No. Bravura has very avöctively been developed and promoted to be an open font.

It may be shared along with the usual license stuff, but ...

>(or
>at least to .gitignore it so it only appears on my machine)? 

... as long as we don't intend to ship Bravura along with LilyPond I'd say it 
shouldn't be added to the repository. Except if it's necessary to get your work 
tested (maybe one day you'll habe a merge request that won't work without a 
real SMuFL font ...).

To keep something local to your computer it's better not to use the .gitignore 
file but .git/info/exclude - which does the same but without itself being 
committed.

Best
Urs

It appears
>to
>be licensed under OFL 1.1, just like Feta, but I'd just like to make
>sure
>I'm not accidentally breaking any laws as I work publicly.
>
>This next one is a minor annoyance and probably a C++ newbie question,
>but
>my IDE (VS Code, chosen for comfort) is reporting "a
>dynamically-initialized local static variable is not allowed inside of
>a
>statement expression" about a million times throughout the .cc files,
>whenever particular #define'd macros, e.g. ly_symbol2scm or
>get_property,
>are referenced. From what I know, macros aren't dynamically
>initialized,
>are they? Does anyone know why this might be happening? This doesn't
>seem
>to affect compilation, so I can easily ignore the red squiggly lines,
>but
>if there's a way to get rid of them, I'm all ears.
>
>And, of course, if you have any comments or suggestions about anything
>else, please let me know!
>
>Thanks,
>Owen

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]