From olaf at infovore.xs4all.nl Sat Nov 10 22:15:57 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:19 2005 Subject: [tex-pretest] Web2C 7.3.5 - a pretest version. In-Reply-To: <87elnlmn6z.fsf@infovore.xs4all.nl> References: <87elnlmn6z.fsf@infovore.xs4all.nl> Message-ID: <87pu6qnx82.fsf@infovore.xs4all.nl> I'm uploading new web2c sources, version 7.3.5. There's still stuff I need to do to get to something I really want to release. Compared to 7.3.4, the following has happened: - Omega 1.23 is incorporated. However, the Omega teams wants to be able to use a C++ compiler on the web2c/kpathsea sources. I'm a lot less enthousiastic about this, and certainly haven't included all necessary changes yet. I also do not agree with all changes they made to web2c for that purpose, and my alternatives in turn imply changes to Omega. Thus the omega tarball differs in a number of places from the "canonical" 1.23 sources. [Are you listening John?] - Documentation has mostly been updated. I would like to document the src-specials better, and still need to do so in the manual pages. Todo: - Search algorithm needs revision. - Use libtool instead of klibtool. - Possibly update the fontname files -- haven't checked their version yet. - Verify that all bits of the texmf tree are up-to-date. Ensure that omega/pdftex/etex basic texmf trees are up-to-date. Location ftp://ftp.tug.org/private/tex -- Olaf Weber Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety. From olaf at infovore.xs4all.nl Sun Nov 11 18:19:28 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:19 2005 Subject: [tex-pretest] Web2C 7.3.5 - a pretest version. In-Reply-To: <87pu6qnx82.fsf@infovore.xs4all.nl> References: <87elnlmn6z.fsf@infovore.xs4all.nl> <87pu6qnx82.fsf@infovore.xs4all.nl> Message-ID: <87adxtmdi7.fsf@infovore.xs4all.nl> Olaf Weber writes: > - Omega 1.23 is incorporated. However, the Omega teams wants to be > able to use a C++ compiler on the web2c/kpathsea sources. I'm a lot > less enthousiastic about this, and certainly haven't included all > necessary changes yet. I also do not agree with all changes they > made to web2c for that purpose, and my alternatives in turn imply > changes to Omega. Thus the omega tarball differs in a number of > places from the "canonical" 1.23 sources. [Are you listening John?] Akira Kakuto was kind enough to draw my attention to the fact that I'd made a pretty dire error in the merge, with the effect that Omega couldn't read back its format files. (I didn't have much time for testing yesterday...) I've updated the Omega tarball at ftp://ftp.tug.org/private/tex Version numbers and such remain the same... -- Olaf Weber [M]ost likely other e-mail programs like Eudora are not designed to enable virus replication. -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp#Faqs From plaice at example.au Mon Nov 12 06:49:23 2001 From: plaice at example.au (John Plaice) Date: Fri Feb 18 15:06:19 2005 Subject: [tex-pretest] Omega and web2c Message-ID: <20011112164923.C15863@omega.cse.unsw.edu.au> Olaf, yes i am listening :) I'll have a look at the changes this evening. Cheers, John From olaf at infovore.xs4all.nl Mon Nov 12 18:26:38 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:19 2005 Subject: [tex-pretest] Omega and web2c In-Reply-To: <20011112164923.C15863@omega.cse.unsw.edu.au> References: <20011112164923.C15863@omega.cse.unsw.edu.au> Message-ID: <87r8r3lx2p.fsf@infovore.xs4all.nl> John Plaice writes: > Olaf, yes i am listening :) > I'll have a look at the changes this evening. Ok, If possible, get me a list of things in web2c/kpathsea that you think need to be changed -- esp. some arguments why a particular mod is good would be useful. Note that I've not enabled the 'file recorder' in Omega. Given the place where those changes come in (lib/openclose.c) I _am_ wondering whether it would be a useful feature for "normal" TeX as well. Arguments for/against? -- Olaf Weber [M]ost likely other e-mail programs like Eudora are not designed to enable virus replication. -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp#Faqs From tgakic at chem.tue.nl Wed Nov 14 03:52:22 2001 From: tgakic at chem.tue.nl (Ionel Mugurel Ciobica) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] latin9.def and latin10.def Message-ID: <20011114035222.A6844@bambam> Hi all, I am not registered to you mailing list, so I hope the message will pass through. Please send me a copy of your answer, if any. I hope this is the good list to address for this matter. As you know in Europe will be a big change with euro and the computers should be ready to display the euro character. I don't see why LaTeX should not do that. Latin9, the replacement of Latin1 was accepted at ISO a long time ago and Latin10, the replacement of Latin2 was accepted few months ago. I have not seen any latin9.def and latin10.def files to go with inputenc. I prepared a version of this files, can you please have a look at it? I would like to submitted at CTAN, but I have no clue how to do that. For the euro symbol the tetex-eurosym has to be installed, otherwise an alternative is to "draw" it on place. Also textcomp has to be used in the document for the \textdegree, for instance. The case of Romanian characters s, S, t and T comma below, it is not that easy to provide a solution. The one I used is not good enough for large characters, but is better that nothing. A better alternative would be to create a commabelow.sty file along the lines: % cat commabelow.sty \typeout{CommaBelow for drawing the comma below the `t', `s', `T' and the `S'.} \typeout{Good for Romanian language! Version 0.01} \typeout{ -- Released May 4, 2001 by Ionel Mugurel Ciob?c?} \def\j@urnalname{commabelow} \def\versi@ndate{May 4, 2001} \def\versi@nno{ver0.01} \def\copyrighth@lder{IMC} % Ionel Mugurel Ciob?c? \typeout{CommaBelow Macro File `\j@urnalname' (\versi@nno) <\versi@ndate>\space[\copyrighth@lder]} \NeedsTeXFormat{LaTeX2e}[1995/06/01] \ProvidesPackage{commabelow} \def\@makefnmark{\hbox{\@commabelow{\normalfont\@thefnmark}}} \DeclareRobustCommand*\commabelow[1]{% \@commabelow{\selectfont#1}} \def\@commabelow#1{% {\o@lign{\relax#1\crcr\hidewidth\sh@ft{-1ex},\hidewidth}}} Hovewer, I am not good at TeX (a use LaTeX) so the example is not working. I just copy the lines where the dot below is definded and changed the dot with the comma :-( maybe a simply \C would be better (shorter) than \commabelow. In omega/lambda fonts the commabelow glyph is present, but the four glyphs: T comma below, t comma below, S comma below and s comma below are not. An work arround for omega is: \par S\kern-.45em?? \par s\kern-.35em?? \par t\kern-.3em?? \par T\kern-.45em?? (I have no clue how this can be translated to lambda). The latin10.def file I used for more than one year now, much before than the final release of ISO-8859-16 charset, as is the only 8bit charset supporting Romanian language. The latin9.def file I did not test it intensively. Can you please have a look and let me know if the files are OK? I am looking forward for your answer. Ionel -- Ionel Mugurel Ciob?c? Schuit Institute of Catalysis Phone: 00 31 (0)40 2473781 Eindhoven University of Technology Fax: 00 31 (0)40 2455054 Laboratory of Catalysis, _SKA_ e-mail: I.M.Ciobica@TUe.nl Theory Group, STW 4.27, POBox 513 5600MB Eindhoven, Netherlands _____ .''`. (o- This is Linux Country. -o) : :' : //\ On a quiet night, you /\\ `. `'` V_/_ can hear Windows reboot. _\_V `- www.Debian.org "Experience is what you get when you didn't get what you wanted." %% %% This is file `latin9.def', %% %% This is a new file. %% %% Copyright 2001 %% Ionel Mugurel Ciobica %% %% Permision granted to copy, distribute and redistribute this file. %% %% Because of the euro symbol the tetex-eurosym package has to be %% installed. Otherwise an alternative is made to "draw" the character %% on place. Uncomment that line and comment the next one. %% %% Because of \textdegree and many other \text... commands, %% you might want to use \usepackage{textcomp} in your document. %% %% \CharacterTable %% {Upper-case \A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z %% Lower-case \a\b\c\d\e\f\g\h\i\j\k\l\m\n\o\p\q\r\s\t\u\v\w\x\y\z %% Digits \0\1\2\3\4\5\6\7\8\9 %% Exclamation \! Double quote \" Hash (number) \# %% Dollar \$ Percent \% Ampersand \& %% Acute accent \' Left paren \( Right paren \) %% Asterisk \* Plus \+ Comma \, %% Minus \- Point \. Solidus \/ %% Colon \: Semicolon \; Less than \< %% Equals \= Greater than \> Question mark \? %% Commercial at \@ Left bracket \[ Backslash \\ %% Right bracket \] Circumflex \^ Underscore \_ %% Grave accent \` Left brace \{ Vertical bar \| %% Right brace \} Tilde \~} \ProvidesFile{latin9.def} [2001/10/07 v0.01 Input encoding file (test version: still liable to change)] \makeatletter \DeclareInputText{160}{\nobreakspace} \DeclareInputText{161}{\textexclamdown} \DeclareInputText{162}{\textcent} \DeclareInputText{163}{\pounds} %\DeclareInputText{164}{{\sffamily C\makebox[0pt][l]{\kern-.70em\mbox{--}}\makebox[0pt][l]{\kern-.68em\raisebox{.25ex}{--}}}} \DeclareInputText{164}{\euro} \DeclareInputText{165}{\textyen} \DeclareInputText{166}{\v S} \DeclareInputText{167}{\S} \DeclareInputText{168}{\v s} \DeclareInputText{169}{\copyright} \DeclareInputText{170}{\textordfeminine} \DeclareInputText{171}{\guillemotleft} \DeclareInputMath{172}{\lnot} \DeclareInputText{173}{\-} \DeclareInputText{174}{\textregistered} \DeclareInputText{175}{\@tabacckludge={}} \DeclareInputText{176}{\textdegree} \DeclareInputMath{177}{\pm} \DeclareInputMath{178}{^2} \DeclareInputMath{179}{^3} \DeclareInputText{180}{\v Z} \DeclareInputMath{181}{\mu} \DeclareInputText{182}{\P} \DeclareInputText{183}{\textperiodcentered} \DeclareInputText{184}{\v z} \DeclareInputMath{185}{^1} \DeclareInputText{186}{\textordmasculine} \DeclareInputText{187}{\guillemotright} \DeclareInputText{188}{\OE} \DeclareInputText{189}{\oe} \DeclareInputText{190}{\" Y} \DeclareInputText{191}{\textquestiondown} \DeclareInputText{192}{\@tabacckludge`A} \DeclareInputText{193}{\@tabacckludge'A} \DeclareInputText{194}{\^A} \DeclareInputText{195}{\~A} \DeclareInputText{196}{\"A} \DeclareInputText{197}{\r A} \DeclareInputText{198}{\AE} \DeclareInputText{199}{\c C} \DeclareInputText{200}{\@tabacckludge`E} \DeclareInputText{201}{\@tabacckludge'E} \DeclareInputText{202}{\^E} \DeclareInputText{203}{\"E} \DeclareInputText{204}{\@tabacckludge`I} \DeclareInputText{205}{\@tabacckludge'I} \DeclareInputText{206}{\^I} \DeclareInputText{207}{\"I} \DeclareInputText{208}{\DH} \DeclareInputText{209}{\~N} \DeclareInputText{210}{\@tabacckludge`O} \DeclareInputText{211}{\@tabacckludge'O} \DeclareInputText{212}{\^O} \DeclareInputText{213}{\~O} \DeclareInputText{214}{\"O} \DeclareInputMath{215}{\times} \DeclareInputText{216}{\O} \DeclareInputText{217}{\@tabacckludge`U} \DeclareInputText{218}{\@tabacckludge'U} \DeclareInputText{219}{\^U} \DeclareInputText{220}{\"U} \DeclareInputText{221}{\@tabacckludge'Y} \DeclareInputText{222}{\TH} \DeclareInputText{223}{\ss} \DeclareInputText{224}{\@tabacckludge`a} \DeclareInputText{225}{\@tabacckludge'a} \DeclareInputText{226}{\^a} \DeclareInputText{227}{\~a} \DeclareInputText{228}{\"a} \DeclareInputText{229}{\r a} \DeclareInputText{230}{\ae} \DeclareInputText{231}{\c c} \DeclareInputText{232}{\@tabacckludge`e} \DeclareInputText{233}{\@tabacckludge'e} \DeclareInputText{234}{\^e} \DeclareInputText{235}{\"e} \DeclareInputText{236}{\@tabacckludge`\i} \DeclareInputText{237}{\@tabacckludge'\i} \DeclareInputText{238}{\^\i} \DeclareInputText{239}{\"\i} \DeclareInputText{240}{\dh} \DeclareInputText{241}{\~n} \DeclareInputText{242}{\@tabacckludge`o} \DeclareInputText{243}{\@tabacckludge'o} \DeclareInputText{244}{\^o} \DeclareInputText{245}{\~o} \DeclareInputText{246}{\"o} \DeclareInputMath{247}{\div} \DeclareInputText{248}{\o} \DeclareInputText{249}{\@tabacckludge`u} \DeclareInputText{250}{\@tabacckludge'u} \DeclareInputText{251}{\^u} \DeclareInputText{252}{\"u} \DeclareInputText{253}{\@tabacckludge'y} \DeclareInputText{254}{\th} \DeclareInputText{255}{\"y} \makeatother \endinput %% %% End of file `latin9.def'. %% %% This is file `latin10.def', %% %% This is a new file. %% %% Copyright 2001 %% Ionel Mugurel Ciob?c? %% %% Permision granted to copy, distribute and redistribute this file. %% %% The comma below accent for S, s, T and t doesn't look good %% for large characters. A solution would be to include internal %% support for comma below in the same way like for the dot below, %% so \C{t} to create the t comma below, etc. %% %% Because of the euro symbol the tetex-eurosym package has to be %% installed. Otherwise an alternative is made to "draw" the character %% on place. Uncomment that line and comment the next one. %% %% Latin10 is also comming with support for the German double quotations. %% You have to use babel with a language that support those quotations, %% German and Romanian come now in my mind... %% %% Because of \textdegree you might want to use \usepackage{textcomp} in %% your document. %% %% \CharacterTable %% {Upper-case \A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z %% Lower-case \a\b\c\d\e\f\g\h\i\j\k\l\m\n\o\p\q\r\s\t\u\v\w\x\y\z %% Digits \0\1\2\3\4\5\6\7\8\9 %% Exclamation \! Double quote \" Hash (number) \# %% Dollar \$ Percent \% Ampersand \& %% Acute accent \' Left paren \( Right paren \) %% Asterisk \* Plus \+ Comma \, %% Minus \- Point \. Solidus \/ %% Colon \: Semicolon \; Less than \< %% Equals \= Greater than \> Question mark \? %% Commercial at \@ Left bracket \[ Backslash \\ %% Right bracket \] Circumflex \^ Underscore \_ %% Grave accent \` Left brace \{ Vertical bar \| %% Right brace \} Tilde \~} \ProvidesFile{latin10.def} [2001/10/07 v0.01 Input encoding file (test version: still liable to change)] \makeatletter \DeclareInputText{160}{\nobreakspace} \DeclareInputText{161}{\k A} \DeclareInputText{162}{\k a} \DeclareInputText{163}{\L} %\DeclareInputText{164}{{\sffamily C\makebox[0pt][l]{\kern-.70em\mbox{--}}\makebox[0pt][l]{\kern-.68em\raisebox{.25ex}{--}}}} \DeclareInputText{164}{\euro} \DeclareInputText{165}{\guillemotleft} \DeclareInputText{166}{\v S} \DeclareInputText{167}{\S} \DeclareInputText{168}{\v s} \DeclareInputText{169}{\copyright} \DeclareInputText{170}{\ooalign{S\crcr\hidewidth\raise-.31ex\hbox{\scriptsize,}\hidewidth}} \DeclareInputText{171}{\quotedblbase} \DeclareInputText{172}{\@tabacckludge'Z} \DeclareInputText{173}{\-} \DeclareInputText{174}{\@tabacckludge' Z} \DeclareInputText{175}{\.Z} \DeclareInputText{176}{\textdegree} \DeclareInputMath{177}{\pm} \DeclareInputText{178}{\v C} \DeclareInputText{179}{\l} \DeclareInputText{180}{\v Z} \DeclareInputText{181}{\textquotedblleft} \DeclareInputText{182}{\P} \DeclareInputText{183}{\textperiodcentered} \DeclareInputText{184}{\v z} \DeclareInputText{185}{\v c} \DeclareInputText{186}{\ooalign{s\crcr\hidewidth\raise-.31ex\hbox{\scriptsize,}\hidewidth}} \DeclareInputText{187}{\guillemotright} \DeclareInputText{188}{\OE} \DeclareInputText{189}{\oe} \DeclareInputText{190}{\" Y} \DeclareInputText{191}{\.z} \DeclareInputText{192}{\@tabacckludge`A} \DeclareInputText{193}{\@tabacckludge'A} \DeclareInputText{194}{\^A} \DeclareInputText{195}{\u A} \DeclareInputText{196}{\"A} \DeclareInputText{197}{\@tabacckludge'C} \DeclareInputText{198}{\AE} \DeclareInputText{199}{\c C} \DeclareInputText{200}{\@tabacckludge`E} \DeclareInputText{201}{\@tabacckludge'E} \DeclareInputText{202}{\^ E} \DeclareInputText{203}{\" E} \DeclareInputText{204}{\@tabacckludge`I} \DeclareInputText{205}{\@tabacckludge'I} \DeclareInputText{206}{\^I} \DeclareInputText{207}{\" I} \DeclareInputText{208}{\D} \DeclareInputText{209}{\@tabacckludge'N} \DeclareInputText{210}{\@tabacckludge`O} \DeclareInputText{211}{\@tabacckludge'O} \DeclareInputText{212}{\^O} \DeclareInputText{213}{\H O} \DeclareInputText{214}{\"O} \DeclareInputText{215}{\@tabacckludge'S} \DeclareInputText{216}{\H U} \DeclareInputText{217}{\@tabacckludge`U} \DeclareInputText{218}{\@tabacckludge'U} \DeclareInputText{219}{\^ U} \DeclareInputText{220}{\"U} \DeclareInputText{221}{\k E} \DeclareInputText{222}{\ooalign{T\crcr\hidewidth\raise-.31ex\hbox{\scriptsize,}\hidewidth}} \DeclareInputText{223}{\ss} \DeclareInputText{224}{\@tabacckludge`a} \DeclareInputText{225}{\@tabacckludge'a} \DeclareInputText{226}{\^a} \DeclareInputText{227}{\u a} \DeclareInputText{228}{\"a} \DeclareInputText{229}{\@tabacckludge'c} \DeclareInputText{230}{\ae} \DeclareInputText{231}{\c c} \DeclareInputText{232}{\@tabacckludge`e} \DeclareInputText{233}{\@tabacckludge'e} \DeclareInputText{234}{\^e} \DeclareInputText{235}{\"e} \DeclareInputText{236}{\@tabacckludge`\i} \DeclareInputText{237}{\@tabacckludge'\i} \DeclareInputText{238}{\^\i} \DeclareInputText{239}{\"\i} \DeclareInputText{240}{\d} \DeclareInputText{241}{\@tabacckludge'n} \DeclareInputText{242}{\@tabacckludge`o} \DeclareInputText{243}{\@tabacckludge'o} \DeclareInputText{244}{\^o} \DeclareInputText{245}{\H o} \DeclareInputText{246}{\"o} \DeclareInputText{247}{\@tabacckludge's} \DeclareInputText{248}{\H u} \DeclareInputText{249}{\@tabacckludge`u} \DeclareInputText{250}{\@tabacckludge'u} \DeclareInputText{251}{\^u} \DeclareInputText{252}{\"u} \DeclareInputText{253}{\k e} \DeclareInputText{254}{\ooalign{t\crcr\hidewidth\raise-.31ex\hbox{\scriptsize,}\hidewidth}} \DeclareInputText{255}{\"y} \makeatother \endinput %% %% End of file `latin10.def'. --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) text/plain (text body -- kept) text/plain (text body -- kept) --- From olaf at infovore.xs4all.nl Wed Nov 14 12:43:44 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] To C++ or not to C++ In-Reply-To: <87adxtmdi7.fsf@infovore.xs4all.nl> Message-ID: <87wv0t1ssv.fsf_-_@infovore.xs4all.nl> As some of you may be aware, the Omega team did some work to get their version of the texlive tree to compile cleanly with a C++ compiler. Most of this hasn't been folded back into the Sebastian's master tree. I'm wondering whether this is worth the trouble. Pro: - A C++ compiler tends to catch problems in C that C compilers ignore. - This _may_ make it easier to write extensions in C++. (But compare pdfTeX which is mixed C/C++.) Con: - A C++ compiler will refuse legitimate C idioms, which have to be worked around with somewhat contorted code. - It implies changes to libraries like zlib, which would have to be reapplied whenever we upgrade the library sources. We already make changes to get these libraries to fit our configure setup, but... - When I did a CC=c++ ./configure on my box, the AC_CONST test resulted in a line #define const in c-auto.h. I'm not sure whether C++ allows this test to fail, but fail it did, and the result was that without manual intervention the code could not compile. The AC_C_CONST test in autoconf 2.52 is identical. Note that doing something like CC=cc ./configure make CC=c++ is just asking for trouble... So my question is, how C++-proof do we want the sources to be? (Note: I'm not denying that libkpathsea needs cleaning anyway.) -- Olaf Weber [M]ost likely other e-mail programs like Eudora are not designed to enable virus replication. -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp#Faqs From sebastian.rahtz at computing-services.oxford.ac.uk Wed Nov 14 22:41:50 2001 From: sebastian.rahtz at computing-services.oxford.ac.uk (sebastian.rahtz@computing-services.oxford.ac.uk) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] To C++ or not to C++ In-Reply-To: <87wv0t1ssv.fsf_-_@infovore.xs4all.nl> References: <87adxtmdi7.fsf@infovore.xs4all.nl> <87wv0t1ssv.fsf_-_@infovore.xs4all.nl> Message-ID: <15346.58654.682472.842237@gargle.gargle.HOWL> Olaf Weber writes: > So my question is, how C++-proof do we want the sources to be? I found it odd when John started down this road. It would not have occurred to me as an issue, I must say. I guess its up to John to justify it.... Sebastian From plaice at example.au Thu Nov 15 00:14:26 2001 From: plaice at example.au (John Plaice) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] To C++ or not to C++ In-Reply-To: <87wv0t1ssv.fsf_-_@infovore.xs4all.nl>; from olaf@infovore.xs4all.nl on Wed, Nov 14, 2001 at 12:43:44PM +0100 References: <87adxtmdi7.fsf@infovore.xs4all.nl> <87wv0t1ssv.fsf_-_@infovore.xs4all.nl> Message-ID: <20011115101426.A20940@omega.cse.unsw.edu.au> Hello everyone, The reasoning behind making most or all of telive C++ - safe is that with omega, we wish to move all development to C++. Given that we have been asked on several occasions, and have agreed to, incorporate many features available in tools like pdfTeX and eTeX, it just seems a lot easier to make sure that all of the programs compile with C++. Furthermore, with the anticipated new font metric files, it would just be so much simpler to write the routines once, and to have them link in without any problems, same thing for the possible reorganization of the data and control flow when using multiple TeX-related applications. I did find two serious casting errors in (o)dvipsk, in which strings were cast to an enumerated type, which can't possibly be correct ! See file emspecial.c, in which they are currently commented out at http://omega.cse.unsw.edu.au/viewcvs/viewcvs.cgi/texlive/source/TeX/texk/dvipsk/emspecial.c And there is a lot of code in many applications where there are implicit casts from double to int. In my opinion, the code is a lot easier to read when those casts are made explicit, because that is truly part of the behavior of the program. This is perhaps not true of casts from (void*) upon each call to xmalloc or xrealloc. Anyway, now all of the code in TeX/texk has been changed to compile with c++, although there are two glitches that force you to type make CC='c++ -DFIXPT -DCPLUSPLUS' CXX=c++ -DCPLUSPLUS' in the web2c directory. The FIXPT comes from the fact that for some reason, John Hobby's optimizations for metapost and metafont using floating-point arithmetic do not work with the c++ compiler: this is probably just a problem with header files. The CPLUSPLUS comes from the fact that pdfTeX is mixed C/C++, and so the references to C programs in the C++ part are extern "C" { ... }, which must be removed when everything is compiled with C++. The only changes that I am not fully confident about, simply because there were so many, were in the TeX/texk/ps2pkm directory, where there implicit casts in every possible direction, and different files had different typedefs for the SAME type (I kid you not !), and something may have been broken. Now, with reference to the changes in zlib and xpfd, perhaps this was a mistake, in the sense that because it is well encapsulated, it would not be difficult to make sure that the references to zlib within web2c or other programs could be bracketed with extern "C" { ... }; , possibly with #ifdef __cplusplus ... #endif This was the approach taken with respect to t1lib and libwww in (o)xdvik, because libwww was just full of C enum structures that took full advantage of the fact that enums are just special kinds of int, and why fix code that works? I'm now working on making sure that the omega texlive tree is consistent with Olaf's latest web2c and with the TeXLive canonical tree. Finally, with respect to the AC_CONST test problem, I am not sure what the solution might be. Regards, John Plaice ---------------------------------------------------------------- On Wed, Nov 14, 2001 at 12:43:44PM +0100, Olaf Weber wrote: > As some of you may be aware, the Omega team did some work to get their > version of the texlive tree to compile cleanly with a C++ compiler. > Most of this hasn't been folded back into the Sebastian's master tree. > I'm wondering whether this is worth the trouble. > > Pro: > - A C++ compiler tends to catch problems in C that C compilers ignore. > - This _may_ make it easier to write extensions in C++. (But compare > pdfTeX which is mixed C/C++.) > > Con: > - A C++ compiler will refuse legitimate C idioms, which have to be > worked around with somewhat contorted code. > - It implies changes to libraries like zlib, which would have to be > reapplied whenever we upgrade the library sources. We already make > changes to get these libraries to fit our configure setup, but... > - When I did a > CC=c++ ./configure > on my box, the AC_CONST test resulted in a line > #define const > in c-auto.h. I'm not sure whether C++ allows this test to fail, but > fail it did, and the result was that without manual intervention the > code could not compile. The AC_C_CONST test in autoconf 2.52 is > identical. > > Note that doing something like > CC=cc ./configure > make CC=c++ > is just asking for trouble... > > So my question is, how C++-proof do we want the sources to be? > > (Note: I'm not denying that libkpathsea needs cleaning anyway.) > > -- > Olaf Weber > > [M]ost likely other e-mail programs like Eudora are not designed to enable > virus replication. > -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp#Faqs > _______________________________________________ > tex-pretest mailing list > tex-pretest@tug.org > http://tug.org/mailman/listinfo/tex-pretest From wl at gnu.org Wed Nov 14 14:42:19 2001 From: wl at gnu.org (Werner LEMBERG) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] latin9.def and latin10.def In-Reply-To: <20011114035222.A6844@bambam> References: <20011114035222.A6844@bambam> Message-ID: <20011114.144219.98854762.wl@gnu.org> > As you know in Europe will be a big change with euro and the > computers should be ready to display the euro character. I don't see > why LaTeX should not do that. Latin9, the replacement of Latin1 was > accepted at ISO a long time ago and Latin10, the replacement of > Latin2 was accepted few months ago. I have not seen any latin9.def > and latin10.def files to go with inputenc. latin-9 is part of the latest LaTeX version, latin10 not yet. > I prepared a version of this files, can you please have a look at > it? I would like to submitted at CTAN, but I have no clue how to do > that. You should send a bug report to latex-bugs@latex-project.org. The database is at http://www.latex-project.org/bugs.html Werner From plaice at example.au Thu Nov 15 07:47:22 2001 From: plaice at example.au (John Plaice) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] Omega and web2c In-Reply-To: <87r8r3lx2p.fsf@infovore.xs4all.nl>; from olaf@infovore.xs4all.nl on Mon, Nov 12, 2001 at 06:26:38PM +0100 References: <20011112164923.C15863@omega.cse.unsw.edu.au> <87r8r3lx2p.fsf@infovore.xs4all.nl> Message-ID: <20011115174722.A21322@omega.cse.unsw.edu.au> Olaf, There are lots of things in web2c/lib which are not useful to Omega, and for which Omega has much more general solutions, does that mean they should not be in web2c/lib? I doubt that anyone would say yes. The file recorder is a great idea, that should be made available as quickly as possible. If you want to include it for other stuff, that's OK, but the syntax is likely to change as we refine the omega doc packaging system, which is written but not released. One possibility is to leave a function call in lib/openclose.c, and then to write the code elsewhere under omegadir. John On Mon, Nov 12, 2001 at 06:26:38PM +0100, Olaf Weber wrote: > John Plaice writes: > > > Olaf, yes i am listening :) > > I'll have a look at the changes this evening. > > Ok, > > If possible, get me a list of things in web2c/kpathsea that you think > need to be changed -- esp. some arguments why a particular mod is good > would be useful. > > Note that I've not enabled the 'file recorder' in Omega. Given the > place where those changes come in (lib/openclose.c) I _am_ wondering > whether it would be a useful feature for "normal" TeX as well. > Arguments for/against? > > -- > Olaf Weber > > [M]ost likely other e-mail programs like Eudora are not designed to enable > virus replication. > -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp#Faqs > _______________________________________________ > tex-pretest mailing list > tex-pretest@tug.org > http://tug.org/mailman/listinfo/tex-pretest From olaf at infovore.xs4all.nl Thu Nov 15 16:25:33 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] To C++ or not to C++ In-Reply-To: <20011115101426.A20940@omega.cse.unsw.edu.au> References: <87adxtmdi7.fsf@infovore.xs4all.nl> <87wv0t1ssv.fsf_-_@infovore.xs4all.nl> <20011115101426.A20940@omega.cse.unsw.edu.au> Message-ID: <874rnw5a4y.fsf@infovore.xs4all.nl> John Plaice writes: > Hello everyone, > The reasoning behind making most or all of telive C++ - safe > is that with omega, we wish to move all development to C++. > Given that we have been asked on several occasions, and have > agreed to, incorporate many features available in tools like > pdfTeX and eTeX, it just seems a lot easier to make sure that > all of the programs compile with C++. >From my point of view -- we're still at a point where the code is written to allow it to compile on pre-ANSI C compilers. It would (IMHO) already be nice if we could simply assume that things like protoypes and such work everywhere. For the kpathsea library, I think it would be nice to clean the header files to the poiint where 'extern "C" { ... }' makes the library usable for C++ code. (Remember that this can be a shared library.) Whether the library is compiled with C or C++ doesn't matter at that point. Something similar applies to the supporting code in web2c/lib. Of course pdfTeX does manage its setup in a mixed C/C++ environment. I see no a priory reason why Omega couldn't do the same. (I do understand that you might consider that more trouble than it's worth.) ... > I did find two serious casting errors in (o)dvipsk, in which > strings were cast to an enumerated type, which can't possibly > be correct ! See file emspecial.c, in which they are currently > commented out at > http://omega.cse.unsw.edu.au/viewcvs/viewcvs.cgi/texlive/source/TeX/texk/dvipsk/emspecial.c That's truly weird. ... > Now, with reference to the changes in zlib and xpfd, perhaps this > was a mistake, in the sense that because it is well encapsulated, > it would not be difficult to make sure that the references to > zlib within web2c or other programs could be bracketed with > extern "C" { ... }; , possibly with #ifdef __cplusplus ... #endif The zlib header files are already "C++-correct". The zlib code itself is K&R, and would have to be redone every time zlib is updated. Something similar holds for the libtiff, libwww, and other bits. ... > I'm now working on making sure that the omega texlive tree is consistent > with Olaf's latest web2c and with the TeXLive canonical tree. > Finally, with respect to the AC_CONST test problem, I am not sure > what the solution might be. My personal preference is to keep the C bits C, but make sure that at the places where we might reasonably want to interface with C++ code, this is actually possible. That is, web2c/lib remains C, but gets an 'extern "C" { ... }' in its header so a C++ compiler can use it. In a similar vein, we'd need to get texmfmp.c to work nicely with C and C++ compilers, but in this case we can (mostly) generate native C++ code when applicable... -- Olaf Weber [M]ost likely other e-mail programs like Eudora are not designed to enable virus replication. -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp#Faqs From olaf at infovore.xs4all.nl Thu Nov 15 18:43:59 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] Omega and web2c In-Reply-To: <20011115174722.A21322@omega.cse.unsw.edu.au> References: <20011112164923.C15863@omega.cse.unsw.edu.au> <87r8r3lx2p.fsf@infovore.xs4all.nl> <20011115174722.A21322@omega.cse.unsw.edu.au> Message-ID: <87zo5o3p5s.fsf@infovore.xs4all.nl> John Plaice writes: > Olaf, > There are lots of things in web2c/lib which are not useful to Omega, > and for which Omega has much more general solutions, does that mean > they should not be in web2c/lib? I doubt that anyone would say yes. Well, lib is just an ar archive, so you should only get those objects from which you actually use things linked in. At present, web2c/lib contains stuff that is too difficult or cumbersome to implement in Pascal, and which _tends_ to be of general use to the programs. In general I'm reluctant to put code in there that is of use to just a single program (like the file recorder code as implemented) when it does "burden" every other program. Especially if instead of burdening other programs a few changes will allow the code to enrich them instead. > The file recorder is a great idea, that should be made available as > quickly as possible. If you want to include it for other stuff, > that's OK, but the syntax is likely to change as we refine the omega > doc packaging system, which is written but not released. > One possibility is to leave a function call in lib/openclose.c, and > then to write the code elsewhere under omegadir. It seems to me there are two "interesting" options: - implement the file recorder more or less as given, except that it is available to other programs (in particular the TeX family) that can use it. - just define a function pointer for a callback out of openclose, which will be set to non-NULL by those programs that want some action taken. The advantage of the first variant is that the packaging system you're designing might thus also work for the TeX family. The advantage of the second variant is that web2c/lib/openclose.c doesn't need to be updated if you change the syntax of the recorder. -- Olaf Weber [M]ost likely other e-mail programs like Eudora are not designed to enable virus replication. -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp#Faqs From olaf at infovore.xs4all.nl Thu Nov 15 19:11:46 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] Omega and web2c In-Reply-To: <87zo5o3p5s.fsf@infovore.xs4all.nl> References: <20011112164923.C15863@omega.cse.unsw.edu.au> <87r8r3lx2p.fsf@infovore.xs4all.nl> <20011115174722.A21322@omega.cse.unsw.edu.au> <87zo5o3p5s.fsf@infovore.xs4all.nl> Message-ID: <87snbf52fx.fsf@infovore.xs4all.nl> John, Following up on my messages, I hope it is clear that I'm not being difficult for the sake of being difficult. It is one of the problems in dealing with developers of different yet closely related and interdependent projects that there are different agendas to be reconciled. Given the relationship between web2c and omega I'm the one who ends up having to pull on the breaks every now and then, asking for decisions to be reconsidered or implementations to be changed. Which brings me to another point: I'd like to make a small change in the way otangle is built. At present, we need both tangle and otangle because they encode different assumptions about the string pool in their output. We also need to bootstrap otangle with itself because it runs into a limit of tangle. What I propose to do is raise the problematic limit in tangle, so that otangle can built by tangle. Then the whole "otangleboot" mess can be removed from the makefiles. WDYT? -- Olaf Weber [M]ost likely other e-mail programs like Eudora are not designed to enable virus replication. -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp#Faqs From plaice at example.au Fri Nov 16 15:32:28 2001 From: plaice at example.au (John Plaice) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] Omega and web2c In-Reply-To: <87r8r3lx2p.fsf@infovore.xs4all.nl>; from olaf@infovore.xs4all.nl on Mon, Nov 12, 2001 at 06:26:38PM +0100 References: <20011112164923.C15863@omega.cse.unsw.edu.au> <87r8r3lx2p.fsf@infovore.xs4all.nl> Message-ID: <20011117013228.A816@omega.cse.unsw.edu.au> Olaf, I have carefully gone through all the changes, and have put together a diff file, attached here, for the differences. I have done the following: - renamed the routines for the file recorder, so that other programs may use them. - added casts in most of the change files, so that they are C++-clean. doing this has an ulterior motive: most of the time the casts are from ASCIIcode to char, which is a move from unsigned char to char for most of the applications. But as we make all of these applications Unicode-compatible, with ranges from 0-10FFFF, we are going to have to solve this problem once and for all. Having casts in the code helps us pinpoint the problems more easily. - got rid of the use of -1 for no file format open calls to open_input this was used in bibtex.ch and mp.ch, I believe. There is already a special flag, called kpse_last_format, which is in fact used exactly for this purpose by kpsewhich.c - running everything through the C++ compiler allowed me to find several inconsistencies between definition and declaration. The code is not yet on the omega CVS repository. This will be done soon. Cheers, John Plaice ----------- On Mon, Nov 12, 2001 at 06:26:38PM +0100, Olaf Weber wrote: > John Plaice writes: > > > Olaf, yes i am listening :) > > I'll have a look at the changes this evening. > > Ok, > > If possible, get me a list of things in web2c/kpathsea that you think > need to be changed -- esp. some arguments why a particular mod is good > would be useful. > > Note that I've not enabled the 'file recorder' in Omega. Given the > place where those changes come in (lib/openclose.c) I _am_ wondering > whether it would be a useful feature for "normal" TeX as well. > Arguments for/against? > > -- > Olaf Weber > > [M]ost likely other e-mail programs like Eudora are not designed to enable > virus replication. > -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp#Faqs > _______________________________________________ > tex-pretest mailing list > tex-pretest@tug.org > http://tug.org/mailman/listinfo/tex-pretest --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) application/octet-stream --- From plaice at example.au Fri Nov 16 15:40:59 2001 From: plaice at example.au (John Plaice) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] otangle and other stuff In-Reply-To: <87snbf52fx.fsf@infovore.xs4all.nl>; from olaf@infovore.xs4all.nl on Thu, Nov 15, 2001 at 07:11:46PM +0100 References: <20011112164923.C15863@omega.cse.unsw.edu.au> <87r8r3lx2p.fsf@infovore.xs4all.nl> <20011115174722.A21322@omega.cse.unsw.edu.au> <87zo5o3p5s.fsf@infovore.xs4all.nl> <87snbf52fx.fsf@infovore.xs4all.nl> Message-ID: <20011117014059.B816@omega.cse.unsw.edu.au> Olaf, Don't worry about being difficult, most people think I am too ;) With respect to otangle, its raison d'etre comes from the way strings are handled. Strings in TeX are numbered from 256, with positions 0-255 as pre-encoded strings for 8-bit characters. Omega uses a similar technique, with the strings numbered from 65536. And that is the only significant difference between tangle and otangle. When we move to 31-bit characters, this approach becomes unfathomable. So, strings will be handled completely differently internally, and the planned implementation will allow us to use a tangle with additional capacity. How does that sound? John Plaice ----------- On Thu, Nov 15, 2001 at 07:11:46PM +0100, Olaf Weber wrote: > John, > > Following up on my messages, I hope it is clear that I'm not being > difficult for the sake of being difficult. > > It is one of the problems in dealing with developers of different yet > closely related and interdependent projects that there are different > agendas to be reconciled. > > Given the relationship between web2c and omega I'm the one who ends up > having to pull on the breaks every now and then, asking for decisions > to be reconsidered or implementations to be changed. > > > Which brings me to another point: I'd like to make a small change in > the way otangle is built. At present, we need both tangle and otangle > because they encode different assumptions about the string pool in > their output. We also need to bootstrap otangle with itself because > it runs into a limit of tangle. > > What I propose to do is raise the problematic limit in tangle, so that > otangle can built by tangle. Then the whole "otangleboot" mess can be > removed from the makefiles. > > WDYT? > > -- > Olaf Weber > > [M]ost likely other e-mail programs like Eudora are not designed to enable > virus replication. > -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp#Faqs > _______________________________________________ > tex-pretest mailing list > tex-pretest@tug.org > http://tug.org/mailman/listinfo/tex-pretest From olaf at infovore.xs4all.nl Fri Nov 16 18:28:36 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:20 2005 Subject: [tex-pretest] Omega and web2c In-Reply-To: <20011117013228.A816@omega.cse.unsw.edu.au> References: <20011112164923.C15863@omega.cse.unsw.edu.au> <87r8r3lx2p.fsf@infovore.xs4all.nl> <20011117013228.A816@omega.cse.unsw.edu.au> Message-ID: <87itcasjzv.fsf@infovore.xs4all.nl> John Plaice writes: > Olaf, > I have carefully gone through all the changes, and have put together > a diff file, attached here, for the differences. I have done the > following: > - renamed the routines for the file recorder, so that other programs > may use them. I don't guarantee that I'll incorporate them verbatim (mkstemp is not that portable, for example), but I do intend to put the file recorder in. > - added casts in most of the change files, so that they are C++-clean. > doing this has an ulterior motive: most of the time the casts are > from ASCIIcode to char, which is a move from unsigned char to char > for most of the applications. But as we make all of these applications > Unicode-compatible, with ranges from 0-10FFFF, we are going to > have to solve this problem once and for all. Having casts in the code > helps us pinpoint the problems more easily. I see that you found my preferred methods: the new xmallocarray and the stringcast macro. But note that xmallocarray already adds 1 to its size argument, which it seems you didn't always take advantage of. > - got rid of the use of -1 for no file format open calls to open_input > this was used in bibtex.ch and mp.ch, I believe. There is already > a special flag, called kpse_last_format, which is in fact used > exactly for this purpose by kpsewhich.c Sounds like a good call. > - running everything through the C++ compiler allowed me to find several > inconsistencies between definition and declaration. I'll look at those as well. > The code is not yet on the omega CVS repository. This will be done soon. If all goes well, 7.3.6 with these changes will be ready this weekend. -- Olaf Weber Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety. From olaf at infovore.xs4all.nl Fri Nov 16 18:17:04 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] otangle and other stuff In-Reply-To: <20011117014059.B816@omega.cse.unsw.edu.au> References: <20011112164923.C15863@omega.cse.unsw.edu.au> <87r8r3lx2p.fsf@infovore.xs4all.nl> <20011115174722.A21322@omega.cse.unsw.edu.au> <87zo5o3p5s.fsf@infovore.xs4all.nl> <87snbf52fx.fsf@infovore.xs4all.nl> <20011117014059.B816@omega.cse.unsw.edu.au> Message-ID: <87n11mskj3.fsf@infovore.xs4all.nl> John Plaice writes: > Don't worry about being difficult, most people think I am too ;) > With respect to otangle, its raison d'etre comes from the way > strings are handled. Strings in TeX are numbered from 256, with > positions 0-255 as pre-encoded strings for 8-bit characters. > Omega uses a similar technique, with the strings numbered from 65536. > And that is the only significant difference between tangle and otangle. That's what I found to be the only difference that I could not (trivially) fold into tangle. > When we move to 31-bit characters, this approach becomes unfathomable. > So, strings will be handled completely differently internally, and > the planned implementation will allow us to use a tangle with > additional capacity. It may interest you to know that my enlarged tangle can process the present omega.{web,ch} without problems (except for the string number issue). If you were to use utf8 for the messages in the web I think the present tangle could already handle things. Anyway, that's your problem to solve. > How does that sound? It sounds like we'll be able to dispense with otangle in the future. Expect the changes to show up in Web2C 7.3.6. -- Olaf Weber Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety. From olaf at infovore.xs4all.nl Sun Nov 18 14:04:57 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] Web2C 7.3.6 -- yet another pretest. Message-ID: <87wv0os006.fsf@infovore.xs4all.nl> I've just uploaded new sources, 7.3.6. As before, there's still stuff I need to do to get to something I really want to release. Compared to 7.3.5, the following has happened: - I've made various changes that should enable the sources to compile with a C++ compiler (though configure will not run correctly if you define $CC to be one). However, I've avoided making such changes to pdfTeX -- I'd rather that Han The Thanh be the judge of that. - Adapted from Omega is the filename recorder. It can be enabled with --recorder for the TeX and MF family of programs, and leaves a .fls file. Omega unconditionally enables it, and uses .ofl. Todo: - The src-specials still need to be documented in the manual pages. - Search algorithm needs revision. - Use libtool instead of klibtool. - Possibly update the fontname files -- haven't checked their version yet. - Verify that all bits of the texmf tree are up-to-date. Ensure that omega/pdftex/etex basic texmf trees are up-to-date. Location ftp://ftp.tug.org/private/tex -- Olaf Weber Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety. From plaice at example.au Mon Nov 19 01:49:31 2001 From: plaice at example.au (John Plaice) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] Web2C 7.3.6 -- yet another pretest. In-Reply-To: <87wv0os006.fsf@infovore.xs4all.nl>; from olaf@infovore.xs4all.nl on Sun, Nov 18, 2001 at 02:04:57PM +0100 References: <87wv0os006.fsf@infovore.xs4all.nl> Message-ID: <20011119114931.A19056@omega.cse.unsw.edu.au> Olaf, I found a real problem, and I think it needs clarifying before a solution is chosen. File kpathsea/types.h contains the following code: > /* Booleans. */ > #ifdef __cplusplus > /* `true' and `false' are reserved words in C++. Sigh. Although sizeof > (bool) may not equal sizeof (boolean), so this isn't completely > correct, we never rely on the size of the type. */ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > #define boolean bool > #else > /* NeXT wants to define their own boolean type. */ > #ifndef HAVE_BOOLEAN > #define HAVE_BOOLEAN > typedef enum { false = 0, true = 1 } boolean; > #endif /* not HAVE_BOOLEAN */ > #endif /* not C++ */ Now whenever an obvious assumption is made, sooner or later it will turn out to be untrue :) File web2c/lib/texmfmp.c contains the following code: > static struct option long_options[] > = { { DUMP_OPTION, 1, 0, 0 }, > { "help", 0, 0, 0 }, > { "ini", 0, (int *) &iniversion, 1 }, as well as > } else if (ARGUMENT_IS (DUMP_OPTION)) { > dump_name = optarg; > if (!user_progname) user_progname = optarg; > dumpoption = true; Finally, file web2c/texd.h contains the following code: > #ifdef INITEX > EXTERN boolean iniversion ; > EXTERN boolean dumpoption ; > EXTERN boolean dumpline ; > #endif /* INITEX */ So, guess what happens when all this gets compiled with CC=c++ and then we type ./tex --fmt=tex --ini .... The dumptoption gets set to true, and then the iniversion gets set to 1. But since the iniversion is not 4 bytes, the dumptoption gets clobbered and reset to 0! Now obviously, this particular problem can be solved by just redefining iniversion to be int. But what sort of guarantees do we have that this problem is not lurking in other places? What should be done? Regards, John Plaice ------------------------------------------------------------------------ On Sun, Nov 18, 2001 at 02:04:57PM +0100, Olaf Weber wrote: > I've just uploaded new sources, 7.3.6. As before, there's still stuff > I need to do to get to something I really want to release. Compared > to 7.3.5, the following has happened: > > - I've made various changes that should enable the sources to compile > with a C++ compiler (though configure will not run correctly if you > define $CC to be one). However, I've avoided making such changes to > pdfTeX -- I'd rather that Han The Thanh be the judge of that. > - Adapted from Omega is the filename recorder. It can be enabled with > --recorder for the TeX and MF family of programs, and leaves a .fls > file. Omega unconditionally enables it, and uses .ofl. > > Todo: > > - The src-specials still need to be documented in the manual pages. > - Search algorithm needs revision. > - Use libtool instead of klibtool. > - Possibly update the fontname files -- haven't checked their version > yet. > - Verify that all bits of the texmf tree are up-to-date. > Ensure that omega/pdftex/etex basic texmf trees are up-to-date. > > Location > ftp://ftp.tug.org/private/tex > > -- > Olaf Weber > > Do not meddle in the affairs of sysadmins, > for they are quick to anger and have no need for subtlety. > _______________________________________________ > tex-pretest mailing list > tex-pretest@tug.org > http://tug.org/mailman/listinfo/tex-pretest From eliz at is.elta.co.il Mon Nov 19 09:33:38 2001 From: eliz at is.elta.co.il (Eli Zaretskii) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] Web2C 7.3.6 -- yet another pretest. In-Reply-To: <20011119114931.A19056@omega.cse.unsw.edu.au> (message from John Plaice on Mon, 19 Nov 2001 11:49:31 +1100) References: <87wv0os006.fsf@infovore.xs4all.nl> <20011119114931.A19056@omega.cse.unsw.edu.au> Message-ID: <200111190833.KAA08896@is.elta.co.il> > From: John Plaice > Date: Mon, 19 Nov 2001 11:49:31 +1100 > > Now whenever an obvious assumption is made, sooner or later it will turn > out to be untrue :) Not if you avoid bugs ;-) > ./tex --fmt=tex --ini .... > > The dumptoption gets set to true, and then the iniversion gets set to 1. > But since the iniversion is not 4 bytes, the dumptoption gets clobbered > and reset to 0! > > Now obviously, this particular problem can be solved by just redefining > iniversion to be int. But what sort of guarantees do we have that this > problem is not lurking in other places? > > What should be done? I think this: { "ini", 0, (int *) &iniversion, 1 }, should instead say this: { "ini", 0, (boolean *) &iniversion, true }, But if this doesn't work somehow, perhaps due to requirements of getopt, a possible solution is to not use the C++ types at all. Just define your own `typedef boolean' with values TRUE and FALSE and use that. It's a PITA, but so is C++ in general ;-) From olaf at infovore.xs4all.nl Mon Nov 19 07:47:06 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] Web2C 7.3.6 -- yet another pretest. In-Reply-To: <20011119114931.A19056@omega.cse.unsw.edu.au> References: <87wv0os006.fsf@infovore.xs4all.nl> <20011119114931.A19056@omega.cse.unsw.edu.au> Message-ID: <871yivdzpx.fsf@infovore.xs4all.nl> John Plaice writes: > Olaf, > I found a real problem, and I think it needs clarifying before a solution > is chosen. > File kpathsea/types.h contains the following code: >> /* Booleans. */ >> #ifdef __cplusplus >> /* `true' and `false' are reserved words in C++. Sigh. Although sizeof >> (bool) may not equal sizeof (boolean), so this isn't completely >> correct, we never rely on the size of the type. */ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A known bad assumption, actually. Just one that hasn't, so far, bitten us in practice. One place where you're likely to get bitten, apart from getopt, is option passing between pieces of code compiled with C and with a C++ compiler. One solution is to define boolean as 'int', whenever we can get away with that, even if the compiler is C++. Even so, the getopt bits probably have to change. Incidentally, it is also a illustration of why it is not a good idea to add casts just to shut up finicky compilers. -- Olaf Weber Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety. From plaice at example.au Tue Nov 20 06:25:41 2001 From: plaice at example.au (John Plaice) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] C++ boolean In-Reply-To: <871yivdzpx.fsf@infovore.xs4all.nl>; from olaf@infovore.xs4all.nl on Mon, Nov 19, 2001 at 07:47:06AM +0100 References: <87wv0os006.fsf@infovore.xs4all.nl> <20011119114931.A19056@omega.cse.unsw.edu.au> <871yivdzpx.fsf@infovore.xs4all.nl> Message-ID: <20011120162541.A27927@omega.cse.unsw.edu.au> Olaf, the following patch seems to work, and nothing else needs to be changed. Apart from this file, my kpathsea directory is synced with yours. John On Mon, Nov 19, 2001 at 07:47:06AM +0100, Olaf Weber wrote: > John Plaice writes: > > > Olaf, > > I found a real problem, and I think it needs clarifying before a solution > > is chosen. > > > File kpathsea/types.h contains the following code: > > >> /* Booleans. */ > >> #ifdef __cplusplus > >> /* `true' and `false' are reserved words in C++. Sigh. Although sizeof > >> (bool) may not equal sizeof (boolean), so this isn't completely > >> correct, we never rely on the size of the type. */ > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > A known bad assumption, actually. Just one that hasn't, so far, > bitten us in practice. > > One place where you're likely to get bitten, apart from getopt, is > option passing between pieces of code compiled with C and with a C++ > compiler. > > One solution is to define boolean as 'int', whenever we can get away > with that, even if the compiler is C++. > > Even so, the getopt bits probably have to change. > > Incidentally, it is also a illustration of why it is not a good idea > to add casts just to shut up finicky compilers. > > -- > Olaf Weber > > Do not meddle in the affairs of sysadmins, > for they are quick to anger and have no need for subtlety. > _______________________________________________ > tex-pretest mailing list > tex-pretest@tug.org > http://tug.org/mailman/listinfo/tex-pretest diff --unified -r ./types.h /home/plaice/texlive/source/TeX/texk/kpathsea/types.h --- ./types.h Mon Dec 30 05:39:43 1996 +++ /home/plaice/texlive/source/TeX/texk/kpathsea/types.h Tue Nov 20 13:09:06 2001 @@ -21,10 +21,12 @@ /* Booleans. */ #ifdef __cplusplus -/* `true' and `false' are reserved words in C++. Sigh. Although sizeof - (bool) may not equal sizeof (boolean), so this isn't completely - correct, we never rely on the size of the type. */ -#define boolean bool +/* `true' and `false' are reserved words in C++, as is the type bool. + But in web2c, boolean values are used for getopt options. Hence + sizeof (boolean) must equal sizeof (int). Therefore in c++, we + just typedef int to boolean. 'true' and 'false' get converted + without any problems to 1 and 0, respectively. */ +typedef int boolean; #else /* NeXT wants to define their own boolean type. */ #ifndef HAVE_BOOLEAN --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) text/plain (text body -- kept) --- From plaice at example.au Tue Nov 20 07:28:03 2001 From: plaice at example.au (John Plaice) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] Web2C 7.3.6 -- yet another pretest. In-Reply-To: <87wv0os006.fsf@infovore.xs4all.nl>; from olaf@infovore.xs4all.nl on Sun, Nov 18, 2001 at 02:04:57PM +0100 References: <87wv0os006.fsf@infovore.xs4all.nl> Message-ID: <20011120172803.A28235@omega.cse.unsw.edu.au> Olaf, Included here are two change files, one for kpathsea, the other for web2c. Without these changes, GNU c++ 3.0 balks. I have not included modifications to web2c/tiedir, web2c/pdftexdir, web2c/otps, web2c/omegafonts Regards, John Plaice ------------------------------------------------- On Sun, Nov 18, 2001 at 02:04:57PM +0100, Olaf Weber wrote: > I've just uploaded new sources, 7.3.6. As before, there's still stuff > I need to do to get to something I really want to release. Compared > to 7.3.5, the following has happened: > > - I've made various changes that should enable the sources to compile > with a C++ compiler (though configure will not run correctly if you > define $CC to be one). However, I've avoided making such changes to > pdfTeX -- I'd rather that Han The Thanh be the judge of that. > - Adapted from Omega is the filename recorder. It can be enabled with > --recorder for the TeX and MF family of programs, and leaves a .fls > file. Omega unconditionally enables it, and uses .ofl. > > Todo: > > - The src-specials still need to be documented in the manual pages. > - Search algorithm needs revision. > - Use libtool instead of klibtool. > - Possibly update the fontname files -- haven't checked their version > yet. > - Verify that all bits of the texmf tree are up-to-date. > Ensure that omega/pdftex/etex basic texmf trees are up-to-date. > > Location > ftp://ftp.tug.org/private/tex > > -- > Olaf Weber > > Do not meddle in the affairs of sysadmins, > for they are quick to anger and have no need for subtlety. > _______________________________________________ > tex-pretest mailing list > tex-pretest@tug.org > http://tug.org/mailman/listinfo/tex-pretest From olaf at infovore.xs4all.nl Tue Nov 20 18:46:18 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] Web2C 7.3.6 -- yet another pretest. In-Reply-To: <20011120172803.A28235@omega.cse.unsw.edu.au> References: <87wv0os006.fsf@infovore.xs4all.nl> <20011120172803.A28235@omega.cse.unsw.edu.au> Message-ID: <876685cp3p.fsf@infovore.xs4all.nl> John Plaice writes: > Olaf, > Included here are two change files, > one for kpathsea, the other for web2c. Er, included where, exactly? > Without these changes, GNU c++ 3.0 balks. I've already made a number of changes after Nelson Beebe reminded me that testing a compile with a C++ would not be a bad idea. Apart from pdftex and the FIXPT issue, I get a reasonably clean compile now. > I have not included modifications to > web2c/tiedir, web2c/pdftexdir, web2c/otps, web2c/omegafonts I've added a tie.ch change file to contain the changes from tie-2.4. Seemed cleaner. For the boolean issue I figure it is best to just use 'int', and '#define' true and false if needed. (C doesn't guarantee the size of an enum -- which means the getopt code would still be a problem.) In the getopt calls, remove the casts '(int *)'. In web code, if you need an integer instead of a boolean to use as an option (e.g. 'ipc_on') declared it as 'c_int_type', which was introduced precisely for that purpose. Also, I've had the opportunity to try a compile on an IRIX box with SGI's compilers. pdftex fails, because pdfcrypt has some functions declared 'static inline'. SGI's make also stumbled over a few lines in omega.mk which should begin with a tab, but don't. Version 7.3.7 will contain all this. -- Olaf Weber Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety. From plaice at example.au Wed Nov 21 00:27:10 2001 From: plaice at example.au (John Plaice) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] Web2C 7.3.6 -- yet another pretest. In-Reply-To: <876685cp3p.fsf@infovore.xs4all.nl>; from olaf@infovore.xs4all.nl on Tue, Nov 20, 2001 at 06:46:18PM +0100 References: <87wv0os006.fsf@infovore.xs4all.nl> <20011120172803.A28235@omega.cse.unsw.edu.au> <876685cp3p.fsf@infovore.xs4all.nl> Message-ID: <20011121102710.A1338@omega.cse.unsw.edu.au> The FIXPT issue i have resolved by preventing the .asm files from being loaded if we are compiling with C++. Your tiedir changes work for me. I forgot to include the files. John On Tue, Nov 20, 2001 at 06:46:18PM +0100, Olaf Weber wrote: > John Plaice writes: > > > Olaf, > > Included here are two change files, > > one for kpathsea, the other for web2c. > > Er, included where, exactly? > > > Without these changes, GNU c++ 3.0 balks. > > I've already made a number of changes after Nelson Beebe reminded me > that testing a compile with a C++ would not be a bad idea. Apart from > pdftex and the FIXPT issue, I get a reasonably clean compile now. > > > I have not included modifications to > > web2c/tiedir, web2c/pdftexdir, web2c/otps, web2c/omegafonts > > I've added a tie.ch change file to contain the changes from tie-2.4. > Seemed cleaner. > > For the boolean issue I figure it is best to just use 'int', and > '#define' true and false if needed. (C doesn't guarantee the size of > an enum -- which means the getopt code would still be a problem.) In > the getopt calls, remove the casts '(int *)'. In web code, if you > need an integer instead of a boolean to use as an option > (e.g. 'ipc_on') declared it as 'c_int_type', which was introduced > precisely for that purpose. > > Also, I've had the opportunity to try a compile on an IRIX box with > SGI's compilers. pdftex fails, because pdfcrypt has some functions > declared 'static inline'. > > SGI's make also stumbled over a few lines in omega.mk which should > begin with a tab, but don't. > > Version 7.3.7 will contain all this. > > -- > Olaf Weber > > Do not meddle in the affairs of sysadmins, > for they are quick to anger and have no need for subtlety. > _______________________________________________ > tex-pretest mailing list > tex-pretest@tug.org > http://tug.org/mailman/listinfo/tex-pretest diff --unified -r kpathsea/line.c /home/plaice/texlive/source/TeX/texk/kpathsea/line.c --- kpathsea/line.c Sun Nov 18 08:25:56 2001 +++ /home/plaice/texlive/source/TeX/texk/kpathsea/line.c Tue Nov 20 16:30:03 2001 @@ -23,8 +23,7 @@ #define BLOCK_SIZE 75 char * -read_line (f) - FILE *f; +read_line P1C(FILE *, f) { int c; unsigned limit = BLOCK_SIZE; diff --unified -r kpathsea/types.h /home/plaice/texlive/source/TeX/texk/kpathsea/types.h --- kpathsea/types.h Mon Dec 30 05:39:43 1996 +++ /home/plaice/texlive/source/TeX/texk/kpathsea/types.h Tue Nov 20 13:09:06 2001 @@ -21,10 +21,12 @@ /* Booleans. */ #ifdef __cplusplus -/* `true' and `false' are reserved words in C++. Sigh. Although sizeof - (bool) may not equal sizeof (boolean), so this isn't completely - correct, we never rely on the size of the type. */ -#define boolean bool +/* `true' and `false' are reserved words in C++, as is the type bool. + But in web2c, boolean values are used for getopt options. Hence + sizeof (boolean) must equal sizeof (int). Therefore in c++, we + just typedef int to boolean. 'true' and 'false' get converted + without any problems to 1 and 0, respectively. */ +typedef int boolean; #else /* NeXT wants to define their own boolean type. */ #ifndef HAVE_BOOLEAN diff --unified -r web2c/bibtex.ch /home/plaice/texlive/source/TeX/texk/web2c/bibtex.ch --- web2c/bibtex.ch Sat Nov 17 04:56:13 2001 +++ /home/plaice/texlive/source/TeX/texk/web2c/bibtex.ch Thu Nov 15 21:41:54 2001 @@ -332,7 +332,6 @@ end; @y @ File opening will be done in C. -@d no_file_path = -1 @z @x [39] Do file closing in C. @@ -394,7 +393,7 @@ @y name_ptr := 1; free (name_of_file); -name_of_file := xmalloc_array (ASCII_code, length (file_name) + 1); +name_of_file := xmalloc_array (ASCII_code, length (file_name) + 2); @z @x @@ -516,9 +515,9 @@ @ {Leave room for the \.., the extension, the junk byte at the beginning, and the null byte at the end.} - name_of_file := xmalloc_array (ASCII_code, strlen (cmdline (optind)) + 5); + name_of_file := xmalloc_array (ASCII_code, strlen (cmdline (optind)) + 4 + 2); strcpy (stringcast(name_of_file + 1), cmdline (optind)); - aux_name_length := strlen (name_of_file + 1); + aux_name_length := strlen (stringcast(name_of_file + 1)); @; aux_not_found: uexit (1); aux_found: {now we're ready to read the \.{.aux} file} @@ -555,7 +554,7 @@ if strcmp (stringcast(name_of_file + 1 + name_length - 3), 'aux') <> 0 then add_extension (s_aux_extension); {this also sets |name_length|} aux_ptr := 0; {initialize the \.{.aux} file stack} -if (not a_open_in(cur_aux_file,no_file_path)) then +if (not a_open_in(cur_aux_file,kpse_last_format)) then sam_you_made_the_file_name_wrong; @z @@ -731,7 +730,7 @@ if (not a_open_in(cur_aux_file)) then @y name_of_file[name_ptr] := 0; -if (not a_open_in(cur_aux_file, no_file_path)) then +if (not a_open_in(cur_aux_file, kpse_last_format)) then @z % [151] This goto gets turned into a setjmp/longjmp by ./convert -- diff --unified -r web2c/cpascal.h /home/plaice/texlive/source/TeX/texk/web2c/cpascal.h --- web2c/cpascal.h Tue Nov 20 16:38:39 2001 +++ /home/plaice/texlive/source/TeX/texk/web2c/cpascal.h Tue Nov 20 16:39:03 2001 @@ -257,7 +257,7 @@ extern TEXDLL void mainbody P1H(void); /* generated by web2c */ /* openclose.c */ -extern boolean open_input P3H(FILE **, int, const_string fopen_mode); +extern boolean open_input P3H(FILE **, kpse_file_format_type, const_string); extern boolean open_output P2H(FILE **, const_string fopen_mode); extern void aclose P1H(FILE *); extern void recorder_change_filename P1H(string); diff --unified -r web2c/lib/openclose.c /home/plaice/texlive/source/TeX/texk/web2c/lib/openclose.c --- web2c/lib/openclose.c Sun Nov 18 10:00:15 2001 +++ /home/plaice/texlive/source/TeX/texk/web2c/lib/openclose.c Tue Nov 20 17:21:14 2001 @@ -13,9 +13,6 @@ extern unsigned namelength; /* For "file:line:error style error messages. */ extern string fullnameoffile; -/* For the filename recorder. */ -extern string recorder_name; -extern boolean recorder_enabled; /* Define some variables. */ string fullnameoffile = NULL; @@ -127,7 +124,7 @@ { free (nameoffile); namelength = strlen (fname); - nameoffile = xmalloc (namelength + 2); + nameoffile = (string) xmalloc (namelength + 2); strcpy (nameoffile + 1, fname); free (fname); } @@ -183,7 +180,7 @@ { free (nameoffile); namelength = strlen (fname); - nameoffile = xmalloc (namelength + 2); + nameoffile = (string) xmalloc (namelength + 2); strcpy (nameoffile + 1, fname); } diff --unified -r web2c/lib/texmfmp.c /home/plaice/texlive/source/TeX/texk/web2c/lib/texmfmp.c --- web2c/lib/texmfmp.c Tue Nov 20 16:46:53 2001 +++ /home/plaice/texlive/source/TeX/texk/web2c/lib/texmfmp.c Tue Nov 20 16:47:35 2001 @@ -1511,7 +1511,7 @@ #endif name = (string)xmalloc (len + 1); #ifndef Omega - strncpy (name, &strpool[strstart[s]], len); + strncpy (name, (const_string) &strpool[strstart[s]], len); #else /* Don't use strncpy. The strpool is not made up of chars. */ for (i=0; i=Hprime) r-=Hprime; @@ -153,7 +153,7 @@ int *hfind P2C(char*,s,Hcell*,htab) { register Hcell *p; - register cnt = Hprime; + register int cnt = Hprime; failure = (Hcell *) 0; p = &htab[hash(s)]; do { @@ -219,7 +219,7 @@ int get_int P1C(char *,s) { - register i, d, neg; + register int i, d, neg; if (s==NULL) goto bad; for (neg=0;; s++) if (*s=='-') neg=!neg; @@ -241,7 +241,7 @@ */ float get_float P1C(char *,s) { - register d, neg, digits; + register int d, neg, digits; register float x, y; digits = 0; @@ -425,7 +425,7 @@ */ int scan_desc_line P2C(int,f, char*,lin) { - static lastcode; + static int lastcode; char *s; s = &strpool[poolsize]; @@ -823,7 +823,7 @@ float Beval P2C(float*,xx, float, t) { float zz[4]; - register i, j; + register int i, j; for (i=0; i<=3; i++) zz[i]=xx[i]; for (i=3; i>0; i--) for (j=0; jtype != Expose) return; @@ -339,10 +337,7 @@ static void -mf_mapstatus (w, data, ev) - Widget w; - XtPointer data; - XEvent *ev; +mf_mapstatus P3C(Widget, w, XtPointer, data, XEvent*, ev) { switch (ev->type) { --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) text/plain (text body -- kept) text/plain (text body -- kept) --- From olaf at infovore.xs4all.nl Wed Nov 21 10:03:47 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] Web2C 7.3.6 -- yet another pretest. In-Reply-To: <20011121102710.A1338@omega.cse.unsw.edu.au> References: <87wv0os006.fsf@infovore.xs4all.nl> <20011120172803.A28235@omega.cse.unsw.edu.au> <876685cp3p.fsf@infovore.xs4all.nl> <20011121102710.A1338@omega.cse.unsw.edu.au> Message-ID: <87y9l0bimk.fsf@infovore.xs4all.nl> John Plaice writes: > The FIXPT issue i have resolved by preventing the .asm files from > being loaded if we are compiling with C++. That looks like the best option, at least at present. > Your tiedir changes work for me. > I forgot to include the files. Note that your use of kpse_last_format to say "no format" is wrong. -- Olaf Weber Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety. From te at informatik.uni-hannover.de Sat Nov 24 23:25:16 2001 From: te at informatik.uni-hannover.de (Thomas Esser) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] Web2C 7.3.6 -- yet another pretest. Message-ID: <200111242225.fAOMPFQ2008278@gauss.informatik.uni-hannover.de> > Also, I've had the opportunity to try a compile on an IRIX box with > SGI's compilers. pdftex fails, because pdfcrypt has some functions > declared 'static inline'. Right, SUN Workshop compilers (4.2) also don't compile that file. Someone has reported a problem in texk/web2c/Makefile using SUN's make. The failiure was just in the new code for loops over possibly empty variables (I think that one has to make sure that no format / mem /base file is enables to actually trigger the bug). The new code is much nicer, so I hope that there is a way to make it work somehow... Thomas From plaice at example.au Mon Nov 26 00:29:12 2001 From: plaice at example.au (John Plaice) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] configuring a new tool Message-ID: <20011126102912.A22712@omega.cse.unsw.edu.au> Hi everyone, I wish to add the omegadocpack program to the texk directory, and could someone explain to me what I have to do to get the configure and Makefile scripts consistent with how the other directories are set up? Thanks, John Plaice From sebastian.rahtz at computing-services.oxford.ac.uk Mon Nov 26 00:44:06 2001 From: sebastian.rahtz at computing-services.oxford.ac.uk (sebastian.rahtz@computing-services.oxford.ac.uk) Date: Fri Feb 18 15:06:21 2005 Subject: [tex-pretest] configuring a new tool In-Reply-To: <20011126102912.A22712@omega.cse.unsw.edu.au> References: <20011126102912.A22712@omega.cse.unsw.edu.au> Message-ID: <15361.33350.32103.403746@spqr.oucs.ox.ac.uk> John Plaice writes: > > I wish to add the omegadocpack program to the texk directory, > and could someone explain to me what I have to do to get the > configure and Makefile scripts consistent with how the other > directories are set up? take a simple one like "dtl", copy its files, and then hack away... thats the way I created some of them. crude but effective. then it needs adding to top-level places as well. sebastian From olaf at infovore.xs4all.nl Sun Nov 25 21:31:23 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:22 2005 Subject: [tex-pretest] Web2C 7.3.6 -- yet another pretest. In-Reply-To: <200111242225.fAOMPFQ2008278@gauss.informatik.uni-hannover.de> References: <200111242225.fAOMPFQ2008278@gauss.informatik.uni-hannover.de> Message-ID: <87lmgu8uec.fsf@infovore.xs4all.nl> Thomas Esser writes: >> Also, I've had the opportunity to try a compile on an IRIX box with >> SGI's compilers. pdftex fails, because pdfcrypt has some functions >> declared 'static inline'. > Right, SUN Workshop compilers (4.2) also don't compile that file. Someone > has reported a problem in texk/web2c/Makefile using SUN's make. The > failiure was just in the new code for loops over possibly empty variables > (I think that one has to make sure that no format / mem /base file is > enables to actually trigger the bug). The new code is much nicer, so I > hope that there is a way to make it work somehow... I don't think I've seen that report myself. On the other hand, I do think saying "use GNU make" is far more acceptable as a workaround than to say "use gcc". So depending on how bad it is, I _may_ decide not to fix this. -- Olaf Weber Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety. From te at informatik.uni-hannover.de Mon Nov 26 18:22:11 2001 From: te at informatik.uni-hannover.de (Thomas Esser) Date: Fri Feb 18 15:06:22 2005 Subject: [tex-pretest] configuring a new tool Message-ID: <200111261722.fAQHMBfJ007383@gauss.informatik.uni-hannover.de> > I wish to add the omegadocpack program to the texk directory, > and could someone explain to me what I have to do to get the > configure and Makefile scripts consistent with how the other > directories are set up? You just need to add a --without-* option in texk/withenable.ac and add your subdir to the PKGS variable in texk/configure.in. Thomas From olaf at infovore.xs4all.nl Tue Nov 27 13:47:48 2001 From: olaf at infovore.xs4all.nl (Olaf Weber) Date: Fri Feb 18 15:06:22 2005 Subject: [tex-pretest] Web2C 7.3.7 -- yet another pretest. In-Reply-To: <87wv0os006.fsf@infovore.xs4all.nl> References: <87wv0os006.fsf@infovore.xs4all.nl> Message-ID: <87lmgswfbf.fsf@infovore.xs4all.nl> Olaf Weber writes: I've just uploaded new sources, 7.3.7. As before, there's still stuff I need to do to get to something I really want to release. Compared to 7.3.6, the following has happened: - I've made various changes that should enable the sources to compile with a C++ compiler (though configure will not run correctly if you define $CC to be one). However, I've avoided making such changes to pdfTeX -- I'd rather that Han The Thanh be the judge of that. - The configure script for the top directory is now present in the web2c tarball, rather than the pdftexlibs tarball. I may have broken some things, though. - Updated fontname files. Todo: - The src-specials still need to be documented in the manual pages. - Search algorithm needs revision. - Use libtool instead of klibtool. - Verify that all bits of the texmf tree are up-to-date. Ensure that omega/pdftex/etex basic texmf trees are up-to-date. Location ftp://ftp.tug.org/private/tex -- Olaf Weber Do not meddle in the affairs of sysadmins, for they are quick to anger and have no need for subtlety. From sebastian.rahtz at computing-services.oxford.ac.uk Wed Nov 28 00:20:21 2001 From: sebastian.rahtz at computing-services.oxford.ac.uk (sebastian.rahtz@computing-services.oxford.ac.uk) Date: Fri Feb 18 15:06:22 2005 Subject: [tex-pretest] Web2C 7.3.7 and texlive In-Reply-To: <87wv0os006.fsf@infovore.xs4all.nl> References: <87wv0os006.fsf@infovore.xs4all.nl> Message-ID: <15364.8117.568962.159553@spqr.oucs.ox.ac.uk> for those following the TeXLive source development tree, it is now fully in sync with Olaf's 7.3.7, although I added a few things to some configure.in files for programs wanting -lm. You'll see those come through, Olaf, maybe you can check I am not being dumb. I get a clean compile end to end of the TeXlive stuff, I am glad to say (for the record, this includes more then web2c 7.3.7, stuff like dvipdfm and tex4ht) sebastian