libpostal-users Mailing List for The libpostal project
Status: Pre-Alpha
Brought to you by:
fullermd
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
| 2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Matthew D. F. <ful...@ov...> - 2003-07-16 18:09:21
|
Well, it's that time again. Fortunately, this time we managed to not go
on hiatus for the better part of 2 years.
libpostal-SNAP6 is now out in the world to fend for itself. As promised,
this release is primarily architectural in nature, with the following
focuses:
- An error-handling system that allows easy passing of errors up the
stack, and easy looking-up by user programs of what error happened
where. User programs may take note of the postal_errno() function,
which can be used in a very similar way to the C 'errno' facility.
When using the pthreads variant of the library, this system can also be
used safely in a POSIX-threaded program. See the information in the
docs on postal_pthread_init() and friends for more information.
- Additional functions have been added to do a lot of the construction
and destruction of various data structures that I've been doing by hand
in various places. Anything to reduce those pesky memory leaks...
- The documentation has been reworked a bit behind the scenes to be a bit
easier to work with. Also, a new version of the Codelibrary SGML DTD
has been released that should be a lot more amenable to use in other
projects. Some architectural work has happened here that should make
it easier down the line to separate out developer and user
documentation (though that's far from ready to rock).
There's also a new tarball of the formatted documentation, and the docs
on the project website have been updated to -SNAP6.
Looking forward, I'm planning to do a more code reworking for the next
SNAPshot, particularly in the arena of the POP implementation. I want to
do a bit of recoding on some of the mbox reading code, to make things a
bit more robust, and to add flexibility in how a user program goes about
doing things. And, overall, I want to add some higher-level functions,
now that we've got the lower-level stuff working pretty well.
And the boilerplate:
libpostal is released under a BSD-style license, to give each user as
much freedom as possible in choosing how they use the software. Share and
enjoy.
libpostal isn't developed in a vacuum. It's not being written just for
the sake of being written, but to be used. Anonymous CVS access lets
anyone always access the latest changes, but it's far easier to put up
periodic SNAPshots. We don't just put them up to look good, they're
there to be downloaded and used. Suggestions, ideas, bug reports,
patches, comments, or whatever other things you want to say about it, are
what this list is about. We developers don't have access to all the
possible systems out there, so try running the sample programs and let us
know about any problems, so we can make sure libpostal is kept as
portable as possible. See the TODO and KNOWN_BUGS files in the
distribution.
=20
The README, BUILDING, and ROADMAP files in the tarball give specific
information about what's what in the distribution. Enjoy! :)
--=20
Matthew Fuller (MF4839) | ful...@ov...
Principal Architect, Release Engineer, Master of Code-fu
The Libpostal Project http://libpostal.sourceforge.net
|
|
From: Matthew D. F. <ful...@ov...> - 2003-05-31 00:10:27
|
Well, it's been a long time since -SNAP4. I've been busy enough with other things that I just haven't had much steam lately to work on libpostal. I'm hoping to be able to do more on it in the near future, but I've said that every SNAP so far, so that's not much of a track record. It's been a year and a half since -SNAP4 now, and while -SNAP5 isn't a year and a half ahead of it, we have still made significant progress toward having a fully workable mail library. Some highlights of the changes since -SNAP4: - Lots of robustness and performance fixes in the mbox code. - POSTAL_MSG_LIST has been consigned to the dustbowl of history. - New functions for manipulation of mail headers. - A number of portability fixes in the code. - Lots of memory leaks (some really bad) have been plugged, and infrastructure has been added to allow the library and the sample/test programs to be built with dmalloc <http://dmalloc.com/> for tracking down any future such problems. - We can build a profiled version of the library for performance work. - Lots of updates in the Make infrastructure make the portability better, and a bit more fail-safe. - And, finally, we now have a reasonably complete implementation of Maildir functionality. Plus, the usual round of bugfixes, performance and robustness improvements, code and documentation cleanup, yada yada. There's also a new tarball of the formatted documentation, and the docs on the project website have been updated to -SNAP5. Looking forward, I'm planning to do a lot of infrastructure work for the next SNAP, especially in the areas of error-handling and -checking and memory management. See the TODO file in the source distribution for some thoughts and information on that. The TODO has been a bit reorganized to be more explicit and useful. And the boilerplate: libpostal is released under a BSD-style license, to give each user as much freedom as possible in choosing how they use the software. Share and enjoy. libpostal isn't developed in a vacuum. It's not being written just for the sake of being written, but to be used. Anonymous CVS access lets anyone always access the latest changes, but it's far easier to put up periodic SNAPshots. We don't just put them up to look good, they're there to be downloaded and used. Suggestions, ideas, bug reports, patches, comments, or whatever other things you want to say about it, are what this list is about. We developers don't have access to all the possible systems out there, so try running the sample programs and let us know about any problems, so we can make sure libpostal is kept as portable as possible. See the TODO and KNOWN_BUGS files in the distribution. =20 The README, BUILDING, and ROADMAP files in the tarball give specific information about what's what in the distribution. Enjoy! :) --=20 Matthew Fuller (MF4839) | ful...@ov... Principal Architect, Release Engineer, Master of Code-fu The Libpostal Project http://libpostal.sourceforge.net |
|
From: Matthew D. F. <ful...@ov...> - 2001-12-30 04:21:18
|
After a fair bit of pain getting things working, the formatted docs have finally arrived. There's a new file package, libpostal_docs, which contains the docs formatted in a number of formats (currently, DVI, PS, PDF, RTF, HTML, and TXT). I've made a -SNAP4 release of it, which corresponds to the -SNAP4 source release. With any luck, they'll stay in sync moving forward. The docs are also available on the project webpage at <URL:http://libpostal.sourceforge.net/>. --=20 Matthew Fuller (MF4839) | ful...@ov... Principal Architect, Release Engineer, Master of Code-fu The Libpostal Project http://libpostal.sourceforge.net/ |
|
From: Matthew D. F. <ful...@ov...> - 2001-12-25 17:45:26
|
Merry Christmas to all, or happy holidays, or whatever the politically correct gunk is. We've been rather slow on libpostal lately; spare time has become practically nonexistent. Still, there's a lot of problems that have been fixed since the last SNAPshot, and I've managed to crank a lot of time into it the past few days and get it whipped into shape. So, there's SNAP4. It's far from perfect, of course, but it's by far our best release yet, and it's steadily moving us forward into useful code. Want to write a quick program to tally up what the proportions of various mail clients people are using on mailing lists you're on? Save it in a mbox file, and you can use the postal_get_header() function to quickly grab them out and do some counting. See the test/listfrom/ test program for an example of how to do it; that program shows how some of our newer mbox functions work and fit together. All the bugs in previous SNAPshots have been squashed, and I'm not currently aware of any in the new code. That, of course, doesn't mean there aren't any, just that I haven't noticed them yet. There's a lot of cruft (like POSTAL_MSG_LIST) that's being phased out, but it's totally gone yet. And there's a lot of stuff that needs further work. Hopefully 2002 will afford me more time to work on it than 2001 did. See the release notes and/or the News blurb on our SourceForge page for more info. Share and enjoy. And the boilerplate: libpostal isn't developed in a vacuum. It's not being written just for the sake of being written, but to be used. Anonymous CVS access lets anyone always access the latest changes, but it's far easier to put up periodic SNAPshots. We don't just put them up to look good, they're there to be downloaded and used. Suggestions, ideas, bug reports, patches, comments, or whatever other things you want to say about it, are what this list is about. We developers don't have access to all the possible systems out there, so try running the sample programs and let us know about any problems, so we can make sure libpostal is kept as portable as possible. See the TODO and KNOWN_BUGS files in the distribution. The README, BUILDING, and ROADMAP files in the tarball give specific information about what's what in the distribution. Enjoy! :) --=20 Matthew Fuller (MF4839) | ful...@ov... Principal Architect, Release Engineer, Master of Code-fu The Libpostal Project http://libpostal.sourceforge.net |
|
From: Matthew D. F. <ful...@ov...> - 2001-10-23 09:18:56
|
We've had a problem in the Makefile-building script I didn't even notice until someone pointed it out to me. The script uses a (stupid) heuristic to figure out where the root of your libpostal build tree is, then uses that to locate some data files. Unfortunately, if the root path wasn't /some/path/that/ends/in/libpostal/ the heuristic would puke totally. This broke *ALL* of the SNAPshot's, because they're extracted as /some/where/libpostal-SNAP#/. Still open current bugs: - Derivation of From_ headers in mbox's is still broken in many cases - There MAY still be a bug hidden in pop_list() that will cause it to segfault Once these bugs get sorted out, I'll be cutting another SNAPshot, then moving on to finishing the mbox support and writing the Maildir/ functions. -- Matthew Fuller (MF4839) | ful...@ov... Principal Architect, Release Engineer, Master of Code-fu The Libpostal Project http://libpostal.sourceforge.net/ ----- Forwarded message from "Matthew D. Fuller" <ful...@us...> ----- From: "Matthew D. Fuller" <ful...@us...> To: lib...@li... Date: Tue, 23 Oct 2001 02:09:03 -0700 Subject: cvs commit: libpostal KNOWN_BUGS TODO libpostal/tools mkmakefiles.pl Message-Id: <E15...@us...> fullermd 2001/10/23 02:09:03 PDT Modified files: . KNOWN_BUGS TODO tools mkmakefiles.pl Log: Use a less *TOTALLY* braindead heuristic in determining where the root of the tree is. Use the fact that we're always called as "...../../tools/mkmakefiles.pl", and just trim back to "....../..". It's vaguely fugly, but it works. This fixes the bug where SNAP's will fail to build because the top-level dir isn't called libpostal/. Revision Changes Path 1.6 +1 -3 libpostal/KNOWN_BUGS 1.9 +1 -2 libpostal/TODO 1.4 +6 -6 libpostal/tools/mkmakefiles.pl _______________________________________________ libpostal-CVS mailing list lib...@li... https://lists.sourceforge.net/lists/listinfo/libpostal-cvs ----- End forwarded message ----- |