Failed compilation succeeds from command line: two problems

[stefano franchi]

Dear all,

I have encountered an annoying problem: compilation of a
luatex+biblatex+biber document from within lyx fails with the following

Missing number: treated as zero

Compilation from the command line succeeds, even though Luatex does indeed
report the same error. However, it seems to be able to recover from it.
So the first question is: how come LyX cannot recover from the error while
lualatex can?

Second issue is the error itself. The full log of the command line
compilation shows that the error is probably biblatex- or biber- related,
as it occur in the bibliography. The context of the error is as follows:

[494]
Overfull \hbox (6.58478pt too wide) in paragraph at lines 309--309
[][][][][]\EU2/MinionPro(0)/m/n/10.95 (). “ Au-topoiesis, Adap-t
iv-ity, Tele-ol-ogy, Agency”. In: \EU2/MinionPro(0)/m/it/10.95 Phe-nomenol-
[]

! Missing number, treated as zero.
<to be read again>
\char
l.309

A number should have been here; I inserted `0'.
(If you can't figure out why I needed to see a number,
look up `weird error' in the index to The TeXbook.)


I cannot quite figure out what is wrong from the above. Line 309 is the
blank line immediately following the \printbibliography command in the
master file.
I thought the error could be in the .bbl file, but can't find any
enlightenment there either: the section of the bbl file that contains the
ref above is as follows:

\entry{DiPaolo2005}{article}{}
\name{labelname}{1}{}{%

{{uniquename=0,hash=9bd649d3ac51ec3f91a4a07fb6111342}{{Di\bibnamedelimb
Paolo}}{D\bibinitperiod}{Ezequiel}{E\bibinitperiod}{}{}{}{}}%
}
\name{author}{1}{}{%

{{uniquename=0,hash=9bd649d3ac51ec3f91a4a07fb6111342}{{Di\bibnamedelimb
Paolo}}{D\bibinitperiod}{Ezequiel}{E\bibinitperiod}{}{}{}{}}%
}
\list{language}{1}{%
{english}%
}
\strng{namehash}{9bd649d3ac51ec3f91a4a07fb6111342}
\strng{fullhash}{9bd649d3ac51ec3f91a4a07fb6111342}
\field{sortinit}{D}
\field{sortinithash}{a01c54d1737685bc6dbf0ea0673fa44c}
\field{labelyear}{2005}
\field{datelabelsource}{}
\field{labeltitle}{Autopoiesis, Adaptivity, Teleology, Agency}
\field{journaltitle}{Phenomenology and the Cognitive Sciences}
\field{number}{4}
\field{title}{Autopoiesis, Adaptivity, Teleology, Agency}
\field{volume}{4}
\field{year}{2005}
\field{pages}{429\bibrangedash 452}
\verb{file}
\verb DiPaolo2005.pdf:AI, ALife and Information sciences/Cybernetics,
on C., Cybernetic paradigm/DiPaolo2005.pdf:PDF
\endverb
\keyw{Ashby; Homeostat; Evolutionary Robotics}
\endentry

From the (very) little I know of biblatex's internal language, it seems to

be okay. Or perhaps not.

I am really clueless...

[Jürgen Spitzmüller]

Post by stefano franchi
Compilation from the command line succeeds, even though Luatex does indeed
report the same error. However, it seems to be able to recover from it.
So the first question is: how come LyX cannot recover from the error while
lualatex can?

Both cannot. The command line simply allows you to ignore the error with
whatever visible or invisible consequences this has. LyX does not let you get
away with it. The error needs to be fixed anyway.

Post by stefano franchi
Second issue is the error itself. The full log of the command line
compilation shows that the error is probably biblatex- or biber- related,
[494]
Overfull \hbox (6.58478pt too wide) in paragraph at lines 309--309
[][][][][]\EU2/MinionPro(0)/m/n/10.95 (). “ Au-topoiesis, Adap-t
iv-ity, Tele-ol-ogy, Agency”. In: \EU2/MinionPro(0)/m/it/10.95 Phe-nomenol-
[]

What looks suspicious here are the old style figures in the year (2005). Do you
us old style figures in the bib file?

Apart from that, we would need to see the whole log file.

Jürgen

[stefano franchi]

Post by Jürgen Spitzmüller
Both cannot. The command line simply allows you to ignore the error with
whatever visible or invisible consequences this has. LyX does not let

you

Post by Jürgen Spitzmüller
get
away with it. The error needs to be fixed anyway.

I understand that, but why is this?

Why not?

Sorry my message got truncated. What I meant to say was:
Why does LyX fail compilation when programs like kile are able to continue
past the error? It does not seem to be a technical constraint but a
conscious decision.

I understand that the error will need to be fixed sooner or later. But in
some tricky cases (like this one) the error may hard to find. Indeed I have
already spent four hour bisecting my document and I haven't pinned it down
yet. As I keep looking, my only choice to keep working on the content is to
export to latex and compile from command line or form mile. Wouldn't it be
better to emulate the latter behavior in LyX? Unless I'm wrong about the
technical constraints, of course.

S.

JÃŒrgen

[stefano franchi]

Post by stefano franchi

Post by Jürgen Spitzmüller
Both cannot. The command line simply allows you to ignore the error with
whatever visible or invisible consequences this has. LyX does not

let you

Post by stefano franchi

Post by Jürgen Spitzmüller
get
away with it. The error needs to be fixed anyway.

I understand that, but why is this?

Why not?

Why does LyX fail compilation when programs like kile are able to

continue past the error? It does not seem to be a technical constraint but
a conscious decision.

Post by stefano franchi
I understand that the error will need to be fixed sooner or later. But in

some tricky cases (like this one) the error may hard to find. Indeed I have
already spent four hour bisecting my document and I haven't pinned it down
yet. As I keep looking, my only choice to keep working on the content is to
export to latex and compile from command line or form mile. Wouldn't it be
better to emulate the latter behavior in LyX? Unless I'm wrong about the
technical constraints, of course.

I meant "from kile" ! Damned autocorrect

Post by stefano franchi
S.

JÃŒrgen

[Scott Kostyshak]

On Sat, Oct 4, 2014 at 12:57 PM, stefano franchi

Post by stefano franchi

Post by Jürgen Spitzmüller
Both cannot. The command line simply allows you to ignore the error with
whatever visible or invisible consequences this has. LyX does not let
you
get
away with it. The error needs to be fixed anyway.

I understand that, but why is this?

Why not?

Why does LyX fail compilation when programs like kile are able to continue
past the error? It does not seem to be a technical constraint but a
conscious decision.
I understand that the error will need to be fixed sooner or later. But in
some tricky cases (like this one) the error may hard to find. Indeed I have
already spent four hour bisecting my document and I haven't pinned it down
yet. As I keep looking, my only choice to keep working on the content is to
export to latex and compile from command line or form mile. Wouldn't it be
better to emulate the latter behavior in LyX? Unless I'm wrong about the
technical constraints, of course.

The answer to "Why?", as Jürgen stated, is that it is important that
the user knows that there is an error so that the error can be fixed
as soon as possible. It would be irresponsible of LyX not to make sure
you know that a command failed. You might think then that we could
just issue a warning, but I don't think things are that simple (as a
permanent LyX solution). For example, if a document is exported from
LyX on the command line, the warning is shown but there is a non-zero
exit code so such a user might not realize there is a problem.

I understand your argument, Stefano. It is a reasonable one and also a
common one. For example, if you have a deadline to meet and a certain
error that you think might not even affect the output of the PDF (and
even if there is a chance, you could proof check the PDF manually),
you just want your PDF and don't have time to think about fixing a
possibly minor error. However, I think this is a feature request and
not a bug. You might want to open a trac ticket because this type of
conversation comes up from time to time and is likely to come up very
often in 2.2 if we start stopping compilation when BibTeX errors occur
(see http://www.lyx.org/trac/ticket/2757). Input from your side of the
debate is important since we don't have any developer currently
defending that (popular) feature request and it is important to
understand and try to accommodate all workflows. If you do open a
feature request, please mention exactly how Kile handles the
situation. It's very useful to compare LyX with other programs and in
this case appears to strengthen your argument.

Off topic, this is an example of why versioning is useful. I use git
and whenever I come across such a complicated issue, I just look at
the differences between my current revision and the last "good"
revision.

I hope you get this frustrating issue figured out soon. It certainly
sounds annoying.

Scott

[Julien Rioux]

Post by Scott Kostyshak
I understand your argument, Stefano. It is a reasonable one and also a
common one. For example, if you have a deadline to meet and a certain
error that you think might not even affect the output of the PDF (and
even if there is a chance, you could proof check the PDF manually),
you just want your PDF and don't have time to think about fixing a
possibly minor error. However, I think this is a feature request and
not a bug. You might want to open a trac ticket because this type of
conversation comes up from time to time and is likely to come up very
often in 2.2 if we start stopping compilation when BibTeX errors occur
(see http://www.lyx.org/trac/ticket/2757). Input from your side of the
debate is important since we don't have any developer currently
defending that (popular) feature request and it is important to
understand and try to accommodate all workflows.

FWIW I also think we should have a compilation mode which keeps going as
far as possible. Of course, it would be a opt-in setting (could be a
dialog asking to continue in the GUI and a --force option on the command
line).

Cheers,
Julien

[stefano franchi]

Post by Scott Kostyshak
On Sat, Oct 4, 2014 at 12:57 PM, stefano franchi

Post by stefano franchi

Post by Jürgen Spitzmüller
Both cannot. The command line simply allows you to ignore the error with
whatever visible or invisible consequences this has. LyX does not

let

Post by stefano franchi

Post by Jürgen Spitzmüller
you
get
away with it. The error needs to be fixed anyway.

I understand that, but why is this?

Why not?

Why does LyX fail compilation when programs like kile are able to

continue

Post by stefano franchi
past the error? It does not seem to be a technical constraint but a
conscious decision.
I understand that the error will need to be fixed sooner or later. But in
some tricky cases (like this one) the error may hard to find. Indeed I

have

Post by stefano franchi
already spent four hour bisecting my document and I haven't pinned it

down

Post by stefano franchi
yet. As I keep looking, my only choice to keep working on the content is

to

Post by stefano franchi
export to latex and compile from command line or form mile. Wouldn't it

be

Post by stefano franchi
better to emulate the latter behavior in LyX? Unless I'm wrong about the
technical constraints, of course.

The answer to "Why?", as JÃŒrgen stated, is that it is important that
the user knows that there is an error so that the error can be fixed
as soon as possible. It would be irresponsible of LyX not to make sure
you know that a command failed. You might think then that we could
just issue a warning, but I don't think things are that simple (as a
permanent LyX solution). For example, if a document is exported from
LyX on the command line, the warning is shown but there is a non-zero
exit code so such a user might not realize there is a problem.

Scott,

I agree with you and JÃŒrgen on the need to show that there has been an
error. I just think LyX could show a warning and (try to) continue.
That's why I mentioned the Latex editor Kile, whose behavior (as far as
LaTeX compilation goes) is functionally equivalent to LyX.
I can create a miniscript to take care of all the needed steps
(latex/biber/latex/latex/indy, etc) and let it run to completion, pretty
much they way LyX does it. I do get the error in the console, but Kile does
not stop compiling and I get my pdf file at the end.

Anyway, good idea to create a feature request. I see there is already one,
I will add to that.

Post by Scott Kostyshak
Off topic, this is an example of why versioning is useful. I use git
and whenever I come across such a complicated issue, I just look at
the differences between my current revision and the last "good"
revision.

I use git as well, but it didn't help this time. I guess there is a real
issue with text-versioning, actually. Unless you commit every time you
complete a paragraph, it does not help very much in debugging this kind of
issues. Perhaps a time-based automatic versioning system would help. I
guess it could be easily added on top of git, although it pretty much runs
against its philosophy.


Cheers,

Stefano

[Scott Kostyshak]

On Sun, Oct 5, 2014 at 11:28 AM, stefano franchi

Post by stefano franchi

Post by Scott Kostyshak
On Sat, Oct 4, 2014 at 12:57 PM, stefano franchi

Post by stefano franchi

Post by Jürgen Spitzmüller
Both cannot. The command line simply allows you to ignore the error with
whatever visible or invisible consequences this has. LyX does not let
you
get
away with it. The error needs to be fixed anyway.

I understand that, but why is this?

Why not?

Why does LyX fail compilation when programs like kile are able to continue
past the error? It does not seem to be a technical constraint but a
conscious decision.
I understand that the error will need to be fixed sooner or later. But in
some tricky cases (like this one) the error may hard to find. Indeed I have
already spent four hour bisecting my document and I haven't pinned it down
yet. As I keep looking, my only choice to keep working on the content is to
export to latex and compile from command line or form mile. Wouldn't it be
better to emulate the latter behavior in LyX? Unless I'm wrong about the
technical constraints, of course.

The answer to "Why?", as Jürgen stated, is that it is important that
the user knows that there is an error so that the error can be fixed
as soon as possible. It would be irresponsible of LyX not to make sure
you know that a command failed. You might think then that we could
just issue a warning, but I don't think things are that simple (as a
permanent LyX solution). For example, if a document is exported from
LyX on the command line, the warning is shown but there is a non-zero
exit code so such a user might not realize there is a problem.

Scott,
I agree with you and Jürgen on the need to show that there has been an
error. I just think LyX could show a warning and (try to) continue.
That's why I mentioned the Latex editor Kile, whose behavior (as far as
LaTeX compilation goes) is functionally equivalent to LyX.
I can create a miniscript to take care of all the needed steps
(latex/biber/latex/latex/indy, etc) and let it run to completion, pretty
much they way LyX does it. I do get the error in the console, but Kile does
not stop compiling and I get my pdf file at the end.
Anyway, good idea to create a feature request. I see there is already one, I
will add to that.

Good. Hopefully we can have a solution that works for everyone.

Post by stefano franchi

Post by Scott Kostyshak
Off topic, this is an example of why versioning is useful. I use git
and whenever I come across such a complicated issue, I just look at
the differences between my current revision and the last "good"
revision.

I use git as well, but it didn't help this time. I guess there is a real
issue with text-versioning, actually. Unless you commit every time you
complete a paragraph, it does not help very much in debugging this kind of
issues. Perhaps a time-based automatic versioning system would help. I guess
it could be easily added on top of git, although it pretty much runs against
its philosophy.

I have had a feature in mind that I thought would be interesting,
which would save a version whenever your compilation succeeds. So you
could always roll back to the last time you successfully produced a
PDF. This of course would rely on you compiling often, which is not
the case for many users.

I also have an idea for an attempt at an "automatic bisect". This is
far away from implementation though.

In any case, I'm glad you got this figured out!

Scott

[Jürgen Spitzmüller]

Post by stefano franchi
Why does LyX fail compilation when programs like kile are able to continue
past the error? It does not seem to be a technical constraint but a
conscious decision.

Because LyX does the whole compilation process automatically and has to decide
for you whether to proceed or not, while on the command line, you are the one
who has to draw decisions.

If we would let LaTeX pass after the error, people would end up with invalid
documents, maybe without even noticing it.

Having said that, there is
http://www.lyx.org/trac/ticket/8739

Jürgen

[stefano franchi]

Post by stefano franchi
Second issue is the error itself. The full log of the command line
compilation shows that the error is probably biblatex- or biber- related,

It took me almost a full day of bisecting, but I got the source of error.
It was indeed a reference, but not the last reference before the error
occurred. The culprit was the following:

@Book{DunsScotus1991,
Title = {Contingency and Freedom. Lectura I 39},
Author = {Duns Scotus, John},
Editor = {A. von Jaczn and H. Veldhuis and A. H.
Looman-Grasaskamp and E. Dekker and N. W. Den Bok},
Publisher = {Kluwer},
Year = {1991},
Address = {Dordrecht},
Series = {New Synth{\'\`}ese Historical Library},
Owner = {stefano},
Timestamp = {2014.09.25}
}


and the problem is in the Series field. I have no idea how I ended up with
two accents, but that apparently caused the error. So it's another
bibliography issue as mentioned in the feature request.


One of the reasons if took me so long is that I encountered a related
problem with compilation, but I'll start a new thread for that.

S.

[Jürgen Spitzmüller]

Post by stefano franchi
It took me almost a full day of bisecting, but I got the source of error.
It was indeed a reference, but not the last reference before the error

Did you also check the biber log file? It would have helped probably to find the
cause faster (which would be an argument in favor of stopping on bibtex/biber
errors).

Jürgen

[stefano franchi]

Post by stefano franchi

Post by stefano franchi
It took me almost a full day of bisecting, but I got the source of

error.

Post by stefano franchi
It was indeed a reference, but not the last reference before the error

Did you also check the biber log file? It would have helped probably to find the
cause faster (which would be an argument in favor of stopping on bibtex/biber
errors).
JÃŒrgen

I did, but there were no errors there. Or at least none I could find. It
was biblatex that chocked.

S.