PATCHES - Countdown for July 4th
Hello, Here is the current patch countdown list. The next countdown will be on 7th July. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5364 Simplify Drul_array indexing - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5364 http://codereview.appspot.com/365730043 5363 Give Paper_columns to Spacing_spanner::note_spacing - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5363 http://codereview.appspot.com/369720043 Countdown: 5366 Move warnings out of find/create context functions - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5366 http://codereview.appspot.com/349740043 Review: No Patches at this time. New: 5367 A few stencil-related refactorings, to wit: - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5367 http://codereview.appspot.com/353750043 5365 Avoid multiple evaluation of markups \pattern \fill-with-pattern - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5365 http://codereview.appspot.com/357740043 regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Now this is a nightmare...
scm_is_integer is not nearly a sufficient prerequisite for calling
scm_to_int (well, of course there are size limits but that's not what I
am talking about). Try
{ \repeat unfold #2.0 c'1 }
which crashes in some strange place. Use #2 instead and it works (of
course), use #2.5 and it fails in a proper manner with the intended kind
of error message.
We probably need some ly_is_integer instead that also checks for
scm_exact_p or so? Guile-2.0 has scm_is_exact_integer but Guile-1
apparently not.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Now this is a nightmare...
> We probably need some ly_is_integer instead that also checks for > scm_exact_p or so? Guile-2.0 has scm_is_exact_integer but Guile-1 > apparently not. What about emulating `scm_is_exact_integer', either in Scheme or in C++? This should make transition to Guile-2 simple. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Now this is a nightmare...
Werner LEMBERG writes: >> We probably need some ly_is_integer instead that also checks for >> scm_exact_p or so? Guile-2.0 has scm_is_exact_integer but Guile-1 >> apparently not. > > What about emulating `scm_is_exact_integer', either in Scheme or in > C++? This should make transition to Guile-2 simple. You mean, complex. Get it wrong, and our private version is getting linked and the Guile-2 version left out. Or we get double-definition link-time errors. So we want an autoconf test and so on. Having our own ly_is_integer variant map to the Guile-2 version conditionally is simple, and when we do it wrong, there is an obvious missing symbol at link time. Or stuff works without complaint. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Now this is a nightmare...
David Kastrup writes: > Werner LEMBERG writes: > >>> We probably need some ly_is_integer instead that also checks for >>> scm_exact_p or so? Guile-2.0 has scm_is_exact_integer but Guile-1 >>> apparently not. >> >> What about emulating `scm_is_exact_integer', either in Scheme or in >> C++? This should make transition to Guile-2 simple. > > You mean, complex. Get it wrong, and our private version is getting > linked and the Guile-2 version left out. Or we get double-definition > link-time errors. So we want an autoconf test and so on. > > Having our own ly_is_integer variant map to the Guile-2 version > conditionally is simple, and when we do it wrong, there is an obvious > missing symbol at link time. Or stuff works without complaint. It may be an upstream battle. Guile-1.8 does it the same: dak@lola:~$ lilypond scheme-sandbox GNU LilyPond 2.21.0 Processing `/usr/local/share/lilypond/2.21.0/ly/scheme-sandbox.ly' Parsing... guile> (define xxx '(1 2 3)) guile> (list-ref xxx 1.0) ERROR: Wrong type (expecting exact integer): 1.0 ABORT: (wrong-type-arg) guile> (list-ref xxx 1) 2 guile> (list-ref xxx 1.5) standard input:4:1: In procedure list-ref in expression (list-ref xxx 1.5): standard input:4:1: Wrong type (expecting exact integer): 1.5 ABORT: (wrong-type-arg) Type "(backtrace)" to get more information or "(debug)" to enter the debugger. guile> Notice how the error message for 1.5 is much more specific than for 1.0? Same reason. Guile-2 is more consistent: dak@lola:~$ guile GNU Guile 2.0.13 Copyright (C) 1995-2016 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (define xxx '(1 2 3)) scheme@(guile-user)> (list-ref xxx 1.0) ERROR: In procedure list-ref: ERROR: Wrong type (expecting exact integer): 1.0 Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> ,q scheme@(guile-user)> (list-ref xxx 1.5) ERROR: In procedure list-ref: ERROR: Wrong type (expecting exact integer): 1.5 Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> ,q scheme@(guile-user)> It's probably more than less incentive not to let bad values get down into the Scheme level... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Now this is a nightmare...
On Jul 4, 2018, at 07:29, David Kastrup wrote: > > Having our own ly_is_integer variant map to the Guile-2 version > conditionally is simple, and when we do it wrong, there is an obvious > missing symbol at link time. Or stuff works without complaint. That’s fine, but if it’s going to be a proxy for scm_is_exact_integer in the long run, the name ly_is_exact_integer gets my vote. — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Now this is a nightmare...
Dan Eble writes:
> On Jul 4, 2018, at 07:29, David Kastrup wrote:
>>
>> Having our own ly_is_integer variant map to the Guile-2 version
>> conditionally is simple, and when we do it wrong, there is an obvious
>> missing symbol at link time. Or stuff works without complaint.
>
> That’s fine, but if it’s going to be a proxy for scm_is_exact_integer
> in the long run, the name ly_is_exact_integer gets my vote.
I don't like the verbosity (basically it can make expressions wrap
around that fit previously). But I admit that this does not really make
for a compelling argument.
One argument not to use scm_is_exact_integer is that we cannot know
whether this is going to be a macro or a function, and our type error
messages actually look up function addresses.
So in order to check, I did one git fetch and discovered that someone is
committing to the 1.8 release branch (Thien-Thi Nguyen) bringing it back
into compilability. That should be interesting information for
self-compilers.
At any rate:
origin:libguile/numbers.c-
origin:libguile/numbers.c-int
origin:libguile/numbers.c:scm_is_exact_integer (SCM val)
origin:libguile/numbers.c-{
origin:libguile/numbers.c- return scm_is_true (scm_exact_integer_p (val));
origin:libguile/numbers.c-}
At least this one is at least at the current point of time in current
master a function (and not a macro).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Now this is a nightmare...
Dan Eble writes: > On Jul 4, 2018, at 07:29, David Kastrup wrote: >> >> Having our own ly_is_integer variant map to the Guile-2 version >> conditionally is simple, and when we do it wrong, there is an obvious >> missing symbol at link time. Or stuff works without complaint. > > That’s fine, but if it’s going to be a proxy for scm_is_exact_integer > in the long run, the name ly_is_exact_integer gets my vote. ly_is_exact_int or even just ly_is_int might be appropriate when also checking that the range for scm_to_int is kept. Though the resulting error messages for exceeding the range could be weird. That would require finding a really good description of the type checked by the predicate. We currently have "an integer" I think as description. "an integer convertible to int" sounds very technical. "an exact integer in suitable range" sounds very fuzzy. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: #5355 Doc: document grob metadata in SVG output in Notation Reference
Paul, On Sun, 1 Jul 2018 17:52:02 -0400, Paul Morris wrote: > On 07/01/2018 02:43 AM, David Kastrup wrote: > > > Edit your .git/config file and change the repository address according > > to the Git repository clone command given for developers on LilyPond's > > Savannah page. > > Thanks. It turned out I had a new SSH key that I hadn't added to > Savannah yet. So I got it to work by following CG 3.4.9 > http://lilypond.org/doc/v2.19/Documentation/contributor/commit-access > > I noticed that where the CG says: > > " > SSH should issue the following warning: > > The authenticity of host 'git.sv.gnu.org (140.186.70.72)' can't > be established. > RSA key fingerprint is > 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5. > Are you sure you want to continue connecting (yes/no)? > > Make sure the RSA key fingerprint displayed matches the one above. > " > > This did not match what I saw in my terminal. (I saved what I saw if > that's useful.) It may have been a bad move but I lived dangerously and > went ahead anyway. But the CG may need an update? I checked and using the command ssh-keygen -E md5 -lf <(ssh-keyscan git.sv.gnu.org 2>/dev/null) I get this for MD5 hashes 1024 MD5:80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 git.sv.gnu.org (RSA) and for SHA256 ... 1024 SHA256:FYkx0iik+iBeCLRzvUyUSTRT98TEBBJoYuQsTXbyGL8 git.sv.gnu.org (RSA) So the CG prints the MD5 hash - and it looks OK to me. If you didn't get either of those can you attach what you did get? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Now this is a nightmare...
>> What about emulating `scm_is_exact_integer', either in Scheme or in >> C++? This should make transition to Guile-2 simple. > > You mean, complex. Hmm. I was thinking along the gnulib mechanism which provides drop-ins for many system functions. > Get it wrong, and our private version is getting linked and the > Guile-2 version left out. Or we get double-definition link-time > errors. So we want an autoconf test and so on. Yep. > Having our own ly_is_integer variant map to the Guile-2 version > conditionally is simple, and when we do it wrong, there is an > obvious missing symbol at link time. Or stuff works without > complaint. This should also work, of course. And transition to Guile-2 would be a simple s/// operation. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: #5355 Doc: document grob metadata in SVG output in Notation Reference
James, On 07/04/2018 09:41 AM, James Lowe wrote: On Sun, 1 Jul 2018 17:52:02 -0400, Paul Morris wrote: Thanks. It turned out I had a new SSH key that I hadn't added to Savannah yet. So I got it to work by following CG 3.4.9 http://lilypond.org/doc/v2.19/Documentation/contributor/commit-access I noticed that where the CG says: " SSH should issue the following warning: The authenticity of host 'git.sv.gnu.org (140.186.70.72)' can't be established. RSA key fingerprint is 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5. Are you sure you want to continue connecting (yes/no)? Make sure the RSA key fingerprint displayed matches the one above. " This did not match what I saw in my terminal. (I saved what I saw if that's useful.) It may have been a bad move but I lived dangerously and went ahead anyway. But the CG may need an update? I checked and using the command ssh-keygen -E md5 -lf <(ssh-keyscan git.sv.gnu.org 2>/dev/null) I get this for MD5 hashes 1024 MD5:80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 git.sv.gnu.org (RSA) and for SHA256 ... 1024 SHA256:FYkx0iik+iBeCLRzvUyUSTRT98TEBBJoYuQsTXbyGL8 git.sv.gnu.org (RSA) So the CG prints the MD5 hash - and it looks OK to me. If you didn't get either of those can you attach what you did get? James Below is what I got, which doesn't match what you have above. Looks like I have ECDSA instead of RSA, or something? $ git pull --verbose The authenticity of host 'git.sv.gnu.org (208.118.235.201)' can't be established. ECDSA key fingerprint is SHA256:qRLLJ4w/GAeiDyYnbx4yWJbZXwGiYYxgNty7lAfUyuM. Are you sure you want to continue connecting (yes/no)? My .git/config file has this in it (except with my actual savannah username): [remote "origin"] url = ssh://usern...@git.sv.gnu.org/srv/git/lilypond.git fetch = +refs/heads/*:refs/remotes/origin/* -Paul ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: #5355 Doc: document grob metadata in SVG output in Notation Reference
Paul Morris writes: > Below is what I got, which doesn't match what you have above. Looks > like I have ECDSA instead of RSA, or something? > > $ git pull --verbose > > The authenticity of host 'git.sv.gnu.org (208.118.235.201)' can't be > established. > > ECDSA key fingerprint is SHA256:qRLLJ4w/GAeiDyYnbx4yWJbZXwGiYYxgNty7lAfUyuM. > > Are you sure you want to continue connecting (yes/no)? "git pull" isn't interactive, so you have no way of answering this question I think. Try ssh usern...@git.sv.gnu.org instead, answering this question with "yes" once (assuming that you are reasonably sure that this session is not spoofed). You won't get anywhere (this connection is severely restricted) but will be able to resolve the question. It's probably not even necessary to get the username right for that. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: #5355 Doc: document grob metadata in SVG output in Notation Reference
Paul On Wed, 4 Jul 2018 15:59:18 -0400, Paul Morris wrote: > James, > > On 07/04/2018 09:41 AM, James Lowe wrote: > > > On Sun, 1 Jul 2018 17:52:02 -0400, Paul Morris wrote: > > > >> Thanks. It turned out I had a new SSH key that I hadn't added to > >> Savannah yet. So I got it to work by following CG 3.4.9 > >> http://lilypond.org/doc/v2.19/Documentation/contributor/commit-access > >> > >> I noticed that where the CG says: > >> > >> " > >> SSH should issue the following warning: > >> > >> The authenticity of host 'git.sv.gnu.org (140.186.70.72)' can't > >> be established. > >> RSA key fingerprint is > >> 80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5. > >> Are you sure you want to continue connecting (yes/no)? > >> > >> Make sure the RSA key fingerprint displayed matches the one above. > >> " > >> > >> This did not match what I saw in my terminal. (I saved what I saw if > >> that's useful.) It may have been a bad move but I lived dangerously and > >> went ahead anyway. But the CG may need an update? > > > > I checked and using the command > > > > ssh-keygen -E md5 -lf <(ssh-keyscan git.sv.gnu.org 2>/dev/null) > > > > I get this for MD5 hashes > > > > 1024 MD5:80:5a:b0:0c:ec:93:66:29:49:7e:04:2b:fd:ba:2c:d5 git.sv.gnu.org > > (RSA) > > > > > > and for SHA256 > > > > ... > > 1024 SHA256:FYkx0iik+iBeCLRzvUyUSTRT98TEBBJoYuQsTXbyGL8 git.sv.gnu.org (RSA) > > > > So the CG prints the MD5 hash - and it looks OK to me. > > > > If you didn't get either of those can you attach what you did get? > > > > James > > Below is what I got, which doesn't match what you have above. Looks > like I have ECDSA instead of RSA, or something? > > $ git pull --verbose > > The authenticity of host 'git.sv.gnu.org (208.118.235.201)' can't be > established. > > ECDSA key fingerprint is SHA256:qRLLJ4w/GAeiDyYnbx4yWJbZXwGiYYxgNty7lAfUyuM. OK I missed out the other stuff on my command line. E.g: ssh-keygen -lf <(ssh-keyscan git.sv.gnu.org 2>/dev/null) 1024 SHA256:FYkx0iik+iBeCLRzvUyUSTRT98TEBBJoYuQsTXbyGL8 git.sv.gnu.org (RSA) 256 SHA256:o/oI4CKKcWc4cZvDFEdmOXsE3tiPP8bWa04h4bQjtV4 git.sv.gnu.org (ED25519) 256 SHA256:qRLLJ4w/GAeiDyYnbx4yWJbZXwGiYYxgNty7lAfUyuM git.sv.gnu.org (ECDSA) Which is what you had. Looks like MD5 is no longer the default response. Although I don't know why you didn't get abn RSA response When I get some time I'll walk thorough the CG guide myself to see if I get you get and we can update the doc. It's been about 12months since I last went through it. But those hashes look correct. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
