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 ri
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 think)
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, whi
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 ha
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 implementatio
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 kn
[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 Äibe
[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 fixe
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
[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.
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 l
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
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
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, Netw
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
[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
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
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 unc
William A. Rowe, Jr. wrote:
>I don't see any issues with your suggestions below. I'll sanity check
>your commit after you've finished (if you haven't already) :-)
>
It's done already. No external changes, just the values in the win32
apr_arch_file_io.h changed, and I added a note to apr_file_io.h
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
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
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 syste
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_READCO
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 r
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
Manfred Schuh (CESOFT GmbH, Bielefeld) wrote:
>hi,
>
>if I copy a file using apr_file_copy the destination file has the actual
>time as creation time.
>I would have expected the time being the same as the source file as e.g. as
>WIN32 CopyFile does?
>
It doesn't. :-) The creation time of the copy
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.theaimsg
Hm, I found one problem with both my reimplementations, and this problem
existed in the original implementation, too: there's a race at the point
where the associated mutex is released and before the thread starts
waiting for the trigger event. IIRC, POSIX promises this will be atomic.
I'm not sure
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
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 we
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
Jeff Trawick wrote:
> Joe Orton wrote:
>
>> On Thu, May 29, 2003 at 07:38:29AM -0400, Jeff Trawick wrote:
>>
>>> [EMAIL PROTECTED] wrote:
>>>
trawick 2003/05/28 11:24:13
Modified:test testdso.c
Log:
get testdso to work with the vendor's compiler on HP-UX, which
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
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
>>/opt
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 h
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
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
> ...
> APR
[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
>
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:
>>
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
[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
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
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 = /
William A. Rowe, Jr. wrote:
>Brane, I am certain you experienced an anomaly, perhaps a broken
>version of rebase.exe. I say this, having compared the sizes of the
>Apache 2.0.44 distributed iconv tree to the latest *release* build of
>the same. (Or perhaps you were looking at *debug* builds.)
>
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 -
ment. IMHO a sufficient test would be to apply this patch and run
configure, 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 wr
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, th
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 t
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 tha
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 se
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 d
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 s
Cliff Woolley wrote:
>On Tue, 18 Feb 2003, [UTF-8] Branko Äibej wrote:
>
>
>
>>It's fairly portable on most every Unix variant. It just so happens that
>>APR isn't about portability across Unixes, so we really should have
>>wrappers. We have apr_os_t
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 ;) ).
>
>
>
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 p
[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 en
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 a
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
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
[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
[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
> =
[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/
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 ch
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)
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
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 for
[EMAIL PROTECTED] wrote:
>jorton 2003/02/07 04:33:00
>
> Modified:test testfileinfo.c
> Log:
> test_buffered_write_size: Pass TRUNCATE not EXCL to open so test isn't
> guaranteed to fail if run more than once.
>
It's not guaranteed to fail, because it uses the APR_DELONCLOSE flag.
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
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'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 pat
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
[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 tha
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)
>> +
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
>neces
[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.
>
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 Change
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 siz
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
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 do
Justin Erenkrantz wrote:
> --On Monday, December 23, 2002 22:00:45 + Tony Finch
> <[EMAIL PROTECTED]> wrote:
>
>> Gosh, does APR really support machines where int is less than 32 bits?
>
>
> Signed vs. unsigned. -- justin
>
Seriously, apr_size_t is for object sizes, not for element counts. Yo
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'
Damir Dezeljin wrote:
>Sorry for two files (hehe ... its the first time I make a patch and I
>don't know which is the correct format:
>- apr-util_queue.diff (produced by: cvs diff -b -B )
>- apr-util_queue.patch (produced by: cvs diff -b -B -u )
>
Just so that you know for the future: Using -b or
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 ad
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)
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_
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 -00
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
>>../svn/subversion/l
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
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
[EMAIL PROTECTED] wrote:
>I've done more research. Wow, this is ugly. Basically, Windows doesn't
>allow you to open anonymous pipes in a non-blocking mode. That means that
>it is impossible to timeout a pipe read/write. Now for the good news.
>There are two possible solutions.
>
>1) Switch to
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 operati
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
William A. Rowe, Jr. wrote:
>One question - should the target install be bin/iconv or simply iconv?
>
>
Hm, by analogy with modules, it should be just iconv I think.
--
Brane Äibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
William A. Rowe, Jr. wrote:
>At 12:12 PM 11/30/2002, William A. Rowe, Jr. wrote:
>
>
>>Perhaps the simplest thing for httpd users is to modify srclib/CVS/Entries
>>and remove the D/apr[-util/-iconv] lines. This prohibits CVS from
>>drilling down into those directories from httpd or other pr
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)
[EMAIL PROTECTED] wrote:
Fix the existing API before we hit 1.0.
+1. Otherwise we'll just have a mess of _ex functions.
--
Brane Äibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
Kevin Pilch-Bisson wrote:
I don't think that's what the problem is. My perl script which copied stdin
to the log file had the same problem, I wrote the above hook just so that I
could attach to it and see where it was hanging.
Ah! Important information, that. :-)
--
Brane Äibej <[EMAIL PROT
David Reid wrote:
+1 on fixing both.
Same here.
--
Brane Äibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
1 - 100 of 155 matches
Mail list logo
