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

[David Allouche]

On Sunday 28 April 2002 19:36, Joris van der Hoeven wrote:
>
> Yes, but like most good moves, it requires a lot of time,
> and David and I are not done yet.

It is really almost done.

I am really confident in the stability and quality of the converted code, 
what work is left falls in three categories:

1. Compilability: it does not compile at yours, but that will be fixed 
after a bit of fiddling with explicit template instanciations. BTW, I 
really need to know which version of g++ you are using. I am going to 
install the latest official g++2 release for testing purposes, when it 
compiles, I will consider that problem fixed.

2. Style: like the naming of files or emacs local variables. That is most 
of what we are discussing right now. It will be fixed really soon if we 
do not get tangled in stylistic arguments.

3. Installer: that is really the only problem I cannot handle by myself. 
I could possibly reverse engineer gendep to figure out the right compile 
and link options, but I think that is not really a wise solution. 
Moreover I will be unable to test it.


> > Also it is the occasion to add 'const's to make the code faster.
>
> Good idea, but *PLEASE*, everything in it's time.

I have already processed some of the fundation classes, that is the files 
in the Basic/Types directory (anyway I had to rewrite most of them) and 
the Basic/Data/tree.* files.

There are two kind of conversions:

1. arguments which were previously counted pointers are now const 
references to counted pointers. Some functions do assignement on 
parameter value, so those parameters are not converted. This change cause 
no change in semantics and bring a very noticeable speed-up. I speculate 
that performing reference counting of parameter passing caused a lot of 
uneeded processor cache misses.

2. Constructed returned counted references are now qualified as const. 
That probably brings no performance improvement, but is sanity measure 
since it prevents the programmer from assigning away the return value of 
functions. Since TeXmacs' code has no const-correctness provisions, this 
modification can only prevent code to compile and cannot change the 
semantics of existing code.

Example:
   string insert_one (string s, int pos, char ins);
becomes
   const string insert_one (const string& s, int pos, char ins);


On Sunday 28 April 2002 19:06, Joris van der Hoeven wrote:
> > 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.
>
> I prefer using the .hh suffix. These directives are ugly and
> if they just serve under emacs, please let them out.

I will put in the .hh suffix and remove the mode directive.

But the c-basic-offset offset really makes it much easier to edit the 
source code for anyone who use different texmacs setting than you. BTW, 
Maybe specifying gnu indentation style would be cleaner.

I have no remorse whatsoever to add emacs-specific stuff in the source if 
it is really useful. After all, that is GNU project, so it is natural to 
make it GNU software friendly.


On Sunday 28 April 2002 18:55, Joris van der Hoeven wrote:
> > 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.
>
> I'll wait; it should be possible to fix such problems by
> cleverly using makefiles.

There is indeed a purely makefile based solution I can think of which 
avoids duplication:

Rename the actual src/makefile into src/nodeps.make and remove the line 
performing the inclusion of the Deps/*.d files. Create a new src/makefile 
which only includes src/nodeps.make and the Deps/*.d files. The base 
Makefile would first "$(MAKE) -f src/nodeps.make deps", and then "$(MAKE) 
-f src/makefile".

I will implement this.


> > > 2. The compilation time is much longer than before, even though we
> > > only use -O2: this is bad.
> >
> > 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
> > make the .cc files
>
> It is hackish, but it really speeds up compilation a lot.
> So this solution should probably be preferred;
> it was part of the .gen.make files before anyway.
> I *want* TeXmacs to compile reasonably fast.

I do not think this is a safe solution.

The problem is that the aggregated compilation approach considerably 
extends the scope of declarations. When converting TeXmacs I had to 
remove several static qualifiers because static symbols were used outside 
of the file in which they were defined. I also had to add bunches of 
#includes and declarations in some files. Being able to use symbols in 
other files without declaring them, and relying on the build system to 
define the scope of static symbols appears to me as really bad style.
I think source files must be self contained.

I propose a dual approach:

1. When fast compilation is needed, use aggregate compilations units that 
will allow to produce binary packages faster and make it easier to work 
on fundation code.

2. To ensure self containment of source files, all patchs and official 
releases should compilable with each source file in a separate 
compilation unit. This should not be a problem to use this system when 
developping the application since recompiles will only processe a few 
files.

I will implement this too.


PS: the next release with all that stuff implemented will come in a 
couple of days.
-- 

                                  -- David --