Re: APR 1.0.1 and 0.9.5 posted for review
+1 Netware Justin Erenkrantz [EMAIL PROTECTED] Wednesday, November 17, 2004 1:37:33 PM Can we please get some feedback on the following releases: http://www.apache.org/~jerenkrantz/0.9.5/ (The directory actually contains 0.9.5 and 1.0.1.) If we get 3 +1s, then I'll copy it over to dist. -- justin
A thin adapting layer for logging service
Hi,
I am looking for some simple logging API for C when I working on
jxta-c, and since log4c is under LGPL, I decided to start my own work
with a simple API. As discussed briefly in [EMAIL PROTECTED], I
thought it may be a nice-to-have for apr-util.
So, I post this here and apr-util is interested to include it, I will
work on to make it better fit for apr. Noted that this is not
compilable within apr as is.
The design behind this is simple, a *process*(e.g, shell) needs to setup
a global logger function by calling jpr_log_using(...) function. This
logger function may be a dispatch function for different logs or just as
simple as a wrapper function to vprintf(...).
The *component*(e.g, libjxta) use the global logger function by calling
jpr_log_append(...) function, which will in turn call the logger
function setup by the *process*.
A *selector* class is implemented to assist decision on whether a
message should be logged based on given *category* and *level*.
*category* is basically a free form string except cannot have ','
character and no leading/trailing spaces.
Six *level*s are defined: critical, error, warning, info, debug and
ext_debug.
Selector can be modified with a programatic way so category can be
added/removed dynamically or initialized with a selector string. The
selector string in ABNF is at end of this email.
A simple file logger is implemented to demonstrate how to use selector
and can serve the purpose of a basic file logger. You can refer to the
unit test program as a sample.
Current version is not thread safe, next version will be. I also want
to use apr_pool function for allocating memory for categories, as I
don't think they will change frequently until the program terminate and
the amount of memory is relative small.
The code attached here are working and for your review purpose to see
if there is interest.
jpr_log.h - public header
jpr_log_priv.h - private header
jpr_log.c - implementation
jpr_log_unit_test.c - simple unit test program to verify the function
Your comments are welcome.
Cheers,
--
Henry Jen, a.k.a slowhog
PS. Selector string in ABNF form (RFC2234):
selector_string = category_list . level_list
category_list = * / ([!] *is_space categories)
categories = *is_space category *is_space [(, categories) / (,
*is_space)]
category = 1*cat_char *(*is_space cat_char)
cat_char = %x01-08 / %0C / %x0E-1F / %x21-2B / %2D-7F ; not isspcae
nor ','
level_list = * / ([!] *is_space level_spec)
level_spec = *is_space level *is_space [(, level) / (, *is_space)]
level = level_literal [ *is_space - *is_space level_literal ]
level_literal = critical / error / warning / info / debug /
ext_debug
is_space = CR / LF / WSP / %x0B ; %x0B is vtab
#ifndef __JPR_LOG_PRIV_H__
#define __JPR_LOG_PRIV_H__
#include stdio.h
#ifdef __cplusplus
extern C {
#endif
struct Jpr_log_selector {
size_t category_count;
size_t category_size;
const char **categories;
unsigned int negative_category_list;
unsigned int level_flags;
};
struct Jpr_log_file {
FILE *thefile;
Jpr_log_selector *selector;
};
#ifdef __cplusplus
} /* extern C */
#endif
#endif
/* vi: set sw=4 ts=4 et: */
#include jpr/jpr_log.h
#include jpr_log_priv.h
extern Jpr_log_selector *jpr_log_selector_new_and_set(const char *selector, Jpr_status *rv);
extern Jpr_boolean jpr_log_selector_is_selected(Jpr_log_selector *self, const char *cat, Jpr_log_level level);
#include stdio.h
#define TEST_SEL(s, x, y, line) \
if (FALSE == jpr_log_selector_is_selected(s, x, y)) \
printf(Failed at line %u\n, line);
#define TEST_NOSEL(s, x, y, line) \
if (TRUE == jpr_log_selector_is_selected(s, x, y)) \
printf(Failed at line %u\n, line);
static const char* _log_level_labels[JPR_LOG_LEVEL_MAX] = {
critical,
error,
warning,
info,
debug,
ext_debug
};
void dump_sel(Jpr_log_selector *s)
{
int i;
printf( Selector status ---\n);
printf(Categories: %s\n, (s-negative_category_list) ? NEG : POS);
for (i = 0; i s-category_count; ++i) {
printf(\t%s\n, s-categories[i]);
}
printf(Mask: 0x%X\n\t, s-level_flags);
for (i = JPR_LOG_LEVEL_MIN; i JPR_LOG_LEVEL_MAX; i++) {
if (0 != (s-level_flags (1 i)))
printf( %s, _log_level_labels[i]);
}
printf(\n\n);
}
int main(int argc, char **argv)
{
Jpr_log_selector *s;
Jpr_log_file *f;
Jpr_status rv;
rv = jpr_log_initialize();
if (JPR_SUCCESS != rv) return 1;
s = jpr_log_selector_new_and_set(a aa, b , ccc, ,ee, ff.critical - warning,debug, warning- error info , ext_debug, rv);
if (JPR_SUCCESS != rv) {
printf(Failed at line %u\n, __LINE__);
}
dump_sel(s);
TEST_NOSEL(s, x, JPR_LOG_LEVEL_WARNING, __LINE__);
TEST_SEL(s, , JPR_LOG_LEVEL_EXT_DEBUG, __LINE__);
jpr_log_selector_set(s, *.!info, ext_debug);
dump_sel(s);
TEST_SEL(s, x, JPR_LOG_LEVEL_WARNING,
Re: Subversion Branch Names
--On Thursday, November 18, 2004 11:49 PM -0700 Paul Querna [EMAIL PROTECTED] wrote: Currently we have 'APR_0_9_BRANCH' and 'APU_0_9_BRANCH' as branch names in subversion. Is there any reason not to make these both '0.9.x'? This is how httpd has been done, and both APR/APU have '1.0.x' branches. I didn't want to just go do it now, since APR has been available via svn for several days now... any objections to renaming the branches? Nope. +1 as it's a great idea. =) -- justin
Re: [PATCH] fix apr_xlate_conv_buffer and testxlate
On Thu, 18 Nov 2004 17:22:50 +0100, Uwe Zeisberger [EMAIL PROTECTED] wrote: Below comes a log and a patch. I assume, that apr_xlate_conv_buffer should convert inbuf and assume, that the strings ends then. Else its use in test/testxlate.c is not appropriate. it was assumed that the application does not have the knowledge to guarantee that complete characters are always passed to apr_xlate_conv_buffer(); instead, we only assume that the complete stream of data passed by the application over multiple calls to apr_xlate_conv_buffer() ends with a complete character (or app gets the INCOMPLETE return code on last call and realizes there is a problem since there is no more input data which could complete the character) it is a big burden on the application to know when a character ends or am I misunderstanding you?
Re: Subversion Branch Names
On Nov 19, 2004, at 12:49 AM, Paul Querna wrote: Currently we have 'APR_0_9_BRANCH' and 'APU_0_9_BRANCH' as branch names in subversion. Is there any reason not to make these both '0.9.x'? This is how httpd has been done, and both APR/APU have '1.0.x' branches. I didn't want to just go do it now, since APR has been available via svn for several days now... any objections to renaming the branches? +1, but since 'svn log --stop-on-copy' will log backwards until the start of this latest copy, it may be worthwhile to note in your log message the initial revision where the branch was created (for purposes of merging later. You can always get this information later, but it's easier to just put it in the log message now. -Fitz
[PATCH] clean up shm sections in testshm to prevent spurious failures
While playing around with the test suite on the way back from ApacheCon
I noticed that if you kill testall at just the wrong time it'll leave
stray shm sections around and further test runs will all fail. Here's a
patch and log message that removes shm sections proactively before
trying to create them, avoiding the problem.
-garrett
If testall is killed at just the wrong time you can leave a shared memory
segment on the machine and all subsequent runs of the test will fail. To
avoid this problem we now proactively remove named shared memory segments
before trying to create them.
* test/testshm.c
(test_named): remove shm segment for SHARED_FILENAME before creating it.
(test_named_remove): ditto.
Index: test/testshm.c
===
--- test/testshm.c (revision 65537)
+++ test/testshm.c (working copy)
@@ -166,6 +166,8 @@
apr_exit_why_e why;
const char *args[4];
+apr_shm_remove(SHARED_FILENAME, p);
+
rv = apr_shm_create(shm, SHARED_SIZE, SHARED_FILENAME, p);
APR_ASSERT_SUCCESS(tc, Error allocating shared memory block, rv);
if (rv != APR_SUCCESS) {
@@ -220,6 +222,8 @@
apr_status_t rv;
apr_shm_t *shm;
+apr_shm_remove(SHARED_FILENAME, p);
+
rv = apr_shm_create(shm, SHARED_SIZE, SHARED_FILENAME, p);
APR_ASSERT_SUCCESS(tc, Error allocating shared memory block, rv);
if (rv != APR_SUCCESS) {
Re: Subversion Branch Names
Brian W. Fitzpatrick wrote: +1, but since 'svn log --stop-on-copy' will log backwards until the start of this latest copy, it may be worthwhile to note in your log message the initial revision where the branch was created (for purposes of merging later. You can always get this information later, but it's easier to just put it in the log message now. +1. The only reason I was going to object was the fact that it would make --stop-on-copy a bit less useful, but putting the info in the log message will fix that problem nicely. -garrett
Email archive busted?
In an attempt to see what happened in the last day or so while my email was accidentally being routed to /dev/null (never mess with your email settings right before getting on a plane, it's just asking for trouble) I checked out the eyebrowse archives for dev@apr.apache.org and [EMAIL PROTECTED] and it seems that neither are working. The most recent mail in the archives for both lists are from november 2003. Can someone either kick the thing until it works again or point me in the direction of the right person to bug? Thanks, -garrett
Re: Email archive busted?
--On Friday, November 19, 2004 9:00 AM -0800 Garrett Rooney [EMAIL PROTECTED] wrote: Can someone either kick the thing until it works again or point me in the direction of the right person to bug? Eyebrowse is horribly broken. We want to re-create our archives on another box, but that's going to take a lot of time, unfortunately. Sorry. You could try: http://mail-archives.eu.apache.org/~jerenkrantz/mod_mbox/ HTH. -- justin
Re: [PATCH] clean up shm sections in testshm to prevent spurious failures
On Fri, Nov 19, 2004 at 08:08:40AM -0800, Garrett Rooney wrote: While playing around with the test suite on the way back from ApacheCon I noticed that if you kill testall at just the wrong time it'll leave stray shm sections around and further test runs will all fail. Here's a patch and log message that removes shm sections proactively before trying to create them, avoiding the problem. Committed, thanks. joe
Re: Email archive busted?
Justin Erenkrantz wrote: --On Friday, November 19, 2004 9:00 AM -0800 Garrett Rooney [EMAIL PROTECTED] wrote: Can someone either kick the thing until it works again or point me in the direction of the right person to bug? Eyebrowse is horribly broken. We want to re-create our archives on another box, but that's going to take a lot of time, unfortunately. Sorry. You could try: http://mail-archives.eu.apache.org/~jerenkrantz/mod_mbox/ Thanks, that'll help tremendously, it's both up to date and not as mind bogglingly slow as eyebrowse! ;-) -garrett
Re: apr_poll* changes
Paul Querna wrote: Joe Orton wrote: Quite a lot of unnecessary whitespace changes, e.g: I believe all of these changes are in accordance with the style guidelines. I made style 'fixes' in the new files, and did the same with what is left of poll.c. I guess I shouldn't treat the changed poll.c as a new file? I can undo the style changes for poll.c if you want them in a separate patch. The whitespace changes in this patch seem to be of two kinds. First, there's just plain old whitespace cleanup (removing trailing whitespace and whatnot). This seems fine, but should be committed separately from the rest of the patch as it makes it difficult to tell what functional changes are being made. Second there is an awful lot of changing from foo *bar to foo * bar when pointers are declared. I'm not sure what the style guide says about this, but I can't find anything in APR now that uses the new style you're using, so I'd personally prefer to just leave things as they are. Consistency seems more important than personal preference in this case. Technically speaking I think this patch is a great step forward, it makes the poll code considerably easier to read, and is a Good Thing (tm), I'd just like to avoid having the functional changes obscured by the intermingled whitespace changes. -garrett
Re: svn commit: r76284 - apr/apr/trunk
Now that we have converted to SVN, why doesn't the subject line include the file that is being changed in the commit message? This makes it harder to prioritize patches that need to be reviewed. Brad [EMAIL PROTECTED] Thursday, November 18, 2004 2:31:22 PM Author: jorton Date: Thu Nov 18 13:31:21 2004 New Revision: 76284 Modified: apr/apr/trunk/CHANGES Log: Note apr_file_printf rewrite. Modified: apr/apr/trunk/CHANGES == --- apr/apr/trunk/CHANGES (original) +++ apr/apr/trunk/CHANGES Thu Nov 18 13:31:21 2004 @@ -5,6 +5,10 @@ and upgrading it to do SHA-256. Not yet ready for prime time. [Ben Laurie] + *) Rewrite apr_file_printf to handle arbitrary length strings. + PR 28029. [Chris Knight Christopher.D.Knight nasa.gov, + Garrett Rooney rooneg electricjellyfish.net] + Changes for APR 1.0.1 *) Fix HUP return codes in pollset when using KQueue.
RE: svn commit: r76284 - apr/apr/trunk
Hi Brad, Now that we have converted to SVN, why doesn't the subject line include the file that is being changed in the commit message? This makes it harder to prioritize patches that need to be reviewed. Even though I'm a newbie as far as SVN (and APR) are concerned, I believe I can answer that: SVN supports commits of multiple files in one operation. Joe Abbate Senior Software Engineer Computer Associates [EMAIL PROTECTED]
Re: apr_poll* changes
At 12:04 PM 11/19/2004, Garrett Rooney wrote: Second there is an awful lot of changing from foo *bar to foo * bar when pointers are declared foo * bar implies multiplication to the reader. foo *bar implies pointer dereference. Syntactically equal, visually very different.
RE: svn commit: r76284 - apr/apr/trunk
At 12:30 PM 11/19/2004, Abbate, Joseph M wrote: Hi Brad, Now that we have converted to SVN, why doesn't the subject line include the file that is being changed in the commit message? This makes it harder to prioritize patches that need to be reviewed. Even though I'm a newbie as far as SVN (and APR) are concerned, I believe I can answer that: SVN supports commits of multiple files in one operation. Of course. So did cvs - question remains why don't svn commit messages include some manifest? Bill
Re: svn commit: r76284 - apr/apr/trunk
--On Friday, November 19, 2004 11:11 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: Now that we have converted to SVN, why doesn't the subject line include the file that is being changed in the commit message? This makes it harder to prioritize patches that need to be reviewed. Our CVS mailer only showed the last directory (with files) that was committed - so subject lines were *always* inaccurate when touching multiple directories. The SVN mailer always shows all directories that were modified. I think that's a far better compromise. Plus, we've received a number of complaints that the subject lines were too long to be useful: hence just the directory names. *shrug* -- justin
Re: svn commit: r76284 - apr/apr/trunk
Justin Erenkrantz wrote: --On Friday, November 19, 2004 11:11 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: Now that we have converted to SVN, why doesn't the subject line include the file that is being changed in the commit message? This makes it harder to prioritize patches that need to be reviewed. Our CVS mailer only showed the last directory (with files) that was committed - so subject lines were *always* inaccurate when touching multiple directories. The SVN mailer always shows all directories that were modified. I think that's a far better compromise. really? take a look at the current httpd commit page now on marc: http://marc.theaimsgroup.com/?l=apache-cvsr=1b=200411w=2 and compare it to the prior page http://marc.theaimsgroup.com/?l=apache-cvsr=2b=200411w=2 at least some of the commits in the past had the full filename in the subject, making them much easier to scan. if everything starts looking like it does now we'll have 50 million commits where the subject starts svn commit: r105782 - httpd/httpd/branches/2.0.x/... and runs off the edge of your email client. anyway, not to complain - you guys have been doing great work, and I'm very, very appreciative that things went so smoothly. but if there is a chance that the commit email format can be made more useful, that would be great. Plus, we've received a number of complaints that the subject lines were too long to be useful: hence just the directory names. httpd-test just had this subject svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules which I guess means that no matter what you do it can be long. --Geoff
More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
I'm sure that last thing that you want to hear is another complaint after all of the work you have gone to, but I'm not sure just listing directories is a better compromise. At least before I could see the difference between CHANGES and STATUS, now I just see trunk which could be any one of a number of files. Not all of which I am interested in. Personally I would opt for file listings rather than directory listings to keep the subject line shorter and more informative. I also don't need to see svn commit: r at the front of every message. I already know it is an SVN commit based on the mailing list it came from. And if I am really interested in the revision number, I'm sure I can get that from the message content. Thanks again for all of your hard work. Brad Justin Erenkrantz [EMAIL PROTECTED] Friday, November 19, 2004 12:12:39 PM --On Friday, November 19, 2004 11:11 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: Now that we have converted to SVN, why doesn't the subject line include the file that is being changed in the commit message? This makes it harder to prioritize patches that need to be reviewed. Our CVS mailer only showed the last directory (with files) that was committed - so subject lines were *always* inaccurate when touching multiple directories. The SVN mailer always shows all directories that were modified. I think that's a far better compromise. Plus, we've received a number of complaints that the subject lines were too long to be useful: hence just the directory names. *shrug* -- justin
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
--On Friday, November 19, 2004 2:41 PM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: listings to keep the subject line shorter and more informative. I also don't need to see svn commit: r at the front of every message. I already know it is an SVN commit based on the mailing list it came from. And if I am really interested in the revision number, I'm sure I can get that from the message content. IMHO, the revision number is the *most* important attribute of the commit. Subversion uses global revision numbers: there is no per-file revisions like CVS. If you know the revision number, you can get everything else. And, we already had a 'cvs commit: ' prefix on our previous CVS emails. -- justin
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
I understand about the revision numbers and I agree that it is an important piece of information, but unnecessary on the subject line. The subject line needs to include information that allows one to quickly sort and prioritize the commits. IMHO, the revision number isn't a piece of information that helps do that. Once I have determined that the commit is important enough for me to review, I will certainly open and view the contents of the message. After I have reviewed the commit via the message contents and determined that further review is necessary, that is the point when the revision number becomes *very* important. As far as the svn commit: prefix is concerned, it was redundant information before and I believe that it is still redundant information. Perhaps svn: is all that would be required so that when a commit message is replied to on the dev@ lists, it is distinguished from other posts. Brad [EMAIL PROTECTED] Friday, November 19, 2004 2:47:17 PM --On Friday, November 19, 2004 2:41 PM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: listings to keep the subject line shorter and more informative. I also don't need to see svn commit: r at the front of every message. I already know it is an SVN commit based on the mailing list it came from. And if I am really interested in the revision number, I'm sure I can get that from the message content. IMHO, the revision number is the *most* important attribute of the commit. Subversion uses global revision numbers: there is no per-file revisions like CVS. If you know the revision number, you can get everything else. And, we already had a 'cvs commit: ' prefix on our previous CVS emails. -- justin
msdev chokes on .dsp and .dsw in unix text file format
Hi. I know Im new, and I wanted to check out the APR-1.0.0 release. With the release, APR is receiving a lot of attention at the moment, so I thought Id post my only problem and solution. Everything compiled fine under cygwin and redhat linux, but choked in msdev. The .dsp and .dsw files are in Unix text file format, and msdev doesnt give a clear error message. It simply says project not found. Of course, the solution was to run lineends.pl on the tree and everything worked fine. I propose adding lineends.pl to the Build on Win32 page, or try to keep the .dsp and .dsw files in DOS format. Im sorry if this issue has come up previously. Thanks, and great job on the release! -- kris
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
Brad Nicholes wrote: I'm sure that last thing that you want to hear is another complaint after all of the work you have gone to, but I'm not sure just listing directories is a better compromise. At least before I could see the difference between CHANGES and STATUS, now I just see trunk which could be any one of a number of files. Not all of which I am interested in. Personally I would opt for file listings rather than directory listings to keep the subject line shorter and more informative. I also don't need to see svn commit: r at the front of every message. I already know it is an SVN commit based on the mailing list it came from. And if I am really interested in the revision number, I'm sure I can get that from the message content. I agree with Brad. Also what kind of usability one finds to get a 10 lines and more long Subject? Here is an example of a recent commit. Subject: svn commit: r105803 - in httpd/test/trunk/perl-framework: . Apache-Test Apache-Test/lib/Apache Apache-Test/t Apache-Test/t/conf c-modules c-modules/authany c-modules/client_add_filter c-modules/eat_post c-modules/echo_post c-modules/echo_post_chunk c-modules/input_body_filter c-modules/list_modules c-modules/nntp_like c-modules/random_chunk c-modules/test_apr_uri c-modules/test_pass_brigade c-modules/test_rwrite c-modules/test_ssl t t/conf t/conf/ssl t/htdocs/modules/access/htaccess t/htdocs/modules/cgi t/htdocs/modules/rewrite t/modules I think it'll be more useful to have the following Subject format: $id $first_subdir/$first_file ($trunk) in the example above (where only dirs were affected): Subject: r105803 . (httpd/test/trunk/perl-framework) If there was a file changed, e.g. Apache-Test/README Subject: r105803 Apache-Test/README (httpd/test/trunk/perl-framework) if you wish to retain 'svn' prefix, that's fine, but there is need to waste space with 'svn commit'. e.g.: Subject: svn r105803 Apache-Test/README (httpd/test/trunk/perl-framework) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: msdev chokes on .dsp and .dsw in unix text file format
Kris Carlgren wrote: Hi. I know Im new, and I wanted to check out the APR-1.0.0 release. With the release, APR is receiving a lot of attention at the moment, so I thought Id post my only problem and solution. Everything compiled fine under cygwin and redhat linux, but choked in msdev. The .dsp and .dsw files are in Unix text file format, and msdev doesnt give a clear error message. It simply says project not found. Of course, the solution was to run lineends.pl on the tree and everything worked fine. I propose adding lineends.pl to the Build on Win32 page, or try to keep the .dsp and .dsw files in DOS format. Actually now that APR is in Subversion we can just set svn:eol-style on the files in question and never have this problem again. -garrett
