Hi all, After almost two months it was definately time for a new snapshot. News compared to the 20070426 version: * The lua node processing interface is completely reworked. It is now completely based on userdata, and uses a new lua table called 'node' to hold the methods. More detailed information is in the manual (of course). * There is a fifth node processing callback: pre_output_filter this is executed just before the packaging of \box 255. * The hpack_filter and pre_linebreak_filter callbacks now receive an extra argument indicating the number of top-level glyphs in the node list. * Virtual fonts can now contain a 'node' key in the glyph commands: the value should be a hlist node (i.e.: a horizontal box), and that will then be output for each character access in that font. * A new set of registers is added, called \attribute. These are values that will be automatically attached to nodes created in their scope. More information in the manual. * Direct read/write access to TeX's box registers is addded to the lua 'tex' table. * TeX's main memory now grows dynamically, and the (de)allocation routines have been rewritten completely. * The 'kpse' table is extended with extra interface functions, to allow texlua to be used as a scripting engine. * The \pdftexversion command now returns 200, not 140. * The displayed banner and --version screens are cleaned up. * The format file is now RLE compressed. Not as small as before, but unpacking is much faster. Happy TeXing, Taco
Taco Hoekwater
After almost two months it was definately time for a new snapshot.
News compared to the 20070426 version:
[...] Are there any estimates regarding the relative performance?
* A new set of registers is added, called \attribute. These are values that will be automatically attached to nodes created in their scope. More information in the manual.
Presumably useful for things like colors.
* Direct read/write access to TeX's box registers is addded to the lua 'tex' table.
Quite desirable.
* TeX's main memory now grows dynamically, and the (de)allocation routines have been rewritten completely.
Sounds like something long overdue. I could imagine that this could be an area relevant for profiling, though.
* The 'kpse' table is extended with extra interface functions, to allow texlua to be used as a scripting engine.
Having an efficient, crossplatform available scripting engine capable of doing all the kpathsea gimickry without external executables is certainly very appealing and would help to shrink the Unix/whatever gap. It will remain to be seen how "dialog" and its ilk are best replaced in texconfig and similar scripts communicating with the user. Thanks (now I just need to get my working copy updated without that No route to host: Can't connect to host 'scm.foundry.supelec.fr': No route to host message), David -- David Kastrup
David Kastrup wrote:
Are there any estimates regarding the relative performance?
when no callbacks are used there is no big differece; when callbacks are used to process nodes, luatex is slower than pdftex but that is to be expected; on production runs doing node manipulations at several levele you can expect luatex to be a about twice a slow as pdftex, but that's the price we pay for progress anyhow, we did quite some tests and performance is quite good given what we're dealing with; one may win back tim e by replacing time consuming macros
* A new set of registers is added, called \attribute. These are values that will be automatically attached to nodes created in their scope. More information in the manual.
Presumably useful for things like colors.
indeed
* TeX's main memory now grows dynamically, and the (de)allocation routines have been rewritten completely.
Sounds like something long overdue. I could imagine that this could be an area relevant for profiling, though.
performance seems ok; there are some optimizations possible but those are on the agenda for next year when some other bits and pieces have been cleaned up in general, you can expect luatex to have a larger memory footprint than pdftex (esp when open type fonts are used and etc); a 100 mb mem footprint is no exception for more advanced docs Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
David Kastrup wrote:
Taco Hoekwater
writes: After almost two months it was definately time for a new snapshot.
News compared to the 20070426 version:
[...]
Are there any estimates regarding the relative performance?
20070619 is definately faster than 20070426. In fact, it is generally faster than Aleph at Aleph things (because I fixed the memory leak that made both progressively slower). It is a some 20-30% percent slower than pdftex at doing pdftex things, but that has been true from the start and AFAICS, it is caused more by the extra work done by the Omega code than by anything else.
* TeX's main memory now grows dynamically, and the (de)allocation routines have been rewritten completely.
Sounds like something long overdue. I could imagine that this could be an area relevant for profiling, though.
I doubt you can gain much. One of the reasons why this snapshot took such a long time to come about, was exactly because of extensive profiling and refactoring. Once LuaTeX is 'up to steam' (after one or two text pages), memory (de)allocation is basically controlled by a dozen dedicated avail lists.
Thanks (now I just need to get my working copy updated without that No route to host: Can't connect to host 'scm.foundry.supelec.fr': No route to host message),
"No route to host" sounds like a local network error on your side. It resolves nicely over here, and the IP address is 193.48.224.170 Good luck, Taco
Taco Hoekwater
David Kastrup wrote:
Thanks (now I just need to get my working copy updated without that No route to host: Can't connect to host 'scm.foundry.supelec.fr': No route to host message),
"No route to host" sounds like a local network error on your side. It resolves nicely over here, and the IP address is 193.48.224.170
Oh, it resolves fine here as well. It is just the port (don't ask me why this error message gets chosen): dak@lola:/home/tmp/luatex$ telnet scm.foundry.supelec.fr svn Trying 193.48.224.170... telnet: Unable to connect to remote host: No route to host dak@lola:/home/tmp/luatex$ telnet scm.foundry.supelec.fr http Trying 193.48.224.170... Connected to scm.foundry.supelec.fr. Escape character is '^]'. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Taco, What David is experiencing doesnt look like local issue on his side because I also lost anonymous access to svn repository. "svn checkout svn://scm.foundry.supelec.fr/svn/luatex" stopped working recently (on my side it just hangs forever) "svn checkout https://scm.foundry.supelec.fr/svn/luatex" seems to work but requires user and password. What command, user id , and pass should be used for anonymous access ? Kind regards, Igor On Jun 19, 2007, at 11:50 AM, Taco Hoekwater wrote:
David Kastrup wrote:
Taco Hoekwater
writes: After almost two months it was definately time for a new snapshot.
News compared to the 20070426 version:
[...]
Are there any estimates regarding the relative performance?
20070619 is definately faster than 20070426. In fact, it is generally faster than Aleph at Aleph things (because I fixed the memory leak that made both progressively slower). It is a some 20-30% percent slower than pdftex at doing pdftex things, but that has been true from the start and AFAICS, it is caused more by the extra work done by the Omega code than by anything else.
* TeX's main memory now grows dynamically, and the (de)allocation routines have been rewritten completely.
Sounds like something long overdue. I could imagine that this could be an area relevant for profiling, though.
I doubt you can gain much. One of the reasons why this snapshot took such a long time to come about, was exactly because of extensive profiling and refactoring. Once LuaTeX is 'up to steam' (after one or two text pages), memory (de)allocation is basically controlled by a dozen dedicated avail lists.
Thanks (now I just need to get my working copy updated without that No route to host: Can't connect to host 'scm.foundry.supelec.fr': No route to host message),
"No route to host" sounds like a local network error on your side. It resolves nicely over here, and the IP address is 193.48.224.170
Good luck, Taco
_______________________________________________ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Hi Igor, Igor Khomyakov wrote:
working recently (on my side it just hangs forever) "svn checkout https://scm.foundry.supelec.fr/svn/luatex" seems to work but requires user and password. What command, user id , and pass should be used for anonymous access ?
Using https will not work. If I understand the issue correctly that is because apache is stubbornly forcing validation thanks to the 's' in the protocol, even if subversion doesn't need it. There were problems with the svnserve configuration as well, but these are now fixed, so this syntax should once again work correctly: svn checkout svn://scm.foundry.supelec.fr/luatex Best wishes, Taco
2007/6/21, Taco Hoekwater
There were problems with the svnserve configuration as well, but these are now fixed, so this syntax should once again work correctly:
svn checkout svn://scm.foundry.supelec.fr/luatex
Works perfectly, thanks. But who is this "no author" guy? :-)
LANG=C svn log -r496
r496 | (no author) | 2007-06-21 11:40:43 +0200 (Thu, 21 Jun 2007) | 2 lines Best Martin
Works nicely now. Thank you! Updated to revision 499 w/o any issues. Thanks. On Jun 21, 2007, at 6:49 AM, Martin Schröder wrote:
2007/6/21, Taco Hoekwater
: There were problems with the svnserve configuration as well, but these are now fixed, so this syntax should once again work correctly:
svn checkout svn://scm.foundry.supelec.fr/luatex
Works perfectly, thanks.
But who is this "no author" guy? :-)
LANG=C svn log -r496
-- r496 | (no author) | 2007-06-21 11:40:43 +0200 (Thu, 21 Jun 2007) | 2 lines
Best Martin _______________________________________________ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
On 6/21/07, Taco Hoekwater
There were problems with the svnserve configuration as well, but these are now fixed, so this syntax should once again work correctly:
svn checkout svn://scm.foundry.supelec.fr/luatex
I get a svn: Can't connect to host 'scm.foundry.supelec.fr': Operation timed out The IP resolves to 193.48.224.170. -- Morten
participants (6)
-
David Kastrup
-
Hans Hagen
-
Igor Khomyakov
-
Martin Schröder
-
Morten Høgholm
-
Taco Hoekwater