From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Tuesday, June 19, 2001 7:57 PM
> On Tue, 19 Jun 2001, Roy T. Fielding wrote:
>
> > On Tue, Jun 19, 2001 at 08:30:13PM -0400, Cliff Woolley wrote:
> > > In the following lines from readwrite.c line 90, should the if()
> > > conditional clause really
From: "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]>
Sent: Wednesday, June 20, 2001 8:55 AM
> > You miss my point. We at _least_ need to return a "Windows Acceptable Pipe
> > Name", instead
> > of some /PIPE/pluming style name.
>
> it is *important* that NT-style conventions are followed.
From: "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 7:35 AM
> thanks bill!
>
> recommendation. use the actual expected format for pipename:
> pass in "\\.\\PIPE\pipename" _not_ "pipename" and have it
> hidden / constructed by apr.
APR is here to make folks cr
From: "Luke Kenneth Casson Leighton" <[EMAIL PROTECTED]>
Sent: Sunday, June 24, 2001 12:05 PM
> my point of the [reducto-ad-juvenile-conclusion] comments
> above were to say, well, if you have the same names, but
> different functionality, why would you want to limit
> the [apr] functionality to
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Wednesday, June 27, 2001 5:17 PM
> rbb observed...
> > [...] whenever an API changes, the module magic number must be bumped.
>
> *should* being the operative word here. Don't see that happening. I
> stoddard01/07/01 08:13:35
>
> Modified:network_io/win32 sendrecv.c
> Log:
> Back out this portion of Bill Rowe's large file support patch. We should
> not
> use the event handle in the apr_file_t to do overlapped i/o on a socket. We
> either need to wait for io completion on
From: "Mladen Turk" <[EMAIL PROTECTED]>
Sent: Tuesday, July 10, 2001 9:41 AM
> Hi all,
> I don't now who is in charge for that particular peace of code, but...
APR doesn't have 'owners' in the sense that 1.3 ports and modules had official
'maintainers', but I'll address most anything on the Win3
From: <[EMAIL PROTECTED]>
Sent: Thursday, July 12, 2001 12:30 PM
> stoddard01/07/12 10:30:16
>
> Modified:threadproc/win32 proc.c
> Log:
> Set the DETACHED_PROCESS creation flag
> * window we are starting in. And we had better redfine our
> * handles for S
Ok, I'm back to fixing all the 64 bit off_t discrepancies in APR/Apache.
Can we basically agree that a "Bucket" can never be bigger than apr_ssize_t?
I've no problems with using apr_off_t for the length of a full Brigades itself.
That means we can split a brigade on any apr_off_t, but would only n
After a respectable lunch at Boudin's, Ryan and I think we have the general
answers
to child handles.
The apr_foo_open/create calls need an APR_INHERIT flag bit to mark resources as
inheritable. This offers two advantages;
1. the app doesn't need to worry about fork/exec cleanups v.s. inherit
visit for a bit.
- Original Message -
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To:
Sent: Friday, July 13, 2001 3:45 PM
Subject: Inherited Handles and APR
> After a respectable lunch at Boudin's, Ryan and I think we have the general
> answers
> to chil
From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Saturday, July 14, 2001 9:21 AM
> On Sat, 14 Jul 2001, Mladen Turk wrote:
>
> > Recenty the guy asked me is it possibile to use the password database
> > created on UNIX using default crypt algorithm on WIN platform.
> > So, here I have a patch tha
es that sound 'saner' to everyone ... using OpenSSL which we will be using
within Apache (and other foos: daemons or clients) anyways?
Bill
- Original Message -----
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To: "Cliff Woolley" <[EMAIL PROTECTED]&g
From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Friday, July 13, 2001 7:10 AM
> > Ok, I'm back to fixing all the 64 bit off_t discrepancies in APR/Apache.
> >
> > Can we basically agree that a "Bucket" can never be bigger than apr_ssize_t?
>
> Is the bucked backed by RAM? If so, then I agree. f
Just to sharpen my knowledge here... if the thread calls fork(), we end up
running the single, calling thread. The other thread's cleanups are tossed
unless they are still decended from the parent pool. This would be badness.
So, if I'm not mistaken, we cannot introduce thread-pools that aren't
From: <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 11:13 AM
>
> I believe that the problem is that the threaded code is creating the
> pool, and not advertising it to the thread itself. This is an easy thing
> to fix. I do not agree that every APR app that uses threads should have
> to creat
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 12:00 PM
> On Tue, Jul 17, 2001 at 11:26:55AM -0500, William A. Rowe, Jr. wrote:
> > But _unless_ they remain rooted to the top level pool, in
> > apr_process_create
> > they be
From: "dean gaudet" <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 6:15 PM
> if you assume that you want some form of notification, but you want to
> leave it unspecified because you're not sure what each apr thread will be
> used for, then you can make a somewhat generic "kill off other thread
From: "Aaron Bannert" <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 6:41 PM
> [snip]
> > > that would be registered in the "parent" thread's pool -- and would only
> > > be invoked by the "parent" thread.
> > >
> > > pools let you do this, you don't need the mutexes for it, you just have to
>
From: "dean gaudet" <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 7:18 PM
> i object... reasons found in a message i just sent to apr-dev (at least i
> don't think it went to new-httpd).
And this will be my last post on the topic to new-httpd as well... if folks want
the dirty internals, plea
From: "dean gaudet" <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 7:14 PM
> On Fri, 13 Jul 2001, William A. Rowe, Jr. wrote:
>
> > After a respectable lunch at Boudin's, Ryan and I think we have the general
> > answers
> > to child handles.
From: "dean gaudet" <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 7:52 PM
> On Tue, 17 Jul 2001, William A. Rowe, Jr. wrote:
>
> > We agree. APR_INHERIT is the 'option', APR_NON_INHERIT is a zero (usual
> > case) value.
>
> my complain
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2001 10:01 AM
> On Wed, Jul 18, 2001 at 01:52:54PM +0200, Luke Kenneth Casson Leighton wrote:
>
> > also, what happens if the child sms is *already part of the parent*?
> >
> > can you guarantee that the registration and des
From: <[EMAIL PROTECTED]>
Cc:
Subject: Re: [PATCH] Fix apr_thread_exit(), change apr_thread_start_t, etc...
> Please post patches in-line, because it makes it MUCH easier to reply
> to them and make useful comments.
I believe the rule is simply attach in text/plain. Some mail agents are for
sh
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2001 10:27 AM
> And enforcing that the 'allocation' pool is either top-level itself, or a
> descendant of the 'scope' pool, assures that the cleanups will unwind
> properly f
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2001 11:52 AM
> [ Not sure if you meant to send this on-list or not. ]
I meant to... so here it is...
> On Wed, Jul 18, 2001 at 11:25:54AM -0500, William A. Rowe, Jr. wrote:
> > I think you hav
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2001 11:23 AM
> [ Dropping tomcat-dev and adding [EMAIL PROTECTED] ]
>
> On Wed, Jul 18, 2001 at 05:10:43PM +0100, Pier P. Fumagalli wrote:
> > Justin Erenkrantz at [EMAIL PROTECTED] wrote:
> >
> > > On Wed, Jul 18, 2001 at
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Thursday, July 19, 2001 1:06 PM
> I wouldn't recommend using the threaded code at all because we are still
> doing a per-process allocation mutex which causes threaded to become
> useless. When that is changed (i.e. we enable SMS), I think that
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Thursday, July 19, 2001 1:39 PM
> From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
> Sent: Thursday, July 19, 2001 1:06 PM
>
>
> > I wouldn't recommend using the threaded code at all
Sounds doable. I'd pass the 'desired' as an arg to apr_dbm_create rather
than a half-dozen new fn's though.
- Original Message -
From: "Ian Holsman" <[EMAIL PROTECTED]>
To:
Sent: Thursday, July 19, 2001 2:54 PM
Subject: Apr_dbm
> I was wondering if anyone had any reason why we couldn'
From: "Dale Ghent" <[EMAIL PROTECTED]>
Sent: Friday, July 20, 2001 1:04 PM
> This should probably be addressed. I started 2.0.21 up last night, and one
> of my log files has grown to be >2GB (my apache 1.3.20 knows largefiles)
> and httpd silently died when it attempted to open() the access_log a
From: "Aaron Bannert" <[EMAIL PROTECTED]>
Sent: Saturday, July 21, 2001 1:52 AM
> [Still trying to get the hang of this whole patch-submission/OSS project/
> mailing list thing :) -- this patch should be *much* smaller]
Much improved :)
> Update to APR thread API to explicitly pass the apr_thre
From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Saturday, July 21, 2001 11:29 AM
> On Saturday 21 July 2001 09:16, Justin Erenkrantz wrote:
> > On Sat, Jul 21, 2001 at 08:07:50AM -0400, Jeff Trawick wrote:
> > > Here is my copy of the program. It seems to work properly whether or
> > > not apr_file
From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Saturday, July 21, 2001 11:09 AM
> > > Changed the worker routine's signature to take a single parameter:
> > > apr_thread_param_t, which contains the opaque data and the apr_thread_t.
> >
> > Can we simply hide the details, and use our own _thread_mai
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Monday, July 23, 2001 11:23 AM
;dev
> apr_pipe_create() sets apr_file_t->fname to
>
> apr_pstrdup(p, "PIPE")
>
> (why not just "")
>
> Why not leave it NULL? I don't see any code to retrieve it.
> Presumably if somebody is looking at the struc
From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Saturday, July 21, 2001 11:55 AM
I spoke with rbb who is traveling, and finally persuaded him that exactly two
thread arguments are reasonable, one is the single "apr's private and otherwise
useful data", a private apr_thread_info_t, which the user can
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Monday, July 23, 2001 12:07 PM
> "William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
>
> > From: "Jeff Trawick" <[EMAIL PROTECTED]>
> > Sent: Monday, July 23, 2001 11:23
From: "Aaron Bannert" <[EMAIL PROTECTED]>
Sent: Monday, July 23, 2001 12:24 PM
> On Mon, Jul 23, 2001 at 11:53:39AM -0500, William A. Rowe, Jr. wrote:
> > From: "Ryan Bloom" <[EMAIL PROTECTED]>
> > Sent: Saturday, July 21, 2001 11:55 AM
> >
From: "Aaron Bannert" <[EMAIL PROTECTED]>
Sent: Monday, July 23, 2001 12:24 PM
> On Mon, Jul 23, 2001 at 11:53:39AM -0500, William A. Rowe, Jr. wrote:
> > From: "Ryan Bloom" <[EMAIL PROTECTED]>
> > Sent: Saturday, July 21, 2001 11:55 AM
> >
The Crux of the problem is in the disconnected way the entire cleanup API
is working.
apr_pool_child_cleanup_kill() is pure BS, since it also kills the plain cleanup.
Nobody uses it, so I'm killing the function.
I'll replace it with a apr_pool_child_cleanup_set() that allows you to replace
the or
Anyone with a 'private' numeric network (e.g. .theoffice.7 ) is a dufus, +1
in theory :)
Bill
- Original Message -
From: "Doug MacEachern" <[EMAIL PROTECTED]>
To:
Sent: Monday, July 23, 2001 5:02 PM
Subject: apr_sockaddr_info_get + server startup time
> with a small number of vhosts
From: "Aaron Bannert" <[EMAIL PROTECTED]>
Sent: Monday, July 23, 2001 5:44 PM
> Quick implementation question. I've got this working as described above
> under UNIX, but I'd like to do this correctly and I've run into a small
> issue.
>
> I'm not seeing a reason for having apr_thread_info_t in t
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Monday, July 23, 2001 5:40 PM
> On Mon, Jul 23, 2001 at 10:19:13PM -, [EMAIL PROTECTED] wrote:
> > wrowe 01/07/23 15:19:13
> >
> > Modified:include apr_pools.h
> >include/arch/unix inherit.h
> >m
> wrowe 01/07/23 15:19:13
>
> Modified:include apr_pools.h
>include/arch/unix inherit.h
>memory/unix apr_pools.c
> Log:
> Depricated the broken apr_pool_child_cleanup_kill, and added the new
> apr_pool_child_cleanup_set() to replace the regist
> > wrowe 01/07/23 15:19:13
> >
> > Modified:include apr_pools.h
> >include/arch/unix inherit.h
> >memory/unix apr_pools.c
> > Log:
> > Depricated the broken apr_pool_child_cleanup_kill, and added the new
> > apr_pool_child_cleanup_set() to re
Sorry. Just committed the 'right' patch to toggle the child cleanup
between a null cleanup and the 'real' cleanup.
Let me know of any problems.
Bill
- Original Message -
From: "Aaron Bannert" <[EMAIL PROTECTED]>
To:
Sent: Monday, July 23, 2001 6:55 PM
Subject: [PATCH] typos in arch/un
Outch, I tried :( Thanks for straightening.
Bill
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 24, 2001 7:36 AM
Subject: cvs commit: apr/file_io/os2 open.c
> bjh 01/07/24 05:36:57
>
> Modified:file_io/os2 open.c
> Log:
>
From: <[EMAIL PROTECTED]>
Sent: Tuesday, July 24, 2001 5:53 AM
> dreid 01/07/24 03:53:06
>
> Modified:threadproc/beos thread.c
> Log:
> dummy_func != dummy_worker
>
> I'm sorry, but this change seems crazy to me. Know I haven't been following
> the discussion that closely
The upshot of this patch: Brigades deal with apr_off_t bytes, but a single
bucket never
deals with more than apr_size_t bytes :)
From: "Roy T. Fielding" <[EMAIL PROTECTED]>
Sent: Thursday, July 12, 2001 11:54 PM
> Bill wrote some time ago;
>
> > This means a huge file would need to be split by
From: "Aaron Bannert" <[EMAIL PROTECTED]>
Sent: Tuesday, July 24, 2001 12:35 PM
> Will the experts on each non- or semi-POSIX system please comment on if
> these concepts are implementable? At this point I'm ignoring issues like
> PROCESS_SHARED vs PROCESS_PRIVATE, since I think at first simply pr
A funny thing happened on the way to normalizing and optimizing both
mod_include's static generate_size() and mod_autoindexes' ap_send_size().
My (simple !?!) goals were to accept 64 bit offsets and clean up the floating
point arithmetic.
I'd argue the following numbering schema would actually ma
From: <[EMAIL PROTECTED]>
Sent: Wednesday, July 25, 2001 10:33 PM
> jwoolley01/07/25 20:33:21
>
> Modified:file_io/win32 filestat.c
>user/win32 userinfo.c
> Log:
> I did a recursive grep for "#ifdef APR_" and am cleaning up what I found.
> =-)
>
> PS: How did
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Thursday, July 26, 2001 10:13 AM
> On Wed, Jul 25, 2001 at 10:29:35AM -0700, Brian Pane wrote:
> > Lately the httpd won't build when configured with
> > --enable-sms, because of unresolvable references to
> > apr_pool_child_cleanup_set in file_i
Brad... you know better than submit context diffs :) Can you send us
the diff -u3 ?
Please note, if you have a significant change (except in sendfile, which
is already so fragmented to be completely illegible :) please watch for
the appropriate places to drop a foo/netware/ derivation. For minor
From: "Ben Collins-Sussman" <[EMAIL PROTECTED]>
Sent: Thursday, July 26, 2001 3:42 PM
> I need to get the char *username of the person running the current
> process. I looked in apr_user.h, and see routines for converting
> back-and-forth between apr_uid_t and char *username -- but no routines
>
rv = apr_get_userid(&userid, &groupid, username, p);
if (rv != APR_SUCCESS) {
fprintf(stderr, "apr_get_userid(,,%s,) failed: %s\n",
username,
apr_strerror(rv, msgbuf, sizeof(msgbuf)));
exit(-1);
}
else {
printf("user/group ids
We should really write a preface in the API docs ... when are apr_foo_t's
== not equal :)
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 27, 2001 11:54 AM
Subject: cvs commit: apr/memory/unix apr_sms_threads.c
> trawick 01/07/27 09:54:44
>
From: "Brian Havard" <[EMAIL PROTECTED]>
Sent: Friday, July 27, 2001 11:30 AM
> On Fri, 27 Jul 2001 11:09:55 -0500, William A. Rowe, Jr. wrote:
>
> >It gets you (and I) the apr_thread_pool_get declaration that _used_ to hide
> >within this very same bloc
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Friday, July 27, 2001 12:59 PM
> "William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
>
> > We should really write a preface in the API docs ... when are apr_foo_t's
> > == not equal :)
>
&g
It gets you (and I) the apr_thread_pool_get declaration that _used_ to hide
within this very same block, which was bad mojo.
Bill
- Original Message -
From: "Brian Havard" <[EMAIL PROTECTED]>
To:
Sent: Friday, July 27, 2001 5:41 AM
Subject: Re: cvs commit: apr/include apr_thread_proc.h
From: "Brian Pane" <[EMAIL PROTECTED]>
Sent: Friday, July 27, 2001 2:05 AM
> Justin Erenkrantz wrote:
>
> >Right now, I've got it so that most of the locks are now in libc
> >(aka NIMBY), but the performance still doesn't match pools (by a
> >factor of 2). I'm scratching my head as to why this
apr/test/server.c client.c aren't behaving correctly, we are getting a hard
EOF as soon as the sockets connect. Does anyone on other platforms observe
this?
If anyone wants to play in apr/test on win32, just open the apr/test/aprtest.dsw
workspace and have at it ... you will need to include a pat
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Monday, July 30, 2001 3:15 PM
> On Mon, Jul 30, 2001 at 12:54:18PM -0600, Brad Nicholes wrote:
> > I would like to propose adding the function apr_thread_yield() as part
> > of the threading API's. The reason for this to to
allow applicati
Can this ever fail (and do we care?) or should it actually be a void fn?
Bill
- Original Message -
From: "Brad Nicholes" <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>
Sent: Monday, July 30, 2001 6:05 PM
Subject: [PATCH] New thread API apr_thread_yield()...
This patch adds the API ap
My response below... Brad, what does Netware look like on this?
From: "Aaron Bannert" <[EMAIL PROTECTED]>
Sent: Tuesday, July 31, 2001 2:21 PM
> I've been looking into this over the last few days and although I'm
> totally in favor of adding condition variables to APR, I'm not yet
> convinced th
From: "Aaron Bannert" <[EMAIL PROTECTED]>
Sent: Tuesday, July 31, 2001 2:21 PM
> I've been looking into this over the last few days and although I'm
> totally in favor of adding condition variables to APR, I'm not yet
> convinced that we can properly implement them on non-POSIX platforms
> withou
- Original Message -
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To: "Aaron Bannert" <[EMAIL PROTECTED]>;
Sent: Tuesday, July 31, 2001 3:50 PM
Subject: Re: Conditionals...
> From: "Aaron Bannert" <[EMAIL PROTECTED]>
> Se
That would be most cool :) Please focus this discussion, for the moment, at
the dev@apr.apache.org list instead, till we have something finished to 'share'
with the new-httpd list :)
I certainly expect we would appreciate it, even if its final 'apr-ized' form
looks a bit different than your exi
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Wednesday, August 01, 2001 3:03 PM
> Is anybody gonna be aggravated if I change test apps to exit with
> status zero if they work as expected?
No. (You mean they will work like we would expect?)
I'd be happy to take a look at this, thank you. The implementation as it were
is already in need of some refactoring for 'real life' uses, and Apache's own
directory_walk and a few remaining ap_foo functions needed to be depricated.
This should help.
- Original Message -
From: "Sterling
Pipe 'names' for debugging patch attached.
Three issues,
1. the stack exception code doesn't work on NT. In fact, I doubt it ever
works for
threading. Pulling _just_that_ alone should help debug on threaded
architechtures.
The better solution is to build a 'list of stacks'. The _end symbol
Uhhh... the patch :|
- Original Message -
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To:
Sent: Thursday, August 02, 2001 3:17 PM
Subject: Does anyone want this committed?
> Pipe 'names' for debugging patch attached.
>
> Three issues,i
>
First off - this patch names apr_pool_t allocations (nothing to do with pipes,
sorry for my earlier misnomer.)
From: "Branko Čibej" <[EMAIL PROTECTED]>
Sent: Thursday, August 02, 2001 5:51 PM
> William A. Rowe, Jr. wrote:
>
> >2. I can't figure out how to
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Friday, August 03, 2001 7:28 AM
> I'm happy to create a new APR_INCOMPLETE_CHAR status, hijack the
> current doc for APR_INCOMPLETE, and change Apache/APR as appropriate.
>
> Does APR_INCOMPLETE (for incomplete file status) need to be renamed as
> w
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Friday, August 03, 2001 6:36 AM
> FYI... You should commit all closely related changes at once (e.g.,
> your various implementations of apr_thread_yield()), assuming that you
> had them ready at the same time.
With one discrepancy ... please don't
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Friday, August 03, 2001 12:25 PM
> "William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
>
> > From: "Jeff Trawick" <[EMAIL PROTECTED]>
> > Sent: Friday, August 03, 2001 7:28 AM
&g
From: <[EMAIL PROTECTED]>
Sent: Tuesday, August 07, 2001 9:12 AM
> trawick 01/08/07 07:12:29
>
> Modified:file_io/win32 dir.c
> Log:
> mention some problems with apr_dir_rewind() for Win32
>
> Revision ChangesPath
> 1.58 +6 -0 apr/file_io/win32/dir.c
>
>
When you build with apr.mak, everything should be static.
So when you have sources that depend on static bindings to apr, you need to
/D APR_DECLARE_STATIC, which takes out (with no pain) all of the dynlink
fooness of the .dlls :) See the httpd-2.0 support projects, such as ab.dsp.
Bill
- O
From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Monday, August 13, 2001 3:03 PM
>
> I'm all for a new apr-ldap CVS module / library. But its presence in APRUTIL
> feels very questionable to me.
++1
I've hesitated to speak out of my a$$, for lack of a more tactful way to put it,
but I have huge port
Jon,
can you take a look at the attached bug report, and assure that your patch
handles this case correctly before we apply it today? I'd like to lick all
the bugs, and wanted to be sure that this report is dead as well (on 2.0.)
Bill
- Original Message -
From: "Jon Travis" <[E
[Reply sent to dev@apr.apache.org - where this phase of this discussion belongs.
if you aren't subscribed, it's [EMAIL PROTECTED]
From: "Paul Bayley" <[EMAIL PROTECTED]>
Sent: Tuesday, August 21, 2001 12:15 AM
> >> * Should I modify srclib/apr/include/apr_file_info.h?
> >
> >That will break bin
From: "Martin Kraemer" <[EMAIL PROTECTED]>
Sent: Tuesday, August 21, 2001 1:36 AM
> On Mon, Aug 20, 2001 at 12:34:37AM -0500, William A. Rowe, Jr. wrote:
> > > * What is the difference between mtime and ctime? Also, would anybody
> > > have any use for crea
[forwarded to dev, where the discussion belongs]
- Original Message -
From: "Martin Kraemer" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, August 21, 2001 9:43 AM
Subject: Re: file attribute questions
> On Tue, Aug 21, 2001 at 08:36:33AM +0200, Kraemer, Martin wrote:
> > Luckily there are VER
From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Saturday, August 25, 2001 4:09 PM
> Somebody please explain this commit to me:
>
> ===
> RCS file: /home/cvspublic/apr-util/buckets/apr_buckets_simple.c,v
> retrieving revision 1.29
>
... passes the config parsing with flying colors, even when it's meaningless.
Is there a reason we are allowing unrecognized/unparsed blocks into the config?
I would expect we would want to error out.
I discovered this with my patch, when I forgot
to load the proxy module. We wouldn't accept
From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Sunday, August 26, 2001 4:00 AM
> On Sat, Aug 25, 2001 at 05:09:14PM -0400, Cliff Woolley wrote:
> >...
> > APU_DECLARE_NONSTD(apr_status_t) apr_bucket_simple_split(apr_bucket *a,
> > - apr_off_t
From: "Roy T. Fielding" <[EMAIL PROTECTED]>
Sent: Sunday, August 26, 2001 11:26 PM
> > No. There really aren't many sendfile implementations that allow you to
> > transmit more than an apr_size_t, if you start digging the man pages.
> > Afraid this was a concensus decision make while you were on
Well it was busted. Bad. Reactivated your patch, Jeff, and started
stepping...
The simple test is set your browser language to en and request;
http://www2.rowe-clan.net:8080/error/HTTP_NOT_FOUND.html.var
If you error 406, the seek (APR_CUR, -value) doesn't work correctly.
It got as far as lang
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 8:52 PM
> If you error 506, then we are in the negotation bug (or mod_includes
> anti-recursion bug), and clear of our apr file read/buffered seek
> fooness. This bug is a bigger pita, but a
From: "Jeff Trawick" <[EMAIL PROTECTED]>
Sent: Tuesday, August 28, 2001 6:47 AM
> Brian Pane <[EMAIL PROTECTED]> writes:
>
> > On platforms where neither HAVE_GMTOFF nor HAVE___OFFSET is defined,
> > like Solaris, the function "get_offset" in apr/time/unix/time.c is a
> > bottleneck in time form
From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Tuesday, August 28, 2001 8:57 AM
> On Monday 27 August 2001 23:27, Brian Pane wrote:
>
> > How does this patch look? It does the check only on bucket
> > boundaries, and it pushes out the buffered content if either:
> > * the amount of buffered con
Someone want to verify this is gone? (Email me off-list if you
would like me to close this issue and you don't have bugs access
yourself ;)
http://bugs.apache.org/index.cgi/full/7822
>Environment:
OSF 4.0F, patchkit 4, cc
>Description:
Making all in threadproc/unix
/bin/sh /home/hlx/src/apache/h
Similar issue here
http://bugs.apache.org/private/index.cgi/full/7540
>Environment:
DEC UNIX 4.0g with patch level 1
DEC cc for this OS release.
- Original Message -
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
To:
Sent: Thursday, August 30, 2001 1:55 PM
S
Jeff,
this will become a problem on Win32 as well, and it's pretty fragile.
What if we institute a two-pass clean? Don't eliminate any dependencies on
the
first go, and the distclean target can then mop up the obvious (.mk targets,
generated
.h files, etc.) I think this would be safer, al
From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Friday, August 31, 2001 12:36 PM
On 31 Aug 2001 [EMAIL PROTECTED] wrote:
> bnicholes01/08/31 09:28:06
>
> Added: user/netware userinfo.c groupinfo.c
> Log:
> NetWare user and group info functions
>
> Revision ChangesPath
>
Justin, Ryan,
it seems there are now two interesting rfc822+ Apache apps out there
(pop and mbox) and I was wondering... do either of you already have the
multipart parsing that we could move to apr-util (along with rfc822) to
implement Martin's suggestion of using multipart/alternative (server
> rbb 01/08/31 22:10:23
>
> Modified:include/arch/win32 threadproc.h
>threadproc/win32 thread.c
> Log:
> Implement apr_thread_once for Windows.
>
> +APR_DECLARE(apr_status_t) apr_thread_once(apr_thread_once_t *control,
> +
iven a multipart/alternative document, Martin has
suggested that
we use this new parser, and in the negotation phase choose one body to serve
from
multipart/alternative.
I'll follow your leads in a week or two and see how far I get with this
solution.
Bill
> > On Friday 31 August 2001
> rbb 01/09/04 15:54:58
>
> Modified:file_io/unix dir.c
> Log:
> apr_dir_read (with something like APR_FINFO_TYPE in wanted) will return
> APR_INCOMPLETE if it encounters a broken symlink... bug or feature?
>
> I say bug... the caller can quite happily cope with symlinks,
Josh just came up with what I believe is the best explanation of if and
when to reformat - I think this applies equally well to sources and docs.
I'd added only one caviat - changes to the format should always -preceed-
the patch to the actual code, and there shouldn't be format changes if there
i
1 - 100 of 3471 matches
Mail list logo
