On Mon, 13 Jan 2020 at 03:41, Doug McKenna <d...@mathemaesthetics.com> wrote:
> >| Are there architectural reasons preventing you from having a > >| format file, or is it simply that you hope to make loading quick > >| enough that you do not need it? > > Yes, and yes. JSBox does not depend on an internal array of integers (mem[] > or whatever). Doing so makes it essentially impossible to use a modern-day > debugger to examine data structures. Every data structure that is allocated > is done so (indirectly) via malloc() or whatever the equivalent might be on > some system. This makes it harder to create a \dump format file, though not > impossible. But it wouldn't be (or need to be) compatible with anything in > the official TeX world. Regardless, my goal is to see how far one can get > without needing format files. You could probably look at what luatex is doing as it is possibly closer to you here than xetex: the sources are in C and use dynamic memory allocation replacing almost all of tex's fixed arrays, but they do manage to dump formats. > Also, see below. > > >| The pressure to load more into a > >| format is likely to increase rather than decrease, people often > >| routinely make custom formats preloading large packages like tikz or > >| pstricks for example. > > True, but there is a fundamental difference between what I'm working toward, > and what the TeX infrastructure does. In the TeX world, every job is a > single process. Every time a TeX job is done, a process is launched, the job > gets done, and the program ends. It's the Unix/command-line way. So the > format has to be loaded (fast) on every job. Makes perfect sense. This seems really quite strange to me I can think of very few user level programs that are compiled from source on every use, it is placing a big extra burden on the programmer (the latex team in this case) to write the program with all code paths optimised for run time speed rather than being able to offload expensive testing to compile time so it is only done once. David
