lilypond-user
[Top][All Lists]
Advanced

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

Re: error :GUILE signaled an error for the expression beginning here #


From: ming tsang
Subject: Re: error :GUILE signaled an error for the expression beginning here #
Date: Mon, 12 Jul 2021 09:21:14 -0400

Heart fill thank you. It was a very experience talking to the lilypond user group and I learned a lot.

Knute:  Thank you for following up on handling of the utf-8 file name and/or file path (location) problem in frecobaldi.

David Kastrup:  Thank you for helping me to use convert-ly.

David Wright:  Help me identify the problem with my lily score code.

Jean:  Help me identify the problem codes as well.

Thomas:  Thank you for updating the LSR#197. Very useful.

Jonas:  thank you for the undocumented \input-file-name use.

Aaron:  Thank you for the sample code for v2.18.2 and v2.20.0.  They both work wonderfully.  I am running v2.23.3 now, but will keep v2.18.2 handy in case I need to go back.  I saved the code in a snippet in frecobaldi v3.1.3.

Once again thank you all. I hope I didn't miss anybody that I should give thanks for helping me.

Shalom,
yMing Tsang






On Mon, Jul 12, 2021 at 6:30 AM Thomas Morley <thomasmorley65@gmail.com> wrote:
Am Mo., 12. Juli 2021 um 08:38 Uhr schrieb Jonas Hahnfeld via LilyPond
user discussion <lilypond-user@gnu.org>:
>
> Am Sonntag, dem 11.07.2021 um 22:54 -0700 schrieb Aaron Hill:
> > On 2021-07-11 12:32 pm, ming tsang wrote:
> > > I am confused about this "file information" LSR.
> > > Yesterday, I did a ""file>save as" to a file name to
> > > untitled_LSR_file-info_v2182.ly. This morning I tried to run the
> > > untitled_LSR_file-info_v2182.ly, but I got run error:
> >
> > The code in LSR 197 is not able to properly handle non-ASCII characters
> > in a file path.  Upon review, its use of object->string is mangling the
> > filename.  Also, the entire premise of the snippet is predicated on the
> > false assertion that the command-line only consists of the filename in
> > question.  In practice, there are likely to be many other arguments.  At
> > best, you might be able to rely on the filename being the last argument:
> >
> > %%%%
> > \version "2.18.2"
> >
> > filename = #(last (command-line))
> > \markup { "File Name =" \filename }
> > %%%%
> >
> > However, why mess about with reparsing the command-line arguments in the
> > first place?  LilyPond has already done this for you, so just ask
> > LilyPond for the current filename:
> >
> > %%%%
> > \version "2.20.0" % or newer
> >
> > filename = #(define-scheme-function () ()
> >   (car (ly:input-file-line-char-column (*location*))))
> > \markup { "File Name =" \filename }
> > %%%%
> >
> > You could adapt the above to work on 2.18.2, but calling the function
> > within markup requires some extra sugar:
> >
> > %%%%
> > \version "2.18.2"
> >
> > filename = #(define-scheme-function (parser location) ()
> >   (car (ly:input-file-line-char-column location)))
> > \markup { "File Name =" $#{ \filename #} }
> > %%%%
> >
> > All the more reason to leave 2.18.2 behind and just focus on the newer
> > versions of LilyPond.
>
> Or you could use the (undocumented) \input-file-name, an internal
> variable of the lexer, which seems to be there since "forever".

In the light of this discussion, I modified said LSR-snippet.
Alas, while the code changed, the image is not updated.
https://lsr.di.unimi.it/LSR/Item?id=197
Likely again a LSR-problem ...

Cheers,
  Harm


--
ming (lyndon) tsang

reply via email to

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