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

[Joris van der Hoeven]

On Mon, 29 Apr 2002, David Allouche wrote:

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

Maybe, but after that, I will need to check the code and
as I said before, this may take some time,
because I have lots of other things to do too.

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

I use 2.96 and 2.95.2.

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

Good.

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

Well, there will be some testers who might help you,
but I certainly won't have any time to go into such details now.
So you have to try the different options and their efficiency yourself
and read the documentation of autoconf. I will wait with making
the changes until I have a version which compiles more or less
as fast as the official one and which produces binaries of
the same size and efficiency.

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

Please *remove* these changes. I am sorry, but I want things to be
done in order. If we mix up several steps, then we will not be able
to make reliable compairisons between the efficiency gains/losses
in the different steps.

Once again, I really do not have much time to spend on this issue now;
I do not want to be forced to make any profound changes in a haste.

> 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);

We will discuss these issues later.
At the moment, I do not want any of these changes.
For a complex change like removing gencc,
I only accept all necessary changes.

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

Good.

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

Please follow the no garbage politics.

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

Well, I use GNU emacs for years and never had those indentation problems.
Garbage out!

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

Good I will wait.

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

Do whatever you want, but don't count on me to work with a version
which needs three times longer to be compiled. This is not only
a personal matter: some users already find it long to compile TeXmacs.
I accept a 20% increase in compilation time; not a 100% increase.

Also, aggregate compilation is cleanly organized in the official distribution.
You may just use exactly the same aggregations as is currently the case.
That would be good anyway, because it will allow to check the changes
that you have made more easily.

Once again: please keep as close to the current code as you can and
only make the necessary changes. The earlier I will have time to
go through the modifications and officialize them.