More bibliography trouble... biber 0.8.3 compiled fine, since the
update to 0.8.4 I get:

INFO - This is biber 0.8.4
INFO - Logfile is 'MyBiberTrial.blg'
INFO - Reading MyBiberTrial.bcf
INFO - Found 3 citekeys in bib section 0
INFO - Processing bib section 0
FATAL - Error loading data source package
'Biber::Input::file::bibtex': data source /var/folders/ss/ssnW
+e7pGCOApKgwLd8Bp++++TI/-Tmp-/par-wolpert/
cache-6d4fc377d8e622910a97d9bdbe1f1b5537ebe5f2/inc/lib/Biber/Input/
file/bibtex.dcf not found in .
Compilation failed in require at (eval 80) line 2.

and no citations or bibliography, of course.

System info: OSX 10.6.6 TeXLive 2010, updated this morning with tlmgr
from UK repository.

(It compiles when switching to bibtex8 -W, although the warning

Package biblatex Warning: Data encoding is 'utf8'.
(biblatex)                Use backend=biber.

may be not useful, since biber 0.8.4 fails. So, for biblatex, please
do not drop bibtex support as a fall-back.)

On 2011-03-23 00:23 +0800, Rembrandt Wolpert wrote:
> FATAL - Error loading data source package
> 'Biber::Input::file::bibtex': data source /var/folders/ss/ssnW
> +e7pGCOApKgwLd8Bp++++TI/-Tmp-/par-wolpert/
> cache-6d4fc377d8e622910a97d9bdbe1f1b5537ebe5f2/inc/lib/Biber/Input/
> file/bibtex.dcf not found in .
> Compilation failed in require at (eval 80) line 2.

Could you try deleting that par-wolpert directory? Biber seems to cache
there and it has caused trouble for me in the past.

Leo

On Mar 22, 7:51=A0pm, Leo <sdl....@gmail.com> wrote:
> On 2011-03-23 00:23 +0800, Rembrandt Wolpert wrote:
>
> > FATAL - Error loading data source package
> > 'Biber::Input::file::bibtex': data source /var/folders/ss/ssnW
> > +e7pGCOApKgwLd8Bp++++TI/-Tmp-/par-wolpert/
> > cache-6d4fc377d8e622910a97d9bdbe1f1b5537ebe5f2/inc/lib/Biber/Input/
> > file/bibtex.dcf not found in .
> > Compilation failed in require at (eval 80) line 2.
>
> Could you try deleting that par-wolpert directory? Biber seems to cache
> there and it has caused trouble for me in the past.
>
> Leo

Thanks a lot, that worked. I'll keep a troubled eye on that directory
in the future.

Rembrandt

On Mar 23, 4:09=A0am, Rembrandt Wolpert <wu.ren...@gmail.com> wrote:

> Thanks a lot, that worked. I'll keep a troubled eye on that directory
> in the future.

This is mentioned in the biber manual - on first run of a new biber
version install, you have to be careful not to interrupt the execution
as it unpacks to the cache dir on first run. If something interferes
with this unpacking, you will get problems like this. It's easy to
fix, as mentioned, just delete the cache and run biber again. This is
the price we pay for having a convenient binary for something which is
a perl program underneath.

On Mar 26, 3:10=A0pm, PK <Phi...@kime.org.uk> wrote:
> On Mar 23, 4:09=A0am, Rembrandt Wolpert <wu.ren...@gmail.com> wrote:
>
> > Thanks a lot, that worked. I'll keep a troubled eye on that directory
> > in the future.
>
> This is mentioned in the biber manual - on first run of a new biber
> version install, you have to be careful not to interrupt the execution
> as it unpacks to the cache dir on first run. If something interferes
> with this unpacking, you will get problems like this. It's easy to
> fix, as mentioned, just delete the cache and run biber again. This is
> the price we pay for having a convenient binary for something which is
> a perl program underneath.

Thanks for the explanation. Well, it was unpacked by tlmgr, and other
things followed from tlmgr, so the interruption my be coming from the
installation mechanism? The binary is very useful -- so thanks for
that (and of course the working biber :-)).

Rembrandt

Actually, tlmgr shouldn't have unpacked it - what unpacks it is
running biber for the first time. This always takes a little longer
than subsequent runs due to the unpacking and I've seen some people
become impatient, assume something is wrong and Ctrl-C/kill it. This
can result in a partially unpacked, that is broken, biber. Deleting
the cache and just running it without arguments to see the help
messages will unpack it and run it. After that, it will be as fast as
a normal perl program (don't laugh ... it's quite fast for what it's
doing as the bulk of the difficult stuff like Unicode sorting is done
by compiled C modules ...)

PK

On Mar 26, 10:30=A0pm, Rembrandt Wolpert <wu.ren...@gmail.com> wrote:

> Thanks for the explanation. Well, it was unpacked by tlmgr, and other
> things followed from tlmgr, so the interruption my be coming from the
> installation mechanism? The binary is very useful -- so thanks for
> that (and of course the workingbiber:-)).

Le lundi 28/03/11 =E0 11h25,
PK <Philip@kime.org.uk> a =E9crit :

> Deleting the cache and just running it without arguments to see the
> help messages will unpack it and run it.

Wouldn't it be possible that tlmgr silently does this job just after
biber install/update?
--=20
Denis

On Mar 28, 9:56=A0pm, Denis Bitouz=E9 <dbitouze...@spam.wanadoo.fr> wrote:
> Le lundi 28/03/11 =E0 11h25,
> PK <Phi...@kime.org.uk> a =E9crit :
>
> > Deleting the cache and just running it without arguments to see the
> > help messages will unpack it and run it.
>
> Wouldn't it be possible that tlmgr silently does this job just after
> biber install/update?
> --
> Denis

Hmm, it would be nice but you'd need to check with the TL maintainers
about this. One potential issue is that I think TL often tries to run
as a "nobody" user. You really need it run a biber first run as the
real user to avoid permissions problems.

On Mar 28, 1:25=A0pm, PK <Phi...@kime.org.uk> wrote:
> Actually, tlmgr shouldn't have unpacked it - what unpacks it is
> running biber for the first time. This always takes a little longer
> than subsequent runs due to the unpacking and I've seen some people
> become impatient, assume something is wrong and Ctrl-C/kill it. This
> can result in a partially unpacked, that is broken, biber. Deleting
> the cache and just running it without arguments to see the help
> messages will unpack it and run it. After that, it will be as fast as
> a normal perl program (don't laugh ... it's quite fast for what it's
> doing as the bulk of the difficult stuff like Unicode sorting is done
> by compiled C modules ...)
>
> PK
>
> On Mar 26, 10:30=A0pm, Rembrandt Wolpert <wu.ren...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Thanks for the explanation. Well, it was unpacked by tlmgr, and other
> > things followed from tlmgr, so the interruption my be coming from the
> > installation mechanism? The binary is very useful -- so thanks for
> > that (and of course the workingbiber:-)).

The trouble then is to run (Xe)LaTeX via a makefile (i.e., "real" make
that runs non-LaTeX programs which are needed in the project as well
as LaTeX) on a project when biber hasn't established itself?

/rfw