mailing-list for TeXmacs Users

[Wolfgang Jansen <address@hidden>]

Henri Lesourd wrote:
> 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.
Someone must have worked out the configuration.
This is the person who is responsible.
Or is your answer to understand as follows:
We have done something, we offer this to the world for use,
we even established a mailing list for discussion and bug reports,
but there is nobody to maintain our stuff.
> > > Since 1998, the design & development of TeXmacs
> > > has always been done by amateurs, by the way.
> > Amateurs? That's my impression, too.
>
> Eh, that's the way lots of OSS projects
> work.
Do you think that successful OSS projects are produced
and maintained by bloody amateurs? Be sure this is not the case.
Even if all contributors are unpaid people
(this is usually the case) there are always some
experienced contributors watching consistence
and quality of the product.
> 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 !
So, if it was clear from by bug report that TeXmacs
violated standards, why did the TeXmacs developers
not fix the bug in the course of half a year?
> > 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).
> We are not "providers". The way it usually
You (or your colleagues) are the providers:
it is _your_ announcement at http://www.texmacs.org.
Why do you not accept the responsibility for your product?
> 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 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).
>
> Aha: now you are coming closer to the root
> of the problem.
This part of discussion could have been started half year ago.
The TeXmacs developers (to avoid the term "providers")
did not answer.
> 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).
There may be many places where the result
of the function is needed. Can the function simply
be switched off? If it was so simple
why has this not already been done?
> 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.
No, it is your part! You violated the standard.
And debugging/testing a program that follows
the standard should be possible also at your platform.
> 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:
> > "/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).
> The placet is simple to obtain: fix the
> 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".
Is it really not design related? It may be
that capitals in identifiers have been reserved
for specific purpose, or it may be that it is planned
to introduce explicitly the name "Quadruple".

In any case, this bug is not caused by the
TeXmacs developers and it is my part to
provide a bug fix. Since you promised the placet,
I did the necessary modifications.
I add then in patch "quadruple.tar.gz".

The problem of "Xutf8LookupString" is still open.
And there is the next bug (see attachment "color.bug"
for compiler messages): type "color" seems to be unknown.
In fact, I did not find a definition in TeXmacs'
header files.

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


./Typeset/Boxes/Modifier/change_boxes.cpp:355: error: expected unqualified-id 
before numeric constant
./Typeset/Boxes/Modifier/change_boxes.cpp:357: error: expected ',' or '...' 
before numeric constant
./Typeset/Boxes/Modifier/change_boxes.cpp:365: error: prototype for 
'highlight_box_rep::highlight_box_rep(path, box, SI, SI, SI, tree, color, 
color)' does not match any in class 'highlight_box_rep'
./Typeset/Boxes/Modifier/change_boxes.cpp:352: error: candidates are: 
highlight_box_rep::highlight_box_rep(const highlight_box_rep&)
./Typeset/Boxes/Modifier/change_boxes.cpp:357: error:                 
highlight_box_rep::highlight_box_rep(path, box, SI, SI, SI, tree, color)
./Typeset/Boxes/Modifier/change_boxes.cpp: In constructor 
'highlight_box_rep::highlight_box_rep(path, box, SI, SI, SI, tree, color, 
color)':
./Typeset/Boxes/Modifier/change_boxes.cpp:367: error: expected identifier 
before numeric constant
./Typeset/Boxes/Modifier/change_boxes.cpp:367: error: expected `(' before 
numeric constant
./Typeset/Boxes/Modifier/change_boxes.cpp:367: error: expected `{' before 
numeric constant
./Typeset/Boxes/Modifier/change_boxes.cpp: At global scope:
./Typeset/Boxes/Modifier/change_boxes.cpp:367: error: expected unqualified-id 
before numeric constant
./Typeset/Boxes/Modifier/change_boxes.cpp: In member function 'virtual void 
highlight_box_rep::display(renderer_rep*)':
./Typeset/Boxes/Modifier/change_boxes.cpp:409: error: 'shad' was not declared 
in this scope
./Typeset/Boxes/Modifier/change_boxes.cpp: At global scope:
./Typeset/Boxes/Modifier/change_boxes.cpp:593: error: expected ',' or '...' 
before numeric constant
./Typeset/Boxes/Modifier/change_boxes.cpp: In function 'box 
highlight_box(path, box, SI, SI, SI, tree, color)':
./Typeset/Boxes/Modifier/change_boxes.cpp:594: error: 'shad' was not declared 
in this scope
gmake[1]: *** [Objects/change_boxes.o] Error 1
gmake[1]: Leaving directory `/home/wjansen/TeXmacs-1.0.6.14-src/src'
gmake: *** [TEXMACS] Error 2

Attachment: quadruple.tar.gz
Description: application/gzip