From: Hans Hagen <pragma@wxs.nl>
To: Norbert Preining <preining@logic.at>
Cc: dev-context@ntg.nl, ntg-context@ntg.nl
Subject: Re: integrating context mkiv, luatex, and fmtutil, mktexlsr, etc
Date: Wed, 03 Oct 2007 15:06:43 +0200 [thread overview]
Message-ID: <470393E3.1010803@wxs.nl> (raw)
In-Reply-To: <20071003122106.GA3597@gamma.logic.tuwien.ac.at>
Norbert Preining wrote:
> On Mi, 03 Okt 2007, Hans Hagen wrote:
>> formats go to the paths defined in texmf.cnf (TEXFORMATS) and the
>> filedatabses go alongside the ls-R files, so basically it then behaves
>> like any other tex
>
> ??? "file databases go alongside the ls-R files" what do you mean? I
> thought the stuff generated by luatools is something like the ls-R
> database for luatex. But it is placed NOT alongside the ls-R files,
> right?
well, "TEXMFSHARECACHE=yes" makes sure that it is put in the same path
as the ls-r file
>> the cache path is only used and populated at runtime, so
>
> So every time I run a luatex/context document it has to read ALL the
> trees again??? Cannot be, that was the whole point of ls-R/cache. It
> should be generated once (the cache).
no, not the trees, but if one uses a font, say lmroman10-regular.otf,
then the 'converterd/prepared/whatever' datatable is cached so only that
file ends up in the cache (flat structure, so, when one needs
lmroman10-regular.otf, i first look in the cache (no database needed)
for a tmc/a file, if not present i generate one, using the otf file from
the normal tree, looked up in a kpse like way)
>> LUATEXCACHE=$TEXMFVAR/luacache:...
>> TEXMFSHARECACHE=yes
>>
>> should be ok then; if needed, later i can look into a way to share other
>> cache stuff (say that you generate tmc files for 300 fonts at
>> installation time) but if i understoof right, the main reason was
>> formats and file databases
>
> Yes, currently the main reason is for ls-R replacement and format
> location. But font data could be useful, too. My system has quite a lot
> of fonts ...
sure, but that demands some deep thinking because currently i use
version numbers in the cached data and i don't want to open all cached
files with the same name in order to check
>
>
> On Mi, 03 Okt 2007, Hans Hagen wrote:
>> texexec --make --luatex en
> [...]
>> this depends on the value of TEXFORMATS nd what path is first writable
>
> Hmm,
> $ export TEXFORMATS=/home/norbert/.texmf-var/web2c
> $ texexec --make --luatex en
> ....
> TeXExec | using tex engine luatex
> TeXExec | using tex format path /home/norbert/.texmf-var/web2c/luatex
> TeXExec | generating tex format cont-en
> ....
> Transcript written on cont-en.log.
i know -) texexec only looks there and reports what it finds; texexec
itself is unaware of lua and caches and ... i need to fix that
> LuaTools |
> LuaTools | runtime: 0.18 seconds
> TeXExec | no lua compilations needed
> TeXExec |
> TeXExec | tex engine path: /home/norbert/.texmf-var/web2c/luatex
> TeXExec |
> TeXExec |
> TeXExec | runtime: 9.486118
> $ ls ~/.texmf-var/web2c/luatex
> $ ls -l ~/luatex-cache/context/f7d1b3c25487ab1e1035aff1c53b90da/formats/
> -rw-r--r-- 1 norbert norbert 5669003 2007-10-03 14:07 cont-en.fmt
> -rw-r--r-- 1 norbert norbert 38786 2007-10-03 14:07 cont-en.log
> -rw-r--r-- 1 norbert norbert 159484 2007-10-03 14:07 cont-en.lua
> -rw-r--r-- 1 norbert norbert 112438 2007-10-03 14:07 cont-en.luc
> $
>
> So the format is placed in some strange ;-) place under luatex-cache.
hm, also with the new version and the env var set? here it nicely goes
to texmf-linux/web2c/luatex
btw, the 'strange' is just an md2 of the tree
> To sum it up: It is a bit unclear what purpose the cache is used for:
> - ls-R replacement, ie some sort of file database
indeed, more flexible, faster etc, and in the future we can use it for more
> - preprocessed font data cache so that loading the stuff is done faster
indeed, only at runtime, so normally in the users path someplace
> - formats??? what is saved for this
a cont-en.fmt as well as a cont-en.luc file, the format and it sstub
> But all of this is somehow static. On a normal system a normal user
> shouldn't have the necessity to change anything of the above. That
> should be done at install time of the respective stuff.
no, the font cache is not pregenerated at all, think of it like this:
- luatex loads otf font (takes time)
- provides it as table to mkiv (takes more time)
- mkiv adds a few things, preprocesses the font a bit
- then saves it as table (compiled) so that loading goes in an eyeblink
> Furthermore, the cache could be used (no idea whether this is true) for:
> - single job caching of data
> wouldn't it be better to keep generated files like this in the
> cwd, like .aux, etc files
we're talking of megabytes here
btw, context has no aux, toc etc file but a tuo file where all multi
pass data goes into; in mkiv there is a lua companion because much of
that data is not stored in lua tables (i still have to do the table of
contents)
> What was the reason to do the hashing somewhere else but add the md5sums
> etc for these trees?
lengths of paths and such; i run luatex on the unix web/etc servers and
have multiple trees in parallel, so now i can with one variable changed
access all data;
/temp/luatex/context/<treeroot>/whatever
/temp/luatex/context/c:/blabla/tex/blabla/whatever
does not work that well, so i hash the treeroot
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
| www.pragma-pod.nl
-----------------------------------------------------------------
next prev parent reply other threads:[~2007-10-03 13:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071003110634.GA29863@gamma.logic.tuwien.ac.at>
[not found] ` <47037E8C.7080907@wxs.nl>
2007-10-02 13:55 ` Call for test documents Norbert Preining
2007-10-02 14:48 ` [dev-context] " Hans Hagen
2007-10-03 11:15 ` Norbert Preining
2007-10-03 11:21 ` [dev-context] " Hans Hagen
[not found] ` <20071003074824.GW9324@gamma.logic.tuwien.ac.at>
[not found] ` <47037739.208@wxs.nl>
[not found] ` <20071003111038.GB29863@gamma.logic.tuwien.ac.at>
[not found] ` <47037AF1.4020104@wxs.nl>
2007-10-03 12:21 ` integrating context mkiv, luatex, and fmtutil, mktexlsr, etc Norbert Preining
2007-10-03 13:06 ` Hans Hagen [this message]
2007-10-03 13:18 ` [dev-context] " Norbert Preining
2007-10-03 13:28 ` Hans Hagen
2007-10-03 11:31 ` [NTG-context] Call for test documents Taco Hoekwater
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=470393E3.1010803@wxs.nl \
--to=pragma@wxs.nl \
--cc=dev-context@ntg.nl \
--cc=ntg-context@ntg.nl \
--cc=preining@logic.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).