No room for a new write in LuaLaTeX

Question

This is one of those very large document questions where I am struggling to produce an MWE. But it relates to restriction of write streams in LuaLaTeX vs XeLaTeX. I have a complex document with extra indices, extra float types, where the dreaded write stream limitation in XeLaTex has been a major hindrance.
The morewrites package caused some difficulty so I decided to move to LuaLaTex - under the impression that there are no write stream limitations there up to 256. However to my surprise I get exactly the same error when the streams hit 17 or so.
Below is a grep for write on a 25000 line log file after a LuaLaTex compile. I thought this was not a limitation in principle, so why am I still getting this at exactly the same N? In case it makes a difference I'm using shell-escape too.
 Inserting `luaotfload.rewrite_fontname' at position 4 in `luaotfload.patch_font'.
 @xs@message=write3
 w@pgf@writea=write4
 tcb@out=write5
 tcb@record@out=write6
 forest@copy@out=write7
 Package pgfplots info on input line 82: Found new luatex: initializing lua commands instead of write18 (shell-escape)
 @indexfile=write8
 js@verbatim@out=write9
 @outlinefile=write10
 tf@toc=write11
 tf@lof=write12
 tf@lot=write13
 tf@lotreepic=write14
 [][]TU/LinLibertine(5)/m/n/12 immediatewrite18{grep -vE "(linkcode55)" steelechaimkids.tex > schaimclean.tex} 
 tf@exh=write15
 ./subdocs/templatetikzoddssodds.tex:5269: No room for a new write .
 []TU/LinLibertine(0)/m/n/10.95 didn’t add code for ar-rows. this should not be prob-lem to write code for it (some-thing like []TU/LinLibertine(5)/m/n/10.95 draw[<->] ([xshift=...] r1c4.north east) -- ([xshift=...] r4c1.south east);) 
 ./subdocs/templateshapepar.tex:39: No room for a new write .
 tf@los=write16
 tf@tod=write17
 ./subdocs/templatepgfplots.tex:27: No room for a new write .
 ./subdocs/templatepgfplots.tex:329: No room for a new write .
 ./subdocs/templatepgfplots.tex:413: No room for a new write .
 ./subdocs/templatepgfplots.tex:777: No room for a new write .
 ./subdocs/templatepgfplots.tex:1943: No room for a new write .
 ./subdocs/templatepgfplots.tex:1989: No room for a new write .
 ./subdocs/templatepgfplots.tex:2175: No room for a new write .
 ./subdocs/templatepgfplots.tex:2189: No room for a new write .
 ./subdocs/templatepgfplots.tex:2198: No room for a new write .
 ./subdocs/templatepgfplots.tex:2344: No room for a new write .
 ./subdocs/templatepgfplots.tex:2729: No room for a new write .
 ./subdocs/templatepgfplots.tex:2781: No room for a new write .
 ./subdocs/templatepgfplots.tex:2868: No room for a new write .
 ./subdocs/templatepgfplots.tex:2991: No room for a new write .
 ./subdocs/templatepgfplots.tex:3354: No room for a new write .
 ./subdocs/templatepgfplots.tex:3407: No room for a new write .
 ./subdocs/templatepgfplots.tex:3481: No room for a new write .
 ./subdocs/templatepgfplots.tex:3687: No room for a new write .
 ./subdocs/templatepgfplots.tex:4344: No room for a new write .
 ./subdocs/templatepgfplots.tex:4503: No room for a new write .
 ./subdocs/templatepgfplots.tex:4553: No room for a new write .
 ./subdocs/templatepgfplots.tex:4773: No room for a new write .
 ./subdocs/templatetkzgraphs.tex:64: No room for a new write .
 ./subdocs/templatetikzcirstree.tex:1812: No room for a new write .

Aubrey Blumsohn · Answer

I thought I would answer this myself to close this in case it helps others:
After an extensive search, eliminating things one by one, it turns out that the filecontents package was to blame. The functionality of the filecontents package is (sort of) subsumed within Lualatex. Removing the package resolved all "no room for new write" issues.
To maintain functionality, it is necessary to replace all calls to
begin{filecontents*}{filename}
...Content...
end{filecontents*}

with

begin{filecontents*}[overwrite]{filename}
...Content...
end{filecontents*}

and similarly for the unstarred variant.
In my view the LuaLatex developers should have maintained backwards compatibility (a core LaTex advantage) by making overwrite the default, and also if possible producing an error in the log if an incompatible commonly used package (but with identically named macros) is loaded. Albeit I appreciate that the basis of LuaLatex is to break the mould, such breaking should only be done when absolutely necessary. Apart from the risk of inadvertent use of old data, the slightly different formulation also makes it difficult to maintain documents for both LuaLatex and other compilers. The filecontents package should probably be patched also to load the Lua version when appropriate.

No room for a new write in LuaLaTeX

One Answer

Add your own answers!

Ask a Question