Re: xtl, LyX and a small patch

[Jose Orlando Pereira <jop@di.uminho.pt>]

Allan Rae wrote:
> I ran into a very annoying documentation bug when I first started using
> xtl.  A vitally important line was missing in the code samples that had me
> very frustrated.  The patch fixes the code samples.
> 
> It also adds a \usepackage{pslatex} so that the pdf file uses the standard
> postscript fonts and is therefore readable in xpdf.  It also looks a lot
> neater in acroread and gv also.  LaTeX also gets called an extra time so
> that the citations are all correctly updated.
> 
> A couple of other small fixes to makefiles (mainly adding "./" to a few
> test programs).

Thanks. These are applied in 1.3.pl.2 soon to be sent to this list.
 
> Has anyone started or in anyone planning an automem_buffer<> that would do
> it's own memory management?  Resizing as needed rather than having a
> separate "char buf[some_size_that_might_not_be_big_enough];".
> 
> Such a buffer would simplify the use of xtl in LyX where we'll be using
> mem_buffers all the time for the gui independence work.

Doing a buffer based on an POSIX iovec is in my plans. It would easily
be adapted to grow as necessary by adding more memory chunks. Howvever,
this is not high on my priority list and nobody *else* (hint;-) has
volunteered.
 
> Additionally, I want to pass a memory buffer as a char *.  That way we can
> use the same function to handle inputs from scripts and other external
> applications.  It seems I should be able to externalize the
> mem_buffer<raw_format> variable to get a buffer I can recreate at the
> other end when it's internalized.  This however complicates the work that
> script writers would have to do since they don't have the benefit of xtl.
> I was thinking of just directly modifying the buf[] before passing it as a
> parameter to our function-dispatcher but this is ugly and format
> dependent.
> 
> Instead, I was considering making an automem_buffer<>::c_str() function
> that would prepend the buffer size to the buffer and return it as a char*.
> This is potentially leaky but then so is using an ordinary mem_buffer<> in
> this way (passing a char* as an arguement).

I dont't know if I completely understood you. The mem_buffer is not supposed
to be an encapsulated data container. It is designed as an adapter between XTL 
and a char*. After outputing some data using a mem_buffer you're supposed to
directly use the char* you have previously supplied. At the other end, just
create a new mem_buffer with the same data and the size obtained from the
first mem_buffer. mem_buffers are not intended to be reused and the space
is assumed to be managed elsewhere.

If you see automem_buffer as an encapsulated container it makes perfect
sense to have something like automem_buffer<>::c_str(). Even if 
automem_buffer is not encapsulated but a smart adapter to an iovec,
it would also be nice to provide a simple way to flatten it.

-- 
Jose Orlando Pereira
* mailto:jop@di.uminho.pt * http://gsd.di.uminho.pt/~jop *