Re: guilev2 problem (user-markup-command sometimes not accepted)
David Kastrup writes:
> Thomas Morley writes:
>
>> Hi,
>>
>> the following works fine with current master (and every tested lily-version):
>> #(begin
>> (define-markup-command (dummy layout props arg) (markup?)
>>(interpret-markup layout props arg))
>> (display-scheme-music (markup #:dummy "foo")))
>> #(display "whatever")
>>
>> With guilev2 I get:
>> $ lilypond-git-guile-2.2 atest-85.ly
>> GNU LilyPond 2.21.0
>> Processing `atest-85.ly'
>> Parsing...
>> fatal error: Not a markup command: dummy
>>
>> Not even the later 'display' is reached.
>>
>> Though this works:
>> #(define-markup-command (dummy layout props arg) (markup?)
>>(interpret-markup layout props arg)
>> #(display-scheme-music (markup #:dummy "foo")))
>> #(display "whatever")
>>
>>
>> I'm not able to track this down, anyone with some insight?
>
> I think that Guilev2 may do the syntax form expansion concerning
> "markup" before executing the define-markup-command when both are
> contained in one begin form. Macros are executed a bit differently in
> Guilev2 than in Guilev1.
The markup macro is a piece of crock anyway. Use
(display-scheme-music (make-dummy-markup "foo"))
or
(display-scheme-music #{ \markup \dummy foo #})
here to get out of that predicament.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guilev2 problem (user-markup-command sometimes not accepted)
Thomas Morley writes: > Hi, > > the following works fine with current master (and every tested lily-version): > #(begin > (define-markup-command (dummy layout props arg) (markup?) >(interpret-markup layout props arg)) > (display-scheme-music (markup #:dummy "foo"))) > #(display "whatever") > > With guilev2 I get: > $ lilypond-git-guile-2.2 atest-85.ly > GNU LilyPond 2.21.0 > Processing `atest-85.ly' > Parsing... > fatal error: Not a markup command: dummy > > Not even the later 'display' is reached. > > Though this works: > #(define-markup-command (dummy layout props arg) (markup?) >(interpret-markup layout props arg) > #(display-scheme-music (markup #:dummy "foo"))) > #(display "whatever") > > > I'm not able to track this down, anyone with some insight? I think that Guilev2 may do the syntax form expansion concerning "markup" before executing the define-markup-command when both are contained in one begin form. Macros are executed a bit differently in Guilev2 than in Guilev1. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
guilev2 problem (user-markup-command sometimes not accepted)
Hi, the following works fine with current master (and every tested lily-version): #(begin (define-markup-command (dummy layout props arg) (markup?) (interpret-markup layout props arg)) (display-scheme-music (markup #:dummy "foo"))) #(display "whatever") With guilev2 I get: $ lilypond-git-guile-2.2 atest-85.ly GNU LilyPond 2.21.0 Processing `atest-85.ly' Parsing... fatal error: Not a markup command: dummy Not even the later 'display' is reached. Though this works: #(define-markup-command (dummy layout props arg) (markup?) (interpret-markup layout props arg) #(display-scheme-music (markup #:dummy "foo"))) #(display "whatever") I'm not able to track this down, anyone with some insight? Thanks, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.20 plans.
Am So., 11. Nov. 2018 um 16:37 Uhr schrieb Phil Holmes :
>
> I've just set up a new user on my build machine and tried to build GUB.
> make bootstrap was fine (except missing xelatex which I installed). Make
> lilypond fell over when trying to make guile:
>
> building package: tools::guile
> *** Stage: download (guile, tools)
> *** Stage: untar (guile, tools)
> *** Stage: patch (guile, tools)
> *** Stage: autoupdate (guile, tools)
> *** Stage: configure (guile, tools)
> *** Stage: compile (guile, tools)
> Command barfed: cd /home/gubd/GubDir/gub/target/tools/build/guile-1.8.7 &&
> export
> LD_LIBRARY_PATH=/home/gubd/GubDir/gub/target/tools/build/guile-1.8.7/libguile/.libs:/home/gubd/GubDir/gub/target/tools/root/usr/lib:${LD_LIBRARY_PATH-/foe};preinstguile=/home/gubd/GubDir/gub/target/tools/root/usr/bin/guile
> make -j16
>
> Tail of target/tools/log/guile.log
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/home/gubd/GubDir/gub/target/tools/build/guile-1.8.7'
> make: *** [all] Error 2
> Command barfed: cd /home/gubd/GubDir/gub/target/tools/build/guile-1.8.7 &&
> export
> LD_LIBRARY_PATH=/home/gubd/GubDir/gub/target/tools/build/guile-1.8.7/libguile/.libs:/home/gubd/GubDir/gub/target/tools/root/usr/lib:${LD_LIBRARY_PATH-/foe};preinstguile=/home/gubd/GubDir/gub/target/tools/root/usr/bin/guile
> make -j16
> Tail of target/tools/log/guile.log
>
> *** Failed target: tools::guile
> make[1]: *** [packages] Error 1
> make[1]: Leaving directory `/home/gubd/GubDir/gub'
> make: *** [lilypond] Error 2
>
> The relevant lines in the guile log seem to be:
>
> Perl lib version (5.10.0) doesn't match executable version (v5.18.2) at
> /home/gubd/GubDir/gub/target/tools/root/usr/lib/perl5/5.10.0/i686-linux/Config.pm
> line 46.
> Compilation failed in require at /usr/bin/makeinfo line 31.
> BEGIN failed--compilation aborted at /usr/bin/makeinfo line 31.
>
> Anyone any ideas how to proceed?
>
> --
> Phil Holmes
Hi Phil,
can't say anything about GUB or the errors you see.
Though, if I try to compile guilev1 from the tarball I need to do;
./configure --disable-error-on-warning
on advice by someone from the guile-user-list (don't remember the name).
Otherwise compilation will fail.
Cheers,
Harm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
git cl 404 error
Hi, trying to upload a revised patch-set for Issue 5437 via $ git cl upload origin/master I get a 404 error Full terminal-output: $ git cl upload origin/master scm/markup.scm | 66 +- 1 file changed, 41 insertions(+), 25 deletions(-) This branch is associated with Rietveld issue 34743. Adding patch to that issue. Message describing this patch set: Paul's review Upload server: codereview.appspot.com (change with -s/--server) Your browser has been opened to visit: https://codereview.appspot.com/get-access-token?port=8001 If your browser is on a different machine then exit and re-run upload.py with the command-line parameter --no_oauth2_webbrowser Issue updated. URL: http://codereview.appspot.com/34743 This has been identified with issue 5437. Is this correct? [y/n (y)]y Update attempt returns error code 404 Though, Rietveld _is_ updated. On sourceforge I can read Updated: 9 minutes But no matching time-signature for the messages. Anyone with an idea what happens? Thanks, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve markup->string (issue 347000043 by thomasmorle...@gmail.com)
Hi Paul, thanks for review https://codereview.appspot.com/34743/diff/40001/scm/markup.scm File scm/markup.scm (right): https://codereview.appspot.com/34743/diff/40001/scm/markup.scm#newcode141 scm/markup.scm:141: ;; The string is split at line-breaks, emty strings removed and finally On 2018/11/11 15:43:37, pwm wrote: typo: empty Done. https://codereview.appspot.com/34743/diff/40001/scm/markup.scm#newcode148 scm/markup.scm:148: simple-markup))) On 2018/11/11 15:43:37, pwm wrote: Indent 'list' expression so it is clearer that it is the second argument to 'member' and not another 'and' expression. Done. https://codereview.appspot.com/34743/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve markup->string (issue 347000043 by thomasmorle...@gmail.com)
On 2018/11/11 15:08:57, thomasmorley651 wrote: simplify, catch string-markups patch-set 3 reflects my musing in comment #5 https://codereview.appspot.com/34743/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve markup->string (issue 347000043 by thomasmorle...@gmail.com)
Hi Harm, I took a quick look and it LGTM at a quick read. I have a couple nit-level suggestions. -Paul https://codereview.appspot.com/34743/diff/40001/scm/markup.scm File scm/markup.scm (right): https://codereview.appspot.com/34743/diff/40001/scm/markup.scm#newcode141 scm/markup.scm:141: ;; The string is split at line-breaks, emty strings removed and finally typo: empty https://codereview.appspot.com/34743/diff/40001/scm/markup.scm#newcode148 scm/markup.scm:148: simple-markup))) Indent 'list' expression so it is clearer that it is the second argument to 'member' and not another 'and' expression. https://codereview.appspot.com/34743/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.20 plans.
I've just set up a new user on my build machine and tried to build GUB.
make bootstrap was fine (except missing xelatex which I installed). Make
lilypond fell over when trying to make guile:
building package: tools::guile
*** Stage: download (guile, tools)
*** Stage: untar (guile, tools)
*** Stage: patch (guile, tools)
*** Stage: autoupdate (guile, tools)
*** Stage: configure (guile, tools)
*** Stage: compile (guile, tools)
Command barfed: cd /home/gubd/GubDir/gub/target/tools/build/guile-1.8.7 &&
export
LD_LIBRARY_PATH=/home/gubd/GubDir/gub/target/tools/build/guile-1.8.7/libguile/.libs:/home/gubd/GubDir/gub/target/tools/root/usr/lib:${LD_LIBRARY_PATH-/foe};preinstguile=/home/gubd/GubDir/gub/target/tools/root/usr/bin/guile
make -j16
Tail of target/tools/log/guile.log
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/gubd/GubDir/gub/target/tools/build/guile-1.8.7'
make: *** [all] Error 2
Command barfed: cd /home/gubd/GubDir/gub/target/tools/build/guile-1.8.7 &&
export
LD_LIBRARY_PATH=/home/gubd/GubDir/gub/target/tools/build/guile-1.8.7/libguile/.libs:/home/gubd/GubDir/gub/target/tools/root/usr/lib:${LD_LIBRARY_PATH-/foe};preinstguile=/home/gubd/GubDir/gub/target/tools/root/usr/bin/guile
make -j16
Tail of target/tools/log/guile.log
*** Failed target: tools::guile
make[1]: *** [packages] Error 1
make[1]: Leaving directory `/home/gubd/GubDir/gub'
make: *** [lilypond] Error 2
The relevant lines in the guile log seem to be:
Perl lib version (5.10.0) doesn't match executable version (v5.18.2) at
/home/gubd/GubDir/gub/target/tools/root/usr/lib/perl5/5.10.0/i686-linux/Config.pm
line 46.
Compilation failed in require at /usr/bin/makeinfo line 31.
BEGIN failed--compilation aborted at /usr/bin/makeinfo line 31.
Anyone any ideas how to proceed?
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve markup->string (issue 347000043 by thomasmorle...@gmail.com)
On 2018/11/11 11:07:35, dak wrote: On 2018/11/11 10:57:31, thomasmorley651 wrote: > 'all-relevant-markup-commands' tries to get all markup-(list-)commands where > 'markup->string' may return reasonable output. I have to get used to the thought of not having the monopoly on good ideas. That's all. Well, I'm pretty sure while working on https://sourceforge.net/p/testlilyissues/issues/4685/ you pointed me in the direction how to deduce things like that. ;) Though, I just noticed I introduced a so far unnoticed glitch with 4685 markup->string doesn't work on \simple I looked which other markup commands are unnoticed thrown away. Below they are listed, devided into worth-to-keep and to-ignore, as far as I would think: worth-to-keep: wordwrap-string-markup justify-string-markup simple-markup wordwrap-string-internal-markup-list to-ignore: lookup-markup postscript-markup epsfile-markup fret-diagram-markup tied-lyric-markup musicglyph-markup fret-diagram-terse-markup rest-markup verbatim-file-markup harp-pedal-markup For wordwrap-string-markup and justify-string-markup I think they should be special-cased, meaning deleting tab and newline-characters. Maybe simple-markup can be put there as well. Not sure about wordwrap-string-internal-markup-list, keep or ignore? The to-ignore-markups could be appended to the list already defined with 'markup-commands-to-ignore'. Though, this would introduce a manually to maintain instance which I'd like to avoid, but I'm not aware of a condition to exlude them. Otoh 'markup-commands-to-ignore' has already an entry, so it needs to be mantained anyway. Hmm. Hints? Opinions? https://codereview.appspot.com/34743/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES - Countdown for Nov 11th
Hello, Here is the current patch countdown list. The next countdown will be on 14th November, A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: No patches to Push at this time. Countdown: 5437 Improve markup->string - Thomas Morley https://sourceforge.net/p/testlilyissues/issues/5437 http://codereview.appspot.com/34743 Review: 5435 Typos found by checking clang warnings. - Werner LEMBERG https://sourceforge.net/p/testlilyissues/issues/5435 http://codereview.appspot.com/365800043 New: No New patches at this time. Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve markup->string (issue 347000043 by thomasmorle...@gmail.com)
On 2018/11/11 10:57:31, thomasmorley651 wrote: On 2018/11/10 12:53:18, dak wrote: > I wonder whether it might be reasonable to just have all markup commands with a > last argument of markup? produce their last (recursively treated) argument as > default, and possibly all markup list commands with a last argument of > markup-list? similarly produce their last argument? That leaves fewer commands > to cater for and would also make some user-defined commands work reasonably > well. I think I do not fully understand what you mean. More a case of me talking about stuff I know nothing about. 'all-relevant-markup-commands' tries to get all markup-(list-)commands where 'markup->string' may return reasonable output. I have to get used to the thought of not having the monopoly on good ideas. That's all. I had assumed that you work with large lists of markup commands and rules rather than this kind of deduction and didn't even bother to check. Sorry for the noise. https://codereview.appspot.com/34743/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve markup->string (issue 347000043 by thomasmorle...@gmail.com)
On 2018/11/10 12:53:18, dak wrote: I wonder whether it might be reasonable to just have all markup commands with a last argument of markup? produce their last (recursively treated) argument as default, and possibly all markup list commands with a last argument of markup-list? similarly produce their last argument? That leaves fewer commands to cater for and would also make some user-defined commands work reasonably well. I think I do not fully understand what you mean. 'all-relevant-markup-commands' tries to get all markup-(list-)commands where 'markup->string' may return reasonable output. Currently by looking whether 'cheap-markup?' or 'markup-list?' are somewhere in their predicates. This could be changed to look whether those are last in predicates. Would simplify the coding and 'markup->string' only works in this case anyway. (At least following a comment there.) So far I understood, at least I hope so. I have some other simplifications in mind, will upload with next patch. Though, the amount of caught markup-(list-)commands is the same for both codings. But what do you mean with "produce their last (recursively treated) argument as default" Could you elaborate a bit? https://codereview.appspot.com/34743/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
