[Dev-luatex] getnext et al.

Philipp Gesang philipp.gesang at alumni.uni-heidelberg.de
Wed May 7 08:09:58 CEST 2014


···<date: 2014-05-06, Tuesday>···<from: Hans Hagen>···
> On 5/6/2014 7:39 AM, Philipp Gesang wrote:
> >> reading the chapter 8.2 in the manual, I wonder how to call getnext and its ilk. Is this used like node.getnext()?
> >
> > Yes, but they operate on integer references which you obtain by
> > calling node.direct.todirect() on the node you start out with:
> 
>      local l = tex.getbox(0).list
>      print(node.getnext(l),node.direct.getnext(node.direct.todirect(l)))
> 
> so, node.getnext(n) works on 'normal nodes' (and can be faster than 
> n.next as it saves a metatable lookup + some internal speedup) ... if 
> it's really faster depends on the the use case (and using it also 
> relates to readability ... often n.next looks nicer)
> 
> never think of direct nodes as integers .. they're abstractions that 
> happen to be (positive) numbers

Which also means you can do some weird kind of pointer arithmetic
on them, e.g. to box all the glyph nodes that are among the lower
250 elements of the varmem region:

    \directlua {
      local hd, cur
      for i = 1, 250 do
        local chr = node.direct.getfield (i, "char")
        if chr then
          print (">>", i, chr, string.char (chr))
          local new = node.direct.copy (i)
          if cur then
            node.direct.setfield (cur, "next", new)
            node.direct.setfield (new, "prev", cur)
          else
            hd = new
          end
          cur = new
        end
      end
    
      if hd then
        local hbox = node.direct.hpack (hd)
        node.direct.write (hbox)
      end
    }

I can’t think of a serious use for that property, though,
especially since there doesn’t appear to be a way to query the
number of nodes allocated.

> > @Hans: Considering that node.direct has been part of the master
> > branch for some time and the new model is used in Context without
> > users reporting segfaults, could you give an ETA on when the
> > generic fontloader will benefit from it?
> 
> hard to say ... keep in mind that the gain is mostly in complex font 
> handling of manipulations and that is not always that generic (
> 
> btw, there are some more changes in the font related code (on my 
> machine, one of these days in the core ... given some testing by others) 
> ... one reason for keeping this separate from generic is that i don't 
> want to break that (esp not around tex live code freeze)

I seem to recall that the generic font loader did actually ship
with the nuts code for a short while until you undid that and
reverted it to the previous implementation. Most of the bugs that
occurred since were consequences of the code being out of sync
with the rest of Context -- just wanted to point that out ;)

> the latest generic code + the latest luatex already should run somewhat 
> faster (something halfway) as the regular node code was also optimized

Performance reached new heights during the last year, so much is
certain.

Best,
Philipp


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://www.ntg.nl/pipermail/dev-luatex/attachments/20140507/194d8b8f/attachment.pgp>


More information about the dev-luatex mailing list