Re: Weird compile result -- bug?
On 10/15/21 12:34 PM, Jürgen Spitzmüller wrote:
Am Freitag, dem 15.10.2021 um 11:51 -0400 schrieb Paul A. Rubin:
Over on the user list, there's a lengthy thread (actually set of
threads) triggered by user Rich Shepard trying to compile a report
whose
bibliography stubbornly refused to appear. Rich was using biblatex.
After copies trial and error, Rich got the report to work, but with
no
explanation why.
I was beating on a copy of it (which I am not at liberty to share)
and
discovered that if made any non-fatal change to the preamble, the
bibliography would show up. In particular, just adding \usepackage{}
(with the argument deliberately empty) to the preamble in LyX coaxed
the
bibliography to show up.
Comparing the .tex files that LyX exported with and without the
\usepackage{} command, I discovered two changes. One of course was
the
inclusion of \usepackage{}. The other was that
\usepackage[style=authoryear]{biblatex} in the original document
morphed
into \usepackage[style=authoryear,backend=bibtex8]{biblatex} in the
modified document.
So I went to the original document and, in the bibliography settings,
changed the processor option from default to bibtex8, and sure enough
the original compiled correctly.
I'm not sure if this is a bug or something the user is responsible
for
knowing (it was news to me, but I never use biblatex). So I'm
reporting
it here to let wiser minds decide.
Undecidable without a MWE.
Jürgen
Here's an MWE and the associated .bib file. Since I installed biber, I
no longer fail to generate a bibliography under any scenario, but I can
still reproduce behavior that I think is a bug. This is with LyX 2.3.6.1
on Linux Mint 20.2 using TeXLive 2019. I'm using the PDF (pdflatex)
output format throughout.
1. View the document (which compiles correctly), then run 'grep
biblatex dev_mwe.tex' in the LyX buffer directory. The relevant
output line is "\usepackage[style=authoryear]{biblatex}".
2. Make an arbitrary text change in the document body (anywhere), to
force LyX to recompile. Repeat the previous step. The key line in
the .tex file is unchanged.
3. In Document > Settings... > LaTeX Preamble, add a space at the end
of the preamble and repeat the first step. The line in the .tex file
changes to "\usepackage[style=authoryear,backend=bibtex8]{biblatex}"
(i.e., the "backend" setting is added).
This also happens if I edit the text in the \lehead{}, \rohead{},
\refoot{} or \lofoot{} commands, or if I insert \usepackage{} in the
preamble, or basically if I make any non-fatal change to the preamble.
It makes no sense to me that any of those changes would affect
bibliography processing.
Paul
1.
dev_mwe.lyx
Description: application/lyx
% Encoding: UTF-8
@comment{x-kbibtex-encoding=utf-8}
@Article{VanDoornik2019,
author = {Van Doornik, D.M. and Kuligowski, D.R. and Morgan, C.A. and Burke, B.J. and Seamons, T.R.},
journal = {Fishery Bulliten},
title= {Insights, from genetic analyses, into stock-specific distribution of juvenile steelhead (Oncorhynchusmykiss) from the Columbia River during early marine migration},
year = {2019},
doi = {10.7755/FB.117.1-2.11},
pages= {97--106},
volume = {117},
abstract = {For anadromous Pacific salmon (Oncorhynchus sp.), ocean conditions during their initial entry into the marine environment can greatly affect their survival. Different life history types or stocks may experience different conditions during their marine entry because routes of early marine migration can differ among types or stocks. Steelhead (O. mykiss) from the For anadroumous Pacific salmon (Oncohrynchus sp.) ocean salmon (Oncorhynchus sp.), ocean conditions during their initial entry into the marine environment can greatly affect their survival. Different life history types or stocks may experience different conditions during their marine entry because routes of early marine migration can differ among types or stocks. Steelhead (O. mykiss) from the Columbia River are believed to migrate offshore quickly once they enter the ocean, but little is known about whether life history or stock-specific differences in early marine migration exist. We assembled a baseline of steelhead genetic data that allowed us to estimate the genetic stock of origin for juvenile steelhead that had been caught off the coasts of Washington and Oregon in May, shortly after their out-migration from freshwater. We found differences in the average locations of the various genetic stock groups of the Columbia River, dissimilarities that were most likely due to differences in the timing of the marine entry of juveniles. We also observed considerable variation among years in the average location where we caught steelhead and in the number of steelhead caught, results indicating that freshwater or marine conditions can influence the behavior or survival of steelhead.},
keywords = {fish, Columbia River, rivers, steelhead, trout, distribution,
Re: Weird compile result -- bug?
Am Freitag, dem 15.10.2021 um 11:51 -0400 schrieb Paul A. Rubin:
> Over on the user list, there's a lengthy thread (actually set of
> threads) triggered by user Rich Shepard trying to compile a report
> whose
> bibliography stubbornly refused to appear. Rich was using biblatex.
> After copies trial and error, Rich got the report to work, but with
> no
> explanation why.
>
> I was beating on a copy of it (which I am not at liberty to share)
> and
> discovered that if made any non-fatal change to the preamble, the
> bibliography would show up. In particular, just adding \usepackage{}
> (with the argument deliberately empty) to the preamble in LyX coaxed
> the
> bibliography to show up.
>
> Comparing the .tex files that LyX exported with and without the
> \usepackage{} command, I discovered two changes. One of course was
> the
> inclusion of \usepackage{}. The other was that
> \usepackage[style=authoryear]{biblatex} in the original document
> morphed
> into \usepackage[style=authoryear,backend=bibtex8]{biblatex} in the
> modified document.
>
> So I went to the original document and, in the bibliography settings,
> changed the processor option from default to bibtex8, and sure enough
> the original compiled correctly.
>
> I'm not sure if this is a bug or something the user is responsible
> for
> knowing (it was news to me, but I never use biblatex). So I'm
> reporting
> it here to let wiser minds decide.
Undecidable without a MWE.
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: babel (follow-up to stackexchange)
Try to right click on a toolbar and select a different toolbar size. Admittedly, this should be made automatic. (‘giant’). Thank you. Javier -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/2.3.x] Autoconf: disable warning deprecated-copy when supported
Le 15/10/2021 à 17:48, Jean-Marc Lasgouttes a écrit : commit 1922ee7d4015956555f5a5d82994df027ca60415 Author: Jean-Marc Lasgouttes Date: Fri Oct 15 17:05:04 2021 +0200 Autoconf: disable warning deprecated-copy when supported Kornel, some work for you too! JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
BibLaTeX Issue
Changing the subject to get the right person's attention...
On 10/15/21 11:51, Paul A. Rubin wrote:
Hi all,
Over on the user list, there's a lengthy thread (actually set of
threads) triggered by user Rich Shepard trying to compile a report
whose bibliography stubbornly refused to appear. Rich was using
biblatex. After copies trial and error, Rich got the report to work,
but with no explanation why.
I was beating on a copy of it (which I am not at liberty to share) and
discovered that if made any non-fatal change to the preamble, the
bibliography would show up. In particular, just adding \usepackage{}
(with the argument deliberately empty) to the preamble in LyX coaxed
the bibliography to show up.
Comparing the .tex files that LyX exported with and without the
\usepackage{} command, I discovered two changes. One of course was the
inclusion of \usepackage{}. The other was that
\usepackage[style=authoryear]{biblatex} in the original document
morphed into \usepackage[style=authoryear,backend=bibtex8]{biblatex}
in the modified document.
So I went to the original document and, in the bibliography settings,
changed the processor option from default to bibtex8, and sure enough
the original compiled correctly.
I'm not sure if this is a bug or something the user is responsible for
knowing (it was news to me, but I never use biblatex). So I'm
reporting it here to let wiser minds decide.
Paul
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Weird compile result -- bug?
Hi all,
Over on the user list, there's a lengthy thread (actually set of
threads) triggered by user Rich Shepard trying to compile a report whose
bibliography stubbornly refused to appear. Rich was using biblatex.
After copies trial and error, Rich got the report to work, but with no
explanation why.
I was beating on a copy of it (which I am not at liberty to share) and
discovered that if made any non-fatal change to the preamble, the
bibliography would show up. In particular, just adding \usepackage{}
(with the argument deliberately empty) to the preamble in LyX coaxed the
bibliography to show up.
Comparing the .tex files that LyX exported with and without the
\usepackage{} command, I discovered two changes. One of course was the
inclusion of \usepackage{}. The other was that
\usepackage[style=authoryear]{biblatex} in the original document morphed
into \usepackage[style=authoryear,backend=bibtex8]{biblatex} in the
modified document.
So I went to the original document and, in the bibliography settings,
changed the processor option from default to bibtex8, and sure enough
the original compiled correctly.
I'm not sure if this is a bug or something the user is responsible for
knowing (it was news to me, but I never use biblatex). So I'm reporting
it here to let wiser minds decide.
Paul
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Backport warning fixes to 2.3.x
Hello,
The following fixes are needed with g++ 11 in branch. They are not
needed in master, where clang 10 already made them visible.
OK to commit?
JMarcFrom 3beb9b326d4bd29e4122d759ef48f32a7488161d Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Fri, 15 Oct 2021 15:49:40 +0200
Subject: [PATCH 1/6] Remove variable that is not used
Spotted by clang++ 13.
(cherry picked from commit d99502d9154e7e51a665f03963e010411e9545be)
---
src/frontends/qt4/GuiDocument.cpp | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/frontends/qt4/GuiDocument.cpp b/src/frontends/qt4/GuiDocument.cpp
index 41b08fce7e..b20e16a771 100644
--- a/src/frontends/qt4/GuiDocument.cpp
+++ b/src/frontends/qt4/GuiDocument.cpp
@@ -2745,10 +2745,7 @@ void GuiDocument::updateEngineType(string const & items, CiteEngineType const &
{
engine_types_.clear();
- int nn = 0;
-
for (int n = 0; !token(items, '|', n).empty(); ++n) {
- nn += 1;
string style = token(items, '|', n);
engine_types_.push_back(style);
}
--
2.32.0
From 4d410d0d32a6ade8e5ee27f4390a0340ed8d5b60 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Tue, 28 Apr 2020 13:27:50 +0200
Subject: [PATCH 2/6] Do not for copies in range-based for loops.
Spotted by clang++ 10.
(cherry picked from commit a85c48de5a15c4f70f79a53b451fbe0d083e9ece)
---
src/HunspellChecker.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/HunspellChecker.cpp b/src/HunspellChecker.cpp
index 593a123bf9..c211b47c85 100644
--- a/src/HunspellChecker.cpp
+++ b/src/HunspellChecker.cpp
@@ -424,7 +424,7 @@ void HunspellChecker::suggest(WordLangTuple const & wl,
string const word_to_check = to_iconv_encoding(wl.word(), encoding);
#ifdef HAVE_HUNSPELL_CXXABI
vector wlst = h->suggest(word_to_check);
- for (auto const s : wlst)
+ for (auto const & s : wlst)
suggestions.push_back(remap_result(from_iconv_encoding(s, encoding)));
#else
char ** suggestion_list;
@@ -449,7 +449,7 @@ void HunspellChecker::stem(WordLangTuple const & wl,
string const word_to_check = to_iconv_encoding(wl.word(), encoding);
#ifdef HAVE_HUNSPELL_CXXABI
vector wlst = h->stem(word_to_check);
- for (auto const s : wlst)
+ for (auto const & s : wlst)
suggestions.push_back(from_iconv_encoding(s, encoding));
#else
char ** suggestion_list;
--
2.32.0
From cca4b8d42a282d3b93d86acb0e990074db4f7fd3 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Fri, 15 Oct 2021 16:10:04 +0200
Subject: [PATCH 3/6] Avoid some more copies in range-based for loops
This triggers warnings with clang++ 10 and gcc 11.
(cherry-picked from commit 7035e230caa69a2e35f16dcf0d9696c59cef5c4c)
---
src/frontends/qt4/Menus.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/frontends/qt4/Menus.cpp b/src/frontends/qt4/Menus.cpp
index 5f9eb9068d..a2505dc250 100644
--- a/src/frontends/qt4/Menus.cpp
+++ b/src/frontends/qt4/Menus.cpp
@@ -1337,7 +1337,7 @@ void MenuDefinition::expandToc(Buffer const * buf)
// In the navigation menu, only add tocs from this document
TocBackend const & backend = buf->tocBackend();
TocList const & toc_list = backend.tocs();
- for (pair> const & toc : toc_list) {
+ for (pair> const & toc : toc_list) {
// Handle table of contents later
if (toc.first == "tableofcontents" || toc.second->empty())
continue;
@@ -1695,7 +1695,7 @@ void MenuDefinition::expandCaptions(Buffer const * buf, bool switchcap)
DocumentClass const & dc = buf->params().documentClass();
vector< pair > caps;
- for (pair const & il : dc.insetLayouts()) {
+ for (pair const & il : dc.insetLayouts()) {
docstring instype;
docstring const type = split(il.first, instype, ':');
if (instype == from_ascii("Caption")) {
--
2.32.0
From 09b340a45e4563d11a9a132c86693fb44f898b81 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Fri, 15 Oct 2021 17:41:01 +0200
Subject: [PATCH 4/6] Fix more unintended copies in range-based for loops
Spotted by g++ 11.
---
src/Encoding.cpp | 2 +-
src/TocBackend.cpp | 2 +-
src/frontends/qt4/TocModel.cpp | 2 +-
src/insets/InsetInclude.cpp| 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/Encoding.cpp b/src/Encoding.cpp
index 35a93b40ec..d0046ecc06 100644
--- a/src/Encoding.cpp
+++ b/src/Encoding.cpp
@@ -267,7 +267,7 @@ vector Encoding::symbolsList() const
// add all encodable characters
copy(encodable_.begin(), encodable_.end(), back_inserter(symbols));
// now the ones from the unicodesymbols file that are not already there
- for (pair const & elem : unicodesymbols) {
+ for (pair const & elem : unicodesymbols) {
if (find(symbols.begin(), symbols.end(), elem.first) == symbols.end())
symbols.push_back(elem.first);
}
diff --git a/src/TocBackend.cpp b/src/TocBackend.cpp
index a253d57ca3..4bb91816e8 100644
--- a/src/TocBackend.cpp
+++ b/src/TocBackend.cpp
@@ -272,7 +272,7 @@ void TocBackend::resetOutlinerNames()
{
outliner_names_.clear();
//
Re: babel (follow-up to stackexchange)
Le 15/10/2021 à 09:31, Javier Bezos a écrit : Not related to LaTeX: my screen is K4 and the toolbars are microscopical. Try to right click on a toolbar and select a different toolbar size. Admittedly, this should be made automatic. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: babel (follow-up to stackexchange)
On Fri, Oct 15, 2021 at 09:31:20AM +0200, Javier Bezos wrote: > > > Is our babel code outdated for specific languages (e.g., Hebrew), or in > > general? > > > > Does our current code rely on commands that will be deprecated by babel, or > > is the new way of doing thing just more robust? > > My version es 2.3.6.1. Is it the most appropriate version for > commenting? That is the latest release. We have not made a major (2.x) release for a while so there have been a lot of changes that are not in 2.3.6.1. I suggest that you send me (privately if you want) the .lyx files you are testing and I can export them to the LaTeX flavor you're interested in and send them back so you can see if there are any differences 2.4dev. Would that plan work for you? Alternatively, you can wait for the next 2.4dev pre-release (just a random guess that it would be possibly a couple of months), or I can try to set up an SSH account for you on my test computer so you can SSH in and test there. Here are some LyX features not in 2.3.6.1: https://wiki.lyx.org/LyX/NewInLyX24 The most relevant item seems to be the following: Support for babel with non-TeX fonts has been enhanced (LyX now supports babel's \babelfont font loading interface if babel >= 3.15 is available). > Not related to LaTeX: my screen is K4 and the > toolbars are microscopical. I would not be surprised if this were much better on LyX 2.4dev or much worse :). I do believe there have been some improvements along these lines in 2.4dev but we have not had a lot of testing from different users. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: babel (follow-up to stackexchange)
Is our babel code outdated for specific languages (e.g., Hebrew), or in general? Does our current code rely on commands that will be deprecated by babel, or is the new way of doing thing just more robust? My version es 2.3.6.1. Is it the most appropriate version for commenting? Not related to LaTeX: my screen is K4 and the toolbars are microscopical. Javier -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SSH woes w/ git server
Am Freitag, dem 15.10.2021 um 08:16 +0200 schrieb Jean-Marc Lasgouttes: > What key type do you use? ssh-rsa. The OpenSSH docs state (see my other mail) that these keys continue to work with the new (RSA/SHA-256/512) encrypted signatures. The problem seems to be that the server only provides SHA-1 enrcrypted signatures. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SSH woes w/ git server
Le 15/10/2021 à 07:02, Jürgen Spitzmüller a écrit : Dear all After a recent software update, I an unable to pull from lyx git. I get: Unable to negotiate with 140.211.9.84 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss Research suggests that SSH on the server needs to be updated: http://www.openssh.com/legacy.html Does anyone know how to proceed? What key type do you use? I can see it on the server, but I am not proficient in rsa-ese: I would not recognize a sha1 key if I saw one. If our server supports sha256, I guess we're kind of good right now. But yes, there is an urgency to update our oldish server. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
