Re: [Texmacs-dev] [Announce] nogencc-0.6

[Joris van der Hoeven]

> > Please do not put any const's in the code yet.
> > I want to postpone *all* changes which do not *directly*
> > have to do with removing gencc. When making profound changes,
> > one has to be patient and rigourous. I do not want to repeat
> > this hundred times. In any case, you can make a backup of
> > what you have done and make the change later.
> 
> If you really want, I will do it, anyway that is only a small change to 
> do. But really, I think you are pushing incrementality a bit too far.

Yes please do so. I am not pushing anything; in fact *you* are pushing.
I am being rigourous. Please be rigourous too. I do not understand
why you can't wait with making other changes after removing gencc.

> > > In future releases, I will include a script which renames all
> > > files back the original name, so diff would not be confused.
> >
> > Yes, please do so. And maybe a script for the opposite direction too.
> 
> I will do the script for the opposite transform.

Great.

> > > I will not disable automatic template instanciation. Once the
> > > .rpo files have been generated, that cause no increase in compilation
> > > time. Actually, it even decrease compilation time since only needed
> > > template methods are instanciated. And the .rpo files can be
> > > generated rather quickly by using a first pass of non-optimizing
> > > compilation, and they could even be included in the distribution,
> > > since they are platform independant and compatible across versions of
> > > g++2.
> >
> > Yes, but it may also affect the runtime performance and
> > the size of the executable. Please test these issues.
> 
> Unless you provide your benchmarking tools, I cannot test runtime 
> performance reliably. About the size of the executable, it will not be 
> affected. Anyway, compiling C++ without automatic templates is a pain and 
> I am not willing to go through this.

Why is C++ without automatic templates a pain? It would be nice
to compare code size and efficiency before taking a decision.

> > > My reimplementation of reference counting, resources and events used
> > > a lot of useless indirections. That had probably no impact on
> > > generated code since that used only one-line inline methods, but it
> > > did have a mesurable impact on compilation time.
> >
> > I do *not* want you to reimplement reference counting yet.
> > Again, such changes have to be postponed after removing gencc.
> 
> Sorry, That was the first thing I did. The new implementation provides a 
> much better encapsulation. Especially with abstract classes, the derived 
> pointer class no longer have the responsability of incrementing the 
> reference count in constructors. That design was bad, very error prone...

Maybe, but the design has worked for more than a year.
I want absolutely no changes in the design as a result of
removing gencc. I know you have many great ideas,
but I would like you to carry them out one by one and
not all at the same time.

> Moreover, the new implementation allows for better containers which would 
> share implementations for a given type of counted pointer. That would 
> reduce the size of the code and even probably reduce compilation times.
> 
> Since you obviously have strong opinions against that, I will remove the 
> new reference conting just before you integrate the nogencc change. 

You obviously don't get my point: I don't argue against
the changes themselves, but against the *moment* to incorporate them.

> Removing that change will not be very easy, and then, the new 
> implementation will be much harder to maintain. At the moment, the new 
> refcounting is implemented with code in several hand-rewritten files, and 
> in the conversion filter.  I do not want the new implementation to lag 
> behind, so I am keeping it in a living body of code.
> 
> When I will rip it off for inclusion of nogencc in the mainline, I will 
> create a new branch just for the new refcounting implementation. Since I 
> do not want to maintain several branches, I will probably base my new 
> developments on that branch.
> 
> Making a backup of a part of code is useless. Code on which one work is 
> living. When you cut a part away, you generally cannot expect to be able 
> to merge it back in a few weeks. Changes you ask me to remove are twice a 
> waste of time for me because I have to throw them away. If I just make a 
> backup, when time to put it has come, I will realize half a dozen 
> modifications had been done on the master, so the backup will be 
> basically useless. Actually it will just be error prone because what was 
> appropriate in the old code may be wrong in the new code.

I am not responsable for your initiative to remove gencc.
I agree that I have been a bit blunt when you tried to discuss
this issue with me, but you obviously did not want to understand
the reasons behind this bluntness.

I have a habit of making major global changes in a very rigourous way.
This is a pain and very time consuming, but it pays off.
If you would have persisted to discuss this issue with me before,
then I would have told you so. Also, you are not responsible
for fixing hundreds of bugs: I am.

So I am very sorry for you if you have to do some work over again.
However, this is sometimes unevitable and you should blame
yourself for not having been rigourous about this: not me.
Anyway, reimplementing something what you have done before takes
only half of the time, because you still remember how to do it.

> > > > You probably did not remove the Emacs comments in the right way
> > > > at the end of the files.
> > >
> > > I will have a look. Weirdly, I have no such error here.
> >
> > Yes, but that is precisely one illustration why changes like removing
> > gencc are dangerous: it affects the stability of the system
> > in a different way on each platform.
> 
> That is fixed now. Really, I am not conviced yet, a warning about missing 
> newline is not what I call a stability problem.

Yes, but it shows how different compilers can be behave on stupid issues.
Anyway, it is impossible for me to convince you: the only way to convince
you would be to let *you* correct all bugs in TeXmacs from now on.
But that is clearly impossible right now.

> I do not say there are not still bugs around, but, damn! experimental 
> versions are here to break things, and to get feedback to find breakage 
> faster.

I don't accept this attitude: you never contributed and maintained
a significant part of the TeXmacs *code* (which does not mean that
you did not make significant contributions). Before that you have
proved that you can do this (for example, by implementing the new
style system) I can not trust the reliability of your code.
Although I trust it for 80%, I do not want to take a 20% risk
that some things are getting seriously messed up. I am willing
to take a 20% (or higher) risk for independent code,
but not for fundamental changes.

I also do not agree with your philosophy: experimental versions
are not there to break things. Ideally speaking, no versions break.
Through rigourous programming, programmers always have to attempt
approaching this ideal. Since no human is perfect, there will always
remain bugs around, which need to be corrected. The first responsable
for removing errors is the programmer, not the users.

TeXmacs has been built in several levels. The most basic level
gencc + the data types can be trusted now. This is *very important*,
because it allows me to localize other bugs much faster.
I get the impression that you want to push many changes through
in a very chaotical manner. This does not surprise me,
because you are not responsible for tracking down the bugs.
But I am clearly entitled to oppose this kind of behavior.

So expect me to resist against any change which does not have
to do with removing gencc (and even more after your obstination
in trying to let me do otherwise). As I said before, I will study
the diffs when you are done. At the first few changes which have
nothing to do with removing gencc, I will simply stop checking
and ask you to provide a clean nogencc version.

I decided to do you a pleasure with removing gencc,
which takes me a lot of time and which was not a priority.
In your turn you should do me a pleasure and allow me
to adopt the changes in a smooth and rigourous way.

> > >        version \ optim  | none        medium      high
> > > ------------------------+--------------------------------------------
> > > TeXmacs-1.0.0.1         | 1m55.820s   13m7.290s   12m47.790s
> > > nogencc-0.6 (SEPARATE)  | 3m22.500s   13m54.550s  13m59.570s
> > > nogencc-0.6 (AGGREGATE) | 1m41.090s   13m52.910s  14m10.760s
> > >
> > I obtained quite different timings: 35m for nogencc-0.6 and
> > 14m for the official distribution (using gcc 2.96 on a 1GHz laptop).
> 
> Weird... I got those timing on a PIII 700 with 384 megs of RAM.
> Could someone help us explain that?
> 
> By the way, I could not find any gcc-2.96 on GNU's website. I guess you 
> are using the infamous and notoriously broken RedHat compiler...

OK, I will install 2.95.3 and see whether the problems persist.
But maybe 2.95.4 is better?

> > > I am currently working on a version which actually compiles faster
> > > than the official one in all cases but unoptimized separate
> > > compilation.
> >
> > That is cool, but please don't cheat by modifying the source code:
> > as you understand by now, this should be done after removing gencc.
> 
> All changes were made in Basic/Types/basic.hh, 
> Window/Event/event_codes.hh and Resource/resource.hh. Only parts I had 
> rewritten anyway. No cheating. Just removal of needless indirections.

OK.

Keep on the good work, keep calm, don't get angry and
smoke a sigaret at each time that you want to kill me
(when I am not there in preference).

<Joris>