William A. Rowe, Jr. wrote:
I'd like to modify the Win32 build projects (of mod_jk, and
httpd 1.3/2.0/2.1-dev, along with apr);
The /O2 optimization option is extremely agressive, unfortunately
it produces less than ideal crash traceback information. That
is due to the (implicit) /Oy flag,
William A. Rowe, Jr. wrote:
If the open source community tends to push back on Microsoft's
newest compilers, it's simply because their forced treadmill is
the anathema of inclusiveness.
That's what's happening right now with Subversion. The Python 2.4 distro
is built with VS.NET (2003, I
William A. Rowe, Jr. wrote:
At 04:35 PM 5/11/2005, Branko ibej wrote:
William A. Rowe, Jr. wrote:
If the open source community tends to push back on Microsoft's
newest compilers, it's simply because their forced treadmill is
the anathema of inclusiveness.
That's what's happening
Sander Striker wrote:
On Wed, 2004-01-28 at 22:03, Stas Bekman wrote:
I couldn't find apr_realloc() in the apr API. Is that on purpose or just
wasn't needed so far?
I suppose realloc is hard in the pool architecture, since if you have
allocated something after the alloc, you have to move
Jeff Trawick wrote:
Branko ibej wrote:
The only issue I know of which is presently considered a showstopper
for 1.0 is fixing some of the atomic APIs to return a value.
And fixing the broken condition variable implementation on Windows.
Sorry, I'm working on that, but very slowly due
Jeff Trawick wrote:
Lev Serebryakov wrote:
Is here any plans for relesa separate apr-0.9.5 or even apr-1.0
distribution?
AFAIK, there was plans to release apr-1.0 at 19/Nov/2003...
Is here any new timelines, etc?
I dunno about 0.9.5.
For 1.0:
The only issue I know of which is
[EMAIL PROTECTED] wrote:
striker 2003/11/18 14:52:07
Modified:builddbm.m4
Log:
* build/dbm.m4
Add detection code for Berkeley DB 4.2, to be released this month.
Heh, and note, a couple of weeks ago it was to have been released last
month. :-)
--
Brane ibej
[EMAIL PROTECTED] wrote:
Following some discussion at the hackathon today and previous discussions
on this list, a new 1.0 branch has been created. This will be used for
what will hopefully be an imminent APR 1.0 release!
After the race conditions in the Win32 condition variables are fixed, I
Ben Laurie wrote:
Jeff Trawick wrote:
/* FIXME: this is not C99 or C++ or Java */
What's the matter? Did your editor break? :-)
Besides, your revision is wrong...
/* FIXME: this is not C99 or C++ or Java or gcc */
So now 'gcc' is a language. Sigh.
Try 'gcc -std=c89',
[EMAIL PROTECTED] wrote:
gstein 2003/11/02 12:51:18
Modified:include/arch/os2 apr_arch_networkio.h
include/arch/unix apr_arch_networkio.h
include/arch/win32 apr_arch_networkio.h
network_io/unix sendrecv.c sockets.c sockopt.c
William A. Rowe, Jr. wrote:
I committed the fix and it builds here. What are your observations?
Multicolored spots before the eyes, and the furniture looks a bit
soft... er, obviously I was smoking something weird. A cvs up -A and
rebuild made the problem vanish.
Sorry. Never mind me.
Bill
C K Tan wrote:
I ran into a race condition on Win32 with the attached test program
(pc.c). Looking at thread_cond.c, it became obvious where where this
could happen:
1. on line 96, apr_thread_mutex_unlock can be called multiple times
without corresponding lock operation (if the while loop
[EMAIL PROTECTED] wrote:
striker 2003/09/27 16:51:46
Modified:misc/unix start.c
memory/unix apr_pools.c
Log:
* misc/unix/start.c
(apr_initialize): Remove atomics initialization from this function. Due
to circular dependency, doing it here is too late.
Sander Striker wrote:
From: Branko Cibej [mailto:[EMAIL PROTECTED]
Sent: Monday, September 29, 2003 2:56 AM
[snip]
I can't believe we don't have a Win32 implementation of the atomics. So
right now, HEAD doesn't compile on Windows. :-(
Sure we do. Take a look at
Branko ibej wrote:
Also, I'm being double stupid because it's not APR that doesn't compile,
it's APR-iconv. Ho hum. Now how can that happen?
/me grumbles and looks
Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder
Sander Striker wrote:
From: Branko Cibej [mailto:[EMAIL PROTECTED]
Sent: Monday, September 29, 2003 3:22 AM
Branko ibej wrote:
Also, I'm being double stupid because it's not APR that doesn't compile,
it's APR-iconv. Ho hum. Now how can that happen?
/me grumbles and looks
Cliff Woolley wrote:
On Mon, 29 Sep 2003, [UTF-8] Branko ?^Libej wrote:
Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
dangling references to it in apr_pools.obj.
Uh -- I said HEAD, not the
INOUE Seiichiro wrote:
apr_thread_cond_wait()/apr_thread_cond_timedwait() on Win32 seem to have a
mutex problem.
There's a race condition there. Search the mail list archives -- I
posted a patch a couple of weeks ago. However, I haven't committed it
yet because there's still a race there. I'm
about
the reserved range.
Brane
Bill
At 08:01 PM 7/3/2003, Branko ibej wrote:
In include/arch/win32/apr_arch_file_io.h, we have the following definitions:
/* Internal Flags for apr_file_open */
#define APR_OPENINFO 0x4000/* Open without READ or WRITE access */
#define APR_OPENLINK
Ben Collins-Sussman wrote:
Branko ibej [EMAIL PROTECTED] writes:
I think the Win32 bit won't work on directories without changes,
although I think it can be changed so that it does. The Unix
implementation probably will work on dirs unchanged.
Got 5 minutes to fix the win32
Ben Collins-Sussman wrote:
Branko ibej [EMAIL PROTECTED] writes:
This interface looks sane, and I can cobble up a Windows implementation
in two eyeblinks. As for the patch itself: utimes() is a BSDism and may
not be available on all systems. The Unix implementation needs to check
Cliff Woolley wrote:
On Tue, 8 Jul 2003, [UTF-8] Branko ?^Libej wrote:
on those defines, giving utimes (which has the more precise interface)
priority; e.g.,
#if HAVE_UTIMES
...use utimes...
#elif HAVE_UTIME
IIRC, that should be:
#ifdef HAVE_UTIMES
...use utimes...
#elif
Ben Collins-Sussman wrote:
[EMAIL PROTECTED] writes:
sussman 2003/07/07 15:44:11
Log:
New apr_file_mtime_set() API, implemented in unix and win32.
Patches from Branko Cibej (brane) and Matt Kraai [EMAIL PROTECTED].
So can this API be renamed to apr_path_mtime_set()? Can it
In include/arch/win32/apr_arch_file_io.h, we have the following definitions:
/* Internal Flags for apr_file_open */
#define APR_OPENINFO 0x4000/* Open without READ or WRITE access */
#define APR_OPENLINK 0x2000/* Open a link itself, if supported */
#define APR_READCONTROL 0x1000
I wrote:
This interface looks sane, and I can cobble up a Windows implementation
in two eyeblinks.
And here it is, including tests.
Index: include/apr_file_io.h
===
RCS file: /home/cvs/apr/include/apr_file_io.h,v
retrieving
Cliff Woolley wrote:
On Fri, 4 Jul 2003, [UTF-8] Branko ?^Libej wrote:
/* Internal Flags for apr_file_open */
-#define APR_OPENINFO 0x4000/* Open without READ or WRITE access */
-#define APR_OPENLINK 0x2000/* Open a link itself, if supported */
-#define APR_READCONTROL
Cliff Woolley wrote:
On Wed, 2 Jul 2003, Ben Collins-Sussman wrote:
Subversion is already using apr_stat() to read the mtime of a file.
But now we'd like to be able to *write* timestamps as well.
Has this conversation been had before?
I did some digging on marc.theaimsgroup and found
Branko ibej wrote:
I've been trying to use the APR condition variables on Win32, and the
dam' things kept deadlocking on me whatever I did. So, out of sheer
desperation, I took a look at the implementation... well, let's say that
I was awed by the number of bugs and race conditions I found
I've been trying to use the APR condition variables on Win32, and the
dam' things kept deadlocking on me whatever I did. So, out of sheer
desperation, I took a look at the implementation... well, let's say that
I was awed by the number of bugs and race conditions I found in there. :-)
Anyway: I
Sander Striker wrote:
Madhu,
Can we please end this thread? I think we had this discussion a year
ago on the exact same topic. The outcome of these discussions have
consistently been: outputting error messages to the user is the
responsibility of the application using the library, not of the
William A. Rowe, Jr. wrote:
I don't remember discussion of this on [EMAIL PROTECTED] Work/life/family
have been insane, so I could have missed it.
There wasn't one, at least not recently. I simply followed the design
that was there, adding another flag.
One of the 'good things' (tm) of APR is
Sander Striker wrote:
From: Toby Knudsen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 20, 2003 11:48 PM
I'm leaving town shortly, hope this tip was sufficient. Toby
/bin/ksh /home/alameda/tknudsen/subversion-0.23.0/apr/libtool --silent
--mode=compile
Justin Erenkrantz wrote:
--On Wednesday, April 23, 2003 2:26 PM -0400 Ian Gough
[EMAIL PROTECTED] wrote:
The problem seems to be that the apr-iconv configure script is expecting
libtool 1.3 (looking for ltconfig) but these platforms use libtool and
glibtool 1.4.2, which does not have
Stas Bekman wrote:
Hmm, now I see why apr_generate_random_bytes is not exported on AIX.
For some reason I was checking apr.exp on linux and thought it was
just a bug in older apr versions that apr_generate_random_bytes wasn't
exported. my bad. So we have:
#if APR_HAS_RANDOM
...
Stas Bekman wrote:
Branko ibej wrote:
Yup. There's no apr_fork on Windows, for instance.
mod_perl's APR Perl API doesn't provides a glue for this one, because
perl already provides fork() which works on all platforms, including
win32.
Uh huh. Yes, perl's fork() works on Win32, if work
[EMAIL PROTECTED] wrote:
brane 2003/03/18 15:10:15
Modified:include apr.hw apr.hnw apr.h.in
.configure.in CHANGES
Log:
Define a printf format and format length for apr_uint64_t.
Also define APR_INT64_T_FMT_LEN on Windows and Netware; Unix already
Mladen Turk wrote:
Hi,
The patch enables building apr-iconv with the selected set of
prelinked modules. If the requested module is not found as prelinked,
then the existing mechanism (apr_dso_*) is used.
Right now the selected module list is static, so the next step would
be to make that
[EMAIL PROTECTED] wrote:
wrowe 2003/03/10 16:13:29
Modified:buildmodules.mk.win
Log:
We no longer want or need /debugtype:both and we've discovered that
/pdbtype:sept is harmful (it assures that we don't get locals and other
type information in the final .pdb
William A. Rowe, Jr. wrote:
At 06:43 PM 3/10/2003, Branko ibej wrote:
However, I noticed that the install target copies both *.pdb and
*_src.pdb. Wasn't another patch of yours supposed to address this?
You will probably have to wipe out the apr-iconv/Lib[D|R]/iconv and
apr-iconv
Mladen Turk wrote:
-Original Message-
From: Branko Cibej [mailto:[EMAIL PROTECTED]
Sent: 11. oujak 2003 1:40
To: [EMAIL PROTECTED]
Cc: dev@apr.apache.org
Subject: Re: [PATCH] apr-iconv: enable prelinked modules
Mladen, most of this patch are whitespace-only changes. That
Ben Collins-Sussman wrote:
Joe Orton [EMAIL PROTECTED] writes:
Sander says there was a long thread about this, about how people
wanted strong random, but now we're stuck with a situation where
apr_uuid_get() can block indefinitely... :-(
Workarounds are:
1. configure
Hi Bill,
If you're removing .dbg support, shouldn't you do it for the apr-iconv
modules, too?
--- modules.mk.win.~1.12.~ 2003-03-02 21:41:47.0 +0100
+++ modules.mk.win 2003-03-10 23:12:28.0 +0100
@@ -20,7 +20,7 @@
API_LIB_PFX = $(API_SOURCE)\Release\lib
CFG_CFLAGS =
O.K., I've had a chance to test this myself; it seems to do the right
thing, so I committed this patch.
Volodya, can you confirm that your svn log problem goes away with HEAD
of APR?
Branko ibej wrote:
Hi Bill,
I think this patch is another candidate for 0.9.2 -- or at least for
httpd-2.0.45
and passing that list file to link (just as we do for
libapriconv.dll and other modules.) Should be simple enough, I'll get
to it in just a bit.
Bill
At 10:21 AM 3/7/2003, Branko ibej wrote:
This would get a big +1 from me. If I understand correctly, it would
also make the size of statically
William A. Rowe, Jr. wrote:
I get one failed test in File Info on Mac OS/X (10.1.5) ...
test_buffered_write_size: assert failed
and then one in Thread Locks:
test_thread_rwlock: rwlock_create not implemented on this platform.
???
The first one looks like a side effect of a broken test (the
Jeff Trawick wrote:
William A. Rowe, Jr. wrote:
Wondering how others feel about the feedback below, should we simply
disable threads in APR by default for HPUX 11.0?
I think it is best to disable threads in this situation until we can
address other configure problems (namely, the fact
, then check that HAVE_LANGINFO_H, HAVE_NL_LANGINFO and
HAVE_CODESET are mentioned in apr_private.h.
Sorry I didn't notice this before.
Branko ibej wrote:
Vladimir Prus wrote:
Branko ibej wrote:
Can you look into your apr.h and apr_private.h and see if those
constants are defined in one
William A. Rowe, Jr. wrote:
Someone pointed out that we eat \r's in apr_file_gets() ... now if we
respected the BINARY flag to open that might not be as much of
a problem - but it's deeper than that...
We also don't reassemble \r\n pairs in apr_file_puts() either, which
means any file that goes
Justin Erenkrantz wrote:
--On Tuesday, February 18, 2003 10:13 AM +0100 Damir Dezeljin
[EMAIL PROTECTED] wrote:
Is there a way to get a PID of the current process? I checked the
docs, however I didn't find a function that fit my needs (hehe ...
maybe I missed something ;) ).
You can call
Hmm, looking at our apr_proc_t, I see we _also_ use plain pid_t in there
(and define it in apr.h on platforms that don't have it). This explains
why we don't have an apr_os_proc_get -- users will simple use the pid
member from apr_proc_t. But we don't have one of those in apr_proc_t at
all, which
Branko ibej wrote:
Hmm, looking at our apr_proc_t, I see we _also_ use plain pid_t in there
(and define it in apr.h on platforms that don't have it). This explains
why we don't have an apr_os_proc_get -- users will simple use the pid
member from apr_proc_t. But we don't have one of those
Eeek
William A. Rowe, Jr. wrote:
What say we? Does this sound like something worth researching? Allen,
Brane and fellow Win32 hackers, should I proceed to figure out how to
structure such a binaries and symbols resource after I finish the
apr 0.9.2 and httpd 2.0.45 releases? Of course I will set
[EMAIL PROTECTED] wrote:
brane 2003/02/16 19:47:11
Modified:test testall.c test_apr.h Makefile.win Makefile.in
misc/unix Makefile.in
.libapr.dsp configure.in apr.dsp CHANGES
Added: test testenv.c
misc/win32 env.c
Brian Havard wrote:
As it stands, on OS/2 I get:
testall -v testenv
Partial APR Tests:
Environment: ..N
3 tests run: 2 passed, 0 failed, 1 not implemented.
Not Implemented tests in Environment:
1) test_delenv: apr_env_delete not implemented on this platform
Branko ibej wrote:
Branko ibej wrote:
I'll move those protos to apr_private.h now.
Hm, no I won't... somehow, I was under the impression that apr_private.h
wasn't arch-specific. Duh.
Would anyone object if I added a file include/arch/apr_private_common.h
for private stuff that's
[EMAIL PROTECTED] wrote:
trawick 2003/02/13 05:24:48
Modified:file_io/unix filepath.c filepath_util.c
include/arch/unix apr_arch_file_io.h
Log:
get the prototypes for these functions in the right place
so they actually do some good
filepath_util.c:70:
Cliff Woolley wrote:
On Fri, 14 Feb 2003, [UTF-8] Branko ibej wrote:
Excuse me? your compiler is broken. A function definition is a
prototype, so you don't need an extra prototype in this case. But I
agree that the prototypse should live in a better place.
gcc -Wstrict-prototypes
Branko ibej wrote:
I'll move those protos to apr_private.h now.
Hm, no I won't... somehow, I was under the impression that apr_private.h
wasn't arch-specific. Duh.
Would anyone object if I added a file include/arch/apr_private_common.h
for private stuff that's not architecture-specific? I
[EMAIL PROTECTED] wrote:
brane 2003/02/12 12:20:56
Modified:test testall.dsp testall.c test_apr.h aprtest.dsp
Makefile.win Makefile.in
include apr_pools.h apr_file_info.h
file_io/win32 filepath.c
file_io/unix
[EMAIL PROTECTED] wrote:
brane 2003/02/12 12:23:08
Modified:include apr_pools.h
Log:
Revert bogus commit of revision 1.100.
Revision ChangesPath
1.101 +0 -3 apr/include/apr_pools.h
Index: apr_pools.h
Joe Orton wrote:
On Sat, Feb 08, 2003 at 02:21:28AM +0100, Branko ibej wrote:
Joe Orton wrote:
It does indeed, is this the kind of fix you were thinking of?
I expect that change would avoid the problem, yes. (In fact, in
Subversion, I did an explicit fluxh befode calling
Branko ibej wrote:
William A. Rowe, Jr. wrote:
Let's drop the 'env' concept - this is really useful overall.
And please be careful to strip quotes from around elements, and add
quotes (or on unix, backslash escape) the seperator element (e.g. colon
or semicolon.)
Sure. I think we
Joe Orton wrote:
On Tue, Feb 11, 2003 at 06:41:36PM +0100, Branko ibej wrote:
Joe Orton wrote:
On Sat, Feb 08, 2003 at 02:21:28AM +0100, Branko ibej wrote:
I expect that change would avoid the problem, yes. (In fact, in
Subversion, I did an explicit fluxh befode calling
Just a side note here; although I haven't the faintest idea about the
intricacies of dynamic loading on HP-UX, I _do_ know that in some
situations, even plain C code needs constructor-like initialization when
a shared library is loaded. This leads me to guess that BIND_NOSTART
might be bad even
Joe Orton wrote:
On Mon, Feb 03, 2003 at 11:51:56PM -, Branko ibej wrote:
brane 2003/02/03 15:51:56
Modified:test testfileinfo.c
Log:
Added a new test to check the behaviour of apr_file_info_get in
combination with buffered writes. At the moment, this test
I'd like to propose a new function in the apr_filepath module, to be
added for 0.9.2 and/or httpd-2.0.45:
/**
* Split a search path defined in an environment variable (e.g., @c $PATH)
* into separate components
* @ingroup apr_filepath
* @param pathelts the returned components of the search
William A. Rowe, Jr. wrote:
++1 if we can go with
APR_DECLARE(apr_status_t) apr_filepath_list_split(
apr_array_header_t **pathelts, const char *liststr, apr_pool_t *p);
APR_DECLARE(apr_status_t) apr_filepath_list_merge(
char **liststr, apr_array_header_t *pathelts, apr_pool_t *p);
I
Justin Erenkrantz wrote:
--On Tuesday, February 4, 2003 2:09 PM + Thom May
[EMAIL PROTECTED] wrote:
builds/rules.mk is installed so that's not a problem.
Um, no. It's not.
httpd happens to install *its* rules.mk. But, APR doesn't. -- justin
Which means this change is wrong,
[EMAIL PROTECTED] wrote:
+ * @remark The only reason that the apr_file_open_std* functions exist
+ * is that you may not always have a stderr/out/in on Windows.
Huh? I thought the reason these functions exist is that otherwise you'd
have no portable way of getting a standard i/o handle that
[EMAIL PROTECTED] wrote:
brane 2003/01/22 17:04:09
Modified:lib iconv_module.c iconv.h
include apr_iconv.h
.configure.in
Log:
A search path for conversion modules can now be defined in the
APR_ICONV_PATH environment variable.
*
Eric Gillespie wrote:
[snip]
It may be as simple as changing APR_STATUS_IS_CHILD_NOTDONE, in
which case apr_proc_wait doesn't need to change at all. But i am
not sure that is the solution. No matter what, svn_io_run_cmd
will need to change so that it repeats the apr_proc_wait call as
necessary
Cliff Woolley wrote:
On 23 Jan 2003 [EMAIL PROTECTED] wrote:
{
char buffer[APR_PATH_MAX];
+apr_pool_t *subpool;
+apr_status_t status;
char *ptr;
+status = apr_pool_create(subpool, ctx);
+if (status)
+return status;
+
Justin Erenkrantz wrote:
--On Tuesday, January 21, 2003 8:27 PM + [EMAIL PROTECTED] wrote:
@@ -145,7 +145,7 @@
* @param inputLen The length of the next message block
*/
APU_DECLARE(apr_status_t) apr_md5_update(apr_md5_ctx_t *context,
-
[EMAIL PROTECTED] wrote:
wrowe 2003/01/13 09:57:47
Modified:include apr.hw apr.hnw
Log:
Catch up on some new apr.h.in flags for consistency.
Brad, please correct the netware 64 bit flag, if you have some macro
to test on that platform.
Revision ChangesPath
William A. Rowe, Jr. wrote:
For something completely different, once this is released, we are stuck
with the api...
#define APR_FILEPATH_ENCODING_UNKNOWN 0
#define APR_FILEPATH_ENCODING_LOCALE 1
#define APR_FILEPATH_ENCODING_UTF8 2
APR_DECLARE(apr_status_t) apr_filepath_encoding(int
Greg Stein wrote:
On Thu, Jan 09, 2003 at 10:10:11PM -, [EMAIL PROTECTED] wrote:
brane 2003/01/09 14:10:11
Modified:ces _tbl_simple.c
Log:
Use a cast to ucs2_t to slence two instances of the following MSVC warning:
warning C4761: integral size mismatch in
Mladen Turk wrote:
Hi,
The patch fixes apr-iconv with iconv library (tested with libiconv-1.8).
If you want us to consider your patches, you'll have to provide quite a
bit more information about what the patch is for, and what problem it
fixes. I don't understand this one at all. What does
Damir Dezeljin wrote:
Sorry ... I forgot one thing:
- in apr_queue.h a line containing '#include apu.h' should be added.
Sorry.
No problem; but next time, just send another patch. It's easier to apply
a whole patch than to apply a partial one, then fix things by hand.
Of course, it's even
David Reid wrote:
Yeah nice thought but it's been vetoed by quite a few folks. You do read the
same list I do don't you? :)
Sorry? I haven't seen a single veto. All I've seen is some (admittedly
heated) discussion, and no reply yet from Dirk-Willem (who seems to
oppose this addition the most)
Damir Dezeljin wrote:
Hi.
Can someone pleas explain me how to add apr_queue to the library on
Windows?
I'm using VS.NET . I open 'aprutil.dsw' in apr-util dir. Choose convert
all project files to VS 7 format (BTW: Is of any use if I send those 'new'
project files to the list - e.g. to add them
William A. Rowe, Jr. wrote:
At 11:48 AM 12/18/2002, William A. Rowe, Jr. wrote:
At 08:14 AM 12/18/2002, Philip Martin wrote:
This is for dir.c version 1.71 with the patch reverted. The
Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
it passes APR_FINFO_TYPE |
Philip Martin wrote:
Philip Martin [EMAIL PROTECTED] writes:
Eeek!
I've just upgraded to apache/apr/apr-util to HEAD and now I can
reproduce this.
$ svnadmin create repo
$ svn mkdir file://`pwd`/repo/foo
$ svn co file://`pwd`/repo wc
$ svn up wc
William A. Rowe, Jr. wrote:
I'm sorry... this patch dir not come through to [EMAIL PROTECTED] for me today
(although I watched for it...) but it's simply WRONG.
At 07:04 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 -
David Reid wrote:
Actually my memory is that we don't any form of agreement on how this should
be implemented or even what problem the discussion was trying to solve -
that's why I haven't written anything yet. I was all set to write the code
but the discussion and feeling expressed mean I won't
William A. Rowe, Jr. wrote:
At 06:49 AM 12/12/2002, Jeff Trawick wrote:
[EMAIL PROTECTED] writes:
wrowe 2002/12/11 23:01:52
Modified:file_io/unix filestat.c
Log:
switch {case} and default: are probably better for handling this case.
Is anyone aware of a platform
Dirk-Willem van Gulik wrote:
On 9 Dec 2002 [EMAIL PROTECTED] wrote:
This *is* a portability question.
Well this is the crux- I think that this going further than abstracting
what the OS offer; but trying to put a layer on what a specific machine
offers or a specific operations
Sander Striker wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 07 December 2002 07:37
Bah, bah, bah!
Second time this week this happens to me. Did I mention I'd
like a web interface for moderation?
Again, my apologies for letting this through.
William A. Rowe, Jr. wrote:
Greg,
if there is a way to plug in code into apr, apr-util, httpd, or any other
ASF project after the fact, then I'm +1 on choices (GNU? MS? Sun?
Who cares???)
However, if we choose to 'distribute' code, e.g. binary builds, and those
would (by virtue of our choices)
David Reid wrote:
+1 on fixing both.
Same here.
--
Brane ibej [EMAIL PROTECTED] http://www.xbc.nu/brane/
Aaron Bannert wrote:
+if ( (any 0) || (neg (val acc || (val -= c) acc))
Isn't that one of those short-circuits that causes bad side-effects
under different circumstances? I have a feeling that it is not
well defined if the -= operation is always performed or not, but
I could be
Brian Pane wrote:
William A. Rowe, Jr. wrote:
Ultimately, we must be able to roundtrip from a stat() into a utime()
style call without loosing the old value... at least down to the usec.
Many systems will track file times down to the msec, at a minimum.
Doesn't Posix require these fields to be in
Greg Stein wrote:
And that 0.9.0 is going to be whatever is in APR today. If somebody wants
their darned pet feature in 1.0, then they can get it code before that date.
But I want something *versioned* *today*. SVN users are dyin' cuz we can't
point people at a specific APR release. The best we
[EMAIL PROTECTED] wrote:
striker 2002/08/12 15:02:18
Modified:memory/unix apr_pools.c
Log:
Fix pools to play nice with gcc bounds checking.
Submitted by: Blair Zajac [EMAIL PROTECTED]
Revision ChangesPath
1.184 +5 -9 apr/memory/unix/apr_pools.c
This commit adds
Branko ibej wrote:
William A. Rowe, Jr. wrote:
Branko,
we did NOT mean to build a dynamic libapriconv.dll...
...there is no reason not to compile this module static into libaprutil.
Why not? I can imagine people using apr-iconv, but not apr-util.
I'd rather be consistent with the other APR libs
[EMAIL PROTECTED] wrote:
wsanchez2002/07/24 13:29:38
Modified:.CHANGES configure.in
include apr.h.in apr_strings.h
strings apr_strings.c
Log:
Added apr_strtoll() and apr_atoll() to strings lib.
Submitted by: Shantonu Sen [EMAIL PROTECTED]
You
Argh, I borked the dev@ address ...
Original Message
Subject: Re: [PATCH] apr-iconv Windows build tweak (fix?)
Date: Tue, 23 Jul 2002 02:21:32 +0200
From: Branko ibej [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], William A. Rowe, Jr. [EMAIL PROTECTED]
References
William A. Rowe, Jr. wrote:
Before we consider this patch, there is a deeper question.
Will we support MULTIPLE paths? If so we should consider a given
filepath as an argument to the function. I'm thinking unix or NFS mounts
here, not really win32 filesystems since NT is utf-8 and others are
Justin Erenkrantz wrote:
On Fri, Jul 19, 2002 at 03:28:04PM -0500, Ben Collins-Sussman wrote:
So this patch just adds -liconv to the main set of $APRUTIL_LIBS.
Don't ask me how many hours it took me to figure this out. :-(
Is there a better way to do this?
Index: apu-iconv.m4
Branko ibej wrote:
Probably should check for the libc iconv first, and have_iconv must
always have a value; so tis would become:
AC_CHECK_FUNCS(iconv, [ have_iconv=1 ], [
AC_CHECK_LIB(iconv, iconv, [
APR_ADDTO(APRUTIL_EXPORT_LIBS,[-liconv])
APR_ADDTO(APRUTIL_LIBS,[-liconv])
have_iconv
Karl Fogel wrote:
Translating that to APR and the iconv case, I'd suggest, for Unix:
1. Look into some standard place for the apr-iconv sources. If
they're there, use them.
2. Otherwise, check for --with-iconv=/path, and use the iconv
installed there (this could be any iconv package,
1 - 100 of 159 matches
Mail list logo
