Major commit today
Hi, I have just committed an initial merge of the rest of Aleph. Code status = alpha, of course; what did you expect? ;-). If \pdfoutput=1, then the resulting binary is essentially an unchanged pdfetex 1.40-beta-20060213, except that: * there is no way to turn eTeX off * My \clearmarks patch is included * TeXXeT is removed. Missing primitives from pdfeTeX: \TeXXeTstate \beginL \beginR \endL \endR Therefore, PDF mode is Left-to-Right only for the time being. OTOH, it should be possible to use the '8-bit' extensions provided by Aleph like "fi" stretchability, \localleftbox, and math extensions, and even ocp processing (as long as you stick to 8-bit glyph indices). If \pdfoutput=0, then it is roughly equivalent to aleph-rc2. The following primitives from Aleph are not present: \AlephVersion \Alephminorversion \Alephrevision \Alephversion \OmegaVersion \Omegaminorversion \Omegarevision \Omegaversion \eTeXVersion \eTeXminorversion \chardp (use eTeX's \fontchardp) \charht (use eTeX's \fontcharht) \charit (use eTeX's \fontcharit) \charwd (use eTeX's \fontcharwd) \pageheight (use pdfTeX \pdfpageheight) \pagewidth (use pdfTeX \pdfpagewidth) The split between 'pdftex' and 'aleph' modes is likely to stay for a while. It was not very hard to simply add the aleph dvi code, but implementing a pdf backend to aleph will take quite a lot longer. I will spend the rest of this week as well as next week debugging the merge (so that it will not be possible to make it segfault any more), updating to aleph-rc4 and pdftex-beta-20060725, and documenting all the changes I have made to make both engines cooperate. Hopefully, by the end of next week there will be something that is usable/testable by non-debugger-happy people. Cheers, Taco
Taco Hoekwater wrote:
The following primitives from Aleph are not present:
\AlephVersion \Alephminorversion \Alephrevision \Alephversion \OmegaVersion \Omegaminorversion \Omegarevision \Omegaversion \eTeXVersion \eTeXminorversion
\chardp (use eTeX's \fontchardp) \charht (use eTeX's \fontcharht) \charit (use eTeX's \fontcharit) \charwd (use eTeX's \fontcharwd) \pageheight (use pdfTeX \pdfpageheight) \pagewidth (use pdfTeX \pdfpagewidth)
All reinstated. Not having them available was just unwieldy. The last six are all aliases of eachother: \pageheight and \pdfpageheight map to the same command code (\meaning shows \pageheight, I believe). I have fixed some bugs today, and I have reverted back to strict Unicode (2^20+2^16 possible characters instead of 2^21) because in the current layout, that saves near 300Mb in virtual memory size. Eventually, the affected arrays will become lua hashes, and we can safely go back to 2^21 then. Cheers, Taco
Taco Hoekwater wrote:
Taco Hoekwater wrote:
The following primitives from Aleph are not present:
\AlephVersion \Alephminorversion \Alephrevision \Alephversion \OmegaVersion \Omegaminorversion \Omegarevision \Omegaversion \eTeXVersion \eTeXminorversion
\chardp (use eTeX's \fontchardp) \charht (use eTeX's \fontcharht) \charit (use eTeX's \fontcharit) \charwd (use eTeX's \fontcharwd) \pageheight (use pdfTeX \pdfpageheight) \pagewidth (use pdfTeX \pdfpagewidth)
All reinstated. Not having them available was just unwieldy. The last six are all aliases of eachother: \pageheight and \pdfpageheight map to the same command code (\meaning shows \pageheight, I believe).
makes sense
I have fixed some bugs today, and I have reverted back to strict Unicode (2^20+2^16 possible characters instead of 2^21) because in the current layout, that saves near 300Mb in virtual memory size.
whow, reminds me of former omega days ...
Eventually, the affected arrays will become lua hashes, and we can safely go back to 2^21 then.
good 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 -----------------------------------------------------------------
Hans Hagen wrote:
I have fixed some bugs today, and I have reverted back to strict Unicode (2^20+2^16 possible characters instead of 2^21) because in the current layout, that saves near 300Mb in virtual memory size.
whow, reminds me of former omega days ...
The executable is still around 480Mb in virtual size even with this change :-)
Eventually, the affected arrays will become lua hashes, and we can safely go back to 2^21 then.
good
Bugs first, speedups later. Taco
Hi, Today's news: The source now also compiles using the mingw32 cross compiler. At least, it does on my linux machine, YMMV. Hans says the executable runs OK on XP, and that is the main thing. I do not really understand autoconf all that well, so I probably made a mess of the build system, but at the moment I am extremely happy that the cross-compile creates a valid (non crashing) executable. After three days of constant fighting (building/installing the cross-compiler itself, attempting to apply the mingw32 patches by Siep, and tricking autotools into postponing the configuration to "configure" (to avoid the need for reautoconf), I do not quite feel up to the task of cleaning up (e.g some headers are now duplicated four times). I will commit what I have in a few minutes. There are still quite a few problems with the program itself, but I'll have a look at that after the weekend. Taco
participants (3)
-
Hans Hagen -
Martin Schröder -
Taco Hoekwater