mailing-list for TeXmacs Users

[Wolfgang Jansen <address@hidden>]

Henri Lesourd wrote:
> Wolfgang Jansen wrote:

> I meant: for important bugs, using the TeXmacs
> mailing list is better than only a bug report
> in the bugzilla.
I sent the bug report to this list.
> > > > 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.
>
> Although I only tested recently with 4.2.1, it should
> work with earlier versions...
>
> In any case, I cannot telepathically investigate a
> problem which seems clearly Sun-specific: very clearly,
> it doesn't occurs elsewhere, otherwise the mailing
> list would be flooded with emergency reports.
>
>
> > 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.
>
> The potential users usually do not compile from
> source. And when a codebase is big, issues with
> the compiler become more tricky and frequent.
The potential users compile from sources if there is no binary
(or very old ones only) for their platform as is the case
for TeXmacs -> SUN.
> But I cannot say much more, I'm not among the
> distro guys in the TeXmacs project.
>
>
> > > 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.
> In this respect, "you" is also people like yourself. As
No, not me. I did not write the TeXmacs main page promising
support for "all major UNIX platforms".
> for me, I am only a small part of the global "you", and
> I'm usually not involved with these issues, at least not
> currently.
OK, I did not know who is who in TeXmacs.
Because you answered I thought it was your job
(sorry, for that misunderstanding).
Then I'm wondering why no people responsible for configuring,
C++ compilation and the like does answer.
> Thus as soon as the global "you" does more, the
> set of supported platforms grows.
>
>
> > > 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?
>
> No, my job is focussed on something else than
> solving the configure problems. If I see that
> a discussion starts and I can help, I will
> do it, but in the current situation, I have
> no access to any Sun platform, thus I don't
> know how to do it.
OK, see above.
> Since 1998, the design & development of TeXmacs
> has always been done by amateurs, by the way.
Amateurs? That's my impression, too.
> > 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.
> Because we regularly review the mailing list,
> but since September, we are focussed on solving
> cross platform & GUI issues rather than this.
>
> The other reason is that the default rule
> for platform-specific bugs is that the people
> who can access the platform are those who should
> send a patch.
This cannot be the default rule. In any case, it must be clarified
that the bug is platform specific. This has to be done by both parties:
the platform's owners and the software's providers.
After that clarification and after determination of the program parts
to be modified the software providers may ask the platform owners
to work it out if the bug can be fixed at the platform side (this is not 
possible,
e.g., if the software does not follow standards).  The software 
providers must
have given their placet for modification (modification beyond pure 
private use).

> > 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.
>
> It looks like the makefile cannot see all the
> directories, because it's rather unlikely that
> there are missing files.
1) Not missing files, missing X11 functions:
"Xutf8LookupString" does not belong to the X11R6 standard,
it is an extension provided by XFree86.
This means, it is the TeXmacs programmers' job to fix the bug
(i.e. to go back to the standards).
2) There are even too many files:
"/usr/include/floatingpoint.h" seems to be SUN specific.
Unfortunately, as a system file it must not be modified.
A solution may be renaming "quadruple -> Quadruple"
in the TeXmacs sources (and this needs the placet
of the TeXmacs providers).


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