Hi all, Karl Berry wondered about the plans for luatex, for texlive 2010 planning. Below is the message I replied him, and in a later message he set March 31 as an initial deadline for code submissions, so that is what we have to aim for for 0.60. The most important immediate decision is what to do about the literate programming issue, as we explicitly promised that for the 0.60 release. Here is the list of serious candidates (in my current opinion): * Cweb http://www-cs-faculty.stanford.edu/~knuth/cweb.html * Doxygen http://www.stack.nl/~dimitri/doxygen/ * Noweb http://www.cs.tufts.edu/~nr/noweb/ Cweb has a head start because of its relation to WEB (we all like DEK, the needed tools are in texlive, the retained comments already use the correct formatting, and perhaps most importantly Hartmut and I are used to its quirks). But that does not mean it should automatically be the tool to use. Doxygen has a number of advantages: it formalizes api documentation, it supports html output as well as latex, its use is much more common, and the input keeps looking like normal C files to the build tools (important for dependency tracking in make). Finally, noweb is interesting because it is much simpler than cweb and also (mainly) because Norman Ramsey is/was planning to redo it in lua, which would mean that in the end it might be possible to use luatex to generate itself and its documentation. But it has most of the same build-time drawbacks that cweb has. I'll be studying these options for the next week or so, and I hope you will do the same. Also, let me know if there are other candidates that are worth investigating. Best wishes, Taco PS besides the core luatex team, I put dev-luatex and a bunch of people in the CC list that may have interesting input to the discussion. Taco Hoekwater wrote:
Karl Berry wrote:
That leaves LuaTeX. Taco, what should we aim for shipping in 2010, and when? (And let's be sure that we update context and luatex in TL at the same time this year, so context mkiv stands a chance.)
For luatex itself, the two major plans for 0.60 are 1. go back to Cweb (or something similar) from plain C 2. consolidate binary lua module loading unfortunately, it is likely both will affect the build process
Point 1 still needs a decision to be made (use cweb, use doxygen, or write something ourselves), I expect that decision to be made in this month, and the initial implementation to follow a few weeks later.
Point 2 has unsolved issues with the use of the lua core, which really should become a dynamic, private dll to avoid problems between the lua core symbols use by such external modules and luatex's embedded (patched) lua core symbols. I am not too thrilled about implementing this, so I have postponed it until now. (a longer, more technical email about this will follow in a few days)
There are some other things planned for luatex 0.60, but those are relatively minor and, most importantly, wont affect the build process much. So once the two point above are resolved, the code could go into the TL repository. Sounds like end of March would be doable for that.
Meanwhile, don't forget metapost, massive amounts of work going on there. But metapost 2 will not be finished before early summer (at the very earliest), so I guess the best solution is to stick with metapost 1.2 in TL 2010, and possibly also include a pre-release of metapost 2, if anything release-able is ready in time.
I think actually it would help if you set straight deadlines for code submissions, that way I can reschedule the development work to match those. Both metapost and luatex are actively developed: there is a never a point where there are no great changes planned.
Best wishes, Taco
On Sun, 7 Feb 2010, Taco Hoekwater wrote:
Here is the list of serious candidates (in my current opinion):
* Cweb http://www-cs-faculty.stanford.edu/~knuth/cweb.html * Doxygen http://www.stack.nl/~dimitri/doxygen/ * Noweb http://www.cs.tufts.edu/~nr/noweb/
Hi Taco, from my point of view Cweb/Noweb generate C code (as do flex and bison), whereas Doxygen uses (annotated) C code to generate documentation. Thus they fall into quite different categories. Cweb is special because it is built as part of TL, but otherwise probably much like Noweb. Flex/bison are special because they are directly supported by Automake. Cweb is supported in the TL build system via a shell script that handles all issues for parallel make, but still needs special build rules -- Noweb could be handled in a similar way.
From the build system side, I'd think normal users (i.e., people building TL or just luaTeX) should not be required to have either Noweb or Doxygen, as they are not required to have Autoconf, Automake, Flex, or Bison.
The situation is, of course, quite different for developers/maintainers,
i.e., for everyone modifying the ultimate source files.
Regards
Peter Breitenlohner
Hi, Peter Breitenlohner wrote:
from my point of view Cweb/Noweb generate C code (as do flex and bison), whereas Doxygen uses (annotated) C code to generate documentation. Thus they fall into quite different categories.
Cweb is special because it is built as part of TL, but otherwise probably much like Noweb.
Yes, pretty much the same.
Flex/bison are special because they are directly supported by Automake. Cweb is supported in the TL build system via a shell script that handles all issues for parallel make, but still needs special build rules -- Noweb could be handled in a similar way.
From the build system side, I'd think normal users (i.e., people building TL or just luaTeX) should not be required to have either Noweb or Doxygen, as they are not required to have Autoconf, Automake, Flex, or Bison.
On that note (and lacking other discussion input), I move we go with Cweb. Best wishes, Taco
2010/2/21 Taco Hoekwater
Peter Breitenlohner wrote:
From the build system side, I'd think normal users (i.e., people building TL or just luaTeX) should not be required to have either Noweb or Doxygen, as they are not required to have Autoconf, Automake, Flex, or Bison.
On that note (and lacking other discussion input), I move we go with Cweb.
Sorry for my silence. Peter's assumption for Oxygen is false: It augments the source code, so the only people who would be required to have it would be those who want to build the documentation. And I believe it does many things CWeb doesn't (e.g. diagrams, HTML documentation, ...). One major problem I have with systems like CWEB is that they need tool support (e.g. in the debugger), as the code the compiler sees isn't the one the programmer edits. Best Martin
Hi, Martin Schröder wrote:
2010/2/21 Taco Hoekwater
: Peter Breitenlohner wrote:
From the build system side, I'd think normal users (i.e., people building TL or just luaTeX) should not be required to have either Noweb or Doxygen, as they are not required to have Autoconf, Automake, Flex, or Bison. On that note (and lacking other discussion input), I move we go with Cweb.
Sorry for my silence. Peter's assumption for Oxygen is false: It augments the source code, so the only people who would be required to have it would be those who want to build the documentation. And I believe it does many things CWeb doesn't (e.g. diagrams, HTML documentation, ...).
But we can't have both, I assume. Cweb would be happy with extra Doxygen comments, but not the other way around (right?). And it is traditional for all TL users to be able to generate the typeset documentation.
One major problem I have with systems like CWEB is that they need tool support (e.g. in the debugger), as the code the compiler sees isn't the one the programmer edits.
gdb is perfectly happy to work with my mpost sources, so I am not convinced this is important. For example, I can set breakpoints on the actual line numbers of the web file. As for @d macros: those are converted to standard cpp macros, and behave identically in the debugger. Best wishes, Taco
taco> On that note (and lacking other discussion input), I move we go with Cweb. I am all for it. ms> One major problem I have with systems like CWEB is that they need tool support (e.g. in the debugger), as the code the compiler sees isn't the one the programmer edits. That's true for C, too. As long as CWEB outputs #line/#file information (which I believe it does), I don't think there's a problem.
On Sun, 21 Feb 2010, Taco Hoekwater wrote:
Peter Breitenlohner wrote:
from my point of view Cweb/Noweb generate C code (as do flex and bison), whereas Doxygen uses (annotated) C code to generate documentation. Thus they fall into quite different categories.
yes, and i guess one key difference is that in *web you can use named chunks _before_ having defined their contents. One can't do this with "normal" macro languages or Doxygen, so *web add a level of shuffleability.
On that note (and lacking other discussion input), I move we go with Cweb.
happy with it. Regards, Hartmut
participants (5)
-
Hartmut Henkel
-
karl@freefriends.org
-
Martin Schröder
-
Peter Breitenlohner
-
Taco Hoekwater