Had it with junk mail? Annoyance-Filter sifts mail you wish to read fromjunk arriving in your mailbox by an adaptive process whichgives priority to mail you're interested in reading and evolves to blockcleverly disguised junk mail.
Release Date:
Topic:
Operating System:
All POSIX (Linux/BSD/UNIX-like OSes),
OS Independent (Written in an interpreted language)
License:
Translations:
Intended Audience:
Programming Language:
Registered:
Ratings and Reviews
Be the first to post a text review of Annoyance Filter. Rate and review a project by clicking thumbs up or thumbs down in the right column.
Project Feed
-
Forum comment added
afwaldo commented on the RE: Training and Incremental Training forum thread -
Forum thread added
afwaldo created the AF program speed forum thread -
Forum thread added
afwaldo created the Training and Incremental Training forum thread -
File released: /annoyancefilter/1.0d/annoyance-filter.zip.sig
-
File released: /annoyancefilter/1.0d/annoyance-filter.zip
-
File released: /annoyancefilter/1.0d/annoyance-filter-1.0d.tar.gz.sig
-
File released: /annoyancefilter/1.0d/annoyance-filter-1.0d.tar.gz
-
Code committed
johnwalker committed patchset 12 of module annoyance-filter to the Annoyance Filter CVS repository, changing 15 files -
annoyancefilter 1.0d file released: annoyance-filter-1.0d.tar.gz
\date{2003 October 8} Good ole' \.{gcc} 3.3.1 has taken to complaining if you compare |c<=255| where |c| is an |unsigned char|. Well, of course, this cannot be |false|, but it makes perfect sense when used in an assertion within a macro which only writes out a single byte of its argument. But of course we must sacrifice sound engineering safeguards in the interest of the \.{gcc} thought police's finely-honed sense of purity. So, out goes the assertion in |dictionaryWord::exportToBinaryFile| which guards against any programmer accidentally using |outCount| to write a value which may be larger than 255. Suppose you want to initialise a character class or translation table. What could be more natural than to write, say, ``|ctab['.']=CC_PUNCT|''? Well, not if you have to compile with \.{gcc} 3.3.1 which deems using a |char| as a subscript a distinctly unnatural act meriting a compile-time warning. I added a dumb macro to wrap |static_cast<int>()| around the character table entries initialised in this way in |base64MIMEdecoder::initialiseDecodingTable|, |tokenDefinition::setISO_8859defaults|, and |tokenDefinition::setUS_ASCIIdefaults|. Ooooh, that's {\it soooooh} much cleaner now! \date{2004 March 23} Added a kludge attempt to work around the messages which have begun to arrive with no blank line after the header, which runs directly into the first MIME header. At the moment, the code is just hammered into |mailFolder::nextLine| conditionally compiled on |SLOPPY_HEADERS|. If it does the job, I will make it a proper option and add it to the documentation. \date{2004 March 30} When configured for a system with |HAVE_MKSTEMP|, PDF decoding left a file descriptor pointing to each temporary file it created open. The error was due to |mkstemp|'s returning a handle to the open file as well as the file name. The code in |@<Transcribe PDF document to temporary file@>| went ahead and opened the file on its own, as is done after obtaining a name from |tmpnam|. I modified the code to use the open file handle from |mkstemp| and ensure it's closed when we're done writing the file. Of course this puts us right on the tracks where the |HAVE_FDSTREAM_COMPATIBILITY| locomotive is bearing down on us, necessitating conditionals all around to handle the removal of file handle I/O from |fstream| in later GCC libraries. Release 1.0c. \date{2004 August 4} The latest twist of the knife by the GCC priesthood in G++ 3.4 struck the |dataTable| template class in \.{statlib.w}. The ``enhancement'' which torpedoed this code which previously compiled without warnings in \.{-Wall} mode is ``described'' by this fine \pdfURL{piece of gibberish}{http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html} from the G++ documentation. After you've sorted through all the scholasticism, the bottom line is that any template class you define which is derived from an STL template such as |vector| and innocently uses methods from the parent class such as |size|, |begin|, or |end|, will now blow off with a compile error unless you qualify each of these method references with |this->| or |vector<T>::|. How I regret ever getting involved with this crap-bag language and compiler! The latest version of the the macros for CWEB, \.{cweb/cwebmac.tex} fails with \TeX\ 3.14159 (Web2C 7.3.1) because \.{pdfURL} is defined inside a block of code which is only processed by pdf\TeX. I moved the definition down to the bottom of the file, and now everything seems to work OK{}. To eliminate the need to install \.{cwebmac.tex} in the \TeX\ directory tree and avoid possible version incompatibilities, I added an environment variable set to the invocations of \TeX\ and pdf\TeX\ in \.{Makefile.in} to force the copy in our own \.{cweb} directory to be used. Rebuilt \.{configure} using Autoconf 2.59, which corrects the idiotic \.{char} function type in the |AC_CHECK_FUNCS| macro which was causing |mkstemp| and |system| not to be detected even on systems on which they are present. Promoted the |SLOPPY_HEADERS| code to a full-fledged option, \.{--sloppyheaders}. By default, it is off. To enable parsing of MIME headers with missing blank separators, specify the option both when training and testing messages. Release 1.0d.
-
annoyancefilter 1.0d file released: annoyance-filter-1.0d.tar.gz.sig
\date{2003 October 8} Good ole' \.{gcc} 3.3.1 has taken to complaining if you compare |c<=255| where |c| is an |unsigned char|. Well, of course, this cannot be |false|, but it makes perfect sense when used in an assertion within a macro which only writes out a single byte of its argument. But of course we must sacrifice sound engineering safeguards in the interest of the \.{gcc} thought police's finely-honed sense of purity. So, out goes the assertion in |dictionaryWord::exportToBinaryFile| which guards against any programmer accidentally using |outCount| to write a value which may be larger than 255. Suppose you want to initialise a character class or translation table. What could be more natural than to write, say, ``|ctab['.']=CC_PUNCT|''? Well, not if you have to compile with \.{gcc} 3.3.1 which deems using a |char| as a subscript a distinctly unnatural act meriting a compile-time warning. I added a dumb macro to wrap |static_cast<int>()| around the character table entries initialised in this way in |base64MIMEdecoder::initialiseDecodingTable|, |tokenDefinition::setISO_8859defaults|, and |tokenDefinition::setUS_ASCIIdefaults|. Ooooh, that's {\it soooooh} much cleaner now! \date{2004 March 23} Added a kludge attempt to work around the messages which have begun to arrive with no blank line after the header, which runs directly into the first MIME header. At the moment, the code is just hammered into |mailFolder::nextLine| conditionally compiled on |SLOPPY_HEADERS|. If it does the job, I will make it a proper option and add it to the documentation. \date{2004 March 30} When configured for a system with |HAVE_MKSTEMP|, PDF decoding left a file descriptor pointing to each temporary file it created open. The error was due to |mkstemp|'s returning a handle to the open file as well as the file name. The code in |@<Transcribe PDF document to temporary file@>| went ahead and opened the file on its own, as is done after obtaining a name from |tmpnam|. I modified the code to use the open file handle from |mkstemp| and ensure it's closed when we're done writing the file. Of course this puts us right on the tracks where the |HAVE_FDSTREAM_COMPATIBILITY| locomotive is bearing down on us, necessitating conditionals all around to handle the removal of file handle I/O from |fstream| in later GCC libraries. Release 1.0c. \date{2004 August 4} The latest twist of the knife by the GCC priesthood in G++ 3.4 struck the |dataTable| template class in \.{statlib.w}. The ``enhancement'' which torpedoed this code which previously compiled without warnings in \.{-Wall} mode is ``described'' by this fine \pdfURL{piece of gibberish}{http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html} from the G++ documentation. After you've sorted through all the scholasticism, the bottom line is that any template class you define which is derived from an STL template such as |vector| and innocently uses methods from the parent class such as |size|, |begin|, or |end|, will now blow off with a compile error unless you qualify each of these method references with |this->| or |vector<T>::|. How I regret ever getting involved with this crap-bag language and compiler! The latest version of the the macros for CWEB, \.{cweb/cwebmac.tex} fails with \TeX\ 3.14159 (Web2C 7.3.1) because \.{pdfURL} is defined inside a block of code which is only processed by pdf\TeX. I moved the definition down to the bottom of the file, and now everything seems to work OK{}. To eliminate the need to install \.{cwebmac.tex} in the \TeX\ directory tree and avoid possible version incompatibilities, I added an environment variable set to the invocations of \TeX\ and pdf\TeX\ in \.{Makefile.in} to force the copy in our own \.{cweb} directory to be used. Rebuilt \.{configure} using Autoconf 2.59, which corrects the idiotic \.{char} function type in the |AC_CHECK_FUNCS| macro which was causing |mkstemp| and |system| not to be detected even on systems on which they are present. Promoted the |SLOPPY_HEADERS| code to a full-fledged option, \.{--sloppyheaders}. By default, it is off. To enable parsing of MIME headers with missing blank separators, specify the option both when training and testing messages. Release 1.0d.
Rate and Review
Be the first person to add a text review.
Related Projects
Annoyance Filter Actions
About SourceForge
Develop Software
Community
Copyright © 2010 Geeknet, Inc. All rights reserved. Terms of Use
