mailing-list for TeXmacs Users

[Wolfgang Jansen <address@hidden>]

Henri Lesourd wrote:
> Wolfgang Jansen wrote:
>
> > Henri Lesourd wrote:
> >
> > > Wolfgang Jansen wrote:
> > >
> > > > is a the impossibility of installing TeXmacs because
> > > > of errors in C++ code an important bug?
> > > These kinds of bug are as much bugs in the GNU toolchain
> > > as these are TeXmacs's C++ bugs.
> > Are you severe ?
>
> Undoubtedly, there is an epidemic of crass speech, these
> days ;-(...
>
>
> >   The bug is not somewhere in the GNU toolchain,
> > it is in TeXmacs: the error message is produced by g++ when compiling
> > one of the TeXmacs sources,
> Thank you very much, I know that *across versions of gcc*,
> compiling the TeXmacs sources can become broken.
>
> Sometimes this kind of thing is because gcc is becoming
> more standard compliant, and thus our code is wrong. And
> some other times a new version of gcc introduces a more
> or less subtle bug, for which we need to implement a
> workaround.
>
>
> > > > Half year ago I tried to install TeXmacs on SUN from sources
> > > > (the existing binary is rather old). Installation failed
> > > > because of errors in C++ code. My bug report from 12/14/07 seems
> > > > have to be forgotten: the last version just downloaded fails as well.
> > > > So, I still work with the holy trinity emacs/latex/xdvi.
> > > It's hard to debug autoconf-based makefiles, and if we
> > > don't have the appropriate machines and systems, it's
> > > even pretty impossible.
> >
> > I don't think that error reports of "configure" are machine specific.
>
> Your view of the GNU toolchain seems exceedingly naive: lots
What did you say about "crass speech"?
> of things, including the bugs in configure itself, can be
> more or less platform-dependent.
The next lines of my former mail makes clear that was not speaking about
general "configure", I spoke about the trial to copy/move some files.

> > As I mentioned in the bug report the reason is that the installation
> > tries to copy/move some files to disk locations not accessible
> > by a simple user.
>
> We are well aware of these kinds of issues, although I
> did not imagine there were some in the install *TOO* !
Sorry , I don't understand.
> > Once again, please have look at the bug report.
> > The solution may be just to skip over those parts of "configure"
> > after successful generation of "Makefile".
>
> Usually, the solution is not at all easy to implement,
> for which directories are world-readable or not is
> highly dependent on exactly which UNIX you use.
Standard locations as "/usr/local" have standard access rights, isn't so?
> Thank you for the hint; in any case, posting a mail
> about important bugs is always useful, the mailing
> list is reviewed more often.
I don't understand: are we not talking at the TeXmacs' mailing list?
If not, what is its address?
> > Sorry, the bug occurs deep in the C++ class dependencies.
> > I really do not understand which class to modify to fix the bug,
> > and I do not know which dependencies are disturbed
> > if I modify something.
>
> If there is a bug in compiling the C++ (not the other
> one involving moving files), then it's very probably
> related to the version of gcc: currently, the CVS
> compiles correctly with gcc >= 4.2.1.
Here, I'm running gcc 4.2.0.
BTW, it is my experience not use newest auxiliary software
(compilers, graphics tools etc.) for my own software offered to the world.
2 to 3 years old is fine: the newer auxiliary software is probably
downward compatible so many releases (if not I reduce the set of utilized
features to the common intersection), and one can expect
that the potential users have upgraded their platform within that time.
> > Even worse, the first C++ error (where installation stops) today
> > is at another place (Kernel/Containers/ntuple.hpp), and I do not
> > know how many may follow.
>
> A typical C/C++ compiler problem: only the first error
> message is significant, usually.
I know that.
> > In any case, I used "g++" for compilation. Is this an exotic compiler?
> > How did you manage to avoid the compilation errors?
>
> We use a more recent compiler, very probably. Try:
> gcc --version
>
> to obtain the version of yours.
I know that.
> > > Thus: we cannot afford spending very much time
> > > on such issues, especially in a context where
> > > the problem is also in dealing with debugging
> > > the autoconf / GNU toolchain mess, and in
> > > circumstances where, as well, users don't
> > > want to / cannot help on this.
> > The failure of "configure" is annoying but is not the killer.
> > The killer is the bug in C++ code.
> > Can you really not spend time to eliminate compilation errors?
>
> If we need to be sure it works on *all platforms*,
> this is a daunting task.
Not all platforms, but all you promised to support.
> > > > TeXmacs has lost at least one possible user,
> > > > and I warned my students to use such a buggy software.
> > > This was not a very sensible idea, for as soon as
> > > your students use TeXmacs on a widely spread UNIX
> > > brand (e.g. Ubuntu), it works perfectly.
> > So, you should restrict your software to specific target platforms only.
>
> De facto, that's more or less what we do.
>
>
> > The TeXmacs home page says "TeXMacs runs an all major UNIX
> > platforms and WINDOWS". You may believe it or not, SUN/Solaris is still
> > a major UNIX platform.
> The point is that usually, these issues are solved
> by the configure + automake toolchain, in such a
> way that sooner or later, things become sane again.
>
> But if on a given platform, nobody does the job of
> fixing the problems, then we are stuck, for the people
Isn't this your job?
Well, I may try to modify "configure" for non-privileged users.
But why do you ask for that specific help today, not half a year ago
when I reported the bug? Why did you (or your colleague) just answer
"Much to do, maybe not solved until christmas" and then silence?
I expected that the bug would be fixed.

The C++ bug half year ago is caused by missing function
"Xutf8LookupString" (this was know by my bug report),
today it is the class name "quadruple" that is the name
of a typdef in "/usr/include/floatingpoint.h".
I cannot add the X11 function nor can I remove/rename the typedef.
> of the core TeXmacs team do not enjoy an access to
> all the platforms currently in existence.
Once again: do announce at the TeXmacs home page (and at all other
related pages) only as many platforms as you can really support.

--
Dr. Wolfgang Jansen
University of Potsdam, Germany
mailto: address@hidden