mailing-list for TeXmacs Users

[Henri Lesourd <address@hidden>]

Wolfgang Jansen wrote:

> 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.
If confirmed, this would undoubtedly be a
problem to correct.


> > 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?

Not always. In any case, one cannot write to
those ones, thus it cannot be related to the
bug you describe.


> > 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?

I meant: for important bugs, using the TeXmacs
mailing list is better than only a bug report
in the bugzilla.


> > > 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.

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
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.

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.

Since 1998, the design & development of TeXmacs
has always been done by amateurs, by the way.


> 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.

It is a long-running problem that since a long
time, a full-time engineer is missing to complete
the TeXmacs team and solving issues like the one
you mention. Rather, all the current TeXmacs developers
are more or less employed as researchers in universities.


> 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.