biblatex 2.0/biber 1.0 testing, again

[pk]

Thanks to Joseph W, we now have a beta release of biblatex 2.0 which will not drop bibtex support. In biblatex 2.0, bibtex is frozen and deprecated, not gone. We will continue to backport relevant bugfixes to the internal bibtex codepath, however. Biber users will get all of the 2.0 new features:

* Per-list sorting (\printbibliography now supports a "sorting" option which
overrides the global sorting specification)
* Completely customisable bibliography labels with several flavours of label
auto-disambiguation
* More fine-grained sorting control
* A general "related entries" functionality to deal with the many inter-entry
relationships like "reprinted as", "translated from" etc.
* A full biblatex interface to the biber sourcemap feature
* More fine-grained control over the generation of name initials from names
* Citation key aliases so you can reference the same entry via several keys

All of these features require biber 1.0

Any testing would be appreciated and bugs can be reported on github here:

https://github.com/plk/biblatex

The beta biblatex 2.0 can be found here:

https://sourceforge.net/projects/biblatex/files/development/

and the biber 1.0 beta here:

https://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/development/

[Simon Spiegel]

Tested it with my various test files – nothing unusual to report. Seems
fine to me.

Simon

[Herbert Schulz]

In article <a0s2vf...@mid.individual.net>,

Howdy,

Updated both biber and biblatex from the previous betas. Tested with
both bibtex and biber and it seems fine here. The only noticeable change
here is that biber is the default backend so you must explicitly set the
[backend=bibtex] option to force bibtex execution; certainly not a
problem. Note: I'm not a heavy user of bibliographies so I mostly use
the a few personal files and variations on the example files for testing.

Good Luck,
Herb Schulz

[Joseph Wright]

On 08/05/2012 13:45, Herbert Schulz wrote:
> Updated both biber and biblatex from the previous betas. Tested with
> both bibtex and biber and it seems fine here. The only noticeable change
> here is that biber is the default backend so you must explicitly set the
> [backend=bibtex] option to force bibtex execution; certainly not a
> problem.

This is deliberate, and is a 'breaking' change but one which we hope is
not too bad (old documents need very little work to continue to compile).
--
Joseph Wright

[Axel Berger]

Joseph Wright wrote:
> a 'breaking' change but one which we hope is
> not too bad
> (old documents need very little work to continue to compile).

Actually I think it is bad. Someone who seldom uses TeX, or hasn't done
so for some time, hasn't followed the announcement and discussions,
updates his installation and runs one of his old files will be stumped,
unless he receives a meaningful and explanatory error message.
If he already does my criticism is void.

Axel

[Simon Spiegel]

I don't really know what a 'meaningful and explanatory error message'
would be in this context. Obviously, bibtex can't give such a message
since it doesn't know about biber/biblatex. It will only complain that
there is no relevant data in the .aux file. LaTeX/biblatex on the other
hand will give you this error message (as it has already done in the
past):

> Package biblatex Warning: Please (re)run Biber on the file:
> (biblatex) <file name>
> (biblatex) and rerun LaTeX afterwards.

Maybe this is 'meaningful and explanatory' . In the end, this
hypothetical user will have to read the manual anyway (which is not
such a crazy thing to ask for IMO).

Simon

[Robin Fairbairns]

there was a time when biblatex was declared unstable; that finished at
version 1.0, iirc. up to that point, people who wanted long-term
stability of their documents would not (should not) have used biblatex.

istm that biblatex should have a built-in work-around for users of
bibtex, since it was (obviously) available in 1.0.

if, however, i'm wrong, and biblatex has never been declared stable,
then the need for a work-around is in the "grace and favour" region of
the universe of human interactions.
--
Robin Fairbairns, Cambridge
sorry about all this posting. i'll go back to sleep in a bit.

[Joseph Wright]

Stable doesn't mean frozen. If every time a package is declared stable
no further changes can be made then we are all in for a world of pain
(fixing a bug changes behaviour in some way, so breaks absolute
stability in that sense). So there is a balance between 'being able to
evolve' and 'enabling users to compile old documents without changes'.

After the earlier discussion, we have made sure that BibTeX will remain
supported by including an essentially 'frozen' version of the code to be
loaded when "backend=bibtex" is given as an option. I will also make
sure that an appropriate message appears in the log if no "backend" is
given at all: something like 'No "backend" specified, using Biber
backend. To use BibTeX, load biblatex with the "backend=bibtex" option'.
--
Joseph Wright

[Herbert Schulz]

In article <jodhf0$ctn$1...@dont-email.me>,

Howdy,

I think this is a fine solution to a small problem. However I'm glad to
see that what was a larger problem---not supporting bibtex as a backend
at all---is solved. Again, there are many systems out there (I'm
referring to PPC Macs running OS X 10.5 which is supported by TeX
Live---but there may be others too) that don't have a version of biber
they can run so that is not a simple update problem. (PS: using an
updated Perl on those systems is not the only change that would have to
be made.)

Good Luck,
Herb Schulz

[Lars Madsen]

Or older linux systems where the supplied biber cannot even run

Our libc is too old, and it cannot currently be updated

--

/daleif (remove RTFSIGNATURE from email address)

Memoir and mh bundle maintainer
LaTeX FAQ: http://www.tex.ac.uk/faq
LaTeX book: http://www.imf.au.dk/system/latex/bog/ (in Danish)
Remember to post minimal examples, see URL below
http://www.minimalbeispiel.de/mini-en.html

[Simon Spiegel]

I do wonder who the "supposed victim" of this change would be.
Obviously he's a TeX user which already ranks him among the more
computer literate human beings. Obviously, he' does no restrict himself
to pure TeX or some kind of traditional LaTeX core, since he uses
biblatex. He's also able to update his TeX installation since he must
have biblatex 2.0 to experience this change. But although he's able to
do all those things, he is for some reason unable to interpret error
messages correctly, read the manual to understand that he must add one
single line to his document and also unable to restore his installation
to a former version of LaTeX.

Sorry, but this is a kind of user I wouldn't care about too much.

Simon

[Simon Spiegel]

^^^
That's biblatex of course.

[Lars Madsen]

I think you would be surprised at how many who does not read manuals.
They just get some code from their friends and if it breaks they have no
clue as to what to do.

[Simon Spiegel]

So they can ask the friend.

I do know very well that many people don't' read manuals. I'm one of
those "friend" people tend to ask. But this user you describe will
often encounter problems – no matter what package or updates. He needs
someone in the know if things don't work (which can happen quite often
with LaTeX). Must we really stall development because of this?
Personally, I very much prefer to explain people how to deal with
biblatex/biber than with some decades old BibTeX style.

Simon

[Lars Madsen]

I'm not saying that what have been done is a bad thing. I think it is a
good choice.

Knowing how students pass files around, the 'friend' that added the
biblatex stuff to a template may be long gone at the time where the
update comes through. It would be the same thing as an researcher forced
to use biblatex by a co-author. Then all of s sudden his article can no
longer be compiled and the co-author is on holiday for the next month.

As a user I'm just a bit annoyed that the only program not working in my
LaTeX installation is biber.

[Robin Fairbairns]

Simon Spiegel <si...@remove.simifilm.ch> writes:

> On 2012-05-09 12:15:36 +0000, Lars Madsen said:
>> I think you would be surprised at how many who does not read
>> manuals. They just get some code from their friends and if it breaks
>> they have no clue as to what to do.
>
> So they can ask the friend.

i find it's more often "colleague" -- someone who the 0clue person once
worked with. that research student/academic has gone, and the 0clue
person blunders around their department trying to find an email address,
or someone _else_ who understands the problem.

> I do know very well that many people don't' read manuals. I'm one of
> those "friend" people tend to ask. But this user you describe will
> often encounter problems – no matter what package or updates. He needs
> someone in the know if things don't work (which can happen quite often
> with LaTeX).

i find things "just work" a surprising proportion of the time, once
you've corrected things like \edf or \nwcommand. even 0clue people get
on quite well a lot of the time, but if something big changes they're
absolutely adrift.

> Must we really stall development because of this?

as i understood it, there is an accepted proposition: to retain a bibtex
backend with frozen code within the package. all development will
proceed using the biber backend. there will be an alert when the user
fails to specify their backend (a detailed error message will need to be
issued).

then, unless the user is using an ide that takes the m$ approach ("let's
not show this error message to the user, it's a bit difficult"),
everything's fine.

> Personally, I very much prefer to explain people how to deal with
> biblatex/biber than with some decades old BibTeX style.

with such useful explanations as "change this computer, it's no good for
modern biber"?

[Simon Spiegel]

On 2012-05-09 14:49:18 +0000, Robin Fairbairns said:

>
>> Must we really stall development because of this?
>
> as i understood it, there is an accepted proposition: to retain a bibtex
> backend with frozen code within the package. all development will
> proceed using the biber backend. there will be an alert when the user
> fails to specify their backend (a detailed error message will need to be
> issued).

Yes, this is the path the development is taking. But for some reason
you didn't seem to like that in your last post.

>
> then, unless the user is using an ide that takes the m$ approach ("let's
> not show this error message to the user, it's a bit difficult"),
> everything's fine.
>
>> Personally, I very much prefer to explain people how to deal with
>> biblatex/biber than with some decades old BibTeX style.
>
> with such useful explanations as "change this computer, it's no good for
> modern biber"?

Yes, definitely. There's no point in pretending that you can do
everything with outdated hardware.

Simon

[Robin Fairbairns]

Simon Spiegel <si...@remove.simifilm.ch> writes:

> On 2012-05-09 14:49:18 +0000, Robin Fairbairns said:
>
>>> Must we really stall development because of this?
>>
>> as i understood it, there is an accepted proposition: to retain a bibtex
>> backend with frozen code within the package. all development will
>> proceed using the biber backend. there will be an alert when the user
>> fails to specify their backend (a detailed error message will need to be
>> issued).
>
> Yes, this is the path the development is taking. But for some reason
> you didn't seem to like that in your last post.

quite; there's the regular problem with "ide hides error messages",
coupled with the tendency for even command-line users to ignore logs...

>> then, unless the user is using an ide that takes the m$ approach ("let's
>> not show this error message to the user, it's a bit difficult"),
>> everything's fine.
>>
>>> Personally, I very much prefer to explain people how to deal with
>>> biblatex/biber than with some decades old BibTeX style.
>>
>> with such useful explanations as "change this computer, it's no good for
>> modern biber"?
>
> Yes, definitely. There's no point in pretending that you can do
> everything with outdated hardware.

that is to say, you tell these people that they need to wait until their
department changes its computers (a £millions project, in many cases[*])
before they can use something.

personally, i would always try to find a way around. i certainly can't
afford to replace my computer at home, and am resigned to never being
able to use biblatex/whatever, but the situation is different in the
case of someone embarking on their career (i'm near the end of mine).

[*] in my department, total cost of like-for-like replacement would be
somewhat over £1million. we don't do that; we buy machines when we need
to, retire (==send to scrap) machines that are now deemed useless[**].
this has the advantage that we typically don't have to go through the
ritual of getting three quotes after we've determined the best
supplier ... most orders are too small to trigger the finance people's
silly controls.
[**] my home machine is one of those deemed useless.

[Simon Spiegel]

On 2012-05-09 15:41:56 +0000, Robin Fairbairns said:

> Simon Spiegel <si...@remove.simifilm.ch> writes:
>
>> On 2012-05-09 14:49:18 +0000, Robin Fairbairns said:
>>
>>>> Must we really stall development because of this?
>>>
>>> as i understood it, there is an accepted proposition: to retain a bibtex
>>> backend with frozen code within the package. all development will
>>> proceed using the biber backend. there will be an alert when the user
>>> fails to specify their backend (a detailed error message will need to be
>>> issued).
>>
>> Yes, this is the path the development is taking. But for some reason
>> you didn't seem to like that in your last post.
>
> quite; there's the regular problem with "ide hides error messages",
> coupled with the tendency for even command-line users to ignore logs...

And therefore you suggest what? Stop the development of LaTeX packages?

(Actually, the real solution would be coming up with a different kind
of notification system for LaTeX, where "real" error messages and
warnings are marked in a way that an IDE can pick it up easily. This
would make it possible that the user normally only sees these "real"
messages and not the entire .log file as it is currently done in my
LaTeX GUIs. But since that would probably also mean creating a new kind
of .logc format which isn't 100% backwards compatible, we're stuck
again).

>
>>> then, unless the user is using an ide that takes the m$ approach ("let's
>>> not show this error message to the user, it's a bit difficult"),
>>> everything's fine.
>>>
>>>> Personally, I very much prefer to explain people how to deal with
>>>> biblatex/biber than with some decades old BibTeX style.
>>>
>>> with such useful explanations as "change this computer, it's no good for
>>> modern biber"?
>>
>> Yes, definitely. There's no point in pretending that you can do
>> everything with outdated hardware.
>
> that is to say, you tell these people that they need to wait until their
> department changes its computers (a £millions project, in many cases[*])
> before they can use something.

Yes. You can't run the latest software if you don't have the proper
hardware. biber is not different in this regard than thousands of other
programs.

Simon

[Simon Spiegel]

What I find really strange in this discussion is that some people
behave as if this was actually something new. The problem that a
certain document or template relies on a feature that is only available
in a certain version of a package is nothing new (or that version x of
package ab is buggy and therefore should be updated ASAP). It happens
all the time. I'd actually say that this one of the most common
problems I encounter. And whether a LaTeX run fails because the
package has the wrong version or because biber is missing is really the
same thing for the supposed uninformed user. He's stuck in both cases
and will need help. Since TeXLive offers an update mechanism the chance
that people have different versions of the same package has potentially
increased even more (don't get me wrong: I love the update function).

If you look at biblatex the problem is even there with the
"bibtex-friendly" approach taken for version 2: Some features of
biblatex require biber. No backend directive will change that. And the
number of biber-only feature is likely to increase in the future.

> As a user I'm just a bit annoyed that the only program not working in
> my LaTeX installation is biber.

Fair enough. But what's the alternative?

Simon

[Martin Vaeth]

I would agree if the discussion were about a numerical real-time
application which needs to do zillions of operations a second.
But the discussion is about an application which should essentially
rearrange a well-defined text file according to not so insanely
complex rules - a task which (up to perhaps some memory
constraints) even the oldest hardware should be able to do easily.

Although I like perl, I think the biber dependencies have gone
a little bit over the top: Why is it impossible to avoid requiring
the absolutely newest version of a language interpreter and several
dozens(!) of rather uncommon packages?

Compiling an (in its nature) interpreted language like perl into a
binary is not really a solution to this dependency hell:
Not speaking about security risks (since compiled-in packages cannot
receive independent security updates), it produces an incredibly
huge binary which is just a waste of resources - and of course runs
only on a limited number of systems.

[Simon Spiegel]

On 2012-05-09 17:48:54 +0000, Martin Vaeth said:

> Simon Spiegel <si...@remove.simifilm.ch> wrote:
>> On 2012-05-09 14:49:18 +0000, Robin Fairbairns said:
>>> with such useful explanations as "change this computer, it's no good for
>>> modern biber"?
>>
>> Yes, definitely. There's no point in pretending that you can do
>> everything with outdated hardware.
>
> I would agree if the discussion were about a numerical real-time
> application which needs to do zillions of operations a second.
> But the discussion is about an application which should essentially
> rearrange a well-defined text file according to not so insanely
> complex rules - a task which (up to perhaps some memory
> constraints) even the oldest hardware should be able to do easily.
>
> Although I like perl, I think the biber dependencies have gone
> a little bit over the top: Why is it impossible to avoid requiring
> the absolutely newest version of a language interpreter and several
> dozens(!) of rather uncommon packages?

One reason is AFAIK proper support of Unicode 6.

>
> Compiling an (in its nature) interpreted language like perl into a
> binary is not really a solution to this dependency hell:
> Not speaking about security risks (since compiled-in packages cannot
> receive independent security updates), it produces an incredibly
> huge binary which is just a waste of resources - and of course runs
> only on a limited number of systems.

We're talking about binaries around the size 10–15MB. Maybe some people
still run hardware where 15MB of hard disk space is a "waste of
resources", but most people won't even notice that.

That aside, everyone is free to come up with a biber replacement which
is smaller, has less dependencies and runs on more platforms. Until
this replacement arrives I'm very happy that the biblatex/biber combo
solves a lot of problems which have plagued BibTeX for ages and which
no one cared to fix.

Simon

[Martin Vaeth]

Simon Spiegel <si...@remove.simifilm.ch> wrote:
>> Although I like perl, I think the biber dependencies have gone
>> a little bit over the top: Why is it impossible to avoid requiring
>> the absolutely newest version of a language interpreter and several
>> dozens(!) of rather uncommon packages?
>
> One reason is AFAIK proper support of Unicode 6.

I understand the reasons. For the developer, it is always easier
to use the language with the latest gimmicks. However, such things
run in danger to become an ad-hoc solution. Currently, the dependencies
just accumulate too much.
I experienced that some other projects did not become accepted since
their requirements (regularly the newest bleeding edge libraries)
were just too restrictive for the normal user.

> We're talking about binaries around the size 10–15MB. Maybe some people
> still run hardware where 15MB of hard disk space is a "waste of
> resources", but most people won't even notice that.

We are talking about a blow-up factor of around 400. Do that with
several scripts and you run into space issues on practically any
machine. Moreover, the waste of resources is not only the harddisk space
but also the memory space and the startup time.
That aside, it is always a bad idea to have several copies of
libraries/languages on a system (e.g. for the mentioned security
aspect.)

> That aside, everyone is free to come up with a biber replacement which
> is smaller, has less dependencies and runs on more platforms. Until
> this replacement arrives I'm very happy that the biblatex/biber combo
> solves a lot of problems which have plagued BibTeX for ages and which
> no one cared to fix.

The major problem with bibtex was that it was an ad-hoc solution -
just good enough for the moment. With the dependency hell which is only
ad-hoc solved by the pre-compilation, biber makes a similar mistake IMHO.

[Denis Bitouzé]

Le mercredi 09/05/12 à 20h12,
Martin Vaeth <va...@mathematik.uni-wuerzburg.de> a écrit :

> With the dependency hell which is only ad-hoc solved by the
> pre-compilation, biber makes a similar mistake IMHO.

A question, maybe completely stupid: if biber had been written with lua,
would this trouble have been avoided?
--
Denis

[Simon Spiegel]

On 2012-05-09 20:24:35 +0000, Denis Bitouzé said:

> Le mercredi 09/05/12 ą 20h12,

See the comments on this here:
http://sourceforge.net/tracker/index.php?func=detail&aid=2990463&group_id=228270&atid=1073795


Simon

[Simon Spiegel]

On 2012-05-10 05:02:53 +0000, Simon Spiegel said:

> On 2012-05-09 20:24:35 +0000, Denis Bitouzé said:
>

>> Le mercredi 09/05/12 à 20h12,

>> Martin Vaeth <va...@mathematik.uni-wuerzburg.de> a écrit :
>>
>>> With the dependency hell which is only ad-hoc solved by the
>>> pre-compilation, biber makes a similar mistake IMHO.
>>
>> A question, maybe completely stupid: if biber had been written with lua,
>> would this trouble have been avoided?
>
> See the comments on this here:
> http://sourceforge.net/tracker/index.php?func=detail&aid=2990463&group_id=228270&atid=1073795
>

BTW, a lua port would also drastically reduce the number of potential
users. Although I don't have any stats, the percentage of people using
a Lua(La)TeX is considerably smaller ATM compared to people using
pdf(La)TeX.

[Martin Vaeth]

Denis Bitouzé <dbito...@spam.wanadoo.fr> wrote:
> Martin Vaeth <va...@mathematik.uni-wuerzburg.de> a écrit :
>
>> With the dependency hell which is only ad-hoc solved by the
>> pre-compilation, biber makes a similar mistake IMHO.
>
> A question, maybe completely stupid: if biber had been written with lua,
> would this trouble have been avoided?

This question was already answered by Simon,
but I will add some comments anyway:

I think perl was a good choice for the language.

The problem IMHO is that biber tries to do too much in one program.
There is a good design philosophy in Unix (to which TeX is very close):
A tool should do one job, and it should do it well.

The job of biber should be to sort/extract a file for TeX from
one (or several) .bib-files and some description files. That's all.

It's job should *not* be to output the description file in xml format,
access various databases, query the web for databases and access them etc:
This should be the task of separate tools. In fact, I think most people
would not want that when compiling locally a tex-file a possibly
misconfigured biber uses their ssl keys to contact some online database.

To make it clear once more: I am not speaking against separate tools whose
task is to _generate_ .bib files from certain databases however, IMHO this
should just not be the task of the biber executable.

Of course, if you put everything into one huge program, this program is
almost a full operating system with all the problems managing an operating
system brings. So it comes that security becomes a major issue (if the
program can go online) and that you must install all sorts of web libraries,
XML, and whatever, even if regular calls of biber should use nothing of
these.

[Joseph Wright]

On 10/05/2012 07:56, Martin Vaeth wrote:
> The job of biber should be to sort/extract a file for TeX from
> one (or several) .bib-files and some description files. That's all.
>
> It's job should *not* be to output the description file in xml format,
> access various databases, query the web for databases and access them etc:
> This should be the task of separate tools. In fact, I think most people
> would not want that when compiling locally a tex-file a possibly
> misconfigured biber uses their ssl keys to contact some online database.

Remember that there are issues with the .bib format, and so one aim is
to look 'beyond .bib'. Also, many people now expect to be able to use
online tools to store their references (MyEndnoteWeb, Mendeley, Zotero,
...), and many of those users will simply switch to other workflows if
they can't use LaTeX easily. For example, look at the issues exporting
from some of the online tools to .bib format, where the keys may end up
different each time leading to serious problems.
--
Joseph Wright

[Khaled Hosny]

I think luatex here would be used as a generic lua interpreter, i.e. texlua, like other scripts in texlive (most notably texdoc).

[Martin Vaeth]

Joseph Wright <joseph...@morningstar2.co.uk> wrote:
>>
>> It's job should *not* be to output the description file in xml format,
>> access various databases, query the web for databases and access them etc:
>> This should be the task of separate tools. In fact, I think most people
>> would not want that when compiling locally a tex-file a possibly
>> misconfigured biber uses their ssl keys to contact some online database.
>
> Remember that there are issues with the .bib format, and so one aim is
> to look 'beyond .bib'. Also, many people now expect to be able to use
> online tools to store their references (MyEndnoteWeb, Mendeley, Zotero,
> ...), and many of those users will simply switch to other workflows if
> they can't use LaTeX easily. For example, look at the issues exporting
> from some of the online tools to .bib format, where the keys may end up
> different each time leading to serious problems.

I was not saying that there should be no tools to convert other
(possibly online) databases to .bib (or an improvement thereof):
These tools are certainly needed. What I was saying only is that
these should be *completely separate* tools which should not be
potentially started with every biber run (which in practice is
needed for almost every tex run of a document.)
Then these tools would have their own dependencies (e.g. a
mysql converter need not have a webkit dependency, biber would
not have any dependency on databases or net-related stuff at all),
and also the security issue would be less severe: If you explicitly
run a tool which accesses an online database you know what you
are doing.
There might still be specified some sort of format common to
these tools, so that e.g. you can save some data which you want to
fetch with another tool, but automagically starting such tools in
a huge program is not advantageous (and is maybe even confusing and
error-prone for the users): It is always better if the user
can understand without difficulties what his machine is doing.

[Ulrike Fischer]

Am Wed, 09 May 2012 11:38:25 +0100 schrieb Joseph Wright:

> After the earlier discussion, we have made sure that BibTeX will remain
> supported by including an essentially 'frozen' version of the code to be
> loaded when "backend=bibtex" is given as an option. I will also make
> sure that an appropriate message appears in the log if no "backend" is
> given at all: something like 'No "backend" specified, using Biber
> backend. To use BibTeX, load biblatex with the "backend=bibtex" option'.

Imho that's fine. There probably will some users who don't look in
the log or the documentation and will complain, but that is not
really a problem if one can tell them simply "add backend=bibtex or
switch to biber".

I don't mind to do a bit support and help such users - that's
inevitable if one doesn't want to stop development.

--
Ulrike Fischer

[Herbert Schulz]

In article <at1pf1z0...@nililand.de>,

Howdy,

I couldn't agree more! It is an easy thing to tell them to do.

I want to thank the folks that added the backward compatibility for
using bibtex. I know the advanced features will be biber only but if
they were using bibtex to begin with they wouldn't be using those
features anyway. I can tell folks who are using PPC systems running Mac
OS X 10.5 they can still use biblatex (with the caveat).

Good Luck,
Herb Schulz

[Joseph Wright]

On 09/05/2012 11:38, Joseph Wright wrote:
> After the earlier discussion, we have made sure that BibTeX will remain
> supported by including an essentially 'frozen' version of the code to be
> loaded when "backend=bibtex" is given as an option. I will also make
> sure that an appropriate message appears in the log if no "backend" is
> given at all: something like 'No "backend" specified, using Biber
> backend. To use BibTeX, load biblatex with the "backend=bibtex" option'.

I've now added this warning to the development version of biblatex.
--
Joseph Wright

[pk]

I think you are perhaps not really understanding what biber is supposed to be doing. I too prefer the UNIX philosophy of simple, robust toolchains but that's impossible here. The problem is that a data backend for a bibliography system must be closely tied to the typsetting requirements and makes really subtle features possible at all. Everything biber does really does have to be done by biber and all the seemingly extraneous stuff like accessing remote data is a few lines of code and not bloated at all.

External XML/XSLT libraries are in there, yes. This is much better than relying on the user having them (and the right version). There is no way biber would be used as much as it is without being self-contained. I can say for certain than before I packaged it as a "binary" (more on this below), the user base was about 1% of what it is now. Relying on installed libraries etc makes something a hackers only tool. It's strange to say that "dependency hell" isn't really solved by pre-compilation. It is. It really does solve it. biber users don't need even to have perl installed. It's easy to see it solves it because the user base radically increased when I built "binary" distributions.

biber isn't bloated (compared to what, Endnote?). It is a 10Mb or so "binary" because it's a packed .exe which extracts itself on first run, thanks to the superb PAR::Packer module. There aren't that many "gimmick" modules. We have to have Text::BibTeX as this parses .bib files. We need XML libraries and modules for certain as we need a modern, standard data interchange format between biblatex and biber. libxml2 is fast, a perfect choice. Other than this, there are very few exciting non-core modules and even if there were, 99% of users are using the "binaries" so it doesn't matter.

It has to be perl 5.14 because it's Unicode 6.0 compliant. One of the motivating factors of biber was to do Unicode properly for LaTeX bibliographies. The core Unicode::Collate module and its CLDR support (which, I have to say, biber pushed to get implemented as we really needed it) makes biber's sorting second to none in the bibliography world, free or otherwise.

So, to be clear, any less "bloated" approach would simply not do what is required. It really is more complex that just reading some files and outputting a .bbl. You should look at the uniqueness code in biber (see section 4.5.2 and4.11.4 to get an idea of this). Again, there is nothing like this on the market at all - it's very complex. Flexible data inheritance, on-the-fly source mapping etc. can't be done by an external tool as it depends on live state of the entry objects.

Don't be misled by comparisons with bibtex. You have to compare like with like. Biber does far more than bibtex and to see it as a data-pump reading a format and writing another is utterly inaccurate. A lot of the really hard things biblatex does are done by the backend, that is, by biber. Yes, it could theoretically be written in C or lua. I would estimate a man-year to get a decent beta, if it got that far. I recommend looking at the biber code and documentation to see what it does and why it's a natural choice for a modern interpreted language.

[pk]

On Thursday, 10 May 2012 08:56:34 UTC+2, Martin Vaeth wrote:

> The problem IMHO is that biber tries to do too much in one program.
> There is a good design philosophy in Unix (to which TeX is very close):
> A tool should do one job, and it should do it well.
>
> The job of biber should be to sort/extract a file for TeX from
> one (or several) .bib-files and some description files. That's all.

That's all it does. The objection seems to be that it can access remote files (because some users don't have their bibliography data on their local machine). Yes, this introduces a security risk, just like having a web browser access remote web pages does. I can't see that this is really a problem. I also like the UNIX design philosophy but that doesn't mean it fits all use scenarios.

The issue of dependencies is a psychological one in my opinion. Having to install 60 dependencies in perl (unless you are using the binary and then it is not an issue at all) sounds like "a lot" but is it? Is it better if you just install one dependency but it is 60 times larger? Or you have a core language which has all the functionality in it? It just doesn't matter - you do "Build installdeps" and wait a few minutes. External modules is what makes Perl so powerful and the CPAN module automates this securely and well so who cares if it's 1000 dependencies? The real issue is whether the end result works and does what it is supposed to. LaTeX itself is a "huge" package with thousands of dependant files but ... so?

Biber isn't a "complete operating system". I have taken pains to use as few modules as I possibly could precisely because it used to be unpackaged. I don't consider XML libs, IPC (needed for cross-platform code) etc. bloated at all - that's what they are for and they do the job well and make for maintainable code. I can't see any issue with this really as there are only two use cases:

* Binary - you don't care what perl, what modules are involved, it just doesn't matter
* Unpacked perl version - you type "Build installdeps" and then it all works

This is about as easy as it gets. The remote access stuff is no more dangerous or problematic than having a web broswer. Yes it needs some WWW libraries in perl - again, so? They are stable, mature and that's what they're for. Saying that biber "should" use separate tools to fetch remote data is strange - why "should"? It's not a UNIX program, it runs on Windows, OSX, cygwin too and its job is to resolve citations from databases and then, for example, write a .bbl. There is nothing in this description which restricts it to local databases of only a particular format. Please remember, biber is not supposed to just be a bibtex clone with Unicode, it is supposed to be a custom backend for biblatex which requires a great deal more than this in a much more modern setting than bibtex ever imagined.

[Denis Bitouzé]

Le jeudi 10/05/12 à 01h54,
Khaled Hosny <khale...@eglug.org> a écrit :

> I think luatex here would be used as a generic lua interpreter, i.e.
> texlua, like other scripts in texlive (most notably texdoc).

Yes, it's what I meant.

But Phil Kime, who is much more competent than me in both biber, perl
and, probably lua, estimates a man-year to get a decent beta of a
"luabiber" so certainly no hope in this direction :)
--
Denis

[Martin Vaeth]

pk <phil...@kime.org.uk> wrote:
> and all the seemingly extraneous stuff like accessing remote
> data is a few lines of code and not bloated at all.

It is perhaps not bloated within the biber source-code, but it is
the main cause of dependency (libwww-perl) and security issues.

> External XML/XSLT libraries are in there, yes. This is much
> better than relying on the user having them (and the right version).

This is true on incomplete systems (like windows) without a
proper package management but not on e.g. linux distributions
which can properly add correct dependencies.
(If a package manager cannot manage dependencies on correct
version ranges, it is broken.)

> I can say for certain than before I packaged it as a "binary"
> (more on this below), the user base was about 1% of what it is now.

No doubts about that: The majority of users certainly is
windows users who would not even consider installing
perl and its dependencies.

> It's strange to say that "dependency hell" isn't really solved
> by pre-compilation. It is. It really does solve it.

By replacing it by other problems.
For instance, under Unix, the unpacker uses predictable names
in world-writable directories which is a clear "don't do ever"
from a security viewpoint (symlink attacks, race conditions, etc).
Such security problems cannot be avoided if you want packaging
without using the system's means for it.
As already mentioned there are much more problems with pre-packaging
(e.g. security fixes in pre-packaged libraries would need
much too long to reach the user of a linux distribution as it
involves you as an intermediate packager).

Pre-packing is an ad-hoc solution, probably necessary for the vast
majority of windows users, but a nightmare for those who want to use
a sane safe system and not a "but it is sufficient to work" hack.
A reasonable linux distribution will only include the perl sources.
(Thus, e.g., currently users of Gentoo-based distributions cannot use
biber, because perl-5.14 is there not stable yet. However, if you do
not rely in higher versions of perl in future releases, it is of
course only a question of some time until this problem solves itself.)

> There aren't that many "gimmick" modules.

PC-Run3, IPC-Cmd, List-AllUtils, Readonly, Reaonly-XS,
Data-Dump, Data-Compare, Date-Simple, ...

with lots of implicit dependencies. E.g. IPC-Cmd pulls in
(directly or indirectly):

Module-Load, Module-CoreList, Module-LoadConditional,
Params-Check, Locale-Maketext-Simple

All in all, I had to install about 60 perl modules which
were previously not needed by other perl programs (and I have
several of those). Sure, most of them are small, but the mere
number is enormous. The main bulks are of course things like
libwww.

> We have to have Text::BibTeX as this parses .bib files.

Sure.

> We need XML libraries and modules for certain as we need a modern,
> standard data interchange format between biblatex and biber.

I am probably not the only one who believes that XML is a wrong choice
for an intercommunication format between TeX and an external program:
TeX is not natively related with XML. Moreover, biblatex and biber are
tied by their nature anyway, so a "standard" format is not important:
Why using a bloated format like XML if perl can simply parse any
format (and a more straightforward solution would actually be more
convenient and powerful)?
However, this is a different field of discussion, I do not want to
go into.

> It really is more complex that just reading some files and outputting
> a .bbl. You should look at the uniqueness code in biber (see section
> 4.5.2 and4.11.4 to get an idea of this). Again, there is nothing like
> this on the market at all - it's very complex.

Just this point would not require interaction with external libraries,
so I do not see the relevance here.
Do not confuse complexity of source code with complexity of
dependencies. It is only the latter about which I complained.

> Flexible data inheritance, on-the-fly source mapping etc.
> can't be done by an external tool as it depends on live state of the
> entry objects.

As long as "entry objects" are defined to be contained in the
local database this is all fine (and biber is only about reading
some local files and outputting others, as I stated).
Otherwise (for non-local database) what you mention is exactly
what should not be the case IMHO:
Crossreferences etc. are fine if they refer to the *local biber*
database. If they do not, it should not be the task of biber to
resolve them.

IMHO it is fine to have *additional* external programs (some, for
proprietary databases, might even be proprietary), presumably with a
documented query format, to add crossreferences to the local biber
database from various sources. Maybe one can also add a convenience
wrapper for these programs, but this wrapper should IMHO not be
biber itself: It is not necessary or even desirable to do this in one
pass (or even worse in one program).
Separating these tasks (filling the database and using the database)
separates the dependencies (onto various database/internet backends,
as mentioned, some perhaps even proprietary) and keeps the actual
biber program reliable and secure.
This is also desirable from the user's point of view: Just think
about the author's nightmare that a book actually published
contains a different bibliography than he intended, because
an online database entry was suddenly changed to contain a different
crossreference. Or even worse, if an online database gets hacked
and might then do unexpected things on your machine (in the
best case only to your references).
Summarizing, there is really no need to resolve references to
the non-local database within one pass (or one program).

> Yes, it could theoretically be written in C or lua.

I have not suggested to do this. A high-level language like perl
for a high-level task is appropriate. Even perl-5.14 if it is
really necessary. This would only be a problem if this requirement
changes to perl-5.16 in a few days when it is out and then in
a year or so to perl-5.18, ... Depending on bleeding-edge once
if it really cannot be avoided is one thing and decreases the
user-base only until the former "bleeding-edge" has become a
standard; requiring bleeding-edge permanently keeps the
user-base permanently small ;)

[Martin Vaeth]

pk <phil...@kime.org.uk> wrote:
> Yes, this introduces a security risk, just like having a web
> browser access remote web pages does.

Therefore the web browser *is* a separate tool. And because
it is such a dangerous tool it is configured by some admins
to be run only by special users with reduced privileges,
and many means are taken to secure the main data from these
special users (some use even physically different machines,
some virtual machines, some special security extensions).
Especially monographs somebody is working on for months
should not be in danger only if a remote database server
is hacked. (There should be backups anyway, but the number of
incremental backups is always limited.)

> Having to install 60 dependencies in perl (unless you are using the
> binary and then it is not an issue at all) sounds like "a lot" but
> is it?

Yes it is, because it is 60 tools by many different authors,
each one needs to be taken care for possible security updates;
there might be even malevolent authors among them. Sure, the
perl community does some job, but by such a number it is a problem.
Moreover, you have to install e.g. libwww even if you would not
want the remote access.

> It just doesn't matter - you do "Build installdeps" and wait a few
> minutes.

This is certainly not what a responsible sysadmin would do,
even less a sane linux distribution which wants to include
biber, because this would install packages behind the back
of the package manager which would lead to many problems
(e.g. recompiling some packages after an ABI-incompatible
library change cannot be done automatically, you have no
control about possibly orphant files, if other projects
change to need some of these libraries the package manager
would not know that they are installed, not to speak about
a regular check for security updates etc.)

The most reasonable solution is to build a separate package
for each dependency (for most distributions, there are
some tools which do this, but anyway these built packages
need to be checked regularly for updates and compatibility).
For gentoo, there were "only" ~10 packages not yet in the
main distribution (meanwhile some have been pushed because
of biber, so the number has decreased to 5), but given that
gentoo already includes a lot of perl projects, I guess that
this means that biber really uses a lot "exotic" ones. (Although
I do some perl programming, I am not really familiar with
most perl modules.)

> LaTeX itself is a "huge" package with thousands of dependant
> files but ... so?

This is a severe problem for which no really sane
solution has been found yet. More or less the only
thing which is done is to install practically everything
which is not feasible for a lot of systems (e.g. for
scientists like me it would be very reasonable to have
a mini-tex on a smartphone which I can also use in
foreign countries [i.e. without internet], but I have
to use ancient tex distributions for such a purpose).
It would be nice if biber not even increase this problem.

> that's what they are for and they do the job well and
> make for maintainable code.

I am also developing and know this temptation very well.
E.g. for C++, it is convenient to use boost libraries or
the new 2011 standard, but for my main project I have
refrained so far from using it, although it means I have
to program some things in duplicate for which convenient
libraries exist. The reward is that the tool is used even
on exotic systems.

> Please remember, biber is not supposed to just be a

> bibtex clone with Unicode it is supposed to be a
> custom backend for biblatex

For regular translating you need the "bibtex clone" part
(with unicode and many other features like the uniqueness
you mentioned).
If biber can do other parts as well: fine,
but why must these other parts (with a rather different purpose
and completely different prerequisites e.g. concerning
privileges to web access) be in the same "binary"?

[Simon Spiegel]

On 2012-05-15 07:22:43 +0000, Martin Vaeth said:

>
>
>> External XML/XSLT libraries are in there, yes. This is much
>> better than relying on the user having them (and the right version).
>
> This is true on incomplete systems (like windows) without a
> proper package management but not on e.g. linux distributions
> which can properly add correct dependencies.
> (If a package manager cannot manage dependencies on correct
> version ranges, it is broken.)

This is really funny. Some people here complain about lack of support
for PPC OSX machines, and then this … What's the use of pointing out
that linux distributions have better package managment if this doesn't
help anyone using another OS?

[Martin Vaeth]

Simon Spiegel <si...@removethsi.simifilm.ch> wrote:
>
> This is really funny. Some people here complain about lack of support
> for PPC OSX machines, and then this … What's the use of pointing out
> that linux distributions have better package managment if this doesn't
> help anyone using another OS?

The point is that each system needs its way of distribution of
software: If a package management is available for the system
(Linux distributions, *BSD, whatever) it should be used.
If not (like in Windows, perhaps also OSX - I have no experience
with the latter) there is almost no other way than to use
ad-hoc solutions like shipping a (possibly outdated and buggy)
copy of each used language/library/... for each little tool.
But this (necessarily) broken behavior should not dictate what
happens on systems where such a workaround is not mandatory.

Of course, if no working version of the used language (perl-5.14)
is available for OSX, there is no way to ship it at all for that
system, but reading that the perl maintainers want to make sure
that perl-5 will run everywhere, I guess this is just a question
of time until this problems solves itself...

[Simon Spiegel]

On 2012-05-15 09:41:44 +0000, Martin Vaeth said:

> Simon Spiegel <si...@removethsi.simifilm.ch> wrote:
>>
>> This is really funny. Some people here complain about lack of support
>> for PPC OSX machines, and then this … What's the use of pointing out
>> that linux distributions have better package managment if this doesn't
>> help anyone using another OS?
>
> The point is that each system needs its way of distribution of
> software: If a package management is available for the system
> (Linux distributions, *BSD, whatever) it should be used.
> If not (like in Windows, perhaps also OSX - I have no experience
> with the latter) there is almost no other way than to use
> ad-hoc solutions like shipping a (possibly outdated and buggy)
> copy of each used language/library/... for each little tool.
> But this (necessarily) broken behavior should not dictate what
> happens on systems where such a workaround is not mandatory.

I guess this is true for many parts of TL. But if it's really such a
convern, there's an easy solution: biber is OSS. Anyone is free to
bundle it in a way which fits better to UNIXens.

> Of course, if no working version of the used language (perl-5.14)
> is available for OSX,

5.14 is available for OSX. Standard version shipped by Apple is older,
but if one really wants to he can have Perl 5.14 on OSX.

[Martin Vaeth]

Simon Spiegel <si...@removethsi.simifilm.ch> wrote:
>
> I guess this is true for many parts of TL. But if it's really such a
> convern, there's an easy solution: biber is OSS. Anyone is free to
> bundle it in a way which fits better to UNIXens.

Of course, and this is what is happening. But it is the easier
and more convenient for the user the less dependencies biber has.
And these dependencies might be decreased by "decoupling" biber
into some separate tools. This was the only point of criticism
in my postings.

> 5.14 is available for OSX. Standard version shipped by Apple is older,
> but if one really wants to he can have Perl 5.14 on OSX.

Then I do not understand your complaint that you are not able
to use biber on OSX: As far as I understand, it can be installed
but just makes some work to install. And couldn't just somebody
install Perl 5.14 on his OSX system, pack it, and distribute it
for others?

[Simon Spiegel]

On 2012-05-15 15:34:24 +0000, Martin Vaeth said:

> Simon Spiegel <si...@removethsi.simifilm.ch> wrote:
>>
>> I guess this is true for many parts of TL. But if it's really such a
>> convern, there's an easy solution: biber is OSS. Anyone is free to
>> bundle it in a way which fits better to UNIXens.
>
> Of course, and this is what is happening. But it is the easier
> and more convenient for the user the less dependencies biber has.
> And these dependencies might be decreased by "decoupling" biber
> into some separate tools. This was the only point of criticism
> in my postings.
>
>> 5.14 is available for OSX. Standard version shipped by Apple is older,
>> but if one really wants to he can have Perl 5.14 on OSX.
>
> Then I do not understand your complaint that you are not able
> to use biber on OSX:

I didn't complain. Others complained in this thread that the
prepackaged biber for OSX doesn't run on PPC systems. Actually the fact
that biber requires Perl 5.14 and therefore doesn't run everywhere was
one of the main points of criticism in this very thread. That's why
your UNIX-only suggestion is particularly funny because it would
exclude even more systems..

> As far as I understand, it can be installed
> but just makes some work to install.

It's no work, it's dead easy. Thanks to the prepackaging approach
making biber work on OSX is as easy as on Unix or windows systems. And
if you don't want to wait for the prepackaged builds, you can install
ActivePerl which is free and up to date (that's what I'm doing).

> And couldn't just somebody
> install Perl 5.14 on his OSX system, pack it, and distribute it
> for others?

That is what is happening (AFAIK Phil Kime works on OSX), but I thought
you don't like that approach.

Simon

[Herbert Schulz]

In article <a1f8h6...@mid.individual.net>,

Howdy,

But the biber binary is Intel only; the universal-darwin version is
32bit Intel and there is no PPC code embedded. Doesn't that mean that if
you want to run the biber script you need also install the needed
libraries too. That might just be too daunting a task for most users.

Good Luck,
Herb Schulz

[Simon Spiegel]

That might very well be. But then again, Mac users are a minority, PPC
users are a minority among Mac users, (La)TeX users are definitely a
minority. I'd argue that the few who belong to the super minority of
PPC Mac users engaging in LaTeX are used to this kind of trouble.
Simon

[Herbert Schulz]

In article <a1fjqa...@mid.individual.net>,

Howdy,

Actually, you'd be wrong there. They have not been using biblatex with
the biber back end but rather with bibtex which brings us full circle!
:-)

Thanks again to the biblatex/biber developers for their hard work.
Especially still allowing biblatex to be used with the bibtex back end
(although with reduced functionality --- just as with previous versions
of biblatex.

Good Luck,
Herb Schulz

[Simon Spiegel]

On 2012-05-15 18:31:34 +0000, Herbert Schulz said:

> In article <a1fjqa...@mid.individual.net>,
> Simon Spiegel <si...@remove.simifilm.ch> wrote:
>
>> On 2012-05-15 17:32:20 +0000, Herbert Schulz said:
>>
>>> In article <a1f8h6...@mid.individual.net>,
>>> Simon Spiegel <si...@removethsi.simifilm.ch> wrote:
>>>
>>>> On 2012-05-15 09:41:44 +0000, Martin Vaeth said:
>>>>
>>>>> Simon Spiegel <si...@removethsi.simifilm.ch> wrote:
>>>>>>
>>>>>> This is really funny. Some people here complain about lack of support

>>>>>> for PPC OSX machines, and then this … What's the use of pointing out

You know all of them? Well, given the number of people who actually use
PPC Macs these days, this might actually be true …. ;)

Simon

[Herbert Schulz]

In article <a1fm9i...@mid.individual.net>,

Simon Spiegel <si...@remove.simifilm.ch> wrote:

> On 2012-05-15 18:31:34 +0000, Herbert Schulz said:
>
> > In article <a1fjqa...@mid.individual.net>,
> > Simon Spiegel <si...@remove.simifilm.ch> wrote:
> >
> >> On 2012-05-15 17:32:20 +0000, Herbert Schulz said:
> >>
> >>> In article <a1f8h6...@mid.individual.net>,
> >>> Simon Spiegel <si...@removethsi.simifilm.ch> wrote:
> >>>
> >>>> On 2012-05-15 09:41:44 +0000, Martin Vaeth said:
> >>>>
> >>>>> Simon Spiegel <si...@removethsi.simifilm.ch> wrote:
> >>>>>>
> >>>>>> This is really funny. Some people here complain about lack of support

> >>>>>> for PPC OSX machines, and then this â?¦ What's the use of pointing out

Howdy,

It is pretty clear that all of the users of PPC Macs who use biblatex
MUST use bibtex. I know of no-one on the Mac OS X TeX list that has
gone through the process of obtaining Perl 5.14 + all the necessary
additional libraries + create symlinks to the biber script (the biber
binary won't run on PPC Macs). I certainly know that many institutions
are still using PPC Macs and, given economic constraints, will continue
to use them until they are completely dead.

Good Luck,
Herb Schulz

[Simon Spiegel]

On 2012-05-16 12:07:25 +0000, Herbert Schulz said:

>>>>> Howdy,
>>>>>
>>>>> But the biber binary is Intel only; the universal-darwin version is
>>>>> 32bit Intel and there is no PPC code embedded. Doesn't that mean that if
>>>>> you want to run the biber script you need also install the needed
>>>>> libraries too. That might just be too daunting a task for most users.
>>>>
>>>> That might very well be. But then again, Mac users are a minority, PPC
>>>> users are a minority among Mac users, (La)TeX users are definitely a
>>>> minority. I'd argue that the few who belong to the super minority of
>>>> PPC Mac users engaging in LaTeX are used to this kind of trouble.
>>>> Simon
>>>
>>> Howdy,
>>>
>>> Actually, you'd be wrong there.
>>
>> You know all of them? Well, given the number of people who actually use
>> PPC Macs these days, this might actually be true …. ;)
>>
>> Simon
>
> Howdy,
>
> It is pretty clear that all of the users of PPC Macs who use biblatex
> MUST use bibtex. I know of no-one on the Mac OS X TeX list that has
> gone through the process of obtaining Perl 5.14 + all the necessary
> additional libraries + create symlinks to the biber script (the biber
> binary won't run on PPC Macs). I certainly know that many institutions
> are still using PPC Macs and, given economic constraints, will continue
> to use them until they are completely dead.

Why would you create a symlink? Just build biber from source and
install it in your perl path. And as for you not knowing anyone who
went through this process – you know offically do. I don't use a PPC
Mac, but this is exactly the procedure I've been following since the
first versions of biber got released. I have Perl 5.14 and all the
additional Perl libraries installed. Although I consider myself a
moderately advanced user, doing this is by no means black magic (and
when I encountered problems, Phil was extremely helpful). I knew
literarily nothing about perl when I started with biber, still it took
me little time to understand how to install additional perl modules
with cpan. It definitely is doable.

But as I already tried to indicate: biber certainly isn't the first or
last program which will give trouble to people running a PPC Mac
(according to the numbers I have – http://www.adium.im/sparkle/ and
http://update.omnigroup.com/ give quite similar results – the total of
PPC Macs is currently in the range of 3%).

Simon

[Martin Vaeth]

Simon Spiegel <si...@remove.simifilm.ch> wrote:
>
> Actually the fact
> that biber requires Perl 5.14 and therefore doesn't run everywhere was
> one of the main points of criticism in this very thread.

My main point were the required perl packages which could be
reduced/split if biber would be split. The perl version alone
is not so severe IMHO (if it remains constant).

[pk]

It's swings and roundabouts, either you leave some of the libraries to the OS package manager and then users can't upgrade/install biber because of bugs in/absence ofthe OS libraries and they don't have admin rights or knowledge how to do it, or you make biber self-sufficient so it can rely on the version of the libraries it has. In my experience, the latter option is better for users.

For example, I recently found a bug in libxml2 in the packed binary for linux which needed an upgrade to version 2.7. It was easy, upgrade it and re-package biber ... fixed. With your suggestion, I would add a Readme file that tells users to upgrade the OS libxml2 to 2.7. That's bad for users - what if they can't? They might not have admin rights, might not know how, might break some other software that requires <2.7 etc.

PK

[Lars Madsen]

That does not help users who does not have the same libc version as you
do when you build.

--

/daleif (remove RTFSIGNATURE from email address)

Memoir and mh bundle maintainer
LaTeX FAQ: http://www.tex.ac.uk/faq
LaTeX book: http://www.imf.au.dk/system/latex/bog/ (in Danish)
Remember to post minimal examples, see URL below
http://www.minimalbeispiel.de/mini-en.html

[pk]

Of course not but it's still the least bad way. It's also why I build on an old linux distro with a libc which is therefore compatible with 95% of modern linux builds.

PK

[oleksii....@gmail.com]

On Monday, May 7, 2012 3:37:15 PM UTC+3, pk wrote:
> Thanks to Joseph W, we now have a beta release of biblatex 2.0 which will not drop bibtex support. In biblatex 2.0, bibtex is frozen and deprecated, not gone. We will continue to backport relevant bugfixes to the internal bibtex codepath, however. Biber users will get all of the 2.0 new features:
>
> * Per-list sorting (\printbibliography now supports a &quot;sorting&quot; option which
> overrides the global sorting specification)
> * Completely customisable bibliography labels with several flavours of label
> auto-disambiguation
> * More fine-grained sorting control
> * A general &quot;related entries&quot; functionality to deal with the many inter-entry
> relationships like &quot;reprinted as&quot;, &quot;translated from&quot; etc.
> * A full biblatex interface to the biber sourcemap feature
> * More fine-grained control over the generation of name initials from names
> * Citation key aliases so you can reference the same entry via several keys
>
> All of these features require biber 1.0
>
> Any testing would be appreciated and bugs can be reported on github here:
>
> https://github.com/plk/biblatex
>
> The beta biblatex 2.0 can be found here:
>
> https://sourceforge.net/projects/biblatex/files/development/
>
> and the biber 1.0 beta here:
>
> https://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/development/

Hi, I'm trying to process my bibliography with biblatex2.0+biber1.0
I get the following error for the dummy document below as well as for the real one:
The.tex doument (generated by LyX2.0):

%% LyX 2.0.2 created this file. For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass{article}
\usepackage[latin9]{inputenc}
\makeatletter
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
\usepackage{biblatex}
\makeatother
\usepackage[english]{babel}
\begin{document}
\end{document}

The error I get (from the latex log):

...
Package biblatex Info: Trying to load biblatex default data model...
Package biblatex Info: ... file 'blx-dm.def' found.
(/usr/share/texmf/tex/latex/biblatex/blx-dm.def)
! Extra \fi.
<argument> ...expandafter ,\CurrentOption }}}}\fi

l.4750 \ProcessLocalKeyvalOptions{blx@opt@eldt}

I'm ignoring this; it doesn't match any \if.

Package biblatex Info: Trying to load biblatex style data model...
Package biblatex Info: ... file '.dbx' not found.
Package biblatex Info: Trying to load biblatex custom data model...
Package biblatex Info: ... file 'biblatex-dm.cfg' not found.
\c@afterword=\count131
\c@savedafterword=\count132
...

I am using pdflatex. Tried different vesions of biblatex. This error occurs only for the v.2.0

What could be the issue?

Thanks!

[jon]

On Saturday, 14 July 2012 14:37:55 UTC-4, (unknown) wrote:
> %% LyX 2.0.2 created this file. For more info, see http://www.lyx.org/.
> %% Do not edit unless you really know what you are doing.
> \documentclass{article}
> \usepackage[latin9]{inputenc}
> \makeatletter
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
> \usepackage{biblatex}
> \makeatother
> \usepackage[english]{babel}
> \begin{document}
> \end{document}

i haven't switched to 2.0 yet, and i've never used lyx, but this file is weird:

* load babel before biblatex (and also load csquotes between the two);

* it looks like lyx added '\makeatletter' and you added '\makeatother', which would be surprising (it is also completely unnecessary unless lyx does some magic that you cut out)

(these changes will not fix your problem.)

cheers,
jon.

[pk]

On Saturday, 14 July 2012 20:37:55 UTC+2, (unknown) wrote:

> What could be the issue?

This looks Lyx specific - v2.0 has a new file in it (the default data model blx-dm.def) and perhaps Lyx needs to know about this? Or perhaps you need to run texhash to make your TeX system know where blx-dm.def is?

[pluton]

It looks to me that this biblatex v2 broke the biblatex-chicago package. Is there another way than using backend=bibtex to switch back to v1.7?

[Robin Fairbairns]

speaking as a non-biblatex-user, i've noticed that several of the
published styles have been updated recently.

i don't know the author (david fussner), but mail to him might not go
amiss.
--
Robin Fairbairns, Cambridge
sorry about all this posting. i'll go back to sleep in a bit.