Re: [PATCH] Darwin/Mac OS X Support

The extra linker flags are neither necessary, nor appropriate. Two-level namespace is the one true way, especially for projects that don't dynamically load code (and even those should be updated to use two-level namespace correctly). What cpp-precomp errors did you see? My build log shows no

Re: what's happening?

At the time when I updated the code, it worked fine for my purposes, only differed significantly in: 1) parse failures for spam which often don't have legal (or legible) headers 2) Date: lines which did not include the timezone. I think previously it defaulted to assuming the local time zone,

Re: Do you people have a bugs database which you are using?

Here. If you have a patch, attach it. nmh-workers if you want to talk about it and see if anyone else wants to fix it. On Sun, 9 Dec 2001, Laura Creighton wrote: Where do I report my bugs? Laura

Re: Do you people have a bugs database which you are using?

Gee, sorry for wasting your time. The ChangeLog has every change made in the history of nmh. Shantonu On Sun, 9 Dec 2001, Laura Creighton wrote: Guys, I have a life. I need to know what bugs you already have fixed that will go out in the next release so I don't waste my time and yours by

Re: my attachment code, plus attachments in general

Hold up -- everyone back up a step. The most immediate concern is getting out a release that makes public the changes in CVS for the last 2 (?) years. This is not a good time to be making more changes on the main branch, as it will inevitably hold up the process more. This would be a good

Re: I am still considered a spammer it seems...

Please deal with Jon offline, since your mail is getting through to the rest of us. Shantonu On Friday, December 7, 2001, at 12:25 PM, Laura Creighton wrote: Return-Path: MAILER-DAEMON Delivery-Date: Fri Dec 7 18:21:51 2001 Return-Path: MAILER-DAEMON Received: from localhost (localhost)

Re: A Modest nmh Proposal

On Sat, 8 Dec 2001, Ken Hornstein wrote: I'd say it still only warrants a 1.1. There are insufficient new features added or changed functionality. Leave 2.0 for a major rewrite. I will side with Doug on this (Sorry if I'm being difficult ;-( ). My reasons are explained below. Are you

Re: DATE file

page would have a different date. Would this be confusing? Also, if someone wanted to find out how recent their version was, how would they do it? I certainly have no problem changing the field to something else, as long as we have 5 fields to conform to conventions (I believe). Shantonu *---

Re: Y2K problem.

*---* |Shantonu Sen * (617)225-7269 * [EMAIL PROTECTED]| |Electrical Engineering and Computer Science| |Massachusetts Institute of Technology, 2002| *---* Index: etc/digestcomps === RCS file

Re: Circular dependency in libmh.a and libmts.a causes build to fail

recent ones from ftp://ftp.gnu.org/pub/gnu/config. It should let us identify some more modern operating systems, since it appears that the current files are fairly old. Shantonu *---* |Shantonu Sen * (617)225-7269 * [EMAIL PROTECTED]| |Electrical

Re: [Fwd: Re: Questions about IMAP and sequences]

If there's no way to replace a message on the server with a local version, then if nmh does local caching of IMAP messages, modification of those messages will definitely be an issue. See the APPEND IMAP4rev1 command: append: http://andrew2.andrew.cmu.edu/rfc/rfc1730.html#sec-6.3.10. It

mts code reorganization

As I mentioned in my last email, I've moved over code from zotnet/mts to mts/generic, and made a more comprehensive archive called libmts.a which includes the contents of mts/generic and mts/smtp (which was previously in libsmtp.a). The details are in the ChangeLog. I don't anticipate any

Re: date/time functions

I updated my sources and re-ran against Solaris and AIX using lex and it doesn't appear to work. The file gets lexed without a hitch now, but the .c file it outputs isn't usable. Well, in any event, taking out the case-insensitivity sped up the processing by 1.7% (that's not very scientific,

Re: date/time functions

I set the memory options back, removed %option noyywrap, and added #undef yypwrap to the header section. This appears to work in Solaris and in flex on my linux system. Here's the patch... Did you check these in? They didn't appear to be in the CVS version. Anyway, I added back the memory

Re: nmh 1.0.4 doesn't work as POP client on LInux systems

OK. I seem to recall seeing some programs say "You must use gcc", but we should be able to get around that. Shantonu *-------* |Shantonu Sen * (617)225-6778 * [EMAIL PROTECTED]| |Electrical Engineering and Computer Science| |Massachusetts Institute of Technology, 2002| *---*

Re: nmh 1.0.4 doesn't work as POP client on LInux systems

ruserpass is never used. I removed the dependency because of this kind of complication. Shantonu *---* |Shantonu Sen * (617)225-6778 * [EMAIL PROTECTED]| |Electrical Engineering and Computer Science| |Massachusetts Institute of Technology, 2002| *---*

Re: nmh 1.0.4 doesn't work as POP client on LInux systems

days. Shantonu *---* |Shantonu Sen * (617)225-6778 * [EMAIL PROTECTED]| |Electrical Engineering and Computer Science| |Massachusetts Institute of Technology, 2002| *---*

Re: nmh 1.0.4 doesn't work as POP client on LInux systems

, what would you like to do? Please at least include a note in the MACHINES file about the restriction that on Linux systems, ~/.netrc must be used for POP login/password info. Thanks! Hopefully this will not be necessary. Shantonu *---* |Shantonu Sen

apop support

). using the sbr version to make libmh.a made everything work OK. if it turns out that system ruserpass *is* important, the detection scripts need a little more work. Shantonu *---* |Shantonu Sen * (617)225-6778 * [EMAIL PROTECTED]| |Electrical Engineering