Re: apr-iconv 1.0
At 06:30 PM 6/23/2004, David Reid wrote: I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 - they are seperate subsets with their own set of issues. APR 1.0 does not require apr-util or apr-iconv, there is no dependency. So no holdup of David's plans. Well, I'd agree on apr-iconv (haven't even rolled a 1.0 rc yet) but apr-util needs to be released the same time as apr. Our 2 biggest users (httpd svn) both use both (if that makes sense) so if we have apr 1.0, we have apr-util 1.0. Well, we can't ignore apr-iconv, apr-util has a dependency upon it for those platforms without a native port of iconv. But nothing precludes us from rolling up apr and dropping it upon the world, then rolling up apr-util and dropping that 1.0.0 in a separate step. I'm proposing we switch around apr-iconv's interface to: 1) change typedef void *apr_icon_t; to an incomplete type, e.g. typedef struct apr_icon_t apr_icon_t; 2) consistently use an apr_icon_t * or (for create) apr_icon_t ** as the arguments to the exposed functions. 3) reorder apr_iconv_open to pass the new apr_iconv_t ** placeholder as the first not last arg, consistent with apr. 4) drop apr_pool_t argument from _close, that should use the same pool as the associated _open. Why does this hold up an apr-util 1.0 ? Please elaborate further. Because apr-util 1.0 consumes apr-iconv, at least for non-unix distros. It does slightly annoy me that there has been a decent sized interval to discsuss such issues and only now are they being brought up. Agreed - wish there were more eyes on the code. My attention was solely focused on apr for the past weeks. I think we very nearly have that right, so now i'm looking sideways at apr-util and how it could defy developer's expectations. And the build breakage pointed out to me how wonky the current apr-iconv API really was (and mostly, my fault in the first place :) Bill
Re: apr-iconv 1.0
At 12:35 PM 6/25/2004, Branko Čibej wrote: David Reid wrote: If the answer to the question does what we have now work is yes then apr-util 1.0 is good to go. +1 The apr-iconv API is unfortunate, and the fact that it doesn't support transliteration like GNU libiconv is worse, but most uses of apr-iconv will be through the apr-util xlate wrapper, so it's not so important to clean up the API. Also, if we're going to change the API, we might as well move base it on the iconv-2.0 version (we're currently using the 1.0 as a baseline). Is there a non-[l]gpl iconv 2? I found one is freebsd ports, that I think is the current (and has a new maintainer.) Want to be certain we are speaking about the same one. I'm tempted to say we explicitly declare libapriconv as a private library of libaprutil, just as the bundled expat is, with no public api support. That simplifies things to simply @doxygenate the apr-iconv header to say this is an internal api for use by apr-util, and pointing them to those functions. The goal would be to allow us to redo the latest bsd-licensed iconv to support other platforms, with or without apr, as an opaque dependency. Bill
Re: apr-iconv 1.0
Can I get a vote on apr-iconv in this respect? At 01:12 PM 6/25/2004, William A. Rowe, Jr. wrote: I'm tempted to say we explicitly declare libapriconv as a private library of libaprutil, just as the bundled expat is, with no public api support. That simplifies things to simply @doxygenate the apr-iconv header to say this is an internal api for use by apr-util, and pointing them to those functions. The goal would be to allow us to redo the latest bsd-licensed iconv to support other platforms, with or without apr, as an opaque dependency. E.g. plugging in any iconv, even a non-iconv translation backend behind our apr-util's xlate API, would ensure nobody would 'count on' anything but apr-util apr_xlate_xxx to exist.
Re: [PROPOSAL] cgi_exec_info_t: detached addrspace fieldscombined
At 04:14 PM 6/27/2004, Paul Querna wrote: I think we should branch httpd 2.1 into 2.2, and make a new stable branch. The focus Work on making an APR 1.1 with *any* API changes we need, and at the same time push 2.1 towards a 2.2 branch. Hopefully in a month or two, release APR 1.1.0 and HTTPd 2.2.0 with the new APIs and plenty of new features. ??? First, we aren't [EMAIL PROTECTED], we have no say. Second, 2.1-dev is perpetually 2.1-dev (or 2.1.0-dev, 2.1.1-dev, etc)... There is no reason to fork the 2.1 dev tree because it will never be a release. The 2.2 will be a release according to the generally accepted roadmap of the httpd project. If that means it's based on APR 1.0, or 1.1, or 2.0, all depends on where APR is when httpd-2.2.0 is finally -released-. It will be the finishing point of the httpd-2.1 development effort. AFA this patch, I'd say go for it, it looks pretty useful and mostly harmless. Bill
Re: [PROPOSAL] cgi_exec_info_t: detached addrspace fields combined
At 04:17 AM 6/28/2004, Joe Orton wrote: OK, the apr_procattr_addrspace_set() interface is sufficient to solve this problem, right? And there's no issue with back-porting that to the APR 0.9 branch? The only issue is how to use that interface from mod_cgi/the Netware MPM without requiring an httpd major MMN bump? So why not just overload the 'detached' field in cgi_exec_info_t inside mod_cgi/Netware MPM? That's should cause too much damange. Agreed, if that's a private structure, no bumps needed. -1 on overloading apr_procattr_detach_set() to do this, that's bad API design, and uglifying the APR API just to satisfy an httpd binary compat requirement just seems very wrong. I agree. If you want to overload the bit flags, that's fine, because the actual apr_procattr_t should be opaque to the user, correct? But having two seperate fn's to set detached v.s. addrspace seems like a much better public API.
Re: 1.0 rc2 Tarballs
At 07:06 AM 6/30/2004, David Reid wrote: I haven't done apr-iconv as Will Rowe had some reservations about that module. If someone who's more familiar wants to roll a tarball that's compatible with rc2 that'd be great. Doesn't matter - now that you've tagged apr-util-1.0.0 - we are locked into using that apr-iconv interface period for apr-iconv-1.0.0. All I'd suggested at this juncture is to add some notatation that the apr_iconv_ functions are private interfaces, e.g. @deprecated Private Interface! See the apr-util apr_xlate.h API. Can we get some +1's on this? IMHO we can't release this tarball without moving to apr-1-config as mentioned in the apr pkgconfig thread. This allows us to have 0.9 and 1.0 installed side by side, e.g. if httpd and svn users are building both older and newer software. While they cannot be installed side by side, I'm -1 for release; once addressed I'm +1.
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
At 03:56 AM 6/30/2004, Joe Orton wrote: On Wed, Jun 30, 2004 at 09:49:48AM +0100, Max Bowsher wrote: Joe Orton wrote: On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote: ... So, please change the recently added pkgconfig support to install apr-1.pc, so that upstream packages will run pkg-config --libs apr-1 instead of just looking for any old version of APR. By itself, that won't help with the APR 0.9 to APR 1.x transition, but it will help with APR 1.x to APR 2.x. Yeah, I realised the same thing... I'll rename it. Separately, I will request that APR remove apr-config from APR 1.0 and later in order to correctly manage the APR 0.9 - APR 1.0 transition, but I bet that won't fly. APR cannot mandate presence of pkgconfig, so do you have an alternative? Install apr-config as apr-$(APR_MAJOR_VERSION)-config ? Greg wrote remove rather than rename, though indeed, I guess renaming should work. Hmmm... If an app is written to support apr 2, 1 or 0, wouldn't a sanity check for the presence of apr-2-confiig / apr-1-config / apr-config solve this? Leave installed apr-config as a presumed-rev 0.9.x installed version. Now that Max mentions this - I have tripped over it once before. Bill
Re: cvs commit: apr/strings apr_strings.c
At 08:17 AM 6/30/2004, Jeff Trawick wrote: I like Joe's suggestion of catching it in the test suite. If the API is ever changed so that the caller specifies the length of their buffer, then there will be an interesting case which apr_snprintf() could catch. Unfortunately, you would need to test the full range of possible inputs or you won't catch an edge case. One question, perhaps, is why we silently succeed while truncating the output string in apr_snprintf(). Obviously some snprintf's pass, some fail, so there must be some religious argument over 'proper' behavior. My personal philosophy, retval -1 for apr_snprintf() would tell the user we succeeded in filling their buffer, and then choked. They gave us the size of the buffer, so they should know how much was filled if they are happy with the truncated result Because the (new) flavor can never overflow (invoking apr_snprintf), I'd be happy ignoring the retval entirely. If the last position is non-alpha, the user knows something was borked. Either way, there isn't the risk of an overflow anymore. Bill
Re: apr-config and apr-1-config
At 04:55 PM 7/1/2004, Joe Orton wrote: On Thu, Jul 01, 2004 at 11:45:44PM +0200, Graham Leggett wrote: Joe Orton wrote: I've noticed that the most recent CVS of 1.0.0 installs both /usr/bin/apr-config, and /usr/bin/apr-1-config. Is this intentional? Yes, for the moment. How do you suggest the RPM should handle this? - at the moment installing a v0 RPM and a v1 RPM simultaneously will cause a conflict. Should we just leave it as is for now? Yes, just leave it for the moment I guess. If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( Bill
RE: remaining issues prior to 1.0?
While researching -ctime thoughts on list... (the entire thread might be enlightening to review for those who want some weekend reading :) Nearly a year ago, At 11:09 AM 6/25/2003, William A. Rowe, Jr. wrote: At 03:27 AM 6/25/2003, Marc M. Adkins wrote: * emulating the daemon/services foo within the Win32 port... but call it a 'nice to have' ... I will try to dedicate cycles to this over the summer. It's not exactly a showstopper. Can you expand on this? Are you talking about the usual Windows doesn't fork problem, emulating Windows services on Linux, getting process data (memory size, CPU %, etc.) or something else entirely? Just curious. although I would *really* like to deal with fork() ... it isn't practical (topic for another thread). I was restricting my focus to mapping Service 'Events' - Unix Signals, such as stop, start, shutdown, and marking Apache as 'already daemonized' when you start as a service. My only headache - I spent some time trying to find how we can safely assert that this WinNT/2K/XP/2003 process is running within the SCM (NT kernel service control manager). The short answer so far; it isn't very pretty. If we knew that, we would have APR react and start a service control thread, and then enter the NT event processing loop. On the Win9x side, implement daemonize_process to dismiss the window and mark the process as a 'psuedo-service'. Again, the hidden window we create to track Apache shutting down would trigger our 'unix' signals. so it looks on NT as apr_app_initialize() \- Running as service? \- Spin up service monitor and nt eventlog capture thread for stderr \- In service monitor thread, call into the SCM to be called back. \- Fix the argv[] based on the ServiceStart args. and then react to service control signals to the monitor thread based on our apr_signals() API. The only other two big thorns left in APR? File Create time isn't the same as the inode modified ctime. And we don't have an API to map ACL management between implementations, nor a way for Win32 to handle setuid(). In Win32's case, we need the account 'password' to deal with a setuid() request. The first is a real bug to fix, the second is perhaps beyond the scope of releasing 1.0. And in hind site - I don't see any reason we can't implement signals on win32 using the existing API. The ctime issue was brought up again and seems to be pretty important. And mapping ACL's on HPUX/Win32 and Linux/SE seems like it's own ballgame that would
Re: apr-iconv 1.0
At 06:41 PM 7/1/2004, Branko Čibej wrote: Thoughts? I think 1.0 is an auspicious time to make this change, especially if we declare apr-iconv to be an implementation detail of apr_xlate. The nifty bit is, if we declare apr-iconv to be an internal, implementation detail of apr_xlate - we are free to adopt your suggestions in 1.0.1 :) What is troubling us most, at this instant, are those things that change the API in such a way that developer's code would be broken fixing the problems of APR 1.0.0. As long as they are internal details (default pathing, etc) then we won't be troubled by getting it right a little later. Bill
Re: apr_finfo_t ctime field
Wow - and time is almost gone. Sorry this got no response until today, I'm not sure the powers that be really care for this change to go in until 2.0 at this point (it's an eliminated ctime and added crtime intime member of a transparent structure that's user-allocated.) Would be really nice to see one more bit of feedback before I commit such a change - amazes me we are the only two folks considering this issue. Sander Striker on 4/27/03 and Brian Pane the day after pondered this a while, but apparently we are the only two with any real concern about the ambiguity. Anyone else care to chime in? At 06:28 PM 7/1/2004, Branko Čibej wrote: William A. Rowe, Jr. wrote: As we approach APR 1.0 --- is it time to address the ambiguity between ctime, which is actually the inode file time stamp for unix, and the creation time stamp for win32? Persisting either ctime will propogate the confusion, I suggest splitting them into intime and crtime. Opinions? I'll offer an APR 1.0 patch tommorow based on feedback. Yes, yes, yes. Sorry I didn't notice this before. This would be a very good change. -- Brane
Re: apr-config and apr-1-config
At 07:29 PM 7/1/2004, Greg Stein wrote: On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote: If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( for the moment Joe said it *twice*. Was it that non-obvious? No, it was obvious. However another party is rolling what he hopes to be the initial release on Friday, on his schedule. So if we *release* on Fri this would not be good. If it gets fixed next week and we can hold the release till next week, all would be lovely. Competing interests - and my message wasn't directed at Joe or Graham who have been working hard at the rpm/parallel install issues. It was directed at David who was hoping (expecting?) to roll an RC3 candidate today. Bill Bill
RE: remaining issues prior to 1.0?
At 02:24 AM 7/2/2004, William A. Rowe, Jr. wrote: [...] And in hind site - I don't see any reason we can't implement signals on win32 using the existing API. The ctime issue was brought up again and seems to be pretty important. And mapping ACL's on HPUX/Win32 and Linux/SE seems like it's own ballgame that would ... be it's own incremental version bump, e.g. 1.1 or whatnot. No need to hold up 1.0. Sorry, full of incomplete thoughts today - it's been a long week. Bill
Re: apr-config and apr-1-config
At 11:20 AM 7/2/2004, you wrote: At 07:29 PM 7/1/2004, Greg Stein wrote: On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote: If we leave it, and side-by-side installs are broken, this does not seem like a good initial release point for 1.0 :( for the moment Joe said it *twice*. Was it that non-obvious? No, it was obvious. However another party is rolling what he hopes to be the initial release on Friday, on his schedule. So if we *release* on Fri this would not be good. If it gets fixed next week and we can hold the release till next week, all would be lovely. Competing interests - and my message wasn't directed at Joe or Graham Damn. Competing interests? So, no-one else wants to get 1.0 out teh door. Wow, must have been in dream land for a long, long time then... Speed/Schedule of releasing 1.0 v.s. Completeness/Interoperability w/ 0.9. I for one am glad you've put folks feet to the fire so to speak, and laid out an ambitious plan for release of 1.0 this month :) Sometimes, until you try to implement, what seemed just fine in a build system turns out to be ineffective when confronted with rolling usable rpm's, deploying side by side with previous versions, etc. It wasn't until apr-1.0 that the apr/httpd side has ever really considered side-by-side installation issues, since we need the legacy 0.9 for some time to support httpd 2.0, and will need 1.0 installed and ready for httpd 2.1+, svn, jakarta-jk2 and so forth. Graham's RPM efforts have put a magnifying glass to every open parallel install issue - I think it's wonderful that he created the perfect example case whether he intended to, or not :) who have been working hard at the rpm/parallel install issues. It was directed at David who was hoping (expecting?) to roll an RC3 candidate today. Well, some form of explanation of the above would be more helpful than cryptic comments. Sorry, it was my reaction to Greg's comments - which read (to me) that he was saying yes - table this for now, release 1.0.0, install and clobber the existing shared apr 0.9.5 install, then figure out how to get it right with release 1.0.1. That concerned me. 1/10 on helpfulness. I believe, with the possible exception of apr_finfo_t::ctime (and still asking for feedback), that APR is code-complete API stable for 1.0. With apr-iconv designated as a mutable implementation detail of the public apr_xlate interface, that is not an issue either. I spent no time in apr-util so I really don't have an opinion either way. If Graham's efforts, with Joe's useful feedback, produces a build system which cleanly lets 0.9 and 1.0 (and future releases) coexist, I'm satisfied we finished APR 1.0. I'd be very happy if we left apr-config alone (as 0.9), created apr-1-config or apr-1.0-config with a symlink named apr-1-config, and let the consumers attempt to use apr-[n..1]-config down to apr-config, based on what THEIR application is targeted at and capable of supporting. The version argument solution to apr-config also sounds like it could solve the problem. Bill
Re: apr-iconv 1.0
At 12:46 PM 7/2/2004, Branko Äibej wrote: William A. Rowe, Jr. wrote: At 06:41 PM 7/1/2004, Branko Ãibej wrote: Thoughts? I think 1.0 is an auspicious time to make this change, especially if we declare apr-iconv to be an implementation detail of apr_xlate. The nifty bit is, if we declare apr-iconv to be an internal, implementation detail of apr_xlate - we are free to adopt your suggestions in 1.0.1 :) That's true. Then I suggest we really do close off apr-iconv. This means the apr-iconv headers shouldn't get installed, right? Among other things. ++1 to that idea, as long as apr-util internally gets the -I / -L paths to the build of apr-iconv, and they don't persist in the apu-1-config file. Bill
[PATCH APR 1.0] crtime v.s. intime
Here's the patch for those interested, which splits ctime into crtime
and intime.
An interesting side effect, neither crtime nor intime stay part of the
APR_FINFO_MIN set of information - one bit or the other would be
toggled.
BillIndex: file_io/netware/filestat.c
===
RCS file: /home/cvs/apr/file_io/netware/filestat.c,v
retrieving revision 1.34
diff -u -r1.34 filestat.c
--- file_io/netware/filestat.c 29 Mar 2004 17:53:28 - 1.34
+++ file_io/netware/filestat.c 2 Jul 2004 20:01:09 -
@@ -55,8 +55,9 @@
static void fill_out_finfo(apr_finfo_t *finfo, struct stat *info,
apr_int32_t wanted)
{
-finfo-valid = APR_FINFO_MIN | APR_FINFO_IDENT | APR_FINFO_NLINK
-| APR_FINFO_OWNER | APR_FINFO_PROT;
+finfo-valid = APR_FINFO_MIN | APR_FINFO_INTIME
+ | APR_FINFO_IDENT | APR_FINFO_NLINK
+ | APR_FINFO_OWNER | APR_FINFO_PROT;
finfo-protection = apr_unix_mode2perms(info-st_mode);
finfo-filetype = filetype_from_mode(info-st_mode);
finfo-user = info-st_uid;
@@ -67,7 +68,8 @@
finfo-nlink = info-st_nlink;
apr_time_ansi_put(finfo-atime, info-st_atime.tv_sec);
apr_time_ansi_put(finfo-mtime, info-st_mtime.tv_sec);
-apr_time_ansi_put(finfo-ctime, info-st_ctime.tv_sec);
+/* XXX Is this intime (or actually cr time?) */
+apr_time_ansi_put(finfo-intime, info-st_ctime.tv_sec);
/* ### needs to be revisited
* if (wanted APR_FINFO_CSIZE) {
* finfo-csize = info-st_blocks * 512;
Index: file_io/os2/dir.c
===
RCS file: /home/cvs/apr/file_io/os2/dir.c,v
retrieving revision 1.36
diff -u -r1.36 dir.c
--- file_io/os2/dir.c 13 Feb 2004 09:38:24 - 1.36
+++ file_io/os2/dir.c 2 Jul 2004 20:01:10 -
@@ -101,12 +101,12 @@
thedir-entry.ftimeLastWrite);
apr_os2_time_to_apr_time(finfo-atime, thedir-entry.fdateLastAccess,
thedir-entry.ftimeLastAccess);
-apr_os2_time_to_apr_time(finfo-ctime, thedir-entry.fdateCreation,
+apr_os2_time_to_apr_time(finfo-crtime, thedir-entry.fdateCreation,
thedir-entry.ftimeCreation);
finfo-name = thedir-entry.achName;
finfo-valid = APR_FINFO_NAME | APR_FINFO_MTIME | APR_FINFO_ATIME |
-APR_FINFO_CTIME | APR_FINFO_TYPE | APR_FINFO_SIZE |
+APR_FINFO_CRTIME | APR_FINFO_TYPE | APR_FINFO_SIZE |
APR_FINFO_CSIZE;
return APR_SUCCESS;
Index: file_io/os2/filestat.c
===
RCS file: /home/cvs/apr/file_io/os2/filestat.c,v
retrieving revision 1.41
diff -u -r1.41 filestat.c
--- file_io/os2/filestat.c 22 May 2004 07:26:10 - 1.41
+++ file_io/os2/filestat.c 2 Jul 2004 20:01:10 -
@@ -42,11 +42,11 @@
fstatus-ftimeLastAccess );
apr_os2_time_to_apr_time(finfo-mtime, fstatus-fdateLastWrite,
fstatus-ftimeLastWrite );
-apr_os2_time_to_apr_time(finfo-ctime, fstatus-fdateCreation,
+apr_os2_time_to_apr_time(finfo-crtime, fstatus-fdateCreation,
fstatus-ftimeCreation );
finfo-valid = APR_FINFO_TYPE | APR_FINFO_PROT | APR_FINFO_SIZE
| APR_FINFO_CSIZE | APR_FINFO_MTIME
- | APR_FINFO_CTIME | APR_FINFO_ATIME | APR_FINFO_LINK;
+ | APR_FINFO_CRTIME | APR_FINFO_ATIME | APR_FINFO_LINK;
}
Index: file_io/unix/filestat.c
===
RCS file: /home/cvs/apr/file_io/unix/filestat.c,v
retrieving revision 1.72
diff -u -r1.72 filestat.c
--- file_io/unix/filestat.c 27 Mar 2004 13:11:17 - 1.72
+++ file_io/unix/filestat.c 2 Jul 2004 20:01:10 -
@@ -69,7 +69,8 @@
static void fill_out_finfo(apr_finfo_t *finfo, struct_stat *info,
apr_int32_t wanted)
{
-finfo-valid = APR_FINFO_MIN | APR_FINFO_IDENT | APR_FINFO_NLINK
+finfo-valid = APR_FINFO_MIN | APR_FINFO_INTIME
+ | APR_FINFO_IDENT | APR_FINFO_NLINK
| APR_FINFO_OWNER | APR_FINFO_PROT;
finfo-protection = apr_unix_mode2perms(info-st_mode);
finfo-filetype = filetype_from_mode(info-st_mode);
@@ -81,7 +82,7 @@
finfo-nlink = info-st_nlink;
apr_time_ansi_put(finfo-atime, info-st_atime);
apr_time_ansi_put(finfo-mtime, info-st_mtime);
-apr_time_ansi_put(finfo-ctime, info-st_ctime);
+apr_time_ansi_put(finfo-intime, info-st_ctime);
/* ### needs to be revisited
* if (wanted APR_FINFO_CSIZE) {
* finfo-csize = info-st_blocks * 512;
Index: file_io/win32/filestat.c
===
RCS file: /home/cvs/apr/file_io/win32/filestat.c,v
Re: 1.0.0 RC3
At 10:45 AM 7/12/2004, Graham Leggett wrote: I have created a spec file for apr-iconv - but so far it seems apr-iconv is only necessary on windows. Can anyone confirm whether apr-iconv is needed on any Unix like platforms at all? Anyone have other examples for Graham? Inquiring minds want to know! This has alot to do with creating the appropriate 'patch' to enable iconv-2.0 to run in Win32, thereby jettisoning apr-iconv in APR-util 1.0.1. Obviously the answer to this question will shape how we win32 porters move forward. Bill
Re: 1.0.0 RC3
At 10:52 AM 7/12/2004, David Reid wrote: Timetable is RC4 tomorrow, 1.0.0 on Thursday afternoon after my proficiency checks at work are over! David, please make sure we don't include STATUS in those final tarballs. I'd like to roll an RC4 win32 .zip as soon as your are done rolling RC4. If you use the roll-release script, apr-iconv should get an API_1_0_0_RC4 tag, but if not I will tag what I extract for win32. Bill
Re: 1.0.0 RC4
At 10:43 AM 7/14/2004, Joe Orton wrote: On Wed, Jul 14, 2004 at 04:33:14PM +0100, Max Bowsher wrote: Joe Orton wrote: RC4 is still installing prefix/bin/apr-config , so making it impossible to install apr 0 and apr 1 side-by-side. Known issue, will get fixed sometime after 1.0.0 once everything else has been hooked up to use apr-1-config. Won't that be too late, because of API compat requirements? Which answer do you prefer? :) 1. No, apr-config is not part of the API 2. Yes, tough I was surprised that you missed #3. It's broke - but you get both pieces. I'm really not teasing - show us the code to fix the complaint. I do find it incredibly amusing and ironic that the same crew fighting with which libtool rev will work?, due to *that* moving target, would endorse either answer 1. or 2. But, I have no intentions of installing apr globally on any box, so it doesn't affect me at all. Every application based on apr that I'm interested in I've always built against a private apr install. (As I say, I'm a vpath build addict.) So... The first group this primarily hurts are devs attempting to build against either, installed side-by-side (still trusting apr-config? outch, you are broke on 1.0.1). Document that they must use apr-1-config, they are fine. Ohhh, also document that they need to rename apr-config out of the way before 1.0 installation, and then copy it back. They are devs, it's not that difficult, and it gets them ready to build against apr 1.0.1. The other group this also hurts are OS packagers, who can't ship apr 1.0.0 as designed. Presuming they want to roll in apache 1.3, 2.0, and svn sometime in the near future, they just need to rejigger the finished set of files. The final group, app users, really won't notice. First, by the time they are ready to adopt an apr 1.0 app, 1.0.1 will be out and this will be fixed, perhaps. Provided the first two groups don't goof on our account. So I'm +1 for -beta, -0 for release. I won't block it. But I certainly hope those, who get so ticked off at the example of libtool's bogosity, would wish less pain and more consistency for _our_ end users. Just not looking forward to the day when Why do my modules fail to build with apxs (-2.0) start to show up on [EMAIL PROTECTED] Bill
Re: [PATCH APR 1.0] crtime v.s. intime
Ping list - 12 days elapsed. No interest? Only comment was from Branko,
and not in response to this patch.
Since we've floated about this for a year with only a few interested parties
- I suppose it's time to kill the proposal and just document the inconsistency.
Attached are two patches, one introduces intime/crtime (I missed adding
the actual apr_time_t intime member in the last patch - this fixes it.)
The doc_fix patch just documents the deficiency. Let's pick one or the other.
Bill
At 03:06 PM 7/2/2004, William A. Rowe, Jr. wrote:
Here's the patch for those interested, which splits ctime into crtime
and intime.
An interesting side effect, neither crtime nor intime stay part of the
APR_FINFO_MIN set of information - one bit or the other would be
toggled.
Index: include/apr_file_info.h
===
RCS file: /home/cvs/apr/include/apr_file_info.h,v
retrieving revision 1.47
diff -u -r1.47 apr_file_info.h
--- include/apr_file_info.h 25 Jun 2004 15:28:42 - 1.47
+++ include/apr_file_info.h 14 Jul 2004 20:22:03 -
@@ -133,7 +133,7 @@
#define APR_FINFO_LINK 0x0001 /** Stat the link not the file itself if
it is a link */
#define APR_FINFO_MTIME 0x0010 /** Modification Time */
-#define APR_FINFO_CTIME 0x0020 /** Creation Time */
+#define APR_FINFO_CTIME 0x0020 /** Creation or inode-changed time */
#define APR_FINFO_ATIME 0x0040 /** Access Time */
#define APR_FINFO_SIZE 0x0100 /** Size of the file */
#define APR_FINFO_CSIZE 0x0200 /** Storage size consumed by the file */
@@ -191,7 +191,7 @@
apr_time_t atime;
/** The time the file was last modified */
apr_time_t mtime;
-/** The time the file was last changed */
+/** The time the file was created, or the inode was last changed */
apr_time_t ctime;
/** The pathname of the file (possibly unrooted) */
const char *fname;
Index: file_io/netware/filestat.c
===
RCS file: /home/cvs/apr/file_io/netware/filestat.c,v
retrieving revision 1.34
diff -u -r1.34 filestat.c
--- file_io/netware/filestat.c 29 Mar 2004 17:53:28 - 1.34
+++ file_io/netware/filestat.c 14 Jul 2004 20:13:39 -
@@ -55,8 +55,9 @@
static void fill_out_finfo(apr_finfo_t *finfo, struct stat *info,
apr_int32_t wanted)
{
-finfo-valid = APR_FINFO_MIN | APR_FINFO_IDENT | APR_FINFO_NLINK
-| APR_FINFO_OWNER | APR_FINFO_PROT;
+finfo-valid = APR_FINFO_MIN | APR_FINFO_INTIME
+ | APR_FINFO_IDENT | APR_FINFO_NLINK
+ | APR_FINFO_OWNER | APR_FINFO_PROT;
finfo-protection = apr_unix_mode2perms(info-st_mode);
finfo-filetype = filetype_from_mode(info-st_mode);
finfo-user = info-st_uid;
@@ -67,7 +68,8 @@
finfo-nlink = info-st_nlink;
apr_time_ansi_put(finfo-atime, info-st_atime.tv_sec);
apr_time_ansi_put(finfo-mtime, info-st_mtime.tv_sec);
-apr_time_ansi_put(finfo-ctime, info-st_ctime.tv_sec);
+/* XXX Is this intime (or actually cr time?) */
+apr_time_ansi_put(finfo-intime, info-st_ctime.tv_sec);
/* ### needs to be revisited
* if (wanted APR_FINFO_CSIZE) {
* finfo-csize = info-st_blocks * 512;
Index: file_io/os2/dir.c
===
RCS file: /home/cvs/apr/file_io/os2/dir.c,v
retrieving revision 1.36
diff -u -r1.36 dir.c
--- file_io/os2/dir.c 13 Feb 2004 09:38:24 - 1.36
+++ file_io/os2/dir.c 14 Jul 2004 20:13:39 -
@@ -101,12 +101,12 @@
thedir-entry.ftimeLastWrite);
apr_os2_time_to_apr_time(finfo-atime, thedir-entry.fdateLastAccess,
thedir-entry.ftimeLastAccess);
-apr_os2_time_to_apr_time(finfo-ctime, thedir-entry.fdateCreation,
+apr_os2_time_to_apr_time(finfo-crtime, thedir-entry.fdateCreation,
thedir-entry.ftimeCreation);
finfo-name = thedir-entry.achName;
finfo-valid = APR_FINFO_NAME | APR_FINFO_MTIME | APR_FINFO_ATIME |
-APR_FINFO_CTIME | APR_FINFO_TYPE | APR_FINFO_SIZE |
+APR_FINFO_CRTIME | APR_FINFO_TYPE | APR_FINFO_SIZE |
APR_FINFO_CSIZE;
return APR_SUCCESS;
Index: file_io/os2/filestat.c
===
RCS file: /home/cvs/apr/file_io/os2/filestat.c,v
retrieving revision 1.41
diff -u -r1.41 filestat.c
--- file_io/os2/filestat.c 22 May 2004 07:26:10 - 1.41
+++ file_io/os2/filestat.c 14 Jul 2004 20:13:39 -
@@ -42,11 +42,11 @@
fstatus-ftimeLastAccess );
apr_os2_time_to_apr_time(finfo-mtime, fstatus-fdateLastWrite,
fstatus-ftimeLastWrite );
-apr_os2_time_to_apr_time(finfo-ctime, fstatus-fdateCreation
Re: 1.0.0 RC4 (apr-config - apr-1-config)
At 04:24 PM 7/14/2004, Max Bowsher wrote: Joe Orton wrote: On Wed, Jul 14, 2004 at 04:12:29PM +0100, Max Bowsher wrote: David Reid wrote: Tarballs available at http://www.apache.org/~dreid/ Test report! RC4 is still installing prefix/bin/apr-config , so making it impossible to install apr 0 and apr 1 side-by-side. Known issue, will get fixed sometime after 1.0.0 once everything else has been hooked up to use apr-1-config. I'm unsure whether my m4 skills are sufficient, but since this is of interest to me as I package apr for cygwin, I'm going to work on this, to ideally get it done for apr 1.0.0, if I can, if not, helping to get it done in 1.0.1 at the latest. Thank you Max! I know that others and I are all willing to review patches. Just be prepared for a little give-and-take in getting them approved :) Is there anything I've missed out here: apr: Needs the find_apr.m4 machinery fixed to use apr-1-config. Sounds right. Folks have asked for a fallback-schema for users who are willing to code alot of #if (APR_MAJOR_VERSION 1) code into their applications. Would be a seperate macro to find apr-1-config, or if not found, then find apr-config. apr-util: Needs to adapt to the changes in apr, and have mirrored changes to apu-config (Can this wait until after apr-1.0.0, provided it is done soon after?) I raised this question - and the answer I heard was that apr + -util + -iconv are all leaving the door together. httpd-HEAD: Needs to adapt to the changed find_apr.m4 (Again, must this be done simultaneously with the apr changes?) subversion: No changes, using apr-0.9, at least as the officially supported version. I'm sure these two both need help (including svn head), but it can occur after APR 1.0.0 is released. Only the warm-fuzzies that it all plays well together would hold anything up. I know that mod_jk2 is also very hokey, I need to spend some time over there after I finish cleaning up some win32 version-foo. Bill
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0 RC4 (apr-config - apr-1-config)
At 10:09 AM 7/15/2004, Justin Erenkrantz wrote: --On Thursday, July 15, 2004 5:34 AM -0700 Noah Misch [EMAIL PROTECTED] wrote: The minimum version field does need to accept two digits. A project could use an API added in APR 1.X, in which case e.g. APR_FIND_APR(,,, 1.4, 3) would be appropriate and necessary. No? If a project wants that level of specificity, they can call $apr_config after calling APR_FIND_APR to reject versions they find unsuitable. But, you can't have parallel installs of APR with the same major version number. -- justin APR_FIND_APR returns only the first apr found - what 'list of found apr's' do you suggest the author validate against to determine where apr-1(.1) lives? Bill
Re: [PATCH] Stop installing apr-config, and give clients an APR_FIND_APR that works with apr-1-config.
At 04:11 AM 7/16/2004, Max Bowsher wrote: 4) Because there is no sensible default. [1 0] implies that a project should work with either. Unless project maintainers decide to maintain testing of both versions, the secondary choice may well get stale. Defaulting to [1] will result in projects that don't even consider whether they can work with apr-0. And [0] is clearly useless. No, [0] as default means the app was built for an older APR_FIND_APR, e.g. 0.9 - and every modern user can choose between [1] and [0 1] depending on the amount of compatibility effort. Anyone trusting that a shared apr_find.m4 installed in aclocal.m4 does the 'right thing' needs the reassurance that svn, apache etc will pick apr 0. Bill
Re: setjmp/longjmp vs try/throw/catch
At 06:54 PM 7/19/2004, Nick Kew wrote: I have a couple of modules using third-party libraries that require me to supply an abort function (or they'll abort by exiting). For example, libjpeg in my mod_jpeg. My preferred approach to this situation is usually to resort to C++, put my code in a try/catch loop, and provide an abort handler that throws an exception. However, this doesn't play well with Apache, and when I run it in gdb, the throw appears to generate an Abort. Switching to setjmp/longjmp does appear to work well with apache and gcc. But that leaves me wondering if I need to worry about thread-safety. Is using setjmp/longjmp with Worker or Windoze MPM asking for trouble? And if so, is there an alternative approach I could try? IIRC - all setjmp and other usually-thread-agnostic calls in a normal clib were redesigned to use TLS in the Win32 msvcrt lib, long before most Unixes considered implementing threads :) I believe on win32 you will be fine, I'd be more worried about the thread implementations. This sure sounds like an abstraction we should assist with using apr. Bill
Re: apr pool realloc?
At 04:06 AM 7/24/2004, Nick Kew wrote: Is there some fundamental reason why there's no apr_prealloc()? [...] I can't help thinking this should be (a) standardised. (b) optimised to work with pools. I've thought that for some time, with the understanding that you can't be playing in the pool you are reallocing. See the apr_psprintf() vformatter function for apr's internal implementation, and I'll offer a huge +1 if you care to abstract that behavior :) Bill
Re: broken pipe (was:Re: 1.0.0.rc2 tarballs now ready...)
If you toggle the APR_FILES_AS_SOCKETS constant back to 0 (zero)does this remedy the behavior you are seeing? Bill At 05:41 PM 6/30/2004, Jean-Jacques Clar wrote: I am getting the following error when running CGIs on the current version of NetWare (6.5 sp2): (32)Broken pipe: ap_content_length_filter: apr_bucket_read() failed I am working on tracking down the problem. Changes done to mod_cgi.c, mod_include.(h c) back in August 22, 2003 are exposing a broken pipe problem on NetWare. mod_cgi.c had a great deal of change in r1.153. I am not sure what exactly is causing that problem. It is surfacing only now because of recent changes in the pipe code of our own library. At this point I am highly suspicious that the problem is in our library, but it could also be in the http/apr code. We are trying to isolate the problem and will update the list with any new info. JJ
Re: 1.0.0 RC5
At 08:18 AM 7/30/2004, David Reid wrote: However, we need to remove the APR_STATUS_IS_SUCCESS macro before 1.0 goes out, because otherwise we are stuck with it for a very long time. There were win32 comments from Brane? Is someone going to commit the changes needed? What changes? Note in apr_errno : #define APR_FROM_OS_ERROR(e) (e == 0 ? APR_SUCCESS : e + APR_OS_START_SYSERR) #define APR_TO_OS_ERROR(e) (e == 0 ? APR_SUCCESS : e - APR_OS_START_SYSERR) #define apr_get_os_error() (APR_FROM_OS_ERROR(GetLastError())) #define apr_set_os_error(e) (SetLastError(APR_TO_OS_ERROR(e))) #define apr_get_netos_error() (APR_FROM_OS_ERROR(WSAGetLastError())) #define apr_set_netos_error(e) (WSASetLastError(APR_TO_OS_ERROR(e))) so as you see we already fold 0 : 0 but ... oh my what''s this in the OS2 section??? // XXX deprecated #define APR_STATUS_IS_ETIMEDOUT(s) ((s) == APR_ETIMEDOUT \ || (s) == APR_OS_START_SYSERR + SOCETIMEDOUT) Bad comment form and a left-over deprecation? I'm out of week, but someone please squish that :-/ Bill
Re: apr win32 bug [PATCH]
Although I agree, with your patch in spirit, if apr_thread_join is never called, your patch -can- leak handles like a sieve :( Did we ever define that apr_thread_create() must be partnered with an apr_thread_join? If not, it seems we need a clever way to mark the apr_thread_t HANDLE member as destroyed, and allow the apr_thread_join to simply return immediately. Bill At 04:52 PM 7/31/2004, Max Khon wrote: Hi! apr_thread_join for win32 is implemented incorrectly: thread handle is destroyed too early (in apr_thread_exit). If apr_thread_exit() is called before apr_thread_join() and new object is created (thread handle is reused) before calling apr_thread_join(), apr_thread_join() will possibly wait on invalid handle. Patch is attached. /fjoe
Re: apr-util/ldap/ - sink or really swim to 1.0 release?
At 12:26 PM 7/30/2004, Graham Leggett wrote: William A. Rowe, Jr. wrote: 4. our APR_HAS_XXX_LDAPSDK macros are entirely bogus, still, on unix. Explain? (so I can fix). Here's my philosophy. First, we don't set up the HAS_BAR_LDAPSDK 0 values after setting the HAS_FOO_LDAPSDK 1 value. So this is a bug. But everything that we do relative to 'which toolkit is this?' should be behind the apu_private.h section, can use the classic HAVE_FOO_LDAP style macros, and shouldn't be shared. If we are describing ldap in terms of 'which toolkit?' then we didn't go to enough effort in apr-util/ldap to make this even worthwhile. My 2c. 5. we *bogusly* define ldap_memfree and ldap_search_ext_s in the *ldap*'s namespace. This is absolutely incorrect, and will immediately cause any ldap-based code to fail once the ldap library is upgraded (symbolic duplicates.) I plan to change all the apr defined ldap functions to be apr_ldap - will this fix this? Ack :) But I would ask, please, wrap behind functions not macros. In that way, changing the aprutil-1.so file can immediately result in using an alternate ldap provider. Thanks for getting excited about this - 'finishing' ldap apr support is good. I simply asked because releasing the 'old ldap' support as 1.0 would have dug us a deep hole, it would have been easier to release, sans ldap, then reintroduce in 1.1. But since you have the energy and motivation to just get it right - kudos and my thanks. Bill
Re: 1.0.0 RC5
At 12:11 PM 8/1/2004, Graham Leggett wrote: David Reid wrote: So I see. I'll tag roll APR RC5 later on tonight and hopefully as soon as apr-util is patched for apr-config I'll be able to roll. Would it be possible to include the recent LDAP changes in v1.0.0? They fix some LDAP fooness that shouldn't get out the door if at all possible. I would be +1 to simply remove auth_ldap from APR 1.0, and reintroduce the entire feature in the new APR 1.1 (which we can start development on immediately.) And that presumes httpd 2.1/2.2 will depend on the 1.1 release of apr-util. I hate to hold up 1.0 any further. I would hate to release apr-util as-in even more. Thoughts or comments about my solution above? Bill
Re: 1.0.0 RC5
At 04:04 PM 8/2/2004, Graham Leggett wrote: David Reid wrote: The main fooness is in apr_ldap_url.c. Can we not mark this code as deprecated in v1.0, which should hopefully warn alert coders that the code should not be used, and can be pointed out to coders who are asleep otherwise if they moan. How much work is needed to fix it? What exactly is broken about it? It needs an overhaul as it does some wrong things. Fixing it can wait till APR v1.1. In the meantime we can mark what's there as deprecated so as to not cause confusion. If they need the broken implementation, they can keep using 0.9 - in the meantime let's design the right interface by 1.1 and completely REMOVE, not 'deprecate' the existing flavor. Deprecation isn't getting rid of a feature until the next release. This IS the next release, so just branch 1.1-dev, and remove the ldap files on the 1.0 branch, knock out the config.m4 magic, and we have a valid 1.0 release. Let's take the course of least action shall we? Is this release creating a record for being the longest in history? I'm away for most of the rest of the week. I had hoped to have RC5 rolled today, but guess that isn't going to happen now. *sigh* I have added a note that the two offending LDAP source files (apr_ldap_compat and apr_ldap_url) are deprecated subject to an overhaul. Quick - roll RC5! I'll vote -1 on this sheist - however that's just a vote. Shall see if anyone else is this disgusted. David, if we are at 1.0, shall we branch 1.1 right now and I'll do the dirty deed myself tomorrow night at the hotel? Bill
Re: 1.0.0 RC5
At 12:53 PM 8/2/2004, David Reid wrote: Graham Leggett wrote: William A. Rowe, Jr. wrote: I would be +1 to simply remove auth_ldap from APR 1.0, and reintroduce the entire feature in the new APR 1.1 (which we can start development on immediately.) And that presumes httpd 2.1/2.2 will depend on the 1.1 release of apr-util. I hate to hold up 1.0 any further. I would hate to release apr-util as-in even more. Thoughts or comments about my solution above? Why (I feel I have to ask) is this ONLY just coming to light now? Well, it isn't. Several APR contributors have griped that apr-util would become nothing more than a garbage pit of hacks-upon-hacks around broken/inconsistent APIs. My only ldap hacks to date were on win32. Now I'm deeply immersed in config and build issues for many more unix platforms, and was hacking in Sun LDAP SDK support. It's when I discovered apr-util's implementation of ldap was valueless for writing portable code. If our code doesn't facilitate portable code, it doesn't belong in APR. So I threw it to the list, drop the existing implementation? I'm NOT suggesting we put it back in before APR 1.0 release. How much work is needed to fix it? What exactly is broken about it? Right now it does little. Graham and I agree on the right solution, to abstract out the logic to do SSL connections in a portable way. There will be no need for the 'application developer' to know which toolkit they are using. We will make that transparent. Ripping it out is a whole lot of work best avoided IMHO. Let's take the course of least action shall we? Least action is fork 1.1, cvs rm the offensive files, and change about 10 lines of the makefiles and rip out the ldap detection. Pretty trivial. Deprecating means we support this junk till 2.0 releases. Bill
Re: 1.0.0 RC5
At 06:08 AM 8/3/2004, Graham Leggett wrote: William A. Rowe, Jr. wrote: Right now it does little. Graham and I agree on the right solution, to abstract out the logic to do SSL connections in a portable way. There will be no need for the 'application developer' to know which toolkit they are using. We will make that transparent. This has already been done, and is already checked into apr_util. Very cool! I am traveling non-stop so haven't dug into the code, and probably can't till Tuesday. That 40% of the 80%... Least action is fork 1.1, cvs rm the offensive files, and change about 10 lines of the makefiles and rip out the ldap detection. Pretty trivial. That's overkill. The two most important bits of the LDAP support are ./configure magic to find the right toolkit, and the newly overhauled apr_ldap_init.c, which replaces the LDAP SDK's inconsistent ldap_init() function. These should work fine. No - the most important bit is to start hiding the details in apu_private.h and quit publicizing the sdk versions, define mapping wrappers, etc. Once everything that aprutil-1 elects to do is hidden inside aprutil-1.so, and the interface is always the same (no matter which linkage), then we have 1. defined binary compatibility, and 2. stuck to it :) Deprecating means we support this junk till 2.0 releases. Then cvs rm apr_ldap_url.c, which seems to be the main issue. We can fix it and put it back in the next release. Actually, isn't that the most trivial to fix? #if HAVE_ldap_parse_url return ldap_parse_url(...); #else [all the code] #endif What issues are there with apr_ldap_compat.c? This code is very short, and any issues are probably easily fixed. iirc this is a bunch of macros. Any code linked against one flavor of aprutil-1.so can't be expected to load under another. This is problematic, no? Bill
Re: 1.0
malc, is there anything that can be done in our apr/test/ tree to validate the correct behavior, and tickle these bugs? This would obviously help validate the patches you propose, and possibly pick up such bugs in other condition variable implementations. The emphasis for 1.0.0 is API-complete. It won't mean zarro boogs. It will mean that as folks develop for APR 1.0 - the api won't shift beneath their feet from subversion to subversion, and it will remain backwards compatible from minor to minor version. In fact, for users who build APR-based apps, things will only get better (till 2.0 really improves things by a leap - but also will require the developers to make adjustments for the API - all at once.) I hope to find cycles this week to review the patches (don't let that stop anyone else of course.) A test case would obviously help, alot. Bill At 11:57 AM 8/9/2004, malc wrote: Hi, Perhaps im way off on this and please do correct me if i am wrong. Condition variables on Win32 are broken, if you are going to label APR with 1.0 mark and release it right now, without mentioning this fact in big red letters, this would essentially be equal to releasing a trojan horse - a free, attractive, portable thing with a stamp of greatness (Apache) in its name, but deadly. Not only code responsible for condvars under Win32 lacks any error checking whatsoever, there are also races, stuff which (to the best of my knowlege) results in upredictable behavior, so people using it will be bitten.. hard. -- mailto:[EMAIL PROTECTED]
Re: Win32 critsec
At 02:49 PM 8/12/2004, James Mansion wrote: I'd like to offer a replacement for the broken critsec code. Who can I send it to for review? I've never contributed before, have filled no paperwork etc. I work through a contractor umbrella company and I'm at home rather than at a client site, so I don't think theer will be a problem getting paperwork - just a delay since I'm not a director etc. Feel free to post your patches to the list, and/or attach them to the appropriate bug report with the PatchAvailable keyword. Both is probably the surest way that they are considered. We prefer diff -u3 style patches, following the style guide http://www.apache.org/dev/styleguide.html If this is a trivial bugfix, we don't require a CLA. If you are providing an entirely new implementation, or submitting brand new code, we would ask you to submit a Contributors License Agreement, and if you don't have full authority to speak for what you do on your companies' time, also file the Corp CLA... http://www.apache.org/licenses/#clas Instructions for faxing or mailing these documents is embedded in the agreements themselves. Please remember, the more focused and single purpose each patch you offer is, the easier it is for the reviewers to grok and approve/commit. Looking forward to your contributions! Bill
Re: [PATCH] WIN32 - fix apr_thread_join (PR: 28460) - v.2
At 02:24 PM 8/27/2004, Mladen Turk wrote: Cliff Woolley wrote: On Fri, 27 Aug 2004, Mladen Turk wrote: c) If thread_exit was never called before thread_join do not set the retval but rather return APR_INCOMPLETE. That's really what the unix impl does? Probably not :) Didn't test what happens if you call the thread_join without ever calling thread_exit. APR_INCOMPLETE was supposed to mean that partial results were returned but just not quite everything the caller asked for (as in the case of stat()ing a file but only getting back some of the information the user wanted rather than all). Surely this is an error condition, right? In that case, one of the APR_E* codes would be more appropriate. Or maybe I'm not correctly understanding the situation you're describing... APR_INCOMLETE says : The operation was incomplete although some processing was performed and the results are partially valid This rv can only happen if the code has been wrongly written, meaning that the user didn't call the thread_exit inside the thread func, but sill wishes to retrieve the thread exit value using thread_join. Because the thread handle is closed the operation is incomplete, meaning: OK, I can close the thread, but can not give you the thread's return value, cause you never set that. Anyhow, any error value will do as long as it makes sense :) It doesn't because you didn't get a partial-results, you got no results (it wasn't done.) I like the idea of researching what Unix reports and matching it. Bill
Re: WIN32: save MSVC files with CR+LF?
At 03:02 PM 8/28/2004, Cliff Woolley wrote: Normally Bill Rowe will come along behind and build a .zip of the distribution that was checked out using a Win32 version of CVS so that *all* of the files have DOS line endings. The .tar.gz and .tar.Z distributions always have unix line endings. Actually, apr/build/lineends.pl will do that nicely for anyone who has perl installed, even from the .tar.gz's :) To Klaus's comments; On Sat, 28 Aug 2004, Klaus Keppler wrote: Suggestion: the following MSVC files should be saved with CR+LF (if that's possible?), so you can open them out-of-the-box with Visual C++ 6.0. Actually you always have to convert these files right after unpacking the archive file. The .dsp / .dsw / .mak files you mention are only a handful of the TEXT FILES we distribute with the package. Unix filesystems have \n lineends. Win32 has \r\n endings. Anyone who wants to contend with a mishmash has my blessing on their system but not in our repository! Why do I shake violently at fools who commit such files as binary \r\n line endings? My reasons are really trivial, and result in massive wastes of time for me. I maintain dozens of patches across platforms which, checked out under unix, neatly patch the unix text files. These same patches also neatly apply when checked out with dos line endings, to dos files on windows. Now - if you work with native files on unix, and then attempt to cvs diff this garbage, you end up with 100% deltas of the files. The bigest offenders are tomcat and php, I frequently have two-line patches to the .dsp files to change library/include paths to my locally employed path envvars. There is no way for me to maintain such patches for both platforms without extra passes through lineends.pl, and then rerunning the files several times to get the cvs diff out of the picture. On top of this mess, I've frequently seen TEXT files in cvs with \r\n endings on unix, which check out under windows cvs as \r\r\n. E. If you are win32'er using cvs, why on earth would you use a port of cvs-like utilities which check out text as \n? If you are a cygwin'er, you use \n text exclusively, you aren't using silly MS tools to ever handle those files (right?) As far as tarballs, httpd and apr toss up a corresponding .zip files in the process, identical to the unix .tar.gz, with the exceptions 1) unix line endings, 2) win32 visual studio 5.0 makefiles (because that version couldn't do command line builds from .dsp files), and 3) some files generated from awk/sed/bison that the user might not be able to generate without extra utilities. If that's not possible, a small notice in the docs would certainly help other people ;-) Seeing as we offer the tool for the job (apr/build/lineends.pl) that sounds like a wonderful idea! Working on a compiling_win32.html fix right now. Bill
Re: WIN32: save MSVC files with CR+LF?
At 08:31 PM 8/28/2004, William A. Rowe, Jr. wrote: On Sat, 28 Aug 2004, Klaus Keppler wrote: If that's not possible, a small notice in the docs would certainly help other people ;-) Seeing as we offer the tool for the job (apr/build/lineends.pl) that sounds like a wonderful idea! Working on a compiling_win32.html fix right now. Updated http://apr.apache.org/compiling_win32.html please tell me what you think. Bill
Re: [Fwd: Re: Making pool 3 times faster on WIN32]
At 01:32 PM 9/1/2004, Mladen Turk wrote: Bill Stoddard wrote: Not sure what's the total httpd's time spent for palloc, but I suppose it's quite a large value. I saw no significant difference serving a 500 byte file: Keep in mind that the whole idea behind APR pools is to minimize calls to the native memory allocators (malloc/heap). If your benchmark recycled the pool each time you did an allocation, the 3x difference is not suprising, but that is a somewhat artifical benchmark imho. Yes, it seems that the number of times the allocator is actually calling malloc/free is low compared to the palloc calls. Yes - httpd tends to perform a rather small number of malloc/free operations - well, if you aren't using some add-in modules such as svn which have more atomic memory units to free up. Sorry for the noise :) I don't consider it noise. Please don't dismiss this patch soely on the basis that it offers small benefit to httpd. There are other applications that rely on APR, I'd love to see the concept of this patch incorporated. I'll spend cycles on it myself after I finish reviewing the rather large list of patches you recently submitted :) Bill
OT: Loopback bug in WinXP-SP2
Just thought this might bite some apr dev'ers - The initial SP2 release will not loopback on any port except 127.0.0.1, so if you use .2, .3 etc in more sophisticated testing, these will bomb under SP2. They know it, there is a generally unavailable fix for this condition. Bill
Re: renaming apr_file_permissions defines
At 07:53 PM 9/17/2004, you wrote: and the rename of apr_file_permissions group: s/APR_/APR_FILEPROT_/ Veto - defer for 2.0
Re: renaming apr_filetype enum entries
At 09:05 PM 9/17/2004, William A. Rowe, Jr. wrote: At 06:54 PM 9/17/2004, you wrote: So any objecttions to the s/APR_/APR_FILETYPE_/ rename? Veto - defer for 2.0 I don't object to the new names, but find it pretty absurd to start deprecating interfaces the month we roll out 1.0. Bill
Re: renaming apr_file_open_flags group defines
At 08:34 PM 9/17/2004, you wrote: This group wasn't discussed before, but it suffers from the same problem. #define APR_READ 0x1 /** Open the file for reading */ #define APR_WRITE 0x2 /** Open the file for writing */ #define APR_CREATE 0x4 /** Create the file if not there */ Not sure what's the best prefix here. Is APR_OPEN_ good? APR_OPEN_READ, APR_OPEN_WRITE, ... Veto - defer for 2.0 About this group - smakes sense to me unless these flags are 'generic', e.g. apply-to other. And no, APR_OPEN_ isn't ideal, but APR_FILE_OPEN_ would be.
Re: renaming apr_filetype enum entries
At 10:03 PM 9/17/2004, Max Bowsher wrote: Stas Bekman wrote: William A. Rowe, Jr. wrote: I don't object to the new names, but find it pretty absurd to start deprecating interfaces the month we roll out 1.0. You mean, I've missed the train? Well, we are about to freeze the mod_perl 2 API, and we would like to have non-ambiguous constants. So I'm not sure how to proceed from here. If you release mod_perl with those identifiers, you will be bound to APR 1.1 - and httpd 2.1-dev is keyed to APR 1.0 at this time. You must use APR 1.0 constants to be compatible with 2.2 when it's released unless httpd adopts an APR 1.1. Remember, new features get a minor version bump from now on, not just another subversion bump. See: http://apr.apache.org/versioning.html Well, the APR_ namespace is non-ambiguously APR's, and APR itself can ensure sanity within that namespace - what more is required? Legibility is important too, so I've agreed with Stas, in principal, with his renaming suggestions. Unfortuantely, I didn't see enough other people comment about them to adopt any of the proposed changes, for or against :( Personally, I think it's good that APR's constant names aren't needlessly bloated in length. It's nice to have shorthand, and amusing that most Java developers consider the terminal width to be 96 characters these days :) I wouldn't consider the longhand needlessly bloated, however. Bill
Re: renaming apr_file_permissions defines
At 09:15 AM 9/19/2004, Greg Stein wrote: On Fri, Sep 17, 2004 at 09:21:17PM -0500, William A. Rowe, Jr. wrote: At 07:53 PM 9/17/2004, you wrote: and the rename of apr_file_permissions group: s/APR_/APR_FILEPROT_/ Veto - defer for 2.0 There is no reason to wait until 2.0. The versioning guidelines allow us to provide new symbolic names in 1.x versions. As long as APR_REG and friends exist in all 1.x versions, then everything is fine. If 1.1 happens to include a new APR_FILETYPE_REG, then there isn't a problem. This is correct, yes. We need to first branch APR_1_0 development so such patches can be applied to cvs HEAD. IOW, I'd encourage you to reconsider your veto. I don't see the problem that you're trying to prevent. I'm retracting the vetos on these three renames, provided we apply them to APR_1_1, but I'm not 100% comfortable that our own devs want such wordy names. Is it wrong to have both shorthand and the strongly-typed equivalents? In any case, it would not be a good idea to rename these based on minority opinion. I'm +1 for less ambiguous names myself. Bill
Re: Some pending pathches for review/commit
At 10:47 AM 9/19/2004, Mladen Turk wrote:
Trying for a third week :).
Keep trying :) Several project releases distracted a number
of users of this list...
so I'm sending them all at once with brief explanation for each.
Actually, it inhibits discussion to do that :( I would like
to see Ben Laurie feedback to 2. and 5. since he understand
these better than most, and they implicate some unspoken
assumptions that he should review. Ben?
For your 1. and 3. and 4. they are fine, simply commit them,
+1 to fix in both head and APR_0_9.
2. apr_random.patch
Set the hash tables to zero on init.
Although the test are passing now, some deep explanation
would be fine (probably from Ben Laurie).
I presume that the unix is setting the
memory to zero while on WIN32 it is set to 0xCD, and that's
why the expected test values are never met on WIN32.
5. sha2.patch
Just fixes the compile time warnings caused by assigning 64
bit values to 32 bit integers, by casting them to unsigned int.
Index: apr_random.c
===
RCS file: /home/cvspublic/apr/random/unix/apr_random.c,v
retrieving revision 1.9
diff -u -r1.9 apr_random.c
--- apr_random.c28 Feb 2004 18:31:41 -1.9
+++ apr_random.c28 Aug 2004 14:35:06 -
@@ -111,8 +111,8 @@
/2)*g-pool_hash-size*2;
g-reseed_size = APR_RANDOM_DEFAULT_RESEED_SIZE;
-g-H = apr_palloc(p,H_size(g));
-g-H_waiting = apr_palloc(p,H_size(g));
+g-H = apr_pcalloc(p,H_size(g));
+g-H_waiting = apr_pcalloc(p,H_size(g));
g-randomness = apr_palloc(p,B_size(g));
g-random_bytes = 0;
Index: sha2.c
===
RCS file: /home/cvspublic/apr/random/unix/sha2.c,v
retrieving revision 1.6
diff -u -r1.6 sha2.c
--- sha2.c28 Feb 2004 18:31:41 -1.6
+++ sha2.c27 Aug 2004 09:04:43 -
@@ -458,7 +458,7 @@
/* Sanity check: */
assert(context != (SHA256_CTX*)0 data != (sha2_byte*)0);
-usedspace = (context-bitcount 3) % SHA256_BLOCK_LENGTH;
+usedspace = (unsigned int)((context-bitcount 3) %
SHA256_BLOCK_LENGTH);
if (usedspace 0) {
/* Calculate how much free space is available in the buffer */
freespace = SHA256_BLOCK_LENGTH - usedspace;
@@ -504,7 +504,7 @@
/* If no digest buffer is passed, we don't bother doing this: */
if (digest != (sha2_byte*)0) {
-usedspace = (context-bitcount 3) % SHA256_BLOCK_LENGTH;
+usedspace = (unsigned int)((context-bitcount 3) %
SHA256_BLOCK_LENGTH);
#if !APR_IS_BIGENDIAN
/* Convert FROM host byte order */
REVERSE64(context-bitcount,context-bitcount);
@@ -780,7 +780,7 @@
/* Sanity check: */
assert(context != (SHA512_CTX*)0 data != (sha2_byte*)0);
-usedspace = (context-bitcount[0] 3) % SHA512_BLOCK_LENGTH;
+usedspace = (unsigned int)((context-bitcount[0] 3) %
SHA512_BLOCK_LENGTH);
if (usedspace 0) {
/* Calculate how much free space is available in the buffer */
freespace = SHA512_BLOCK_LENGTH - usedspace;
@@ -820,7 +820,7 @@
void SHA512_Last(SHA512_CTX* context) {
unsigned intusedspace;
-usedspace = (context-bitcount[0] 3) % SHA512_BLOCK_LENGTH;
+usedspace = (unsigned int)((context-bitcount[0] 3) %
SHA512_BLOCK_LENGTH);
#if !APR_IS_BIGENDIAN
/* Convert FROM host byte order */
REVERSE64(context-bitcount[0],context-bitcount[0]);
Re: renaming apr_filetype enum entries
At 04:20 PM 9/19/2004, Stas Bekman wrote: So if that's fine with everybody and now Bill has pulled down his veto, the only thing to wait for is the APR_1_1 branch to appear? Any plans for that? APR_1_0 should be created soon, before new progress. HEAD should be 1_1 till we release it.
Re: Bug in unix apr_stat involving the name field.
At 11:53 AM 9/20/2004, you wrote: The following works on win32 but not on linux. Looks like the name field of apr_file_t is never set on unix so the value is garbage. are you testing the .valid bit APR_FINFO_FNAME value? There are scenarios on every platform when specific fields cannot be set, it's important to check the .valid bits. If apr_stat(, APR_FINFO_NAME, poll) returns APR_SUCCESS, that would be a bug, the correct return code is APR_INCOMPLETE. It would be -totally- wrong to just stuff the name passed for Unix, because some Unix file systems, e.g. mounted from Samba, HFS (Mac OS), and others can return another file from a non-canonical name. Bill
Re: cvs commit: apr/network_io/win32 sendrecv.c
At 01:21 PM 9/22/2004, [EMAIL PROTECTED] wrote:
--- ap_regkey.c 9 Feb 2004 20:40:49 - 1.11
+++ ap_regkey.c 22 Sep 2004 18:21:29 - 1.12
@@ -185,7 +185,7 @@
*/
LONG rc;
DWORD type;
-DWORD size = 0;
+apr_size_t size = 0;
#if APR_HAS_UNICODE_FS
IF_WIN_OS_IS_UNICODE
@@ -201,7 +201,7 @@
else if (valuelen)
return APR_ENAMETOOLONG;
/* Read to NULL buffer to determine value size */
-rc = RegQueryValueExW(key-hkey, wvalname, 0, type, NULL, size);
+rc = RegQueryValueExW(key-hkey, wvalname, 0, type, NULL, (DWORD
*)size);
Allen!!! This is insidiously evil!!! This change makes assumptions
of the endianness will bite us some day!
Please don't use casts :( Certainly, never recast pointer types
in this manner. Can you explain your choice of type below, I'm
not grokking it... (perhaps we mean ULONG_PTR instead?)
--- readwrite.c 13 Feb 2004 09:38:27 - 1.80
+++ readwrite.c 22 Sep 2004 18:21:30 - 1.81
@@ -68,7 +69,8 @@
file-pOverlapped-OffsetHigh = (DWORD)(file-filePtr 32);
}
-rv = ReadFile(file-filehand, buf, len, nbytes, file-pOverlapped);
+*nbytes = 0;
+rv = ReadFile(file-filehand, buf, len, (LPDWORD)nbytes,
file-pOverlapped);
if (!rv) {
rv = apr_get_os_error();
@@ -85,7 +87,7 @@
switch (rv) {
case WAIT_OBJECT_0:
GetOverlappedResult(file-filehand, file-pOverlapped,
-nbytes, TRUE);
+(LPDWORD)nbytes, TRUE);
rv = APR_SUCCESS;
break;
case WAIT_TIMEOUT:
@@ -309,7 +311,7 @@
rv = WaitForSingleObject(thefile-pOverlapped-hEvent,
INFINITE);
switch (rv) {
case WAIT_OBJECT_0:
-GetOverlappedResult(thefile-filehand,
thefile-pOverlapped, nbytes, TRUE);
+GetOverlappedResult(thefile-filehand,
thefile-pOverlapped, (LPDWORD)nbytes, TRUE);
rv = APR_SUCCESS;
break;
case WAIT_TIMEOUT:
Otherwise nice work :)
I wish you would have broken out the xmitfile bit, it was a pretty
comprehensive change in and of itself.
Bill
Re: cvs commit: apr/include apr.hnw
At 11:33 AM 9/24/2004, [EMAIL PROTECTED] wrote: clar2004/09/24 09:33:03 added define for DWORD_MAX Could we -please- use an APR decorated name? Bill
RE: Static Linked on Linux and Win32
At 11:06 PM 9/27/2004, David Barrett wrote: Ok, with Dror's and William's help I'm up and running with APR. Now, what about static linking with APRICONV? Starting with Dror's HelloWorld DSW (which compiles, links, and runs fine with just APR), I added the lines: # #include apr_iconv.h # ... # apr_iconv_open( 0, 0, 0, 0 ); apr_iconv is a private interface. It will soon be gone. Stick with the apr_xlate interface. Bill
Re: Hello :-)
At 01:14 PM 9/28/2004, you wrote: Hi Guys, We're starting a new open source project, and are looking into using APR for our portable framework. Wonderful! Once you have a beta release, we would love to include you in the list of APR-based projects! We started with the Win32 side first, and found out that the DSP and DSW had to be converted to CRLF since Visual Studio 6.0 could not recognize those files properly. Simple enough - use apr/build/lineends.pl Posting -win32-src.zip flavors, including exporting makefiles, has been on my list of round tuits, thanks for the nudge :) We're wondering if there's a nice reference project we can take a look at, that compiles well on Win32 and Linux. First and foremost is httpd server. Version 2.1 (available from http://httpd.apache.org/dev/dist/) is the version that builds against APR 1.0, just drop apr and apr-util under it's srclib/ tree. For Win32, also drop apr-iconv in there. Another issue that arose was the dependency of the code on LDAP. To get it to compile, we had to download Novel's ldap implementation + libraries/headers. Is there a way to get around this? This is already noted as an issue with 1.0 - for 0.9 it shouldn't adversely affect you. But we hope you stick with release 1.0 and look forward to our 1.0.1 release which should allow you to configure apr without ldap on unix. On win32, ldap is always available to APR. Bill
Re: Hello :-)
At 02:49 PM 9/28/2004, [EMAIL PROTECTED] wrote: First and foremost is httpd server. Version 2.1 (available from http://httpd.apache.org/dev/dist/) is the version that builds against APR 1.0, just drop apr and apr-util under it's srclib/ tree. For Win32, also drop apr-iconv in there. What's the role of the apr-iconv package? What do I do when I want to compile my application under Un*x? Does it have defines that will simply not include the apr-iconv source? Ideally I would like to have a shared source tree for all platforms. Win32 does not have the iconv library. We are considering moving to the BSD distribution of iconv with Win32 specific patches, rather than attempting to maintain a win32 flavor. For that reason, apr-iconv should not be considered a permanent fixture. This is already noted as an issue with 1.0 - for 0.9 it shouldn't adversely affect you. But we hope you stick with release 1.0 and look forward to our 1.0.1 release which should allow you to configure apr without ldap on unix. On win32, ldap is always available to APR. Why do I need LDAP to begin with? And why in a portable runtime? Don't use apr-util if you don't want such features. apr-util are utility accessors to help provide for portable ldap, xlate and other system library features. If it doesn't relate to another library, you will find it in apr. If it relates to external libraries, e.g. database, ldap, iconv, etc, you will find it in apr-util. Because those libraries have small discrepancies, but the authors needed a modestly portable interface to basic database, conversion and authentication features, the apr-util project was born. Another issue we discovered today is a conflict of APR with STL. Is this a known issue? When STL is added into the project, we get the following error: error C2955: 'allocator' : use of class template requires template argument list If you search the archives, I recall something about that. Feel free to offer a patch of course. Bill
Re: Hello :-)
At 03:30 PM 9/28/2004, William A. Rowe, Jr. wrote: Win32 does not have the iconv library. We are considering moving to the BSD distribution of iconv with Win32 specific patches, rather than attempting to maintain a win32 flavor. For that reason, apr-iconv should not be considered a permanent fixture. I should have been more specific. YES win32 has a codepage translation facility. That native library will not convert partial-content (e.g., when the destination string overflows, it will not report the partial conversion results.) There is a COM based component which will perform partial content translation - but the overhead of writing this as a COM consumer was less than appealing. Bill
Re: cvs commit: apr/network_io/win32 sendrecv.c
At 05:50 PM 9/28/2004, Jeff Trawick wrote: -#define DWORD_MAX 4294967295 +#define APR_DWORD_MAX 4294967295 or #define APR_DWORD_MAX (DWORD_MAX) since this is a platform which defines it? or... #ifdef DWORD_MAX #define APR_DWORD_MAX DWORD_MAX #else #define DWORD_MAX 4294967295UL #endif it seems we forgot to correctly sign this constant
Re: [PATCH] WIN64: apr_pools.c
At 11:48 AM 9/30/2004, Joe Orton wrote: On Thu, Sep 30, 2004 at 11:22:41AM -0400, Allan Edwards wrote: so I don't see how it could be made private either. This patch demonstates that it can be made private, Only if you redefine private :) This is all pedantic, because you can't make this interface private until APR 2.0. The only fix we could possibly adopt before then, outside of -validating- and restricting these to 32 bit quantities on those platforms with mismatches, is to -retract- the release of APR 1.0 on all platforms with 32bit int/64bit pointers. Thoughts? Bill
Re: cvs commit: apr/network_io/win32 sendrecv.c
At 12:21 PM 10/1/2004, Greg Marr wrote: #ifdef DWORD_MAX #define APR_DWORD_MAX DWORD_MAX #else #define APR_DWORD_MAX 0xUL #endif Defining DWORD_MAX at all could cause problems if it was defined by a later header file. ++1, this is the right solution, and infinitely more legible.
Re: [PATCH] apr_file_writev() on UNIX
At 11:12 AM 10/6/2004, you wrote: As far as not having a bug in the !HAS_WRITEV implementation, I disagree. The current implementation does not have a single chance of being successful if there is more than 1 vector. This does not make sense to me. Let assume the write part is successful, the function will return apr_success but has completely failed to his task. That's only partially true - we should never return for a blocking socket writev, only for a nonblocking one when the socket would block on the remaining vector(s). In the header file there is a remark saying that apr_file_writev is available even if the underlying os doesn't provide writev(). Why providing something that it is going to fail every single time? Does writev() return *success* on a partial-write? I very much doubt it (EINTR, EWOULDBLOCK or EAGAIN is what I would expect.) The performance of the existing code is obviously sub-par, and we should loop through all the vectors until we get a hiccup. At that point the user can retry the remaining vectors. I should make a point that it seems 'wrong' we implemented this lie - there is another property of writev() that we've ignored... writev() will gather up the vectors into a single datagram, even when nagle is off. So this implementation leaves us potentially sending dozens of datagrams for a few dozen very small buffers. It seems a true implementation would use it's own buffer to concat all of the smaller fragments into a single packet - the pain in cpu is nominal compared to the pain of multiple datagram processing. Bill
Re: APR 1.0.0 and CYGWIN
Daniel, we really shouldn't be building unix/ on cygwin. In spite of the built-in support, it simply hasn't been vetted and is bound to have vulnerabilities if used for Apache 2.0. Ideally we should modify the configure.in for cygwin to determine win32/ as the build sources, and toggle -DWIN32. There are probably other side effects, but I'd be happy to help you work through them if you would like to help us put together a patch. In many cases (see the file lists in the .dsp win32 build files) we zig-zag between win32/ and unix/ in the same tree, and need to see how to do so effectively for cygwin. If we do this right, the same sources should build on both cygwin and mingw. Bill At 02:17 PM 10/14/2004, Daniel May wrote: I was unable to build ARP-1.0.0 on CYGWIN. I get the following error: $ make make[1]: Entering directory `/cygdrive/y/spryware/apr/apr-1.0.0' /bin/bash /cygdrive/y/spryware/apr/apr-1.0.0/libtool --silent --mode=compile gcc -g -O2 -DHAVE_CON FIG_H -DCYGWIN -I./include -I/cygdrive/y/spryware/apr/apr-1.0.0/include/arch/unix -I./include/arch /unix -I/cygdrive/y/spryware/apr/apr-1.0.0/include -o network_io/unix/sockopt.lo -c network_io/unix /sockopt.c touch network_io/unix/sockopt.lo network_io/unix/sockopt.c: In function `apr_socket_opt_set': network_io/unix/sockopt.c:135: error: `ttllevel' undeclared (first use in this function) network_io/unix/sockopt.c:135: error: (Each undeclared identifier is reported only once network_io/unix/sockopt.c:135: error: for each function it appears in.) network_io/unix/sockopt.c:136: error: `ttl' undeclared (first use in this function) make[1]: *** [network_io/unix/sockopt.lo] Error 1 make[1]: Leaving directory `/cygdrive/y/spryware/apr/apr-1.0.0' make: *** [all-recursive] Error 1 Daniel May
Re: APR 1.0.0 and CYGWIN
At 04:47 PM 10/14/2004, Max Bowsher wrote: Cygwin is supposed to be unix-like. Packages shouldn't need to start applying win32 specific tricks, and when they do, it often compromizes the unix-like feel that is a major feature of Cygwin. If cygwin used the unambiguous POSIX file flags and had close to 100% compatibility with a unix filesystem (no pathname ambiguity, case sensitive file names, valid filename characters of \ : etc) then there would be little concern for security, and it would be very rational to go with the unix flavor port.
Re: APR 1.0.0 and CYGWIN
I should have added that the pseudo-fork and condition vars on cygwin would actually be better preserved by using the unix port. In fact, if the cygwin build simply used the win32 apr_file_io code I'd be quite happy with it relying on the other (unambiguous) features of the cygwin API. Bill At 04:47 PM 10/14/2004, Max Bowsher wrote: Cygwin is supposed to be unix-like. Packages shouldn't need to start applying win32 specific tricks, and when they do, it often compromizes the unix-like feel that is a major feature of Cygwin. If cygwin used the unambiguous POSIX file flags and had close to 100% compatibility with a unix filesystem (no pathname ambiguity, case sensitive file names, valid filename characters of \ : etc) then there would be little concern for security, and it would be very rational to go with the unix flavor port.
Re: Win32 project building
At 02:02 AM 11/12/2004, David Christie wrote: Then I tried the dynamic libraries (project libaprutil). It failed immediately with: Configuration: libapr - Win32 Debug--- Creating apr.h from apr.hw Creating Version Resource Compiling resources... C:\ORG\apache\apr\libapr.rc (3): error RC2127 : version WORDs separated by commas expected C:\ORG\apache\apr\libapr.rc (3): error RC2167 : unrecognized VERSIONINFO field; BEGIN or comma expected Error executing rc.exe. Which flavor of awk are you using? We strongly recommend the one cited on the 'building_win32' page. DJGPP and GNU awk were both flawed in 3.0.3-3.0.6. You can try manually adjusting that file for valid version tags. Using some clever macros - we may eliminiate the dynamic creation of VERSIONINFO tags in the coming few weeks - It's already in the incubation/httpd/cli/trunk/mod_aspdotnet/ included version file to generate different flavors of the version token, since we need both comma and period delimited flavors. I'll try backporting this change. About your static build - it sounds somehow fatally flawed. I will try to reproduce; note we use VC6 for our dev, test and release, usually. I've used the VC6 built apr in 2003 studio projects, but haven't tried building on 2003 studio in a while. Bill
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: msdev chokes on .dsp and .dsw in unix text file format
At 05:34 PM 11/19/2004, Garrett Rooney wrote: 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. ONLY if svn:eol-style crlf in conjunction with an svn diff produces an identical result on linux and win32. Even then it creates a binary diff (mixing line ending codes). This is -not- elegant. Search for my previous rants on the subject. Kris, are you using a win32 port of svn? Or are you trying to use a non-win32 port such as cygwin? Those are two different operating systems. I love the idea of noting build/lineends.pl in the building on win32 page!!! I'm shocked it wasn't there and appologize for the oversite. Bill
Re: [NOTICE] CVS to SVN migration complete
At 06:52 PM 11/19/2004, Justin Erenkrantz wrote: --On Saturday, November 20, 2004 1:49 AM +0100 André Malo [EMAIL PROTECTED] wrote: Just a question: Maybe I'm missing the info - is the httpd trunk supposed to work with the apr 1.0.x branch or just the apr trunk? We're going to have to decide which APR branch/release httpd 2.1/2.2 should work with - and, we'll have to decide soon. Whichever we pick, we need to stick 2.2 to a *released* version of APR. At this point, without a compelling argument, I'd vote for 1.0.x. -- justin I'll offer compelling argument. Allen offered patches, which Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, and told Allen to go back and fix APR. That is the right answer, branch APR 1.x, fix on svn trunk (2.0.0) and commit the right code in httpd-2.2 such that an allocation of memory is consistently size_t and an allocation of disk is consistently off_t, and none of which has anything to do with int or long. Bill
Re: msdev chokes on .dsp and .dsw in unix text file format
At 09:14 PM 11/19/2004, Garrett Rooney wrote: William A. Rowe, Jr. wrote: ONLY if svn:eol-style crlf in conjunction with an svn diff produces an identical result on linux and win32. Even then it creates a binary diff (mixing line ending codes). This is -not- elegant. Search for my previous rants on the subject. I'm not sure exactly what the behavior is, but I will note that nobody has seemed to have a problem with using svn:eol-style on these kind of files in the Subversion tree. If there is a problem with the way it currently works I'm sure the Subversion dev list would like to hear about it. If there have been discussions about such things in the past that were ignored then a reminder of the issues involved would probably help get them dealt with. Simple. Let me suggest a patch containing libapr.dsp apr.dsp build/config.m4 that effects some change to the build, for private build purposes. Now, imagine trying to svn co such a patch, and have it apply, on both win32 and unix without missing a beat. When all TEXT files are native eol-style, this just works. When checked out on win32 native, the patch and to-be-patched files all have matching line ends. When checked out unix native, the patch and to-be-patched files all have matching line ends. It only becomes a NIGHTMARE when folks believe that a unix utility should be used for checkouts to win32. Not only do the .dsp, .dsw, makefiles and .vcproj/.sln files all fail, but there are much more subtle errors in the compilation of code, such that later debugging information doesn't line up with actual lines of code. It's very exasperating and a total waste of time to decipher segfaults that result in such code. I've always maintained that to build win32, one uses win32 files. To build unix (including cygwin) one uses unix files. And to check out from a repository, one uses the native svn to the target. I love the spirit, concept, and even occasionally the implementation of cygwin. But it drives me mad to have folks expect cygwin and native win32 results correspond with one another. They are most certainly two different platforms. Another possibility, FWIW, is to port the gen-make.py code from Subversion that generates VS6 and VS.NET build files automatically, rather than keeping manually generated ones in the tree. This, of course, is a marvelous idea. Bill
Re: msdev chokes on .dsp and .dsw in unix text file format
At 09:35 PM 11/19/2004, Garrett Rooney wrote: William A. Rowe, Jr. wrote: Simple. Let me suggest a patch containing libapr.dsp apr.dsp build/config.m4 that effects some change to the build, for private build purposes. Now, imagine trying to svn co such a patch, and have it apply, on both win32 and unix without missing a beat. When all TEXT files are native eol-style, this just works. When checked out on win32 native, the patch and to-be-patched files all have matching line ends. When checked out unix native, the patch and to-be-patched files all have matching line ends. It only becomes a NIGHTMARE when folks believe that a unix utility should be used for checkouts to win32. Not only do the .dsp, .dsw, makefiles and .vcproj/.sln files all fail, but there are much more subtle errors in the compilation of code, such that later debugging information doesn't line up with actual lines of code. It's very exasperating and a total waste of time to decipher segfaults that result in such code. I've always maintained that to build win32, one uses win32 files. To build unix (including cygwin) one uses unix files. And to check out from a repository, one uses the native svn to the target. I love the spirit, concept, and even occasionally the implementation of cygwin. But it drives me mad to have folks expect cygwin and native win32 results correspond with one another. They are most certainly two different platforms. So are you saying that if we force svn:eol-style to CRLF on the .dsp files that the resulting patches won't work. When I try it here (a unix box) I get a diff that includes \rs at the end of the lines for changes in a CRLF file. Isn't that what it should be? If you apply that patch using native patch on win32, we have duplicate \r's and that does fail. Patch seems to deal with it just fine BTW, even if there are some CRLF and some NL files. Modern versions of patch learned to (mostly) ignore \r's - but when you have oddballs (I'm fighting hp/ux and aix at home, this evening) patch is dirt stupid. I admit, I haven't tried this on win32 (either normal or cygwin), since I don't have access to such a machine at the moment, but I have no reason to believe it will work differently there. Trust - it does. Please consider that the patch itself is pushed and extracted from svn just as the original sources, so \r-ness is very consistent. Another possibility, FWIW, is to port the gen-make.py code from Subversion that generates VS6 and VS.NET build files automatically, rather than keeping manually generated ones in the tree. This, of course, is a marvelous idea. Unfortunately it requires someone with more Win32-fu than me to do it. 2c US - I'll invest some effort with you. ITMT the suggestion of using either native Win32 svn or converting with build/lineends.pl is the way to go tonight. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 11:03 PM 11/19/2004, Justin Erenkrantz wrote: --On Friday, November 19, 2004 8:01 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I'll offer compelling argument. Allen offered patches, which Roy vetoed, to fix object sizes on 32/64/64 ILP bit platforms, and told Allen to go back and fix APR. I don't believe that Allen would be able to complete his changes in a reasonable timeframe. So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- I guess the ball is to Allen, then, but I'd also be happy to quickly whack at it. The concept is Simple(tm) and would be far less painful than actually fighting through all the ( cast )s of his later patches. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 08:23 AM 11/20/2004, Jim Jagielski wrote: On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote: So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin +1. Of course, I am assuming that his 64bit fixes will likely break binary compatibility. It does - that's the rub. And, for 2.2, this was always the plan. For module writers it's not a big deal, but for commercial 3rd party modules it might be. Simply because they would need to produce yet another version of their modules for httpd. They will. Implicit in the '2.0 isn't a moving target' comes the correlary '2.1-dev is a moving target, and once we get it right, it will be 2.2 and quit shifting the API beneath you.' Recall how long it took for some 1.3 modules to be ported to 2.0? With 2.2 they will now need to port to 2.2, which obviously is trivially easier than going from 1.3-2.0. Yes - though there will be api changes as well. We obviously need to move beyond APR 0.9 - either to 1.x or (if we have to fix the API) to 2.x. But there will be delay. If we then produce another 2.x which isn't binary compatible, then it's another process and the module list will start looking quite crowded [...] That's a lot of modules for companies to worry about. We might, or it might be too drastic (event mpm's which allow requests to jump threads.) If they are too radical for 2.4 or 2.6 expectations, then 3.0 comes along. I'd hope no faster than 6-18 mos per minor bump because you are right - it creates a burden for module authors. No, I don't have the answer but we should be prepared for the uptake of 2.2 to be less than we hope or imagine. Of course. This is true of most projects, Major bump is quite slow (initially), minor is a noticeable delay, and subver should be quick if we keep it painless. This kind of brings up an idea that's been sloshing around between that handful of neurons in my noggin: Some sort of API seed program within httpd/apr where we put a little more effort in getting the latest API versions out there. We've been operating on a pull me scenario, and it's worked, but it's been hardly optimal. Maybe some sort of push mechanism would be useful. Even if it's just a blurb on the site that Apache 2.2 will be released soon, here is the new API (which is frozen), if you plan to have your Apache modules ready for 2.2 when released, please grab this tarball and test. I'm 100% with you - we should loudly scream The alpha is here! Tell module authors this is it - if we can make your life easier, now is the moment we will break ABI in order to do so! Of course, snooze you lose, if there is something you needed, it will just wait until 2.3-dev for us to begin work after the feature/api freeze 2.2. Bill
Branches, please vote...
We have apr/apr/branches/ 1.0.x/ - this is great APR_0_9_BRANCH - this should be 0.9.x? APR/ unlabeled/ - these are duds - delete them? apr/apr-util/branches/ 1.0.x/ - again, dandy APU_0_9_BRANCH - this should be 0.9.x? apr/apr-iconv/branches/ 1.0.x/ - again, dandy API_0_9_BRANCH - this should be 0.9.x? API_1_0_BRANCH ICONV - these are dead - rm them? Opinions on my '?'s above?
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 08:23 AM 11/20/2004, Jim Jagielski wrote: This kind of brings up an idea that's been sloshing around between that handful of neurons in my noggin: Some sort of API seed program within httpd/apr where we put a little more effort in getting the latest API versions out there. The other alternative is a 'fixed' subset of the httpd API that we simply don't touch. At least so it's APR compat if not ABI compat. That also means leaving httpd n.x releases on apr m.x releases. But mod_isapi already builds on all platforms if you are looking for a stable plug-in api ;-) Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 12:37 PM 11/20/2004, William A. Rowe, Jr. wrote: The other alternative is a 'fixed' subset of the httpd API that we simply don't touch. At least so it's APR compat if not ABI compat. s/APR compat/API compat/
Eliminate .rc files?
http://svn.apache.org/viewcvs.cgi/httpd/mod_aspdotnet/trunk/Apache.Web/Apache.Web.Version.h?rev=105923view=markup is how I coded the version header for mod_aspdotnet, so that the .rc file... http://svn.apache.org/viewcvs.cgi/httpd/mod_aspdotnet/trunk/Apache.Web/Apache.Web.rc?rev=105923view=log never needs to be autogenerated. The differences between apr and mod_aspdotnet? Our apr_version.h file includes apr.h, and only because we declare some fn's in there. Does anyone object to flipping those version function declarations into apr.h (they are immutable) and including apr_version.h within apr.h? It's already protected from double-inclusion. The only possible breakage is including apr_version.h without ever including apr.h - a scenario I think is most unlikely. It seems like this could fall under the 1.1 bump. Comments? Bill
[SVN] Branches for apr[-util|-iconv] 0.9.x moved
apr/apr/branches/ APR_0_9_BRANCH - 0.9.x apr/apr-util/branches/ APU_0_9_BRANCH - 0.9.x apr/apr-iconv/branches/ API_0_9_BRANCH - 0.9.x All changed... you need to... cd into your local checkout directories, and switch them. cd /path-to-local/apr-0.9/ svn switch https://svn.apache.org/repos/asf/apr/apr/branches/0.9.x cd /path-to-local/apr-util-0.9/ svn switch https://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x cd /path-to-local/apr-iconv-0.9/ svn switch https://svn.apache.org/repos/asf/apr/apr-iconv/branches/0.9.x and you will jump right up with us. apr/apr/branches/ APR/ unlabeled/ - these are duds - delete them? apr/apr-iconv/branches/ API_1_0_BRANCH ICONV - these are dead - rm them? All gone. Bill
Re: svn commit: r106038 - in apr/apr/branches: 0.9.x APR_0_9_BRANCH
At 07:10 PM 11/20/2004, Jim Jagielski wrote: [EMAIL PROTECTED] wrote: Author: wrowe Date: Sat Nov 20 14:46:04 2004 New Revision: 106038 Added: apr/apr/branches/0.9.x/ - copied from r106037, apr/apr/branches/APR_0_9_BRANCH/ Removed: apr/apr/branches/APR_0_9_BRANCH/ Log: Reorganize the apr project 0.9 branches Quick question (I *know* I should have hit at least one SVN preso/BOF @ Ac2004, but there it is): if I already checked-out the APR_0_9_BRANCH, how do I change it, locally, to the 0.9.x one? I don't have to re-checkout, do I? Nope - that's one happy detail svn considered; see the post Subject: [SVN] Branches for apr[-util|-iconv] 0.9.x moved for details of how to switch. Also, more a generic question, why didn't we svn move instead of cvn copy ? We did, that's how the commit message appears (copy foo from bar, removed bar.) Bill
Re: svn commit: r105961 - apr/apr-util/trunk
At 07:41 AM 11/21/2004, Max Bowsher wrote: Author: jorton Date: Sat Nov 20 05:17:18 2004 New Revision: 105961 Modified: apr/apr-util/trunk/CHANGES apr/apr-util/trunk/Makefile.in apr/apr-util/trunk/configure.in Log: Link libaprutil against the libraries on which it depends (dropping support for libtool 1.3): * configure.in: Remove EXTRA_OS_LINK export. * Makefile.in: Link target against APRUTIL_LIBS. PR: 11122 Could this be backported to 0.9.x, please? Most unlikely, as we supported libtool 1.3 throughout apr 0.9. More likely, we add a disclaimer with 1.x.x releases proclaiming 'you must use libtool 1.4'. I don't believe 1.x.x has been around long enough for this to affect end users. (Developers, yes, but I don't worry nearly as much about them.) Offer up a patch that doesn't break libtool 1.3 and I'd review. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 10:08 AM 11/22/2004, Bill Stoddard wrote: William A. Rowe, Jr. wrote: At 08:23 AM 11/20/2004, Jim Jagielski wrote: On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote: So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin +1. Of course, I am assuming that his 64bit fixes will likely break binary compatibility. It does - that's the rub. And, for 2.2, this was always the plan. And that's precisely the reason we should attack the 64 bit problem for 2.2. This will give the 2.2 series a much longer life than if we push off the 64 bit work to 2.4. +1 - well said. By the way, Allen was out for the week of AC but returns this week, perhaps he can jump back into this conversation. Yes - I understand that this means 1.x will never be used by httpd. Version numbers are cheap. The APR project should become used to this, if they are active, and httpd moves at it's normal pace, it would be easy to go through APR 2.x, 3.x, and land somewhere in version 4.x by the time httpd 2.4 or 3.0 walks out the door. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 11:08 AM 11/22/2004, Cliff Woolley wrote: On Mon, 22 Nov 2004, William A. Rowe, Jr. wrote: Yes - I understand that this means 1.x will never be used by httpd. Version numbers are cheap. The APR project should become used to this, if they are active, and httpd moves at it's normal pace, it would be easy to go through APR 2.x, 3.x, and land somewhere in version 4.x by the time httpd 2.4 or 3.0 walks out the door. Do you understand how ridiculous that sounds? How so? Let's imagine the release -after- 2.2 takes another 12-18 months. Perhaps the event mpm gets plugged in, and it takes three months, alone, just to find all the gotchas of thread-jumping. In the meantime, apr is adopted by other projects. These coders offer up some solid functionality for their own applications, and the apr team agrees. Yes, I realize most of the time new functionality can be a minor bump of apr. Yes, I realize apr has not been all that active in the past 12 months. All I'm arguing is that apr shouldn't be addicted to some 1:1 correspondence of httpd and apr bumps. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN
At 12:17 PM 11/22/2004, Justin Erenkrantz wrote: I expect that as it stands right now most 2.0 modules will compile for 2.2 with very minor (if any) changes. If we 'fix' 64-bit issues now, then that means that their modules are going to undergo massive changes. This I will attest to; porting to 2.2 for mod_aspdotnet, I encountered; - lost APR_BRIGADE_FOREACH - changed apr_pool_get_parent // apr_pool_parent_get and of course; link to libapr-1 / libaprutil-1. other than that, it was very clean. That *will* affect the 2.2 uptake rate because our third parties will take a lot of time to get their modules 64-bit clean (if they do at all). WHO CARES?!? That's on them. They can release bug fixes after bug fixes, or extend their list of tested/supported platforms as they get around to it. It's their problem. As it stands, WE will be in THEIR WAY with incorrect code in apr and httpd. At that point - they cannot address the problems until we release the next version minor (2.4 or 3.0). How unfair is that? I still think this needs to be punted to 2.4. It's just *way* too big. Way too big for you to handle? Ok. Not asking you to develop, test or even review. We'll also have to fix up all of httpd to be 64-bit clean. Not hard. And, that's going to push 2.2 out even further. It's pointless arguing this aspect. Are we done with 2.2? If you want to vote on 2.2 - then vote on 2.2 - don't get in the way of other developers' progress with hand waving. That, I think, is the biggest lesson I took out of the httpd luncheons. This is something we should take our time on - not try to rush out the door and then have to go back and clean up because we rushed 2.2 (and APR 2.0) out the door. No thanks. -- justin I could say the same about... ...nevermind. The lesson we learned, in a nutshell; When httpd 2.1-dev is mostly satisfactory, and we have an alpha that the community decides is ready to take to 2.2 - we fork. That fork gets stabilization improvements until it's beta, and finally GA quality. That GA release is titled 2.2.0. In the meantime, head becomes 2.3-dev. Once again, nobody is standing in the way of code fixes. They can be percolated down to the 2.2 branch (before or after 2.2.0 is blessed), and even all the way to the 2.0 branch. That requires more review, which it should so 'stable' branches don't destabilize.
Re: portability
At 01:07 PM 11/24/2004, Friedrich Dominicus wrote:
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
At 08:24 AM 11/24/2004, Friedrich Dominicus wrote:
How about this code then?
/* #ifndef _WIN32_WCE
if (((*new)-td = (HANDLE)_beginthreadex(NULL,
attr attr-stacksize 0 ? attr-stacksize : 0,
(unsigned int (APR_THREAD_FUNC *)(void
*))dummy_worker,
(*new), 0, temp)) == 0) {
return APR_FROM_OS_ERROR(_doserrno);
}
If you let us know which compiler fails for you, we can
have a look at it. Let us know the compiler's defined()
macro signature as well.
lcc-win32
__LCC__
However there are a bunch of other things I had to add/modify to
get libapr0.93 somehwat compiled. I now fail miserable with the 1.x
version because of poll problem.
What poll problem? we use network_io/unix/select.c, not poll.c.
Howerver it was still not an easy going to get libapr compiled on
MSVC, so I either I've messed up my MSVC, Windows or libapr or the
might be another problem
You might try a clean checkout.
The point which we have trouble with are this declarations
#elif defined(APR_DECLARE_EXPORT)
#define APR_DECLARE(type)__declspec(dllexport) type __stdcall
#define APR_DECLARE_NONSTD(type) __declspec(dllexport) type
#define APR_DECLARE_DATA __declspec(dllexport)
#else
#define APR_DECLARE(type)__declspec(dllimport) type __stdcall
#define APR_DECLARE_NONSTD(type) __declspec(dllimport) type
#define APR_DECLARE_DATA __declspec(dllimport)
The declaration while building a DLL seem to be ok, but Mr Navia the
author of lcc-win32 thinks that the APR_DECLARE in the else part is
wrong. Maybe you can point us to the documentaton on where this is
required.
There is no error. You need to declare dllimport in order
to ensure these functions are mapped. If Mr Navia is certain
that all relocation stubs (ESPECIALLY data relocations!!!) don't
need special handling under lcc, he should simply recognize and
ignore that __declspec construct.
If you are trying to build STATIC .lib - you must define the
macro APR_DECLARE_STATIC when building the library. You can
also use it when compiling against the static library headers
in your own app to save the compiler lots of fixups.
Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 12:29 PM 11/24/2004, Allan Edwards wrote: If we can make good progress towards a stable 64 bit APR 2.0 then moving httpd 2.1/2.2 to it could make sense. The question is whether there is enough feature freeze pressure to say that 64 bit does not warrant the wait... Allan - your last patches were to try to -wedge- the current API into httpd. Can you share the patch just to fix APR? Then we can start to comprehend scope. NO CASTS - just the correct declarations in the first place. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 01:05 PM 11/24/2004, Cliff Woolley wrote: On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote: Allan - your last patches were to try to -wedge- the current API into httpd. Can you share the patch just to fix APR? Then we can start to comprehend scope. NO CASTS - just the correct declarations in the first place. Since this is obviously going to be big, don't you think it would be better to just get going on a sandbox branch of APR so that we can work iteratively instead of passing big patches back and forth? ++1
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 01:29 PM 11/24/2004, Cliff Woolley wrote: On Wed, 24 Nov 2004, Justin Erenkrantz wrote: I'm sick of all talk and no action. We tried this last year when we were almost ready to branch APR 1.0 and all action on that front ceased entirely for a YEAR. This time it's one or the other. I'll wait 24 hours at most to hear opinions. Whichever route gets the most support wins. So far we have: trunk remains 1.1, 64-bit is sandboxed: jwoolley, jerenkrantz wrowe: (conditional on committing to head once it's reviewed, and branch 1.1 if we want to keep 1.1 alive.) trunk becomes 2.0: rooneg --Cliff
Stas's proposed symbol renames
Now that 1.0.x is branched, svn is up and running and most of the headaches are diminishing with the help of a bit of advil... I see no reason for Stas not to commit his APR_ file macro renames on 1.1.x - it's commit-then-review so be my guest. Bill
Re: svn commit: r106663 - /apr/apr/trunk/CHANGES /apr/apr/trunk/include/apr_file_io.h
At 03:26 PM 11/26/2004, you wrote: Author: stas Date: Fri Nov 26 13:26:37 2004 New Revision: 106663 URL: http://svn.apache.org/viewcvs?view=revrev=106663 Log: rename the fopen defines (APR_READ, APR_WRITE, etc.) to have prefix APR_FOPEN_ (keeping the old defines) Stas, you forgot doxygen @deprecate tags! For example, with; +#define APR_FOPEN_READ 0x1 /** Open the file for reading */ we need a matching doxygen entry redirecting the user; +#define APR_READ APR_FOPEN_READ /** @deprecated @see APR_FOPEN_READ */ This provides documentation that devs *need* to track the changes. Bill
Re: svn commit: r106663 - /apr/apr/trunk/CHANGES /apr/apr/trunk/include/apr_file_io.h
At 10:50 AM 11/29/2004, Stas Bekman wrote: Also should the deprecated macros stay in this file or can those be moved to some dedicated file to reduce the noise? They stay in place. During the next major+1 bump, the RM trawls through the files looking for @deprecated, and simply strips them out. The way doxygen works, you would not want these moving out of scope to another file. Bill
Re: apxs/apr-config/apu-config on Win32
At 11:51 AM 11/29/2004, Stas Bekman wrote: Randy Kobes wrote: I've been testing out some perl scripts to emulate apxs/apr-config/apu-config on Win32 (under Apache/2.0.x), and was wondering if there was any interest in developing them within the appropriate httpd/apr sources. At present they can be installed via a perl script http://perl.apache.org/dist/win32-bin/install_apxs This assumes an installed Apache binary with the associated apr/aprutil libs, but it would be possible to separate out the apxs from the apr/apu config utilties. In their present form they're intended for building modules outside of the httpd sources; they've been tested out on the c-modules within the perl-framework under httpd-test, as well as those under env/ of httpd-apreq-2, and they seem to work OK. +1 Randy is a long time committer to the mod_perl project, so I'm sure that if the proposed scripts are integrated with apr/httpd, Randy will be able to maintain those, once the right karma is added. There are very few brave folks who handle the win32 world, so let's make it easier for them to help the disadventaged win32 users. ++1 - this is a wonderful thing. One note - I'd like to see this stripped to the point where you don't have a ton of dependencies on additional modules. Would be nice to distribute without the need to use Makemaker. Is this possible? (Putting necessary .pm stubs in the same tree as apxs and letting it run out-of-the-box?) Bill
Re: svn commit: r106663 - /apr/apr/trunk/CHANGES /apr/apr/trunk/include/apr_file_io.h
At 11:45 AM 11/29/2004, Stas Bekman wrote: William A. Rowe, Jr. wrote: At 10:50 AM 11/29/2004, Stas Bekman wrote: Also should the deprecated macros stay in this file or can those be moved to some dedicated file to reduce the noise? They stay in place. During the next major+1 bump, the RM trawls through the files looking for @deprecated, and simply strips them out. That's not possible with this particular change, since everything (APR/httpd) still uses the old macros. No, it's a requirement when we push major+1. Then again, httpd may stay with 1.x, or may have a prerequisite 1.1 (meaning we assume your change is there) or it may even move to 2.x - in which case we -must- update all occurrences within httpd. There is no reason to keep using the old symbols in apr[-util/-iconv] so feel free to start migrating those. The way doxygen works, you would not want these moving out of scope to another file. Is there a way to put them in a different file and tell doxygen that the following entries really belong to a different file? 1. it isn't pretty and 2. you can't force a user to include another file from minor to minor bump. Their code should keep compiling w/o changes. Please don't worry that this seems 'polluted' - the next major bump cleans this all out. In the meantime, if they look for these symbols grep APR_FOO include/* they should find the old and new flavors in the same file, helping them with their own migration tasks. Bill
Re: RFC use APR's getpass() instead of native getpass() on HP-UX?
Joe makes a good point, +1 for this change when we roll over into 2.0. Bill At 01:30 PM 12/1/2004, Joe Orton wrote: On Wed, Dec 01, 2004 at 09:36:32AM -0500, Jeff Trawick wrote: HP-UX apparently has no other function than getpass(), and it silently truncates after 8 characters. There are Apache httpd and Subversion users grappling with this limit. (It caused a some puzzlement for me with cvs too, but APR won't help that ;) ) The hint from Joe is to set ac_cv_func_getpass=no before running configure. A nicer way would be to add a configure option such as --enable-apr-getpass. But why not avoid the system getpass() by default? Is maintaining compatibility with limitations of other applications on the same system preferable to breaking compatibility with the same application used on different systems with different native capabilities? Using the getpass replacement iff PASS_MAX is defined and small would sound sensible? The terminal handling of the APR getpass doesn't look as good as my nearest libc w.r.t. handling control characters though if that were fixed I guess it would be fine to use it on all platforms with POSIX termios support. But the trade-off is also against backwards-compatibility of APR, right? Use of long passwords could break when upgrading to a new version of APR with this fixed, since they would stop being truncated, although the workaround is obviously simple. I think I'd agree that compatibility of applications across platforms would be of more value than any of the other compatibilities, in any case! joe
Re: RFC use APR's getpass() instead of native getpass() on HP-UX?
At 11:09 AM 12/3/2004, Jeff Trawick wrote: On Wed, 1 Dec 2004 19:30:43 +, Joe Orton [EMAIL PROTECTED] wrote: On Wed, Dec 01, 2004 at 09:36:32AM -0500, Jeff Trawick wrote: HP-UX apparently has no other function than getpass(), and it silently truncates after 8 characters. There are Apache httpd and Subversion users grappling with this limit. (It caused a some puzzlement for me with cvs too, but APR won't help that ;) ) The hint from Joe is to set ac_cv_func_getpass=no before running configure. A nicer way would be to add a configure option such as --enable-apr-getpass. But why not avoid the system getpass() by default? Is maintaining compatibility with limitations of other applications on the same system preferable to breaking compatibility with the same application used on different systems with different native capabilities? is this an accurate understanding? the migration problem comes with the subversion-type usage scenario; user thinks password is 10 characters; actual stored password on server (HP-UX) was truncated at 8 characters; user upgrades APR on HP-UX client and now the passwords don't match when user continues to enter 10 characters; if server wasn't HP-UX or client wasn't HP-UX, it never would have worked to begin with; when both are HP-UX, client has to now be aware that they only thought their password was 10 characters, and it was really 8 with the Apache httpd (htpasswd) testcase, the discrepancy would already have been noted since the long password entered on the web browser dialog would never have matched; so no migration concern Yes. Now the question becomes, do we fix? Since it changes the expectations, my thought is; 1. optionally disable in 0.9, 1.x APR. Put this in README. 2. automatically disable in 2.0 APR.
Re: apr_sha1
At 07:53 AM 12/5/2004, Joe Orton wrote: On Sun, Dec 05, 2004 at 12:53:58PM +, Thom May wrote: You don't say which you propose to change, but either way it's an API change not really worth bumping the major number for, I'd reckon. There's an objection to making the md5 functions return void in STATUS, FWIW. Note that on x86 platforms, in general, adding a return type in place of a previous void type is a noop. However, if you code for testing the 'new' return type in 1.1 - the author is free (by our version rules) to assume their code will work back in 1.0 - and the random garbage will cause their code to hiccup if the test the rv. But this is implementation specific, and it's quite possible that on another platform, potentially mainframe compilers for example, adding a return type may break the call/return stack semantics. This simply isn't a good idea until 2.0. Bill
Re: apr_sha1
At 06:32 AM 12/7/2004, Julian Foad wrote: William A. Rowe, Jr. wrote: This simply isn't a good idea until 2.0. Does the project have a standard place to record proposed API changes for the next major version so that they are not forgotten when that time comes? If not, may I suggest putting this in the STATUS file under a heading like For version 2? Add an @bug to the doxygen comments for such functions, in the form of a patch. I don't remember if you answered Joe's question of which was the right answer - both use an apr_status_t or neither? Bill
Re: broken apr_brigade_cleanup?
At 10:15 AM 12/7/2004, Stas Bekman wrote:
apr_brigade_cleanup looks wrong:
APU_DECLARE(apr_status_t) apr_brigade_cleanup(void *data)
{
apr_bucket_brigade *b = data;
apr_bucket *e;
shouldn't it be:
apr_bucket_brigade *b = (apr_bucket_brigade *)data;
why does it have (void *data) argument? why is this inconsistent with:
APU_DECLARE(apr_status_t) apr_brigade_destroy(apr_bucket_brigade *b);
it seems to work fine on linux but on windows causes all kind of crashes.
It shouldn't - all ANSI C compilers should promote any void* type
to an appropriate foo* type silently and without any negative
consequences.
Is it possible you created a mis-aligned apr_bucket_brigade (not
on an appropriate word boundry?) What module is crashing? Is
this perl? C? C++?
Bill
Re: Compilation on Windows
At 10:51 AM 12/9/2004, Tangui Morlier wrote: I could not acces to the mailing list archive. If this topic has already been discused here, please tell me how i can read these messages. I used apr in linux without any problem. Now I would like to use the windows version. As i could not find the binary distribution, I tried to compile it. I downloaded the apr, apr-util, apr-iconv source archives, untared then and try to compile them with Visual C++ Pro 6.0 as indicated in your web site, but it is not working. More info in the log file attached. This is an easy one, ensure that the undecorated directories are parallel to each other; e.g. buildroot\apr\ \apr-util\ \apr-iconv\
Re: Compilation on Windows
At 03:42 PM 12/9/2004, Branko Čibej wrote: Tangui Morlier wrote: By the way, folks, why on earth do those files have svn:eol-style set to native instead of CRLF? * because they contain text * because 'patch' should always 'just work' * because other platform maintainers may add/delete sources * because .dsp/.dsw are only the 'obvious' problem. The less obvious issue is that the compiler gets entirely twisted about what 'line number' of the sources corresponds to a given symbol, and the debugging support becomes worthless with \n terminated sources. apr/lineends.pl exists for this purpose. Sadly, it can and will corrupt svn tree files if you use it on a checkout, rather than on a tarball. I'll commit the patch shortly. Bill
Re: Compilation on Windows
At 04:44 PM 12/9/2004, Branko Äibej wrote: William A. Rowe, Jr. wrote: At 03:42 PM 12/9/2004, Branko Ãibej wrote: Tangui Morlier wrote: By the way, folks, why on earth do those files have svn:eol-style set to native instead of CRLF? * because they contain text What's that have to do with the end-of-line style? Yes most linux editors, at least recent ones, recognize dos line endings. But those are not linux text files, and on older OS's - they become harder to maintain. * because 'patch' should always 'just work' It has for me. I've not yet seen a version of patch (on Unix) that would get confused by the CRs. Apparently you don't do AIX 4.3, HP/UX and other twisted varients lol. * because other platform maintainers may add/delete sources So? They can use a non-broken editor, such as Emacs, vim, etc. It's unix'es editors job to recognize silly MS conventions? * because .dsp/.dsw are only the 'obvious' problem. The less obvious issue is that the compiler gets entirely twisted about what 'line number' of the sources corresponds to a given symbol, and the debugging support becomes worthless with \n terminated sources. Huh? Which compiler? And what does that have to do with the format of .dsp files? Has to do with the format of all text files built by MS cl. A broken build is a broken build, whether it just won't build at all, or when the build results are mildly bogus by being impossible to debug/trace etc. apr/lineends.pl exists for this purpose. It existed for this purpose while we were using CVS. Many people argued against putting the -kb flag on DSP files, and I sort of agree with that. However, Subversion is quite a bit smarter than CVS. I'm coming to learn that, though I'm still not reassured. Better point though; svn unix users (or the cygwin port users) can add a flag to their checkout to grab files as CRLF. There's no need to even use the win32 svn port to accomplish this. I'd like to see concrete examples of problems that can't be worked around. This hand-waving and inventing problems bores me. I've been using Subversion with CRLF eol-style set on .dsp files for years, from both Windows and Unix, and I've never had a single problem. I deal with about 6 different 'edgy' unicies, which aren't nearly as forgiving as Linux. There are alot of broken projects which focus only on the expected Linux/OSX/Win32/Solaris8+ and don't even know what an .sl file is, year old projects who can't grok .dylib files, etc... while our APR project attempts to be wildly more cross platform. Simple fact (again, cvs, and svn may prove better) - In order to patch mixed source and .dsp files as one update against, say, cvs-php4, it's impossible to apply the same patch, checked out on hpux, linux, solaris, and win32. It works just dandy on win32, they all come out with cr/lf's, patches included. Try that on hpux for example, and it chokes. But much worse, try a cvs diff on unix, and you end up with a mess of ^M's on the patch. Now, commit that patch, check it out on win32, and you end up with the beautiful CR/CR/LF line endings. This isn't getting any prettier. SVN has it's own issues. Do an svn diff of a text file (native.) Guess what? The resulting patch isn't even native! On win32 I'm left with LF delimited deltas. Obviously, I won't be ditching lineends.pl any time soon. The [EMAIL PROTECTED] project's httpd/mod_aspdotnet repository is actually a nice place to play with these issues; we only build that module on Win32, so almost every issue I mentioned is moot. I'm struggling to see how svn is helping us and what it can do to seriously help Win32 users. Bill
Re: Backport and release policy for APR and APR-UTIL...
Ok, you have me confused :) There can be no binary breakage between 1.0.0 and 1.99.999. Nothing (except for unreleased changes in our svn repository) as we move forward. Minor bumps introduce new features. Subversion bumps fix bugs. That's the short story. I'm increasing concerned that folks believe that we won't go to 1.1 or 2.0 until there is some magic 'httpd' project release. Nothing is farther from the truth. APR and APR-UTIL will be released as we have improvements that are stable. If the httpd, svn, foo, bash or bang projects want to use a specific version that is fine. Moving forward, httpd may decide to 'officially' move from version 1.1 to 1.3, for example, between their 2.2.0 and 2.2.4 releases. That's allowed by both project's compatibility rules. Nothing is changing that breaks code compiled for apr 1.1 or httpd 2.2.0 when a user moves up to 1.3 and 2.2.4. Where projects with strong binary bindings get trapped, is when they want to jump from APR 1.x to 2.x (or straight to 3.x skipping our 2.x releases.) We've assured our users that APR won't break compatibility until they jump major version. So the httpd project will prod us to continue to bug fix both apr 0.x, and apr 1.x, once they have released some httpd that is based on 1.x (if they do.) That's understandable. But asking about backporting from 1.1.x to 1.0.x seems somewhat silly. Bill At 12:29 PM 12/15/2004, Cliff Woolley wrote: On Wed, 15 Dec 2004, Brad Nicholes wrote: release of APR 1.0. Since then there has been a lot of activity in TRUNK as compared to almost no activity in the 1.0.x branch. After the 1.0.x branch was created at ApacheCon, Justin and Thom backported everything that they thought could be backported without breaking binary compatibility... --Cliff
Re: Backport and release policy for APR and APR-UTIL...
At 04:31 PM 12/15/2004, Paul Querna wrote: Brad Nicholes wrote: The reason why it's *not* silly is because of our release schedules. Unless the APR project wants to do something completely different with versioning, revision releases (1.0.1 to 1.0.2) are usually on the order of a few months. Point releases (1.0.x to 1.2.x assuming even numbered releases) are usually on the order of years. Major releases (1.x to 2.x) are on the order of who knows when. That has been the history of HTTPD and I don't see any reason why it wouldn't be the history for APR as well. I hope we -don't- try to model httpd. A library such as apr is substantially different than httpd. Given that assumption, I don't want to wait a year for APR 1.2 to be released just to see a minor bug fixed. I want it backported to 1.0.x so that it gets released next month (or sooner). Also using HTTPD as an example, HTTPD 2.2 will not be binary compatible with 2.0. We have already made sure of that with a magic number bump. Therefore, I don't see why APR 1.2.x must be binary compatible with 1.0.x. Because those are our versioning rules... please review them. Although httpd can change it's rules to suit the project, those who adopt the apr library have based their decisions on the rules we had laid down and already voted on. We absolutely cannot break binary compatibility until the next major rev. If that means that apr is 10.1.0 in two years, so be it. I am thinking it might be a good idea todo a 1.1.0 release before httpd-2.2. Or 2.0 - if we actually fix the alignment issues. Lets just do it. Whats stopping a 1.1.0 release today? I don't see any big issues, so, someone needs to take charge as a release manager and make it happen. +1 if 1.1 includes new features, and STATUS showstoppers are closed. hint description=If you have a 1.1 issue, add it to STATUS / Bill
