headers
Joel Reicher | 10 Apr 2006 11:13

Any objections to completed .cvsignore files?

My working copy has .cvsignores containing all generated files so that
I can mix cvs operations and rebuilds/reconfs comfortably. Anybody unhappy
with me committing these files?

Cheers,

	- Joel

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply | 0 comments |
headers
Joel Reicher | 11 Apr 2006 07:58

Refactoring the nmh source

I'd like to start refactoring the code. I've had a look around, and much
of it is a little messy.

I think refactoring bit-by-bit is a better way to go then trying a
rewrite, and the process will reveal the bits that really do need
rewriting.

To begin with I was planning on very simple refactorings; eliminating
duplicate code, some reorganisation to put things in sensible places, etc.

New code will come along later, but I'd like to leave that until it's
more obvious what needs doing and the right way to do it.

I have three questions for the list. Firstly, are there any objections to
the basic idea of doing this?

Secondly, do you want a new branch for this work? I'm hoping the answer
to this question is "no", partly because I'm aiming for the refactoring to
be modest/trivial to begin with.

Lastly, what's the policy with commits and ChangeLog? I'd prefer to do
frequent and small commits, but that may annoy some people. I also wouldn't
put most of what I'm planning to do into the ChangeLog.

Cheers,

	- Joel

_______________________________________________
Nmh-workers mailing list
(Continue reading)

Permalink | Reply | 4 comments |
headers
pmaydell | 11 Apr 2006 11:15
Picon

Re: Refactoring the nmh source

Joel Reicher wrote:
>I'd like to start refactoring the code. I've had a look around, and much
>of it is a little messy.

>I have three questions for the list. Firstly, are there any objections to
>the basic idea of doing this?

It sounds like a good idea to me.

>Lastly, what's the policy with commits and ChangeLog? I'd prefer to do
>frequent and small commits, but that may annoy some people. I also wouldn't
>put most of what I'm planning to do into the ChangeLog.

I agree with small commits, but am less sure about the ChangeLog. At the
moment ChangeLog seems to be a record of just about everything that's done
to the code, large or small, so I think refactorings ought to get mentioned.
(It seems to mostly duplicate CVS log comments, which makes me wonder if
it shouldn't be autogenerated.) Perhaps we should have a different document
that only describes the changes significant to users -- bugs fixed, new
functionality added, etc ?

-- PMM

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply | 1 comment |
headers
Josh Bressers | 11 Apr 2006 13:33
Gravatar

Re: Refactoring the nmh source

> Joel Reicher wrote:
> >I'd like to start refactoring the code. I've had a look around, and much
> >of it is a little messy.
> 
> >I have three questions for the list. Firstly, are there any objections to
> >the basic idea of doing this?
> 
> It sounds like a good idea to me.

I've been trying to work on this bit by bit.  Some things have come up as
of late which have stopped me though (temporarily).  This source is in dire
need of love.

> 
> >Lastly, what's the policy with commits and ChangeLog? I'd prefer to do
> >frequent and small commits, but that may annoy some people. I also wouldn't
> >put most of what I'm planning to do into the ChangeLog.
> 
> I agree with small commits, but am less sure about the ChangeLog. At the
> moment ChangeLog seems to be a record of just about everything that's done
> to the code, large or small, so I think refactorings ought to get mentioned.
> (It seems to mostly duplicate CVS log comments, which makes me wonder if
> it shouldn't be autogenerated.) Perhaps we should have a different document
> that only describes the changes significant to users -- bugs fixed, new
> functionality added, etc ?

Now that there is a functioning CVS commits list, I question how important
this is.  I admit it is nice to have it in one place, but I also believe
we're diluting its value by putting every single modification in it.
Hopefully in the future savannah will support subversion, which has atomic
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Reicher | 11 Apr 2006 16:24

Gate nmh-announce to usenet?

The discussion about that list a few weeks ago made me think of this.

Is there a gateway established? Announcements should go to comp.mail.mh
at the very least.

Cheers,

	- Joel

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply | 2 comments |
headers
Bill Wohler | 11 Apr 2006 19:49
Picon
Picon
Gravatar

Re: Refactoring the nmh source

Joel Reicher <joel <at> panacea.null.org> writes:

> I have three questions for the list. Firstly, are there any objections to
> the basic idea of doing this?

I haven't mucked enough with the code to form a first opinion, but
from what I've read here, it is in need.

> Secondly, do you want a new branch for this work? I'm hoping the answer
> to this question is "no", partly because I'm aiming for the refactoring to
> be modest/trivial to begin with.

Since I'm not actively developing nmh (MH-E and Emacs keeps me busy
enough ;-), I'm not sure how much work this might impact, but it would
certainly be easier, especially with CVS, to keep the work on the
trunk.

> Lastly, what's the policy with commits and ChangeLog? I'd prefer to do
> frequent and small commits, but that may annoy some people. I also wouldn't
> put most of what I'm planning to do into the ChangeLog.

I heavily use ChangeLogs to see what and when changes were made to
functions and variables and their relationships to other functions and
variables. I therefore never use wildcards and mention every function
and variable names, even when touching hundreds of them, since a grep
would miss those changes.

I use Emacs to add ChangeLog comments easily, and then use those
comments for CVS check-ins (automatically via Emacs per PMM's
observation) so that the CVS logs are useful as well.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chad Walstrom | 11 Apr 2006 20:01

Re: Re: Refactoring the nmh source

ChangeLog management is a tough problem to solve when you have many
branches of development going on.  It's sometimes easier to maintain a
separate ChangeLog.MYBRANCH file until you merge with the trunk.
Alternatively, like Bill mentioned, don't bother with editing the
ChangeLog file while working on the branch, but format your SCM
changelog entries so that you can slurp them out at the time of the
merger and dump them into the ChangeLog.

I use Monotone, whose "log" output doesn't follow chronological order
for its entries, but rather parent-child relationships between
revisions.  This makes for some interesting reading, but has a more
accurate representation about when the changes took place relative to
the development lifecycle.

--

-- 
Chad Walstrom <chewie <at> wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply | 0 comments |
headers
Jerry Peek | 13 Apr 2006 16:24
Gravatar

Re: Gate nmh-announce to usenet?

I haven't read Usenet for years -- except to search it via
Google Groups, that is.  Unless something has changed and
there's no more spam on Usenet, I don't think we should
route Usenet traffic onto any nmh mailing lists.  But it's
a good idea to put nmh-announce messages onto comp.mail.mh.
It'll make nmh more visible, let other people kow about new
releases (and get that info into Google Groups, etc.).  It
could also encourage other people to join us.  

Jerry

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply | 1 comment |
headers
Joel Reicher | 14 Apr 2006 01:18

Re: Gate nmh-announce to usenet?

> I haven't read Usenet for years -- except to search it via
> Google Groups, that is.  Unless something has changed and
> there's no more spam on Usenet, I don't think we should
> route Usenet traffic onto any nmh mailing lists.  But it's
> a good idea to put nmh-announce messages onto comp.mail.mh.
> It'll make nmh more visible, let other people kow about new
> releases (and get that info into Google Groups, etc.).  It
> could also encourage other people to join us.  

Yup. The latter is all I meant, and it's easy to do with Mailman.

Cheers,

	- Joel

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Permalink | Reply | 0 comments |
headers
Paul Fox | 18 Apr 2006 17:39
Picon
Favicon

Re: pick character classes

in late march, i wrote:
 > i noticed this afternoon that pick doesn't honor ranges in
 > character classes.  it treats the class "[a-z]" as three
 > characters ('a', 'z', and '-') instead of 26.  so i implemented it.

i have a followon patch to the first one i did.  this one fixes
an issue where a very long character-class range (128 or more
characters) causes negative indexing into the case-folding array.

i'll apply this sometime next week unless i hear otherwise.

paul
=---------------------
 paul fox, pgf <at> foxharp.boston.ma.us (arlington, ma, where it's 55.2 degrees)

cvs diff: Diffing .
Index: picksbr.c
===================================================================
RCS file: /sources/nmh/nmh/uip/picksbr.c,v
retrieving revision 1.10
diff -u -u -r1.10 picksbr.c
--- picksbr.c	31 Mar 2006 15:14:49 -0000	1.10
+++ picksbr.c	18 Apr 2006 15:38:26 -0000
 <at>  <at>  -575,7 +575,7  <at>  <at> 
 {
     register int c;
     int cclcnt;
-    register char *ep, *dp, *sp, *lastep = 0;
+    register unsigned char *ep, *dp, *sp, *lastep = 0;
(Continue reading)

Permalink | Reply | 0 comments |

Gmane