On 2012-12-11, at 6:26 PM, Ken Hornstein wrote:
> Well, this isn't exactly the fault of git, per se ... it's the post-receive
> hook script, and we don't manage the repo so we can't change that.
And there's my bitch. Outsourcing sucks if their gear doesn't do the job you
want done.
___
Lyndon Nerenberg writes:
> What would be useful, though, would be links to a set of diffs that
> could be viewed externally.
FWIW, Postgres (my main project) sends out commit log mail that links to
commitdiff displays on our gitweb server. Samples can be seen in the
list archives here:
http://ar
>Do we have anyone on board capable of fighting Git enough to give us
>*useful* commit messages?
Well, this isn't exactly the fault of git, per se ... it's the post-receive
hook script, and we don't manage the repo so we can't change that. I
can put in requests to the savannah admins (and I belie
>Well, I'm not too concerned about the exact API for this as long as it's
>reasonably doable. Just seems to me that m_getfld is already scanning
>the message, and MIME has made it so that one has to scan further in order
>to get all of the "headers". So it seems like a natural place for it.
So l
On 2012-12-11, at 6:20 PM, Paul Fox wrote:
> i wouldn't want diffs by mail, but a more concise message (perhaps
> just the output of "git log master" since the last mail), and links
> to the commits would be nice.
We used to get diffs by mail. I bitched loudly until they were shut down.
Yes,
Lyndon wrote:
> Do we have anyone on board capable of fighting Git enough to give us
> *useful* commit messages?
Didn't someone (you?) already hack the commit hook to not
show diffs? I don't even know where it is.
David
___
Nmh-workers mailing list
N
lyndon wrote:
>
> On 2012-12-11, at 5:46 PM, David Levine wrote:
>
> >Removed some dead code, all inside #if 0's. I tried to not remove
> >anything useful, so there are a few #if 0's remaining.
>
> Do we have anyone on board capable of fighting Git enough to give
> us *useful* c
On 2012-12-11, at 6:04 PM, Ken Hornstein wrote:
> So, think about the data flow for a second. mhl reads the body of the
> message in (using m_getfld()!) and then writes it to a pipe. replyfilter
> reads it from the pipe and then processes it. So we're talking about
> a stdio read, a copy from th
On 2012-12-11, at 6:04 PM, Ken Hornstein wrote:
> So ... can we all agree this isn't worth the trouble and forget it?
Let's not forget it, lest we have this conversation once again before I am dead
:-P
___
Nmh-workers mailing list
Nmh-workers@nongnu.o
>Ultimately, though, mmap() is just a micro-optimization in the context
>of a *822/MIME parser. The effort that would be expended on mmap() I/O
>would be better spent on writing a bullet-proof parser. No matter what,
>you will end up copying data to and from user space on the way to its
>eventual
On 2012-12-11, at 5:56 PM, chad wrote:
> P.S. Yes, the recent obit brought it to mind again
I don't think he's quite dead yet :-P
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
On 11 Dec 2012, at 17:25, Lyndon Nerenberg wrote:
>
> Now if you *really* want to speed things up, let's talk about lazy folder
> indexes.
I wonder if anyone has looked at or useful experience with (extended) MIX
format?
~Chad
P.S. Yes, the recent obit brought it to mind again
__
On 2012-12-11, at 5:46 PM, David Levine wrote:
>Removed some dead code, all inside #if 0's. I tried to not remove
>anything useful, so there are a few #if 0's remaining.
Do we have anyone on board capable of fighting Git enough to give us *useful*
commit messages?
I.e., could we drop
On 2012-12-11, at 5:25 PM, Lyndon Nerenberg wrote:
> But again, these really are micro-optimizations. mmap() won't make anything
> run perceivably faster, but it will introduce the potential for many subtle
> bugs. Best to leave well enough alone.
I forgot to say ...
Someone mentioned FreeB
On 2012-12-11, at 4:54 PM, Ralph Corderoy wrote:
> mmap seems fine if the program is
> accessing files under its sole control, perhaps not such a good fit for
> nmh.
For now, perhaps not an issue. But there has been some minor grumbling about
concurrent access issues on the list. If we do lea
Hi David,
> Would it make sense to toss it all and use mmap()? Conceptually, it
> doesn't seem like a difficult problem to parse header fields and maybe
> a body and just hand back a pair of pointers and the state indication.
I'd be -1. It doesn't seem like it's worth deviating from the file I/
"MS" == markus schnalke writes:
"NS" == Norm Shapiro
"DL" == David Levine
MS> Let's ditch msh
NS> In the ensuing decades, I've never had occasion to use it.
DL> The only use I can envision for it now would be to manage
DL> message archives. But of course it's not required for
I was tidying up the nmh homepage, and I saw a link to rbmhshow. I didn't
know about this so I clicked on the link for it ... and it seems to be
dead. Does anyone know about this? One link I found suggested that it was
last updated in 2005.
--Ken
___
David Levine writes:
> And Jon wrote:
>
> # I would like any m_getfld replacement to have the ability to extract
> # information about MIME message parts which means finding headers in
> # the middle of bodies. As per postings some years ago, I would like to
> # add code for reading attachments t
Paul V. wrote:
> mmap needs a file descriptor.
fileno() would take care of that. But . . .
> we need a way way way better way to talk to
> the message interface. in fact we need a message interface. and for all
> i know some of m_getfld's callers are passing in a socket or a pipe
> sometimes.
20 matches
Mail list logo
