no pdf-output in lilypond code blocks

no pdf-output in lilypond code blocks

[Florian Beck]

Hi,

execute the following code block:

#+begin_src lilypond :exports results :file 93bff287-036e-4129-8f17-fd6374f4ccdc.pdf
\header { tagline = ##f }
\score{
\relative c' {
\key d \minor
d2 a'2 f2 d2 }}
#+END_src

This will create a results block:

#+RESULTS:
[[file:93bff287-036e-4129-8f17-fd6374f4ccdc.pdf]]

but actually create the file 93bff287-036e-4129-8f17-fd6374f4ccdc.eps
(note the extension). [I need pdf, because I cannot get xelatex handle
eps files.]

It seems `ly-process-basic' hardcodes a "--png" option. If I change it
to "--pdf" everything works fine (though it won't produce pngs any more,
I guess). Of course, it should really be set as appropriate for the extension.


-- 
Florian Beck

Re: no pdf-output in lilypond code blocks

[Bastien]

Hi Florian,

Florian Beck <fb@miszellen.de> writes:

> It seems `ly-process-basic' hardcodes a "--png" option. If I change it
> to "--pdf" everything works fine (though it won't produce pngs any more,
> I guess). Of course, it should really be set as appropriate for the
> extension.

Line 155 in ob-lilypond.el use --png.

Is it okay to use --pdf --html and --svg here too?

If so, I'll fix ly-process-basic so that it depends on
ly-gen-png/pdf/html/svg.

Thanks for confirming,

-- 
 Bastien

Re: no pdf-output in lilypond code blocks

[Florian Beck]

Hi Bastien,

> Line 155 in ob-lilypond.el use --png.
>
> Is it okay to use --pdf --html and --svg here too?

The only choices are --pdf, --png, and --ps.

See:
http://www.lilypond.org/doc/v2.16/Documentation/usage/command_002dline-usage#invoking-lilypond

>
> If so, I'll fix ly-process-basic so that it depends on
> ly-gen-png/pdf/html/svg.
>
> Thanks for confirming,

Thanks for fixing.
-- 
Florian Beck

Re: no pdf-output in lilypond code blocks

[Bastien]

Hi Florian,

Florian Beck <fb@miszellen.de> writes:

>> If so, I'll fix ly-process-basic so that it depends on
>> ly-gen-png/pdf/html/svg.
>>
>> Thanks for confirming,
>
> Thanks for fixing.

Done -- please have a try and let me know.

-- 
 Bastien

Re: no pdf-output in lilypond code blocks

[Florian Beck]

Bastien <bzg@altern.org> writes:

> Hi Florian,
>
> Florian Beck <fb@miszellen.de> writes:
>
>>> If so, I'll fix ly-process-basic so that it depends on
>>> ly-gen-png/pdf/html/svg.
>>>
>>> Thanks for confirming,
>>
>> Thanks for fixing.
>
> Done -- please have a try and let me know.

Minor hitch: the variable is called `ly-use-eps' not `ly-gen-eps'.

However, as far as I understand these variables are intended for tangled
files. The original bug was that exporting or evaluating a code
block doesn't respect the extension of the :file directive.

I can live with setting `ly-gen-pdf', but maybe something like

(pcase (file-name-extension out-file)
        ("pdf" "--pdf ")
        ("ps" "--ps ")
        ("png" "--png ")
        (t "--png "))

would be even better?


-- 
Florian Beck

Re: no pdf-output in lilypond code blocks

[Bastien]

Hi Florian,

Florian Beck <fb@miszellen.de> writes:

> I can live with setting `ly-gen-pdf', but maybe something like
>
> (pcase (file-name-extension out-file)
>         ("pdf" "--pdf ")
>         ("ps" "--ps ")
>         ("png" "--png ")
>         (t "--png "))
>
> would be even better?

Indeed.  This is now the case, thanks!

-- 
 Bastien

Re: no pdf-output in lilypond code blocks

[Achim Gratz]

Bastien writes:
> Hi Florian,
>
> Florian Beck <fb@miszellen.de> writes:
>
>> I can live with setting `ly-gen-pdf', but maybe something like
>>
>> (pcase (file-name-extension out-file)
>>         ("pdf" "--pdf ")
>>         ("ps" "--ps ")
>>         ("png" "--png ")
>>         (t "--png "))
>>
>> would be even better?
>
> Indeed.  This is now the case, thanks!

This would be a bug, I believe you should use backquotes on the string
constants if indeed pcase should wend its way into Org (this would be
the only place using it):

(pcase (file-name-extension out-file)
        (`"pdf" "--pdf ")
        (`"ps" "--ps ")
        (`"png" "--png ")
        (t "--png "))

But wouldn't something like

(or (cdr (assoc (file-name-extension out-file)
                '(("pdf" . "--pdf ")
		  ("ps" . "--ps ")
		  ("png" . "--png "))))
    "--png ")

work just as well?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: no pdf-output in lilypond code blocks

[Florian Beck]

Achim Gratz <Stromeko@nexgo.de> writes:

> This would be a bug, I believe you should use backquotes on the string
> constants 

I don't think so. The string evaluates to itself or am I missing
something?

The real (but harmless) bug is

>         (t "--png "))
should be (_ "--png "))

-- 
Florian Beck

Re: no pdf-output in lilypond code blocks

[Achim Gratz]

Florian Beck writes:
> I don't think so. The string evaluates to itself or am I missing
> something?

If it would fall under "SELFQUOTING" then yes (but I really don't
understand what the doc string is trying to tell me there and what would
be used for comparison).  It seems that a string constant is not
self-quoting during compilation (the byte-compiler complains about an
"Unknown upattern `pdf'"), most likely due to the pre-expansion of the
macro before compilation.  Also the string constant "pdf" compiled ionto
the code can not necessarily match itself when compared to a string
stored in a variable, although at least in interpretation mode this
works.  On the other hand a backquoted QPattern where QPattern is a
STRING(constant) does use "equal" for comparison and this is what we
want, plus the bytecompiler seems to like that form better than the
first.

Anyway, pcase is nice when you need it, but in this case I'm not
convinced its worth the trouble.  It doesn't even put enough syntactic
sugar on it to make the code more readable.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: no pdf-output in lilypond code blocks

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> (or (cdr (assoc (file-name-extension out-file)
>                 '(("pdf" . "--pdf ")
> 		  ("ps" . "--ps ")
> 		  ("png" . "--png "))))
>     "--png ")
>
> work just as well?

Yes, I've committed this change, thanks.

-- 
 Bastien

Re: no pdf-output in lilypond code blocks

[Achim Gratz]

Achim Gratz writes:
> Florian Beck writes:
>> I don't think so. The string evaluates to itself or am I missing
>> something?
>
> If it would fall under "SELFQUOTING" then yes (but I really don't
> understand what the doc string is trying to tell me there and what would
> be used for comparison).

I've looked at this again and I still don't understand the docstring.
I've confirmed that the bytecompiler produces not only a warning during
compilation, but the compiled code won't work, so despite indications to
the contrary the backquotes are indeed necessary.  This means that
either the docstring fails to clearly indicate the necessity of using
the backquotes on string constants or the bytecompiler fails to compile
legal code: I'd suggest you take this example to emacs-bugs and see what
the devs have to say.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: no pdf-output in lilypond code blocks

[Florian Beck]

Achim Gratz <Stromeko@nexgo.de> writes:

> Achim Gratz writes:
>> Florian Beck writes:
>>> I don't think so. The string evaluates to itself or am I missing
>>> something?
>>
>> If it would fall under "SELFQUOTING" then yes (but I really don't
>> understand what the doc string is trying to tell me there and what would
>> be used for comparison).
>
> I've looked at this again and I still don't understand the docstring.
> I've confirmed that the bytecompiler produces not only a warning during
> compilation, but the compiled code won't work, 

I cannot reproduce this. The code works for me and byte compiling
doesn't generate any warning.

GNU Emacs 24.3.50.7 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0) of 2013-01-28 on flo-laptop

> so despite indications to
> the contrary the backquotes are indeed necessary.  This means that
> either the docstring fails to clearly indicate the necessity of using
> the backquotes on string constants or the bytecompiler fails to compile
> legal code: I'd suggest you take this example to emacs-bugs and see what
> the devs have to say.
>
>
> Regards,
> Achim.

-- 
Florian Beck

Re: no pdf-output in lilypond code blocks

[Achim Gratz]

Florian Beck writes:
> I cannot reproduce this. The code works for me and byte compiling
> doesn't generate any warning.
>
> GNU Emacs 24.3.50.7 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0) of 2013-01-28 on flo-laptop

Fail: 24.2 (unknown upattern),
      23.[34] (malformed function),
      22.3 (malformed function)
Pass: 24.3.50, 24.2.9[012]

So it seems to have been fixed by the macro compilation changes that
Stefan Monnier did some months ago.


For grins the result with the backquotes:

Fail: 23.[34] (old-style backquote warning)
      22.3 (old-style backquote warning)
Pass: 24.3.50, 24.2.9[012], 24.2

Still not a good idea to use pcase in code that should be backwards
compatible…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds