Re: Pedal cautionary after a line break (current status and improvements)

On 6/25/20, Paolo Prete wrote: > The lack of a cautionary pedal on a bracket could be seen as an enhancement > only in a self-referential context, which doesn't make sense to me. A > proper way to proceed is to check what modern professional engravers do > with it, and check as a consequence if

Re: [RFC] Use GitLab Milestones

On 6/23/20, Jonas Hahnfeld wrote: > I knew that description and, honestly, that would be a show stopper for > me reporting any issue to a project in 2020. Why? Because mailing lists are a thing of the past in your view? :-) Sending an e-mail to an open mailing list is much more universal and

Re: [RFC] Use GitLab Milestones

On 6/22/20, Jonas Hahnfeld wrote: > In short, I'd like to propose that we replace the labels Fixed_x_y_z > with milestones x.y.z and use these to track which issues were fixed > for a particular release. This has the advantage of a) less labels > which makes the drop-downs more usable and b) the

Re: xdvipdfmx fails with some regtests (“Invalid object”)

On 6/17/20, Valentin Villenave wrote: > `make doc’ has been broken for nearly a week on my system (even with a > clean git clone), with the following error: > > xdvipdfmx:fatal: typecheck: Invalid object type: -1 7 (line 2161) Git bisect actually tells me that xdvipdfmx started misb

Re: xdvipdfmx fails with some regtests (“Invalid object”)

On 6/17/20, Werner LEMBERG wrote: > I suggest upgrading. The current maintainer of xdvipdfmx fixes bugs > in TeXLive directly – however, this doesn't automatically update the > binaries that are in TeXLive's SVN repository. It's not that > complicated to get the TeXLive sources and compile a

Re: “make doc” broken because of gs eps->pdf failing

On 6/17/20, Valentin Villenave wrote: > Thanks for giving me hope, even for a minute :-) I spoke too soon; running doc-clean and _then_ “make doc” indeed fixes the problem. (And Jonas has just merged it onto master so that problem is fixed.) Thanks! Cheers, -- V.

Re: “make doc” broken because of gs eps->pdf failing

On 6/17/20, Michael Käppler wrote: > Do you have > https://gitlab.com/lilypond/lilypond/-/merge_requests/148/diffs?commit_id=c002d5e8c2e737cefbafa84f4b66e4b3bbc6d111 > in your repo? Otherwise that may well be the problem. Jonas wanted to > push this one yesterday, > but it seems that did not

Re: xdvipdfmx fails with some regtests (“Invalid object”)

On 6/17/20, Werner LEMBERG wrote: > It seems that you probably have to update your TeX system... Update or downgrade? I’m using the latest fc32 repos. Besides, I haven’t changed anything on my OS recently and this started happening only a week or so ago; isn’t it possible that this is triggered

“make doc” broken because of gs eps->pdf failing

Greetings everyone, I’ve noticed a recent regression with `make doc’: when it reaches Documentation/ly-examples, gs fails on a bunch of files with the following error message: Command: /home/work/lilypond/out/bin/lilypond -dpreview -dresolution=150 -o ./out-www sesto-violin.ly Changing working

xdvipdfmx fails with some regtests (“Invalid object”)

Hey everybody, `make doc’ has been broken for nearly a week on my system (even with a clean git clone), with the following error: Making input/regression/out-www/collated-files.list < 1368 files Making input/regression/out-www/collated-files.texi < tely Making

Re: Can you give a sample ETF file? and other questions

On 6/14/20, Jean Abou Samra wrote: > That's how I stumbled on etf2ly. There are no regression tests and I > couldn't find a single ETF file across the Net to see how the script's > output looks like. Can anyone provide one? You can find a bunch of those online, for example here:

Janus M. Nowacki

Greetings everybody, I just wanted to let you know that Janus Nowacki, one of the founders of the TeX Gyre font suite that is used by default in LilyPond, has recently died: http://www.gust.org.pl/news/jmn-obit-en And his personal website (in Polish): https://jmn.pl/ The TeX Gyre font project was

Re: Texinfo - manual line breaks in URLs?

On 6/6/20, Michael Käppler wrote: > Is there a reason for this inconsistency? How is it supposed to be? Hi, >From what I gather, that’s merely because Werner’s been looking elsewhere for the past 16 years :-)

Re: new procedure with GitLab CI

On 6/4/20, Jean Abou Samra wrote: > Actually, I had anticipated a long thread full of reactionson bothof the > above options, but not such a silence. Anyone? (I won't feel offended if > you find my proposal dumb!) Well, you have to account for the fatigue :-) I’m not knowledgeable enough to

Re: new procedure with GitLab CI

On 5/27/20, Jonas Hahnfeld wrote: > No, "rebase" is currently manual (with "merge when pipeline succeeds" > being automatic). This has been clearly communicated, sorry if you > missed that. Hey Jonas, hey everybody; just so you know, I’m getting increasingly frustrated -- as you may guess if you

Re: GitLab access

On 5/28/20, Aaron Hill wrote: > In some ways, this is akin to a job interview Gosh, I really hope it isn’t!! My apologies if you’ve been seeing it that way. > It is counter-productive for me to use my > time and talents to fill a role that does not need filling. That’s hardly been the way our

Re: new procedure with GitLab CI

On 5/27/20, Valentin Villenave wrote: > On 5/27/20, Jonas Hahnfeld wrote: >> We do want to have the pipeline on the commit before it is merged >> because this replaces patchy. > > Well, that’s absolutely crucial at the MR review stage. But after passing [sorry, I forgot

Re: new procedure with GitLab CI

On 5/27/20, Jonas Hahnfeld wrote: > We do want to have the pipeline on the commit before it is merged > because this replaces patchy. Well, that’s absolutely crucial at the MR review stage. But after passing > The only limitation is that all MRs are > checked individually. Not only

Re: new procedure with GitLab CI

On 5/27/20, Jonas Hahnfeld wrote: > Pinging this to attention... Yeah, that’s one of those “I’ve read it without fully understanding it” situations (and then the discussion devolved into James’s workflow and I lost track). So IIUC there’s no way to skip the rebase-triggered CI pipeline right

Re: remove merged branches & branches with tags

On 5/26/20, Jonas Hahnfeld wrote: > Is this OK with everyone? Fine by me. -- V.

Re: GitLab permissions

On 5/24/20, Jean Abou Samra wrote: > Since I'm trying to work on MusicXML, it would be nice if I could add > the corresponding label to the appropriate issues, and perhaps > self-assign a few of them. Also, there are some old issues that look > fixed but are still open, so I'd like to close

Re: helping with testing resources

On 5/23/20, Jonas Hahnfeld wrote: > If you have spare hardware and / or want to help with CI testing, this > is easy to setup with GitLab. First you'll need their runner and I'll > defer to the excellent documentation: https://docs.gitlab.com/runner/ > As testing uses Docker, those sections also

Re: Markup vertical alignment

On 5/21/20, James wrote: > A bit like this (still open) issue? > https://sourceforge.net/p/testlilyissues/issues/1322/ > ;) Uh, that’s precisely one I’m trying to close… :-) https://gitlab.com/lilypond/lilypond/-/merge_requests/59 > Mind you I was sure there was some discussion in dev-lilypond

Re: Markup vertical alignment

On 5/20/20, Phil Holmes wrote: > The same is true of the next section on horizontal and vertical alignment. Yes, I tried to rewrite a few things in there. Could you have a look and tell me if that makes thing less confusing in your opinion? On 5/20/20, David Kastrup wrote: > \hspace and

Re: Markup vertical alignment

On 5/20/20, Phil Holmes wrote: > Could someone oblige? Happy to: https://gitlab.com/lilypond/lilypond/-/merge_requests/67 I also took the opportunity of addressing a comment I left when writing NR 1.8 more than a dozen years ago, about \hspace and \vspace (the latter of which was not even

Re: LilyPond GSoC logistics

On 5/20/20, Arthur Reutenauer wrote: > “How often would you like me to make contact?” :-) > https://www.lexico.com/definition/touch_base I urge you not to look up that phrase on Urban Dictionary… ;-) Cheers, -- V.

Re: Final resolution of issue 4751

On 5/16/20, David Kastrup wrote: > I don't really have a good idea here. Looks like quite a mess. I’ve re-categorized it as Status::Started, and removed the Fixed_2_19_44 label for now. I‘ve also linked it with issue #4781 since it seems there’s quite a bit of overlap. Jean, since you wanted

Re: 2.21.0 Issues all verified!

On 5/16/20, Carl Sorensen wrote: > Thanks to all who have helped us get > back to a more regular release schedule! Well, thanks to you! And to everybody who gave a hand (Federico, Karlin, and a few others?). For a little while I was reminded of the Google tracker era, and of all the great work

Re: Another round of questions

On 5/16/20, Werner LEMBERG wrote: > IMHO only bugfixes should be applied to `musicxml2ly` since `xml2ly` > covers much more of MusixXML (and will, AFAIK, also eventually support > its successor, MNX). Huh. xml2ly has very different requirements than musicxml2ly and is (AFAICS) unlikely to ever

Re: mirror GitLab -> Savannah

On 5/14/20, Jonas Hahnfeld wrote: > To keep this short: I'd like to enable push mirroring from GitLab to > Savannah for the following branches [1]: > - master > - release/unstable > - stable/* > - translation* Why not staging? (Assuming that’s still gonna be a thing in months to come.) By

Re: labels on GitLab

On 5/12/20, Jonas Hahnfeld wrote: > I'd really hope we can discuss things before changing... And *I*’d really hope “discuss things” can amount to more than “blindly reverting everything and anything that’s been done by someone else”. Look, you’ve obviously spent quite some time setting this up

Re: labels on GitLab

On 5/12/20, Jonas Hahnfeld wrote: > In my opinion, there are currently far too many labels on GitLab. Well, we used to say `Labels are cheap’ back when we were using Google Code… > please do not create new labels out of thin air for now. Not entirely out of thin air. I’ve actually decreased

How are dynamics (self-)aligned exactly?

Greetings, could anyone give me a hint as to where dynamics alignment is handled? As far as I can see, the self-alignment-interface functions are not used by the (formerly new) dynamic-engraver; and AFAICS the following diff doesn’t break compiling nor change any of the regtests: diff --git

Re: migrating to GitLab

On 5/8/20, Jonas Hahnfeld wrote: > I haven't heard further objections which, for me, means we are going > with GitLab. If you don't agree, now's your final time to speak up. Thanks for tackling this! > 3) The idea is to have the "main" repository at GitLab, next to the > issues and merge

Re: Use GhostScript API instead of forking (issue 548030043 by jonas.hahnf...@gmail.com)

On 5/6/20, jonas.hahnf...@gmail.com wrote: > In case you're interested how I found out about this: > https://www.hahnjo.de/blog/2020/05/06/recursively-timeing-processes.html Good to know, thanks! (And the resulting improvement is indeed impressive.) Cheers, -- V.

Re: GSoC for LilyPond

On 5/5/20, Owen Lamb wrote: > This is all new for me, so I > appreciate your willingness to help me with newbie questions! I'll probably > have quite a few, especially regarding compiling. As it happens, we do have a “newbie-oriented” document here (which includes a section about compiling), so

Re: GSoC for LilyPond

On 5/5/20, Werner LEMBERG wrote: > While you have > me as a personal mentor … And a great mentor at that! > it is rather the collective wisdom of this > list that will guide you through your work. +1. There are _lots_ of absolutely brilliant people here. > We don't have an IRC channel, sorry.

Re: Add a script for running timing benchmarks (issue 545950043 by hanw...@gmail.com)

On 4/26/20, hanw...@gmail.com wrote: > I can host this script somewhere else so it can be referenced in the CG, > but I don't think there optimizing our C++ code is a domain for > beginners. I may be off the mark here, but what about adding your speed test into the standard regression test

Re: Make doc currently broken

On 4/23/20, Federico Bruni wrote: > I confirm it's a stale dependency file. > I had the same problem while testing my patch before pushing and IIRC > removing Documentation/it/out-www/web.texi fixed it. OK, thanks! I should have thought about doc-clean. Cheers, - V.

Re: Verifying fixes?

On Thursday, April 23, 2020, Carl Sorensen wrote:. > > Do you believe we should Verify the fixes, or should we just leave the > issues closed without verification? I'm willing to spend some time doing > the verification, if we think it's valuable to do so. > I'm available to help with that as

Make doc currently broken

Hey everybody, For the past few days, I’ve been unable to make doc because of the following error: *** No rule to make target '/home/work/lilypond/Documentation/it/web/news-headlines.itexi', needed by 'out-www/web.texi'. Stop. Federico, do you know anything about it? Cheers, V.

Re: Issue #1204: Document, and add regtest for, external fonts. (issue 557640051 by v.villen...@gmail.com)

On 4/19/20, David Kastrup wrote: > However, there are a few > other problems with that regtest that should likely show with Guile-2 > (sometimes?). Could you elaborate as to what I need to watch out for? I’ve tested it successfully with Guile 2.2 here (but history has teached us that unforeseen

Re: Issue #1204: Document, and add regtest for, external fonts. (issue 557640051 by v.villen...@gmail.com)

On 4/19/20, David Kastrup wrote: > At that day I was having one patchy run after the other and I did go > through the log files to indicate the failed file and the error message. Yep, and I asked for additional info both on the tracker and on Rietveld; the only reply I did get was from James who

Re: Patchy email

On 4/19/20, David Kastrup wrote: > mkstemp! does not generate a string. It overwrites an existing string > in-place, and that's bad news for a literal string. Yes, it overwrite the string, opens a port, then I read the port-filename which should be an _other_ string object, shouldn’t it? (sigh

Re: Patchy email

On 4/19/20, David Kastrup wrote: > So I am afraid that things are rather weird at my side: > -rw-r--r-- 1 dak dak 36 Apr 19 19:51 .uuid > dak@lola:/usr/local/tmp/lilypond2$ cat dummyfont-C5PUYM-dir/.uuid > 35d52a4b-44f7-41b6-afca-165a4187aa4f WTF. Could it be some trace left due to your

Re: Patchy email

On 4/19/20, David Kastrup wrote: > You need (mkstemp! (string-copy "... > because mkstemp! overrides the string. Why, yes. What I want to copy is precisely the mkstemp-generated string. What did I miss? V.

Re: Rendering chords in "Danish" style

On 4/19/20, Michael Bisgaard Olesen wrote: > *(Resending because it didn't seem to go through the first time)* Greetings, if you’re subscribed to the -devel list, your messages should go through immediately. Perhaps your first message got stuck because your address was not subscribed yet and as

Re: Patchy email

On 4/19/20, David Kastrup wrote: > Note that the delete-file instructions are executed while the book is > being read in while markup is typeset when the books are being processed > at the end of the input file. Yes, it looked completely bonkers to me as well, until I realized it worked :-) >

Re: Patchy email

On 4/19/20, David Kastrup wrote: > ERROR: In procedure mkstemp!: > string is read-only: "kaka-XX" Could the following help? diff --git a/input/regression/font-name-add-files.ly b/input/regression/font-name-add-files.ly index 33f73f0c68..264e2b6532 100644 ---

Re: Issue #1204: Document, and add regtest for, external fonts. (issue 557640051 by v.villen...@gmail.com)

On 4/19/20, David Kastrup wrote: > v.villen...@gmail.com writes: > Breaks my patchy again. Whose patchy was comfortable moving it from > staging to master? Well, at any rate James’ patchy what fine with it. (As it went through the review/countdown process not just once but twice.) The regtest

Re: GS version conflict in packaged 2.20 and 2.21

On 4/17/20, Simon Albrecht wrote: > it appears from this exchange > > that the packaged versions of 2.20.0 and 2.21.0 contain a mixture of GS > 9.21 and 9.26. Yes, a French user also had some gs issues that I think may be

Re: ly:page-turn-breaking core dumps

On 4/17/20, Pierre-Luc Gauthier wrote: > Sorry for necro-following-through so late in the issue. If I may chime in, since it may appear from your name that you speak French, do feel free to subscribe to our French-speaking mailing list, where other contributors can help you investigate such

Re: Annoying 'langdefs.py' warning

On 4/16/20, Werner LEMBERG wrote: > Building lilypond you get a bunch of harmless but annoying > langdefs.py: warning: lilypond-doc gettext domain not found. > and > .../podir-targets.make:14: warning: ignoring old recipe for target > 'po-update' > messages. Is there a way to suppress them?

Re: 2.21.0 released

On 4/9/20, Carl Sorensen wrote: > Thank you so much for your dedication! Ditto; Phil, you and James may both have the most thankless and yet crucial jobs in the LilyPond community, so praises to you both! (And obviously to Jonas, David, Han-Wen & al.). Here’s to hoping we can get back on track

Re: Search box searches in 2.19

On 4/7/20, Francisco Vila wrote: > Search box on front page, shouldn't it look in 2.20 by default? Well, 2.20 docs haven’t been indexed yet (I’ve spent quite a few minutes trying to get some search engines to pay us a visit, but I guess the robots’ll drop by whenever they feel like it). So, that

Re: Problem with LSR import

On 4/5/20, David Kastrup wrote: > Valentin Villenave writes: >> It should be available in the next LSR database dump (but there’s at >> least one file in the Japanese version that depends on it, so the name >> will need to be updated there as well). > > Thanks! Davi

Re: Problem with LSR import

On 4/5/20, David Kastrup wrote: > So perhaps changing the name of that snippet > in the LSR would be a good idea. Hi, I just changed it to customized-drum-notation-in-printed-and-MIDI-output.ly (and I reworded the doc string to make it match a bit more with our guidelines). It should be

Re: output-distance: write HTML as UTF-8 (issue 563810043 by hanw...@gmail.com)

On 4/4/20, jonas.hahnf...@gmail.com wrote: > The reason is that the latest commit in master has a non-ASCII > character in the first line of its commit message [1]. So IIUC it *was* f5f907599ce88d3d610483fa42fa78be12f53d2e in the end… but just because of a char in the commit message!? Man, how

Re: Cannot make check from current master (with no patches applied)

On 4/3/20, David Kastrup wrote: > Anybody have an idea whose Patchy pushed the following: > commit f5f907599ce88d3d610483fa42fa78be12f53d2e Uh, I did push it onto staging after the usual review process. Could that really be what broke some stuff? It’s a fairly simple documentation edit…

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

On 3/31/20, j...@abou-samra.fr wrote: > I'll take a look at it, and try to write appropriate documentation (or > find the authors and ask them to document it!). Setting the issue to > needs_work. I believe it was added by Joe Neeman in order to fix issue #442:

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

On 3/31/20, j...@abou-samra.fr wrote: > By the way, why do we say \RemoveEmptyStaves instead of > \removeEmptyStaves? Because it’s a context property that you need to set for your whole context (it’s actually a \with block), not on-the-fly like \cadenzaOn; see also \RemoveEmptyStaffContext,

Re: Anything missing for 2.21.0?

On 3/29/20, Dan Eble wrote: >str = re.sub (r"\\(compress|expand)FullBarRests)", r"\\\1EmptyMeasures", That’s on me; sorry about that. https://codereview.appspot.com/553750044/diff/561590043/python/convertrules.py I was convinced it had successfully gone through the docs and regtests, which

An exciting new release… of Sibelius!!!

Hi everybody, I know it’s off-topic but I wanted to share the news because, let’s be honest, nobody in their right mind would want to miss it: Yes! It’s finally here! The latest and brightest version of Sibelius is out… *And* it offers one particularly exciting, exclusive new feature:

Re: Patch on dynamics and \RemoveEmptyStaves

On 3/26/20, James Lowe wrote: > Yes David K is correct. If someone could take a look at the scripts in > git-cl and get them working smoothly again (there are other errors > reported on this list about git-cl) it would be a boon to the dev team. By the way (this is not directly related but may

Re: Patchy email

On 3/25/20, Werner LEMBERG wrote: > Oops, I gave wrong advice, sorry. You’re not the one to blame; I was the one who jumped the gun. > Please do > s/@example/@samp/ > and re-commit. Done. Aand this is why we have a patch reviewing process. Lesson learned. (Again.) V.

Re: Patch on dynamics and \RemoveEmptyStaves

On 3/24/20, Jean Abou Samra wrote: > I have the attached very simple patch for LilyPond. Could anyone please > guide me through the process for patch submission? Hi Jean, some step-by-step instructions are available here: http://lilypond.org/doc/latest/Documentation/contributor/quick-start.html

Re: [LSR 2.20] what to do with #280

On 3/14/20, Thomas Morley wrote: > Currently > "Engravers one-by-one" > http://lsr.di.unimi.it/LSR/Item?id=280 > returns several times: > programming error: script direction not yet known > What to do? Would it be a good idea to add \override Script.direction = #UP in the definition of

Re: Doc: organize changes.tely

On 3/9/20, David Kastrup wrote: > I think I was told to run the update script and forgot. I am not sure > where to run it now in order to get the results somewhere. Oh, good. Perhaps we should mention it in the CG’s release-work.itexi to make it less easy for people to overlook in the future?

Re: Doc: organize changes.tely

On 3/8/20, Francisco Vila wrote: > Yes please, it was painful to re-organize a half-translated version. Now > is soon enough, still. By the way (on a more-than-slightly unrelated note), how up-to-date is the official translation status page? http://lilypond.org/translated.html I’m a bit

Re: PATCHES - Countdown for April 6th

On 4/6/19, James wrote: > Here is the current patch countdown list. Greetings James, I suspect this (fairly minor) one has gone unnoticed: https://sourceforge.net/p/testlilyissues/issues/5504/ It has already received a LGTM from two (in)valuable contributors, but could you put it in the

Re: gs version error in latest GUB build

On 4/3/19, Knut Petersen wrote: > An strace log that shows argv and env of execve gs would be helpfull ... Here’s a full strace log from that user, I’m not sure how to find that specific information: http://lilypond-french-users.1298960.n2.nabble.com/file/t249946/lily_strace.txt Cheers, V.

Re: gs version error in latest GUB build

On 4/2/19, Federico Bruni wrote: > As far as I can see from my installations, gs distributed in > lilypond.org recent installers is version 9.26. Nope: $ wget http://lilypond.org/download/binaries/linux-64/lilypond-2.19.83-1.linux-64.sh $ sh lilypond-2.19.83-1.linux-64.sh --tarball $ tar -tjvf

Re: gs version error in latest GUB build

On 3/31/19, Valentin Villenave wrote: > I couldn’t reproduce (but then again I’m not running Ubuntu). I also > find it odd that only some scores are reported to fail while other’s > aren’t. OK, as I suspected *all* scores do indeed fail for this user. Further information just in case:

gs version error in latest GUB build

Greetings, someone on -user-fr has reported gs crashing on some scores (for example the first incipit example from NR 2.9.6), with the following error: gs: Interpreter revision (926) does not match gs_init.ps revision (921). This looks very much like something we’ve seen recently:

Re: Anchor points of Slurs / Phrasing slurs

On 3/16/19, Valentin Petzel wrote: > Currently the anchor points are set both over or both under the starting / > ending note, depending on the slur’s direction. For the S-shape we would > need > the control points to differ in directions, so one point above and one point > beneath the respective

Re: Syntax: numbers prefixed with # or not

On 2/21/19, David Kastrup wrote: > baba = -.4 Indeed. That’s probably rare enough that we could get away with a @knownissues in the right place(s), though… Right now, the new ability to have #-less numbers (and strings, although my recent patch changes that) isn’t documented anywhere but the

Syntax: numbers prefixed with # or not

Greetings, Alongside issue #5473, I’ve started investigating whether numbers still require to be prefixed with #. AFAICS, the only ones that still do are in markups and all markups commands, but hardly anywhere else; which _could_ make LilyPond syntax a tiny bit easier to grasp for new users… Or

Re: Please test new lilypond installers

On 2/6/19, Karlin High wrote: > I got the LilyPond app extracted from .tar.bz and it opens and runs. Greetings Knut, I’ve received reports from two FreeBSD users that the x86_64 installer doesn’t work. - One said that the binary isn’t recognized as an "amd64" arch (he’s using FreeBSD 12.0 on a

Re: New feature: automatically invert chords or drop/rise chord notes (issue 365840043 by v.villen...@gmail.com)

On 2/3/19, Lukas-Fabian Moser wrote: > This statement surprises me. I always thought of 'drop n' (with 'drop 2' > being the most common one) as a means to transform closed-harmony > _upper_ voices into open harmony _upper_ voices, without changing the > bass at all. I see what you mean (and I

Re: New feature: automatically invert chords or drop/rise chord notes (issue 365840043 by v.villen...@gmail.com)

On 2/2/19, Dan Eble wrote: > Isn’t the salient property of an inversion simply which note is lowest in > pitch? (It has been a long time since I studied music theory.) If so, both > of those fit, as does the chord resulting from lowering the e' by an octave. David was more specifically

Re: guilev1/2 musing

On 1/25/19, Thomas Morley wrote: > how exactly is your guile-2-setup, simply checkout the > 'guile-v2-work'-branch, rebase and compile? Oh, I wasn’t even keeping track of this branch (isn’t it dormant, much like Patrick’s previous work on Guilev2?); I’m just using master with --enable-guile2,

Re: guilev1/2 musing

On 1/25/19, Thomas Morley wrote: > Over the years some people worked on the topic - speaking only for > myself, I think all low hanging fruits are done. Indeed. Lily-guile2 actually works pretty well (if you don’t mind the noticeable performance hit); I think I’ve been using it nearly-daily for

Re: guilev1/2 musing

On 1/24/19, David Kastrup wrote: > Development happens on Guile2, none on Guile1. That’s what I’m worried about: if we *were* to include guile1 as a git submodule (effectively forking it, although I don’t imagine many Lily devs are gonna be fiddling with its codebase), what are the

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

On 1/24/19, David Kastrup wrote: > texi2html(?) does have specific version requirements Yes, I meant texi2html! We’re in a bind similar to that of Guile: the old unmaintained version works and not the new one. (Well, minus the outrageous

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

On 1/24/19, Knut Petersen wrote: > There's the possibility to uses git submodules ... guile, ghostscript and > extractpdfmark are primary candidates. Not to mention the specific Texinfo version we rely on. V. ___ lilypond-devel mailing list

Re: Two people try to get lilypond for 2.0.12, but hit a roadblock

On Fri, May 13, 2016 at 10:09 PM, David Kastrup wrote: > Not really as material for a public discussion. Greetings to you both, Well, I for one am quite happy to see that Jan’s still around (even though you guys have every reason to feel tired)... Schikkers-List was an awesome

Re: New context modifier \CompletionRhythms?

On Sat, Apr 9, 2016 at 11:37 PM, David Kastrup wrote: > Why would you even split note values across bars in "ancient music"? At the risk of being blunt: more generally, is there a legitimate use case for completion heads? It never occurred to me that some people (like Simon, it

Re: grob.cc segfaults (with GCC6?)

On 3/25/16, Valentin Villenave <valen...@villenave.net> wrote: > I’m having a weird segfault on several regtests Greetings, I’ve added it as https://sourceforge.net/p/testlilyissues/issues/4814/ (I can use GUB releases for now and Fedora 24 is not even tagged as alpha, so there’s no

grob.cc segfaults (with GCC6?)

Greetings everybody, I’m having a weird segfault on several regtests (and most of my own ly files, which is annoying): Parsing... Interpreting music... Preprocessing graphical objects... Program received signal SIGSEGV, Segmentation fault. 0x00496c2f in Grob::get_offset

Re: Unable to use git-cl

On Mon, Mar 7, 2016 at 3:21 AM, Carl Sorensen wrote: > It appears that my ssl certificate is not working properly. Greetings Carl, have you by any chance disabled JavaScript in your Web browser? (I was unable to post anything until I complied with SourceForge demanding

Re: Lose the tagline (permanently)

On Fri, Mar 4, 2016 at 11:20 PM, tisimst wrote: > Engraved with LilyPond X.Y---lilypond.org Well, it’s still language-dependent. What about David’s earlier proposal, enclosed with small notes? Too cheesy? (I quite liked it, but maybe it’s just embarrassingly telling

Re: Define French as a separate input language (issue 288290043 by v.villen...@gmail.com)

On Mon, Feb 29, 2016 at 12:32 AM, David Kastrup wrote: > Seriously? I mean, no German would think about leaving off umlauts from > a letter under any circumstance Well, in German it can alter the meaning (or at least distinguish between plural and singular). In French it’s a bit

Re: Define French as a separate input language (issue 288290043 by v.villen...@gmail.com)

On Sun, Feb 28, 2016 at 11:07 PM, David Kastrup wrote: > I haven't seen a single reason why anyone would be wanting to use > "francais" for specifying a notename language that calls d "ré". I’m fairly certain that it wouldn’t be used, ever. (Voluntarily, that is.) So this is a

Re: Lose the tagline (permanently)

On Tue, Feb 23, 2016 at 8:00 PM, Noeck wrote: > What is the tiny symbol in front of the url? A time signature but why? Looks like a hack/pun around the © glyph. I like it. (Reminds me of http://artlibre.org/wp-content/copyleft2.jpg) I may be nitpicking here, but is there a

Re: Define French as a separate input language (issue 288290043 by v.villen...@gmail.com)

On Mon, Feb 22, 2016 at 11:53 PM, Noeck wrote: > if you allow non-ascii letters in the note names (namely é in ré), why > not go all the way and call the language "français" instead of > "francais" (or at least in addition)? Greetings Joram, that’s exactly what this patch

Re: Allura account

On Tue, Feb 16, 2016 at 2:42 PM, Trevor Daniels wrote: > I see you're already registered as a Developer on Allura. Maybe Phil just > beat me to it. Greetings Trevor, could you add me as well? (On the off chance I’m able to contribute a bit more to LilyPond in weeks to

Re: Add French-specific note names (issue 239930043 byv.villen...@gmail.com)

On Tue, May 19, 2015 at 11:12 PM, Trevor Daniels t.dani...@treda.co.uk wrote: on my laptop I have to hold down the Alt key and the Fn key, and type JOU, which is actually 164 with the Fn key pressed. That’s because, for some unexplainable reason, you’re still a proud Windows user :-) On a

Re: Add French-specific note names (issue 239930043 by v.villen...@gmail.com)

On Mon, May 18, 2015 at 9:20 PM, Francisco Vila paconet@gmail.com wrote: Besides, this is the status for Spanish users: 'ñ' is a non-shift-needing key in a very prominent place. On the contrary, the very lilypondish '{}[]\' set are all hidden under AltGr. Likewise here. I don't oppose

Re: Add French-specific note names (issue 239930043 by v.villen...@gmail.com)

On Mon, May 18, 2015 at 9:52 PM, David Kastrup d...@gnu.org wrote: We are recommending español over espanol? Says who? Sorry. I should have said: we’re _likely_ to recommend español over espanol in the future, now that the syntax allows it. You said yourself that people had been getting annoyed

Re: Lilypond Issue handling system draft requirements

On Mon, May 4, 2015 at 4:57 PM, Phil Holmes m...@philholmes.net wrote: As promised, a starter list of requirements for the issue handling system, to allow us to check potential replacements to Google code. Hi Phil, thanks for this recap. This may well be a stupid question, and if so please

  1   2   3   4   5   6   7   8   9   >