[Dev-luatex] next steps in development

Hans Hagen pragma at wxs.nl
Sun May 7 20:25:52 CEST 2006

Taco Hoekwater wrote:
> Hi,
> Hans Hagen wrote:
>> (1) \luadef\cs
>> goal: starts an lua instance
>> usage: \luadef\lua
> Expect the primitive syntax to be more like the internals of \toksdef,
> so the toplevel user command would be \newlua.
> There is a catch though: I want to reserve one number for internal
> use (callback functions that handle C functionality, like finding
> files). Maybe 255, since Tex uses 255 for various things anyway.
ok, although we get an insert like \new* then, so how about just 
starting at zero and then advice (given a luadef); also, we've run out 
of alloc  counters, so we may as well implement newlua different anyway

\newlua \luacallback
\newlua \lua  


\luadef \lucacallback 0
\luadef \lua 1

anyhow, since we cannot use \alloc@ , the 255 is also ok


  {\global\advance\@@luainstances \ifnum\@@luainstances=254 2\else 1\fi
   \luadef #1 \@@luainstances}
if we compare to boxes, counts etc, there is not something like \lua0 to 
use as scratch lua instance unless we also can reset such an engine 
which we need anyway (btw, lua instances are grouping transparent)

we can have a \luadispose (or do a redef) but then we alse need to be 
able to check if an \cs is representing a lua etc etc although we may 
assume sane usage

  {\ifx#1\undefined \global\advance\@@luainstances 
\ifnum\@@luainstances=254 2\else 1\fi \fi
   \luadef #1 \@@luainstances}


\newlua \temp % new instance
\newlua \temp % kill existing and create instance
\newlua \temp % kill existing and create instance


\newdimen \temp

\newlua \temp % fails unless  we have an \iflua\cs as in:

  {\iflua#1\else \global\advance\@@luainstances 
\ifnum\@@luainstances=254 2\else 1\fi \fi
   \luadef #1 \@@luainstances}

\def \temp {whatever}

\newlua \temp % fails unless  we have an \iflua\cs as in:

of course this overload can also happen with registers but then we only 
loose some mem, while with lua we get pending engine *using up much mem)

>> (3) \immediate\luacs
>> goal: feeds back into the token scanner (no need for scantokens, 
>> faster due to less parameter passing)
>> usage: \immediate\lua{tex.print("$x$")}
> This could be the normal behaviour of tex.print(), and if you do
> not want it, you could run \detokenize yourself. And we could have
> a separate function tex.write() for detokenized use.

I opt for two functions (no messing around with detokenization)
>> further, taco and i discussed a lua extension using a variant of 
>> strings using 32 bit entries, partly for the unicode chars and partly 
>> for the \cs etc pointers so that we can do stringlike thinsg with 
>> token lists
> I will write up some stuff about this later this week.
>> well, we discussed more, but i need to search my memory -)
> Amongst other things, we also talked about a new way to load
> and use fonts:  not letting TeX read .tfm and .vf files, but
> using a ruby library for the internal font loading. That library
> then has to return a table with a specified set of keys.
> That way, we could have reencoded and synthetic (virtual) fonts
> from all over the place without being tied to compiled code or
> font formats.
indeed; same for map files 


                                          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

More information about the Dev-luatex mailing list