Re: [Texmacs-dev] Current work, nogencc and tree in generic programming

[David Allouche]

Sorry for the previous message... my fingers slipped on a keyboard 
shortcut I did not know :(

So, let us start again...

On Sunday 28 April 2002 16:45, Joris van der Hoeven wrote:
> I am testing your changes. I am sorry for my blunt answer to your
> anti-gencc manifesto, but I am also sorry that you did not understand
> the reason behind this answer: I meant to make it clear that a profound

[snip]

> make many changes in the C++ code in the near future). Also, I might
> have spared you some time as to further changes which will be
> necessary.

I wanted to do it now for several reasons:

1. I wanted a completely crossreferenced Doxygen, missing
cross-references due to the unresolved smart pointer's operator->
dramatically reduced the usefulness of the tool. There were probably
other hidden problemes too.

2. I wanted to use templates for my project, just because C++ has
templates and I know how to program in C++.

3. Since we are doing a lot of promotion, improving
developper-friendliness is as much a priority as improving
user-friendliness.

Anyway I think there is no point in debating on that. The work is done, 
the problem now is getting the work at level for inclusion in the main
distribution, and that requires some work I cannot do by myself, like
fixing the installer and testing the build on all platforms.

> 1. The compilation starts with error messages
>
> make[1]: Entering directory
> `/home/vdhoeven/texmacs/contrib/allouche/TeXmacs-1.0.0.1-nogencc-0.5-sr
>c/src' makefile:73: Deps/fromtm.d: No such file or directory
> makefile:73: Deps/scheme.d: No such file or directory
> makefile:73: Deps/totm.d: No such file or directory
> makefile:73: Deps/tree.d: No such file or directory
> ...
>
> This is not very logical

That is indeed a bit dirty. The problem is that it uses gmake features
for automatic dependences resolution.

The gmake info documentation (node: How Makefiles Are Remade) says:

    To this end, after reading in all makefiles, `make' will consider
    each as a goal target and attempt to update it.

When first compiling from a clean distribution, the .d files are not
present, so the first pass inclusion fails, and then the .d files are
made.

I will fix that by defining a "deps" target to create the .d files, and
move the removal of those files (as well as the Objects/*.rpo files) in a
new "maintainer-clean" target.

> 2. The compilation time is much longer than before, even though we only
>    use -O2: this is bad.

That is true. That is a problem with the stupid automatic template
instanciation of g++2 (I do not know if g++3 is any smarter). A template
is instanciated (its code is generated) at the point where it is first
needed in a translation unit. This causes a lot of duplicate code
generation. At link time, the collect wrapper recompiles the units as
necessary until there is no duplicate code. The resulting information
about where templates must be instanciated is stored in the Objects/*.rpo
files, so subsequent compilations generate almost no duplicate code.

We can speed up the compilation by moving the removal of the .rpo files
to the maintainer-clean target.

We could also increase the size of the compilation units, by compiling
only .cc files containing only #include "xxx.cc" directives. However I
find this solution way too hackish because it allows the .cc files to be 
no longer self-contained.

Finally, we can also reduce the amound of generated code by designing 
partial specializations as subclasses for fundations classes. That is 
nice, but it may be a bit difficult.

> 3. You systematically use
>
> -I Basic/Data -I Basic/Misc -I Basic/System -I Basic/Types -I Resource
> -I Window -I Typeset -I Edit -I Convert -I Texmacs -I Guile
>
> in the compilation options, even when some of them are not necessary.

Why does that bothers you? The makefile could indeed be designed to be 
more savvy, but I do not think that would buy us anything and that would 
have a maintenance cost.

Anyway, I will work to fix it for the next release.

> 4. It might have been nice to change all .gen.h to .hh.
> I did not know 4 years ago that it is was possible to use
> the .hh suffix, but this is better for highlighting in Emacs.

> 6. What are the comments of the form
>
> // Local Variables:
> // mode: c++
> // c-basic-offset: 2
> // End:
>
> doing at the end of each file?

Those comments are directives for Emacs. They tell it to open the file in 
c++ mode (regardless of the file name extension), and use a base 
indentation of two spaces. See the node "Local Variables in Files" in the 
emacs manual.


> 5. The makefile breaks at the linking stage:
>
[snip]
> Objects/instanciations.o: In function `hashmap_iterator_rep<unsigned
> long, void *> type_info function':
> Objects/instanciations.o(.gnu.linkonce.t.__tft20hashmap_iterator_rep2ZU
>lZPv+0x11): undefined reference to `iterator_rep<unsigned long>
> type_info function'
> Objects/instanciations.o(.gnu.linkonce.t.__tft20hashmap_iterator_rep2ZU
>lZPv+0x17): undefined reference to `iterator_rep<unsigned long>
> type_info node' collect2: ld returned 1 exit status
> make[1]: ***
> [/home/vdhoeven/texmacs/contrib/allouche/TeXmacs-1.0.0.1-nogencc-0.5-sr
>c/TeXmacs-1.0.0.1/bin/texmacs.bin] Error 1
> make[1]: Leaving directory
> `/home/vdhoeven/texmacs/contrib/allouche/TeXmacs-1.0.0.1-nogencc-0.5-sr
>c/src' make: *** [TEXMACS] Error 2

That is weird. Here, it compiles and run fine. My gcc version is:
gcc version 2.95.4 20011002 (Debian prerelease)

It appears that the iterator<X> classes are not properly instanciated. I 
will provide a tentative fix in the next release.

I'm quite tired of working around the problems in g++2 template 
instanciation system. When the changes are incorporated into the 
mainline, I will work to fix dirtiness which does not compile with g++3, 
so we will have hopefully much less problems.

> More comments will follow as soon as you have a working version for me.
> It is important that the change does not induce any kind of performance
> loss whatsoever. For instance, it should be checked that -O2 is as
> efficient as -O3 with the extra options.

That has been checked. The next version will also includes changes to 
avoid some uneeded reference counting, I mesured a gain of 15% in 
performance on a simple test: open a big document, type 9 characters 
waiting after each keystroke for the display update to be complete, 
remove the 9 characters while waiting the same way, then quit TeXmacs 
without saving changes.

But I do not understand what you want to do with the -O2 and -O3 options.
--

                                  -- David --