Re: [Dev-luatex] getnext et al.

7 May 2014

      ·········
...
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