Re: lua help build, autotools update

[Daniel J S. <dan...@ie...>]

On 11/16/2014 04:00 PM, Hans-Bernhard Bröker wrote:
> Am 16.11.2014 um 18:20 schrieb Daniel J Sebald:
>> On 11/15/2014 05:02 AM, Hans-Bernhard Bröker wrote:
>>
>>> As an aside, I propose to upgrade the entire auto-tools configuration to
>>> current versions (autoconf 2.69, automake 1.14). Some of our automake
>>> support scripts are almost a decade out of date... This I will only
>>> check in after some discussion.
>>
>> If it is a minor change. My system is about three years old with a few
>> minor upgrades and has autoconf 2.66, automake 1.11.1. The only
>> reluctance would be if any tools require the builder (common user, not
>> bundle maintainer) to upgrade.
>
> It would require people using the CVS source to have the autotools
> versions mentioned above, or newer. Those are both at least a year old
> now, so it's not like I would be requiring bleeding-edge versions ;-)
>
>> Changelogs will be part of the "changeset", written by whomever
>> creates the changeset (just follow the defined format).
>
> Absolutely not. ChangeLog has to be maintained anyway.

One could probably generate the ChangeLog by using some kind of git or 
hg command to list the comments of the repository.  Place it in the 
"prepare" script or something.  For example, here's a hypothetical 
printout of the comments for changesets of a project:

+++++

[sebald@ someproject]$ hg log

changeset:   5:5faee0bf6335
tag:         tip
user:        Dan Sebald <dan@sebald>
date:        Fri Nov 14 13:55:34 2014 -0400
files:       file1.cpp
description:
First line is a summary of what was changed (bug #2949)

* file1.cc: Change the average code to great code.


changeset:   19207:0b12e3693ed4
user:        Buster Keaton <buster@keaton>
date:        Sun Nov 16 20:24:42 2014 -0400
files:       file2.cpp file2.h
description:
Add some hot new feature (patch #1298)

* file2.cpp: This is C++ code.

* file2.h: Header file for file2.cpp containing class declarations.

+++++

That could be done as part of the autoconf stage because with git and hg 
the whole repository exists in the programmer's project.  (That's 
different from CVS in which the comm link to the remote repository has 
to be active in order to do "cvs diff", for example.)

Also, one stipulation is that the current CVS gnuplot repository would 
have be translated and somehow write a script or program that would put 
the existing ChangeLog into the comment of each changeset, i.e., we'd 
still have the whole history.


>> It's much
>> easier to browse through changes in git and hg, create changeset, etc.
>
> For those working off work-in-progress sources, sure. But what about
> people using an actual release version?

Here's the repository for Octave:  http://hg.savannah.gnu.org/hgweb/octave/

The web interface is automatically generated by Mercurial (it's launched 
using the "hg serve" command), and I'm guessing Git has something 
similar.  It's where I go to when I want to check activity.  There is a 
graph page for following what might be happening on the release branch, 
etc.  I've seen better graph displays, but it's OK.

For releases there's no repository, just the generated ChangeLog, I suppose.


>> * True hidden surface code. (I've had in mind for a while to generalize
>> the hidden line segment code to hidden triangle surfaces.)
>
> That wouldn't be a generalization. It'd be a complete re-implementation
> that has essentially no relation to the existing code.

The hidden line segment code isn't too bad.  That's the starting point. 
  Instead of line segments, which are cut at intersections and pieces 
discarded, it becomes little triangular surfaces which are cut into 
smaller sections with some linear algebra, then discard various pieces. 
  I think we actually have that part of the problem from someone 
already--but that's not the hard part.

If you were thinking about the "painters" algorithm that is currently 
used to simulate hidden surfaces, no that's not the starting point.


>> * Better integration with other programs using emerging trends (say SQL
>> or something).
>
> Wow, ROTFL. That must be the first time in well over 20 years that
> anyone has called SQL, of all things, an "emerging trend". ;-)

Well, for me.  Can't be too careful.  :-)

Dan