Subject: mailing-list for TeXmacs Users
List archive
From : Henri Lesourd <address@hidden>- To: Wolfgang Jansen <address@hidden>
- Cc: address@hidden
- Subject: Re: [TeXmacs] segmentation fault
- Date: Mon, 23 Jun 2008 21:08:30 +0200
Wolfgang Jansen wrote:
Henri Lesourd wrote:
Wolfgang Jansen wrote:Then I'm wondering why no people responsible for configuring,
C++ compilation and the like does answer.
Because there is no funding for serving
the salary of such a guy. But if you
can find one, you should not hesitate,
you are welcomed.
Since 1998, the design & development of TeXmacsAmateurs? That's my impression, too.
has always been done by amateurs, by the way.
Eh, that's the way lots of OSS projects
work.
Although IMHO the positive side of this
amateur spirit brings much more benefits
than inconvenients, if the negative side
really annoys you, you should remember
that people usually don't work for free.
Thus as usual in OSS, the agenda is mainly
driven by the developers, *although* in the
case of TeXmacs, lots of care is still devoted
in listening to users.
But there is definitely one thing we cannot
do, namely spending too much time on easy,
but annoying and time-consuming tasks for
which advanced users could usually contribute.
Your problem with the Sun platform is that
although it is well-known, it is too much
minoritary to trigger such kind of advanced
user contribution (there are too few people).
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.
As for me, I know no other way, for I don't
know how to develop software when I can't
debug it, sorry.
In any case, it must be clarified
that the bug is platform specific.
This clearly stems from your report, it's not
something I should myself state !
This has to be done by both parties:We are not "providers". The way it usually
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).
works is much simpler, namely, when people
are in a situation where they can debug
a problem, they start to read the code,
and to hack till they can figure out
what exactly is happening, then they
fix the problem and send a patch.
It's only at that point that we as "providers",
as you say, can look at the patch and see if
it doesn't breaks something somewhere else in
the software.
If all is okay, we commit the patch, otherwise,
if there are other problems, either we fix those,
or either if we cannot do it, we kindly ask the
patch provider to fix the other problems.
In any case, the underlying rule is: if you
provide a patch, it's much more likely that
your problem will quickly be taken into account.
It looks like the makefile cannot see all the1) Not missing files, missing X11 functions:
directories, because it's rather unlikely that
there are missing files.
"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).
Aha: now you are coming closer to the root
of the problem.
As far as I saw, there is only one occurrence
of this function call in the TeXmacs codebase,
it's in string x_gui_rep::look_up_key().
Adding a #ifdef around the appropriate chunk
of C++ code is perhaps not very difficult
to do (either could you replace the function
call by the appropriate, 100% standard
one, or either could you find a way to
disable this call in such a way that it
doesn't breaks things).
And then you could *test* that you can
compile, and that TeXmacs still works.
Once you are done with this, you could
snapshot a patch, and send it to us.
In such circumstances, i.e., if you fix
such an annoying problem and we are sure
that your fix is correct, I can almost
guarantee that your patch will be included
in the next TeXmacs version.
In any case, the current discussion is
useful, because the next time we will
survey the mailing list, we will have
most of the information about how to
solve the problem you describe.
2) There are even too many files:The placet is simple to obtain: fix the
"/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).
problem on your platform, then send us
a patch. Usually, for things like this,
which are not design-related and only
solve problems in the software, the
answer is always "yes".
- Re: [TeXmacs] segmentation fault, (continued)
- Re: [TeXmacs] segmentation fault, Henri Lesourd, 06/20/2008
- Re: [TeXmacs] segmentation fault, Marc Lalaude-Labayle, 06/20/2008
- Re: [TeXmacs] segmentation fault, Henri Lesourd, 06/21/2008
- Re: [TeXmacs] segmentation fault, Wolfgang Jansen, 06/23/2008
- Re: [TeXmacs] segmentation fault, Henri Lesourd, 06/23/2008
- Re: [TeXmacs] segmentation fault, Wolfgang Jansen, 06/23/2008
- Re: [TeXmacs] segmentation fault, Henri Lesourd, 06/23/2008
- Re: [TeXmacs] segmentation fault, Wolfgang Jansen, 06/23/2008
- Re: [TeXmacs] segmentation fault, Henri Lesourd, 06/23/2008
- Re: [TeXmacs] segmentation fault, Wolfgang Jansen, 06/23/2008
- Re: [TeXmacs] segmentation fault, Henri Lesourd, 06/23/2008
- Re: [TeXmacs] segmentation fault, Wolfgang Jansen, 06/24/2008
- Re: [TeXmacs] segmentation fault, Henri Lesourd, 06/20/2008
Archive powered by MHonArc 2.6.19.