<br><br><div class="gmail_quote">On Thu, Jun 12, 2008 at 7:59 AM, Karl Berry <<a href="mailto:karl@freefriends.org">karl@freefriends.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"> What about bibtex? Wouldn't the same problem persist there?<br>
<br>
</div>I don't know what "problem" you mean, but yes, our implementation of<br>
bibtex uses kpathsea (as you know), and so all the same stuff applies.<br>
<div class="Ih2E3d"><br>
bibtex-like functionality should be pretty much be workable directly<br>
through luatex now<br>
<br>
</div>I don't understand. BibTeX has its own job to do. Sure, I guess you<br>
could reprogram it in Lua, but I don't see the point.<br>
<br>
BTW, there is an experimental package which does *all* formatting of bib<br>
entries using LaTeX, and just uses bibtex for sorting.<br>
<a href="http://www.ctan.org/tex-archive/help/Catalogue/entries/biblatex.html" target="_blank">http://www.ctan.org/tex-archive/help/Catalogue/entries/biblatex.html</a><br>
<div class="Ih2E3d"></div></blockquote><div><br>Yes, I did the Danish and Norwegian translations for that package. It was that or amsref which I figured combined with Lua's new indexing/sorting functions should be able to work completely without bibtex.<br>
<br> The point would be to avoid having to run several programs at all. And, as it seems you try to point out, it doesn't really work to work on luatools instead of kpathsea, if luatools only works for one of several programs that need to be used.<br>
<br>However, if there are no plans to fix bibtex, then clearly it will never work to write a luascript rather than a hack to kpathsea.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
But these files are searched according to different path-values, right?<br>
<br>
</div>Sure.<br>
<div class="Ih2E3d"></div></blockquote><div><br>Ok, then that wouldn't be an issue, I would think.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
Are filesystem lookups that much faster than database-lookups?<br>
<br>
</div>It's never been compared, that I know of. I don't think you can make<br>
any general statements about it. It probably depends on many factors,<br>
like the size of the caches on the hard disk, the speed of the cpu for<br>
the database, how the database is indexed, etc., etc.<br>
<div class="Ih2E3d"></div></blockquote><div><br>No, that's why I wondered why it should be such a problem to make 200 db lookups, if it's currently doing the same amount of filesytem lookups. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
Am I completely off here?<br>
<br>
</div>Is this all about speed? I wouldn't expect any huge speed gains from<br>
using an sql database.</blockquote><div><br>Well, that is one of the reasosn why websites generally work on databases rather than files on the harddisk. But more so it's about keeping different user accounts seperated from oneanother, and to keep diskwriting operations donw to a bare minimum. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
These are textbased databases, as far as what I get. Are<br>
lookup times in them faster than in a mysql-base?<br>
<br>
</div>Again, I don't know, but I highly doubt it's significant. All kpse does<br>
is read ls-R (a relatively small text file) into a hash table. It's<br>
hard to imagine mysql being much faster than that. If there were<br>
millions of entries, it would be a different story, but thankfully<br>
there's not.<br>
<div class="Ih2E3d"><br>
What do you mean? just redefine \input{XX} and \include{XX} ?<br>
<br>
</div>No, nothing at the TeX level, that would be completely unworkable. I<br>
meant a shell script that does the sql commands to extract the input<br>
file. I thought you were aiming to create a specific application that<br>
needed reports formatted with TeX.</blockquote><div><br>Yes, it's a editor which stores the documents in a database. Check out <a href="http://www.latexlab.org">http://www.latexlab.org</a> . When someone clicks the button to make a pdf-file, it somehow needs to do that. <br>
</div><div><br>Extracting one file wouldn't be much of a problem, but what about all the potentially included files? One would either need to simply check out all files a user has before compiling, because all of them might be included, or intercept latex at the level of accessing the files -- the approach I've presented here with hacking kpathsea.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
But now it seems you want to replace TeX file lookups, in general.<br>
About all I can do is wish you luck.<br>
</blockquote><div><br>It is fairly straighforward just to pipe an individual latex-document. For that no disk writing operations would ever be needed, and no fixes to anything would need to be applied. The only time this could ever becoe an issue is when files are included. As I understand it from your comments, the onyl way to solve that is to hack kpathsea, at least unless there are plans to rewrite bibtex.<br>
<br><br>Thank you very much for your comments though! And please feel free to comment further if there is more information that is relevant to this task.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
until luatex becomes usable --<br>
<br>
LuaTeX is usable. Not stable/frozen, but usable.<br> <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888"><br>
karl<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Johannes Wilm<br><a href="http://www.johanneswilm.org">http://www.johanneswilm.org</a><br>tel: +5059173717<br>