PATCH: AIX dep.&doc fix; development guidelines

PATCH: AIX dep.&doc fix; development guidelines

[Oliver Kiddle]

The patch fixes the latest AIX dependency problem and fixes a minor
error in the docs. I haven't commited it to cvs (sorry Peter) because I
haven't got ssh and cvs in the same place yet.

It would be nice to have the zsh-development-guide updated to reflect
the new guidelines now that we have CVS. Also, I'm not entirely clear
myself on what these new guidelines are:

1. Has there been a final solution on how we are supposed to create the
ChangeLog entries. It'd be nice to have a solution that doesn't depend
on using emacs (I'm more than happy to learn cvs but don't have the
time, inclination or disc space to learn emacs). Is the ChangeLog
modified just like any other file on the cvs server? If people can only
send a patch should they still include a patch for ChangeLog?

2. Should we still post patches for everything in addition to commiting
to cvs? For some things (like these AIX dependencies) it is hardly
worth it. With many changes the patches are useful, particularly when
they are just to functions and a recompile isn't necessary. It is also 
useful that patches from people such as me can get sanity checked.

3. The .distfiles thing should be mentioned. I take it that we just add
and remove files from the list in it if we add and remove files?

Oliver Kiddle

--- Src/utils.c.bak	Mon Apr  3 15:56:35 2000
+++ Src/utils.c	Mon Apr  3 15:57:00 2000
@@ -2681,7 +2681,7 @@
 }
 
 /**/
-char *
+mod_export char *
 nicedupstring(char const *s)
 {
     return nicedup(s, 1);
--- Doc/Zsh/compsys.yo.bak      Wed Apr  5 17:16:57 2000
+++ Doc/Zsh/compsys.yo  Wed Apr  5 17:18:18 2000
@@ -2794,7 +2794,7 @@
 before executing the var(action) and hence may be used in it (normally
 in an expansion like `tt($expl[@])').

-If the var(action) starts with `tt(= )' (a equal sign followed by a
+If the var(action) starts with `tt(= )' (an equals sign followed by a
 space), tt(_arguments) will insert the contents of the var(argument)
 field of the current context as the new first element in the tt(words)
 special array and increments the value of the tt(CURRENT) special

Re: PATCH: AIX dep.&doc fix; development guidelines

[Bart Schaefer]

On Apr 5,  5:52pm, Oliver Kiddle wrote:
} Subject: PATCH: AIX dep.&doc fix; development guidelines
} 
} 1. Has there been a final solution on how we are supposed to create the
} ChangeLog entries.

Peter wants each developer to create his own.  This causes some oddities
e.g. when Sven and I were both patching today -- article number refs get
out of order, and I had to restart my commit because Sven sneaked one in
between my "cvs update" and finishing writing the log message.

} It'd be nice to have a solution that doesn't depend on using emacs
} (I'm more than happy to learn cvs but don't have the time, inclination
} or disc space to learn emacs).

You don't need emacs.  The ChangeLog format is pretty obvious.  The only
reason for emacs (or for a perl tool like cvs2cl) is to automatically
insert the date and create the ChangeLog entries from the commitlogs.
Which of course means that you have to edit and commit ChangeLog after
you've commited the rest, which is slow and subject to races like the
one I just described when working with a remote server.

So I've pretty much decided I'll have to edit ChangeLog by hand and
commit it at the same time as everything else.

} Is the ChangeLog modified just like any other file on the cvs server?

Yes.

} If people can only send a patch should they still include a patch for
} ChangeLog?

I'd say no; let the person who actually applies the patch write the log.

} 2. Should we still post patches for everything in addition to commiting
} to cvs? For some things (like these AIX dependencies) it is hardly
} worth it.

I confess I've already fixed a couple of minor typos (no-op things, the
equivalent of whitespace changes) without sending a patch to the list.

But with e.g. my patch to Makefile.in, I mailed off the "cvs diff" output
and then waited for the patch to come back to me before committing, so I
could reference the article number in the commitlog.  It appears that Sven
has been doing this too.

} 3. The .distfiles thing should be mentioned. I take it that we just add
} and remove files from the list in it if we add and remove files?

That's correct.

I forget how the CVS commitinfo script works with a remote server.  On a
local server it's possible to write a commitinfo to check that .distfiles
mentions any files that are being added.

BTW, I've just been putting the finishing touches on a script to keep my
local repository in sync with the sourceforge one while still preserving
all my local hacks.  It approximately implements "cvs update -j..." on
two sandboxes (one updated from cvs.zsh.sourceforge.net, the other from
my local repository) by way of an intermediate tree that serves as the
common ancestor (I used the -dev-21 release).  So it means keeping three
copies of the source, but I only have to type three words to download
everything from sourceforge and merge it into my local sandbox.

If anyone is interested in this script I can post it.  It requires GNU
diff with diff3, and patch.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: AIX dep.&doc fix; development guidelines

[Peter Stephenson]

"Bart Schaefer" wrote:
> Peter wants each developer to create his own.  This causes some oddities
> e.g. when Sven and I were both patching today -- article number refs get
> out of order, and I had to restart my commit because Sven sneaked one in
> between my "cvs update" and finishing writing the log message.

I'm happy to consider other ways, but this way we get the changes properly
documented up to date.  If anyone has a script to generate them in
something like the current format, with applier, patch number, files
changed, and brief description, from CVS data when it is committed that
would be splendid.

> } 3. The .distfiles thing should be mentioned. I take it that we just add
> } and remove files from the list in it if we add and remove files?
> 
> That's correct.

There's a few files that you might of thought would be in the repository
but are actually auto-generated --- this is basically Zefram's preconfig
mechanism.  For everything else, they just go in or out of .distfiles as
appropriate.

Here's a script I use for checking for thinks that aren't in either
.distfiles as a source file or .cvsignore.  It doesn't examine
DISTFILES_DOC at the moment.  It can go in /home/groups/zsh/bin at
sourceforge.  It told me that LICENCE hadn't been added, so that will go
into .distfiles when I next commit.


#!/bin/zsh -f

emulate zsh
setopt nonomatch nobadpattern

typeset -A sfiles

# srcdir=~/zsh/sourceforge/zsh
srcdir=/home/groups/zsh/zsh

if [[ ! -d $srcdir ]]; then
  print "Can't find top of distribution" >&2
  exit 1
fi

srcdir=$srcdir[1]

cd $srcdir

typeset -A fdone

for dir in '' **/*(/); do
  if [[ -n $dir ]]; then
    cd $srcdir/$dir
    dir="$dir/"
  else
    cd $srcdir
  fi
  unset DISTFILES_SRC
  fdone=()
  if [[ -f .distfiles ]]; then
    . ./.distfiles
    if (( ${+DISTFILES_SRC} )); then
      for f in ${~=DISTFILES_SRC}; do
	[[ "$dir$f" = *Doc/*.1 || "$dir$f" = *.texi ]] && continue
# the following lists the files to be added to the archive
#       print "$dir$f"
	[[ -f $f ]] || print "WARNING: no such file $dir$f" >&2
        fdone[$f]=1
      done
    else
      print "WARNING: ${dir}.distfiles didn't set DISTFILES_SRC" >&2
    fi
    if [[ -f .cvsignore ]]; then
      for f in ${~$(<.cvsignore)}; do
	[[ -f $f ]] && fdone[$f]=1
      done
    fi
    for f in *; do
      [[ -d $f ]] && continue
      [[ -z $fdone[$f] ]] && print "WARNING: file $dir$f not handled" >&2
    done
  elif [[ $PWD = */CVS ]]; then
    continue
  else
    print "WARNING: ${dir:-top level directory} has no .distfiles" >&2
  fi
done

exit 0

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: PATCH: AIX dep.&doc fix; development guidelines

[Peter Stephenson]

Peter Stephenson wrote:
> Here's a script I use for checking for thinks that aren't in either
> .distfiles as a source file or .cvsignore.  It doesn't examine
> DISTFILES_DOC at the moment.  It can go in /home/groups/zsh/bin at
> sourceforge.  It told me that LICENCE hadn't been added, so that will go
> into .distfiles when I next commit.

Sorry, stupid error in this.  Miss out the line that says:

> srcdir=$srcdir[1]

which dates from when it started off as an array and searched for the right
directory, which it no longer does.  I've installed it as check_dist_files
at sourceforge and it appears to be working.

By the way, the userguide on the web is now up to date again.  This is the
last chance for comments before I shift it to AUC.  (It's time somebody
fixed zftp to handle interrupts properly.  I've been waiting for someone to
come along and say `This is awful' and do it.  I loathe the idea of doing
it myself.  Now I have a zsh completely frozen because the modem hung up.)

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: PATCH: AIX dep.&doc fix; development guidelines

[Bart Schaefer]

On Apr 5,  8:21pm, Peter Stephenson wrote:
> Subject: Re: PATCH: AIX dep.&doc fix; development guidelines
> "Bart Schaefer" wrote:
> > Peter wants each developer to create his own.  This causes some oddities
> > e.g. when Sven and I were both patching today -- article number refs get
> > out of order, and I had to restart my commit because Sven sneaked one in
> > between my "cvs update" and finishing writing the log message.
> 
> I'm happy to consider other ways, but this way we get the changes properly
> documented up to date.  If anyone has a script to generate them in
> something like the current format, with applier, patch number, files
> changed, and brief description, from CVS data when it is committed that
> would be splendid.

I've installed cvs2cl in /home/groups/zsh/bin on zsh.sourceforge.net.

Here's some sample output, just the top few entries.  If we actually include
the article numbers in our commit logs (as pws did in the first one), then
the only other thing is to replace sourceforge user identities with useful
email addresses in the tag lines.  (And edit out all of "akr"s one-liners
from before the sourceforge site was up.)

Note that I recommend that you don't allow cvs2cl to rewrite ChangeLog on
its own; rather, use "cvs2cl --stdout", lop off the bottom bit that is
already reflected in ChangeLog, and then paste the top bit into ChangeLog.

BTW, Peter, it'd be nice if commitlogs say what actually happened to the
source rather than just pointing at zsh-workers articles.  Yes, the rest of
the information is in the ChangeLog, but it's still be nice.

2000-04-05 12:28  pws

        * .distfiles, ChangeLog, Completion/User/_prcs, Doc/Zsh/compsys.yo,
        Doc/Zsh/expn.yo, Src/glob.c, Src/utils.c, Util/mkdisttree.sh:
        Patches 10513, 10516 (Alexandre), 10519 (Oliver), 10524

2000-04-05 05:06  wischnow

        * ChangeLog, Completion/Base/_arguments, Doc/Zsh/compsys.yo:
        support automatically inserted dummy in $words

2000-04-05 04:28  wischnow

        * ChangeLog, Completion/Debian/_apt, Completion/Debian/_bug,
        Completion/Debian/_dpkg, Completion/User/_chown,
        Completion/User/_dvi, Completion/User/_imagemagick,
        Completion/User/_ispell, Completion/User/_lp,
        Completion/User/_mount, Completion/User/_mysql_utils,
        Completion/User/_pbm, Completion/User/_psutils,
        Completion/User/_rcs, Completion/User/_rlogin,
        Completion/User/_ssh, Completion/User/_tiff, Completion/User/_yp,
        Completion/X/_xutils: use basename of commands instead of $words[1]

2000-04-05 04:07  wischnow

        * ChangeLog, Completion/Builtins/_zstyle,
        Completion/Core/_path_files, Doc/Zsh/compsys.yo,
        Functions/Zle/incremental-complete-word: renaming some styles

2000-04-05 03:50  wischnow

        * ChangeLog, Completion/Core/_files,
        Completion/Core/_main_complete: two small completion fixes

2000-04-05 02:20  wischnow

        * ChangeLog, Src/parse.c: make zwc files use the magic number as
        their verios, report zsh-version in error messages

2000-04-05 01:54  barts

        * ChangeLog, Makefile.in: Make config.h and related dependencies
        relative to $(sdir).

Re: PATCH: AIX dep.&doc fix; development guidelines

[Bart Schaefer]

On Apr 7,  9:04pm, Peter Stephenson wrote:
} Subject: Re: PATCH: AIX dep.&doc fix; development guidelines
}
} Bart Schaefer wrote:
} > At the time an actual release is done, will the maintainer (hi, Peter)
} > please do a sweep of the ChangeLog and convert all the "zefram1XX" etc.
} > into the actual article numbers?
} 
} Ouch. Script?

Hrm.  Aassuming you have a directory ~/zsh-workers/mla/ in which you've
unpacked all the tarfiles from the mailing list archive, so that you
have files named for the article numbers, it should go something like:

-------------------------------------------------------------------
#! /usr/bin/perl
open(CHANGELOG, "ChangeLog") or die "can't open ChangeLog";

rename("ChangeLog","ChangeLog.orig") and open(STDOUT, ">ChangeLog")
  or die "can't rewrite ChangeLog";

chdir("$ENV{'HOME'}/zsh-workers/mla")
  or die "can't cd to mailing list archive";

while (<CHANGELOG>) {
  if (/^\s+\* \b(\D\w+\B\d+:)/) {
    open(ARTICLES, "fgrep -l $1 * |"
      or die "can't grep mailing list archive";
    @articles = sort {$b <=> $a} <ARTICLES>;
    close(ARTICLES);
    $article = unshift @articles;
    s/$1/$article:/;
  }
} continue {
  print;
}
-------------------------------------------------------------------

This picks out the most recent article that references the sequence code,
which relies on the last mention of a sequence code like "zefram1"
appearing in the actual patch article.  If somebody has quoted Zefram's
ChangeLog diff in a later article, it'll find that article instead.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: AIX dep.&doc fix; development guidelines

[Peter Stephenson]

Bart Schaefer wrote:
> At the time an actual release is done, will the maintainer (hi, Peter)
> please do a sweep of the ChangeLog and convert all the "zefram1XX" etc.
> into the actual article numbers?

Ouch. Script?

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: PATCH: AIX dep.&doc fix; development guidelines

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Thu, 6 Apr 2000, Zefram wrote:
> 
> > I'd forgotten that that form would clash with old subversion numbers.
> > I'm going to skip ahead 100 numbers, therefore, to get past that clash.
> > I suggest that everyone else using this scheme start off at patch
> > "pws100" etc.
> 
> OK, I'm almost convinced to give in.  Can I make one request?
> 
> At the time an actual release is done, will the maintainer (hi, Peter)
> please do a sweep of the ChangeLog and convert all the "zefram1XX" etc.
> into the actual article numbers?

Placing the burden on Peter again... Hm, that's not as kind as I would 
like to be. And searching all those numbers is a rather tedious job.

I'm torn in two, especially because I find the (real) message numbers
rather convenient myself.

And I've just finished my emacs-lisp support for all this stuff...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: AIX dep.&doc fix; development guidelines

[Bart Schaefer]

On Thu, 6 Apr 2000, Zefram wrote:

> I'd forgotten that that form would clash with old subversion numbers.
> I'm going to skip ahead 100 numbers, therefore, to get past that clash.
> I suggest that everyone else using this scheme start off at patch
> "pws100" etc.

OK, I'm almost convinced to give in.  Can I make one request?

At the time an actual release is done, will the maintainer (hi, Peter)
please do a sweep of the ChangeLog and convert all the "zefram1XX" etc.
into the actual article numbers?

Re: PATCH: AIX dep.&doc fix; development guidelines

[Zefram]

Bart Schaefer wrote:
>No, what file am I going to grep *in*, not what pattern am I looking for.
>I don't have an archive of zsh-workers and don't want one.  I want to be
>able to use http://www.zsh.org/mla/ or the equivalent.  Searching for
>"zefram1" turns up one message from 1998.

The mailing list archive seems to be updated once a day, so you can't
find today's patches yet (but then of course you couldn't look them
up by sequence number either).  As for what "zefram1" et al return,
I'd forgotten that that form would clash with old subversion numbers.
I'm going to skip ahead 100 numbers, therefore, to get past that clash.
I suggest that everyone else using this scheme start off at patch
"pws100" etc.

-zefram

Re: PATCH: AIX dep.&doc fix; development guidelines

[Bart Schaefer]

On Apr 6,  6:27pm, Zefram wrote:
} Subject: Re: PATCH: AIX dep.&doc fix; development guidelines
}
} Bart Schaefer wrote:
} >        Exactly what am I going to grep, anyway?
} 
} grep for the full unique patch ID (e.g., "zefram2").

No, what file am I going to grep *in*, not what pattern am I looking for.
I don't have an archive of zsh-workers and don't want one.  I want to be
able to use http://www.zsh.org/mla/ or the equivalent.  Searching for
"zefram1" turns up one message from 1998.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: AIX dep.&doc fix; development guidelines

[Zefram]

Bart Schaefer wrote:
>Our own sequence numbers?  I can't imagine anyone who's not on the mailing
>list making any sense of four or five separate sets of sequence numbers.
>Heck, I am on the mailing list and I wouldn't want to try to make sense
>of it.

See what I've done with my two patches today, labelled "zefram1" and
"zefram2".  I don't see this getting confusing.  It'd get confusing
if people actually used non-unique patch IDs, granted, so let's get it
right right from the start, OK?

>        Exactly what am I going to grep, anyway?

grep for the full unique patch ID (e.g., "zefram2").  The first mention
is overwhelmingly likely to be the patch you're looking for; the ID
appears in the ChangeLog hunk, so you could narrow down your grepping
a bit on that basis.

>                                                                     How
>do I get Sven's number 22396 and not Peter's?

"wischnow22396" vs "pws22396".

>And what about people who don't have commit access who mail patches to
>the list?

Their patches get committed, by Peter, after they've been mailed.
They can be identified everywhere (commit log, ChangeLog, etc.) by
mailing list sequence number.

-zefram

Re: PATCH: AIX dep.&doc fix; development guidelines

[Bart Schaefer]

On Apr 6,  5:23pm, Zefram wrote:
} Subject: Re: PATCH: AIX dep.&doc fix; development guidelines
}
} Sven Wischnowsky wrote:
} >> But with e.g. my patch to Makefile.in, I mailed off the "cvs diff" output
} >> and then waited for the patch to come back to me before committing
} >
} >Yesss, most annoying... it means that I can't continue hacking on the
} >next thing before the mail comes back.

You could if you used two copies of the source tree like I do ...

} Let's just each use our own sequence numbers, and rely on grep to tie
} the CVS changes to the mailing list message.

Our own sequence numbers?  I can't imagine anyone who's not on the mailing
list making any sense of four or five separate sets of sequence numbers.
Heck, I am on the mailing list and I wouldn't want to try to make sense
of it.  Exactly what am I going to grep, anyway?  Is each of us supposed
to be keeping our own archive of the entire mailing list?  And where does
this additional sequence number appear in the mailing list message?  How
do I get Sven's number 22396 and not Peter's?

And what about people who don't have commit access who mail patches to
the list?

If we're going to drop the article numbers from the ChangeLog because
it's too much work to keep them, then just drop them.  Bolting on some
multithreaded numbering scheme is only going to make things worse.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: AIX dep.&doc fix; development guidelines

[Zefram]

Sven Wischnowsky wrote:
>> But with e.g. my patch to Makefile.in, I mailed off the "cvs diff" output
>> and then waited for the patch to come back to me before committing, so I
>> could reference the article number in the commitlog.  It appears that Sven
>> has been doing this too.
>
>Yesss, most annoying... it means that I can't continue hacking on the
>next thing before the mail comes back. So zsh interrupts my real work
>more often and in smaller time slices.

This is obviously getting in the way of things.  I think we'll have to
abandon the ideal of having mailing list message numbers in commit log
entries and in ChangeLog entries (at least as initially committed).
Let's just each use our own sequence numbers, and rely on grep to tie
the CVS changes to the mailing list message.

-zefram

Re: PATCH: AIX dep.&doc fix; development guidelines

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Apr 5,  5:52pm, Oliver Kiddle wrote:
> } Subject: PATCH: AIX dep.&doc fix; development guidelines
> } 
> } 1. Has there been a final solution on how we are supposed to create the
> } ChangeLog entries.
> 
> Peter wants each developer to create his own.  This causes some oddities
> e.g. when Sven and I were both patching today -- article number refs get
> out of order, and I had to restart my commit because Sven sneaked one in
> between my "cvs update" and finishing writing the log message.

Oh, sorry, I feared that and had waited some time, tried update a
couple of times and then...

> ...
> 
> But with e.g. my patch to Makefile.in, I mailed off the "cvs diff" output
> and then waited for the patch to come back to me before committing, so I
> could reference the article number in the commitlog.  It appears that Sven
> has been doing this too.

Yesss, most annoying... it means that I can't continue hacking on the
next thing before the mail comes back. So zsh interrupts my real work
more often and in smaller time slices.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de