integrating context mkiv, luatex, and fmtutil, mktexlsr, etc
Hi Hans, Taco, all!
I am starting to think about integrating context/mkiv/luatex into TeX
Live (and use as a test bed the Debian packages). Currently I see the
following problems:
- integration into fmtutil:
currently we build formats for cont-en/xetex, cont-en/pdftex, etc
based on the fmtutil.cnf syntax, ie calling something like
$ENGINE -ini -jobname=cont-en -progname=context -8bit *cont-en.ini
Now putting luatex as engine this doesn't work:
(/usr/share/texmf/tex/context/base/luat-env.tex
! LuaTeX error [string "luas[0]"]:1: attempt to index global 'input' (a nil value).
<argument> ...mf.instance,"luat-env.lua","tex")) }
- integration into mktexlsr
see my other email about multiple cache merging, but to some up:
. cache should be read from more then one directory, eg from
TEXMFSYSCACHE and TEXMFCACHE (with usual override stuff)
. single cache updates should be possible:
luatools --generate $HOME/texmf
should generate the cache for $HOME/texmf in $TEXMFCACHE
Other things I realized as user:
- running texexec --lua test.tex generates the format in
~/luatex-cache/context/e027248d6557d124c703335e8a95ecd5/formats
but it creates it again and again.
- If I move the generated files from the above dir to
~/.texmf-var/web2c/luatex/
and regenerate the luatex-cache with --generate --verbose the next run
does not work:
LuaTools | using format name /home/norbert/luatex-cache/context/e027248d6557d124c703335e8a95ecd5/formats/cont-en.fmt
LuaTools | no luc/lua with name /home/norbert/luatex-cache/context/e027248d6557d124c703335e8a95ecd5/formats/cont-en
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Norbert Preining wrote:
I am starting to think about integrating context/mkiv/luatex into TeX Live (and use as a test bed the Debian packages). Currently I see the following problems: - integration into fmtutil: currently we build formats for cont-en/xetex, cont-en/pdftex, etc based on the fmtutil.cnf syntax, ie calling something like $ENGINE -ini -jobname=cont-en -progname=context -8bit *cont-en.ini Now putting luatex as engine this doesn't work: (/usr/share/texmf/tex/context/base/luat-env.tex ! LuaTeX error [string "luas[0]"]:1: attempt to index global 'input' (a nil value). <argument> ...mf.instance,"luat-env.lua","tex")) }
that won't work because luatex by itself cannot take care of the stubs it may need for starting up (how could it know -) making a format (at least formkiv, but also for plain if you want) boils down to: - making a lua stub file (lua) - compiling that for fast loading (luc) - making a format the stub is needed because the first thing that we do is to overload kpse (and provide support for reading from zips etc); the stub is later overloaded by embedded code if needed; luatools takes care of making the stub, compiling it etc etc $ENGINE --luaonly luatools.lua --make --compile cont-en $ENGINE --luaonly luatools.lua --make --compile plain
- integration into mktexlsr see my other email about multiple cache merging, but to some up: . cache should be read from more then one directory, eg from TEXMFSYSCACHE and TEXMFCACHE (with usual override stuff) . single cache updates should be possible: luatools --generate $HOME/texmf
i'll see what i can do
should generate the cache for $HOME/texmf in $TEXMFCACHE
what exactly do you mean with integration? calling luatools?
Other things I realized as user: - running texexec --lua test.tex generates the format in ~/luatex-cache/context/e027248d6557d124c703335e8a95ecd5/formats but it creates it again and again.
strange, since texexec --lua is not supposed to generate a format at all
- If I move the generated files from the above dir to ~/.texmf-var/web2c/luatex/ and regenerate the luatex-cache with --generate --verbose the next run does not work:
(i wonder what i do with the . in .texmf-var -) the cache is not hashed (no reason for doing it)
LuaTools | using format name /home/norbert/luatex-cache/context/e027248d6557d124c703335e8a95ecd5/formats/cont-en.fmt LuaTools | no luc/lua with name /home/norbert/luatex-cache/context/e027248d6557d124c703335e8a95ecd5/formats/cont-en
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 -----------------------------------------------------------------
Hi Hans, hi all, On Mi, 03 Okt 2007, Hans Hagen wrote:
$ENGINE -ini -jobname=cont-en -progname=context -8bit *cont-en.ini [...]
Norbert Preining wrote: that won't work because luatex by itself cannot take care of the stubs it may need for starting up (how could it know -)
making a format (at least formkiv, but also for plain if you want) boils down to:
- making a lua stub file (lua) - compiling that for fast loading (luc) - making a format
Ok, that said we have to adjust the fmtutil script. Currently the information stored in the fmtutil.cnf file is $format $engine $sometestfile $restofcmdlineoptions These lines normally trigger a call to $engine -ini -jobname=$format -progname=context $cmdline (the progname is already a special case AFAIR). Now for combinations of cont-?? $engine ... we could switch to calling texexec --engine $engine --make ?? Is this right? But this doesn't work with luatex: texexec --engine luatex --make en still runs luatex. (Strange btw, isn't it?) So, what is the *recommended* way to generate context formats for the following engines: pdftex: ini, texexec xetex: ini, texexec aleph: ini, texexec luatex: ??? (ini: calling $engine -ini ..., texexec: calling texexec --engine $engine --make ??)
$ENGINE --luaonly luatools.lua --make --compile cont-en $ENGINE --luaonly luatools.lua --make --compile plain
Ok, so one could call luatools --make --compile cont-en ??? For all those texexec/luatools creating of formats there is another problem: The formats are placed in quite arbitrary locations. TEXMFVAR should be the right place, but this is not honoured (in my case texexec did put it into TEXMFHOME!). Or at least it should be *fixed* to which tree the format will be written. Then there is the problem that luatools --make does not work without any cache, well, see below.
- integration into mktexlsr see my other email about multiple cache merging, but to some up: . cache should be read from more then one directory, eg from TEXMFSYSCACHE and TEXMFCACHE (with usual override stuff) . single cache updates should be possible: luatools --generate $HOME/texmf
i'll see what i can do
should generate the cache for $HOME/texmf in $TEXMFCACHE
what exactly do you mean with integration? calling luatools?
Well, the idea is that if someone calls mktexlsr $tree and luatex/context is installed, the luatex cache is also updated. The idea is that we just plug in some code that is only executed if context and luatex is installed, that updates the cache. Take for example Debian: One can install texlive packages, plus independent context and luatex packages. But all the add-on packages for fonts etc only call mktexlsr. We will have a hard time forcing them to add some magic that in case of the presence of luatex/context also the cache (for system files) is updated. My idea is to have something mktexlsr.d/ directory where packages can drop scripts (same would work also in TeX Live) and mktexlsr at the end of the run calls these scripts. So if luatex drops something, and context drops something, we could organize that not only the mktexlsr db, but also the luatex cache is up2date.
Other things I realized as user: - running texexec --lua test.tex generates the format in ~/luatex-cache/context/e027248d6557d124c703335e8a95ecd5/formats but it creates it again and again.
strange, since texexec --lua is not supposed to generate a format at all
Maybe I missed something ...
- If I move the generated files from the above dir to ~/.texmf-var/web2c/luatex/ and regenerate the luatex-cache with --generate --verbose the next run does not work:
(i wonder what i do with the . in .texmf-var -)
Aehmmm, but the luatex cache will quite sure be set to something with a
dot, at least the local one ;-)
---------------------
I think it is time to discuss all this problems now, otherwise inclusion
into TeX Live upstream and Debian will make problems. Ok, I can just
ship the stuff and don't produce and cache/formats whatsoever for MkIV,
MkII still works quite well. But I guess it would be nice to sort this
out in a good way for all parties.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Norbert Preining wrote:
Now for combinations of cont-?? $engine ... we could switch to calling texexec --engine $engine --make ?? Is this right?
But this doesn't work with luatex: texexec --engine luatex --make en still runs luatex. (Strange btw, isn't it?)
texexec --make --luatex en as usual, format generating programs have to mess around with the resulting format file (texexec goes to the format path) you can use luatools --make --compile cont-en instead but then you need to move the format and associated luc file to the right place (i dunno if fmtutil does that)
So, what is the *recommended* way to generate context formats for the following engines: pdftex: ini, texexec xetex: ini, texexec aleph: ini, texexec luatex: ??? (ini: calling $engine -ini ..., texexec: calling texexec --engine $engine --make ??)
just --make --xetex|pdftex|luatex should work
$ENGINE --luaonly luatools.lua --make --compile cont-en $ENGINE --luaonly luatools.lua --make --compile plain
Ok, so one could call
luatools --make --compile cont-en
???
sure, this is what texexec does -) luatools is a subset of the lua files in context/base, merged into one file, and with some extra functionality like playing kpsewhich (but a bit more, like "luatools --pattern=lmr10*" and such, and mtxrun is a closely related thing that we will use to run scripts that like the preloaded libs in luatex as well as file searching, think of mtxrun --script cache --purge mtxrun --script babel --language=greek structure=context babelcoded.tex etc
For all those texexec/luatools creating of formats there is another problem: The formats are placed in quite arbitrary locations. TEXMFVAR should be the right place, but this is not honoured (in my case texexec did put it into TEXMFHOME!). Or at least it should be *fixed* to which tree the format will be written.
this depends on the value of TEXFORMATS nd what path is first writable (if i did things right but maybe taco can check that since he's on linux); i always have a texformats var set -)
Then there is the problem that luatools --make does not work without any cache, well, see below.
- integration into mktexlsr see my other email about multiple cache merging, but to some up: . cache should be read from more then one directory, eg from TEXMFSYSCACHE and TEXMFCACHE (with usual override stuff) . single cache updates should be possible: luatools --generate $HOME/texmf i'll see what i can do
should generate the cache for $HOME/texmf in $TEXMFCACHE what exactly do you mean with integration? calling luatools?
Well, the idea is that if someone calls mktexlsr $tree and luatex/context is installed, the luatex cache is also updated. The idea is that we just plug in some code that is only executed if context and luatex is installed, that updates the cache.
i can add that option
Aehmmm, but the luatex cache will quite sure be set to something with a dot, at least the local one ;-)
yeah ... i've seen those dotted files in linux installations (just as Desktop and other macish/windowish paths, so i wonder when we wil have a Progam Files -); anyhow, it should work and probably works; sometimes i do some . and .. checks to make sure that no one misuses this to get to paths they're not supposed to visit) btw, reminds me ... is this becoming a cross distribution linux convention (was already so on the mac) ... no longer root users, but always a sudu needed?
I think it is time to discuss all this problems now, otherwise inclusion into TeX Live upstream and Debian will make problems. Ok, I can just ship the stuff and don't produce and cache/formats whatsoever for MkIV, MkII still works quite well. But I guess it would be nice to sort this out in a good way for all parties.
sure, and i appreciate your efforts and testing -) 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 -----------------------------------------------------------------
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?
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).
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 ... 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. 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.
btw, reminds me ... is this becoming a cross distribution linux convention (was already so on the mac) ... no longer root users, but always a sudu needed?
No, Debian does not install sudo at all per default. There is a real
root user.
-------------
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
- preprocessed font data cache so that loading the stuff is done faster
- formats??? what is saved for this
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.
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
- caching of user files
like the above, but initiated by the user
Again, I don't see any other use than these ones, but please enlighten
me what else it is used for. But in this case some mktexlsr-ish approach
would make sense.
So suggestion, like any TEXMF tree contains a ls-R file, we could have
for any TEXMFTREE a lcache/ directory $tree/lcache/ which contains the
cache for this tree.
Since luatools and other things extract the texmf trees anyway from the
TEXMFCNF variable, the cache could be read from there.
What was the reason to do the hashing somewhere else but add the md5sums
etc for these trees?
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
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 -----------------------------------------------------------------
HI Hans! On Mi, 03 Okt 2007, Hans Hagen wrote:
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
Ah, ok, that is with the new context you created today. No, didn't test this till now ;-) First I guess I need an updated luatex you said.
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) [...]
- preprocessed font data cache so that loading the stuff is done faster
indeed, only at runtime, so normally in the users path someplace
Hmm, I still don't get it. In all this processing, is there a job depending thing contained? I thought extracting all those tables etc can be done independently of all jobs (and will help all jobs). Anyway, I got it. So this is not a bad thing at all to have this stuff generated at job running time, so we (integrators) don't have to worry about it. Only finding all the files is important for a start, so ls-R replacement.
$ 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
Probably an instance of "get the new beta", btw, where do I get it, from the usual download place? Or is there something else for betas?
- formats??? what is saved for this
a cont-en.fmt as well as a cont-en.luc file, the format and it sstub
Yes of course, but what needs to be cached here but the sole information that the file exist? (ie updating ls-R/cache)
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
Ok, so after the first processing later jobs will have access to these tables in a blink. Ok, don't mind. Good for me ;-) No need to worry about this.
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
Are these megabytes kept and are they useful for later runs? If yes, then it is ok to put them in a separate cache (I assume the stuff is useful, it is the font stuff).
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
Hmm, but if the caches would be in TEXMFTREE/lcache/ then the only thing
necessary would be a change of
TEXMFCNF
referencing other trees.
(Sorry, only trying to understand the details ...)
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Norbert Preining wrote:
Are these megabytes kept and are they useful for later runs? If yes, then it is ok to put them in a separate cache (I assume the stuff is useful, it is the font stuff).
not sure yet, maybe later; but there is a cache cleaner (i may even thrash by date and usage)
Hmm, but if the caches would be in TEXMFTREE/lcache/ then the only thing necessary would be a change of TEXMFCNF referencing other trees.
(Sorry, only trying to understand the details ...)
sure, all depends on what the cache var is set too (too many variants so i play safe and hash (but i can make that piece configurable if needed) the beta is on the website and on the ftp 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 -----------------------------------------------------------------
Norbert Preining wrote:
see my other email about multiple cache merging, but to some up: . cache should be read from more then one directory, eg from TEXMFSYSCACHE and TEXMFCACHE (with usual override stuff) . single cache updates should be possible: luatools --generate $HOME/texmf should generate the cache for $HOME/texmf in $TEXMFCACHE
let's assume that this is only useful for formats and file databases (i cannot imagine a sysadm messing around with documents in order to get a couple of font tables done) as it happens, the file databases and formats used to go into the tree, but currently i default to input.usecache = true now, i added an environment variable so that you can control this ... input.usecache = not toboolean(os.getenv("TEXMFSHARECACHE") or "false",true) yes, true, one, 1 are all equal to true so you can try set TEXMFCACHE=true well, your shell equivalent of that i will upload a beta (generating now) so that you can play with it (luat-tmp, luatools and mtxrun are all adapted) beware, for this beta you need a recent luatex because we no longer preload patterns but load them at runtime (smaller format, faster start, faster run) so we're talking real beta here -) 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 -----------------------------------------------------------------
On Mi, 03 Okt 2007, Hans Hagen wrote:
. cache should be read from more then one directory, eg from TEXMFSYSCACHE and TEXMFCACHE (with usual override stuff) . single cache updates should be possible: luatools --generate $HOME/texmf should generate the cache for $HOME/texmf in $TEXMFCACHE
let's assume that this is only useful for formats and file databases (i cannot imagine a sysadm messing around with documents in order to get a couple of font tables done)
Definitely. The idea is that the cache is for the files installed by system software (Debian packages, Windows sysadm installing TeX Live, etc).
now, i added an environment variable so that you can control this ...
input.usecache = not toboolean(os.getenv("TEXMFSHARECACHE") or "false",true)
yes, true, one, 1 are all equal to true so you can try
set TEXMFCACHE=true
well, your shell equivalent of that
TEXMFCACHE or TEXMFSHARECACHE? But I don't see how this will work? I checked the luacode a bit and I saw that it only loads from ONE cache directory. Could we set LUATEXCACHE=/var/lib/sysluacache:$TEXMFVAR/luacache:... TEXMFSHARECACHE=yes ?? Or do I misunderstand something?
beware, for this beta you need a recent luatex because we no longer preload patterns but load them at runtime (smaller format, faster start, faster run) so we're talking real beta here -)
svn, or is there going to be a release sometimes soon?
Thanks a lot and all the best
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining
Norbert Preining wrote:
But I don't see how this will work? I checked the luacode a bit and I saw that it only loads from ONE cache directory. Could we set LUATEXCACHE=/var/lib/sysluacache:$TEXMFVAR/luacache:... TEXMFSHARECACHE=yes ?? Or do I misunderstand something?
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 the cache path is only used and populated at runtime, so 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 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 -----------------------------------------------------------------
participants (3)
-
Hans Hagen -
Norbert Preining -
Taco Hoekwater