You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Cliff Woolley <cl...@yahoo.com> on 2001/02/16 20:37:30 UTC
[PATCH] RE: cvs commit: apr-util/buckets apr_buckets_file.c (fwd)
> -----Original Message-----
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> This was just committed to apr_util's bucket code. This should fix the
> mod_include problem (at least it did for me). What was happening, was
> that we read from the file, and converted it into a heap bucket. Then, we
> destroyed the file bucket (free'ing *s at the same time), and then we used
> s->start to create the second file bucket.
It occurred to me while I was at lunch that there's no need to destroy the
shared+file bucket at all if we're going to turn around and create a new one
anyway. All we're missing is an apr_bucket struct to point to the
shared+file bucket data we already have constructed. Doing it this way
removes about two frees and three mallocs and a bunch of unneeded pointer
arithmetic from each file_read() call on non-MMAP platforms. The patch is
attached due to a line wrap munging.
--Cliff
RE: [PATCH] RE: cvs commit: apr-util/buckets apr_buckets_file.c (fwd)
Posted by Cliff Woolley <cl...@yahoo.com>.
> -----Original Message-----
> > say it isn't so... I was starting to think Cliff was cool...
>
> >From Cliff's email:
>
> X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
> Sorry... "it's so" :-)
Oh gee, I'm caught. =-o :-) I was forced to install Outlook (eek) a few weeks
ago for side reasons, my worst nightmare come true. I've cursed it so many
times already that I'm very near dumping it, even if it means going to something
on the command line. I guess my honor as a "cool guy" now depends upon it. ;-]
Hell, even Pine would be better. hehehe
(One of countless complaints: It hides too much important stuff from you, eg the
full MIME text of a message. So I had no way to know what MIME type it was
assigning to attachments, because it just won't tell you. UGGHHHH)
--Cliff
Re: [PATCH] RE: cvs commit: apr-util/buckets apr_buckets_file.c (fwd)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Feb 23, 2001 at 07:26:45AM -0500, Jeff Trawick wrote:
> Greg Stein <gs...@lyra.org> writes:
> > On Sat, Feb 17, 2001 at 03:14:37PM -0500, Cliff Woolley wrote:
> > > > Attachment: YES. But "application/octet-stream": NO. (unless it's binary)
> > >
> > > Sorry about that. I'll do my best to correct this on my end. (I usually
> > > prefer to just inline the darned things to avoid these problems, but my UA
> > > is also bad about wrapping lines, which munges them even worse.)
> >
> > You might be able to configure Windows to recognized ".patch" as text/plain.
> > You could also call the patches foo.patch.txt or something.
>
> say it isn't so... I was starting to think Cliff was cool...
>From Cliff's email:
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Sorry... "it's so" :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] RE: cvs commit: apr-util/buckets apr_buckets_file.c (fwd)
Posted by Jeff Trawick <tr...@bellsouth.net>.
Greg Stein <gs...@lyra.org> writes:
> On Sat, Feb 17, 2001 at 03:14:37PM -0500, Cliff Woolley wrote:
> > >
> > > Attachment: YES. But "application/octet-stream": NO. (unless it's binary)
> >
> > Sorry about that. I'll do my best to correct this on my end. (I usually
> > prefer to just inline the darned things to avoid these problems, but my UA
> > is also bad about wrapping lines, which munges them even worse.)
>
> You might be able to configure Windows to recognized ".patch" as text/plain.
> You could also call the patches foo.patch.txt or something.
say it isn't so... I was starting to think Cliff was cool...
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: [PATCH] RE: cvs commit: apr-util/buckets apr_buckets_file.c (fwd)
Posted by Cliff Woolley <cl...@yahoo.com>.
---Greg Stein said:
> You might be able to configure Windows to recognized ".patch" as text/plain.
That's exactly what I did. I haven't tested it yet, but I will before I submit
another patch via attachment.
> You could also call the patches foo.patch.txt or something.
Yup, that's the fall-back plan.
Thanks,
Cliff
Re: [PATCH] RE: cvs commit: apr-util/buckets apr_buckets_file.c (fwd)
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Feb 17, 2001 at 03:14:37PM -0500, Cliff Woolley wrote:
> > -----Original Message-----
> > [-- Attachment #2: fileread.patch --]
> > [-- Type: application/octet-stream, Encoding: quoted-printable,
> > Size: 1.3K --]
> >
> > Sorry, guys -- pleeeeeeeeeeeeze!!!!!!!!!!!!!!
> >
> > Can you try to configure your MUA's to tag patches (like these) as
> > "text/plain" instead of "application/octet-stream"? It makes life *MUCH*
> > easier for me & others, because we don't need an intermediate "save & run"
> > step to invoke an editor on the patch.
> >
> > Attachment: YES. But "application/octet-stream": NO. (unless it's binary)
>
> Sorry about that. I'll do my best to correct this on my end. (I usually
> prefer to just inline the darned things to avoid these problems, but my UA
> is also bad about wrapping lines, which munges them even worse.)
You might be able to configure Windows to recognized ".patch" as text/plain.
You could also call the patches foo.patch.txt or something.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: [PATCH] RE: cvs commit: apr-util/buckets apr_buckets_file.c (fwd)
Posted by Cliff Woolley <cl...@yahoo.com>.
> -----Original Message-----
> [-- Attachment #2: fileread.patch --]
> [-- Type: application/octet-stream, Encoding: quoted-printable,
> Size: 1.3K --]
>
> Sorry, guys -- pleeeeeeeeeeeeze!!!!!!!!!!!!!!
>
> Can you try to configure your MUA's to tag patches (like these) as
> "text/plain" instead of "application/octet-stream"? It makes life *MUCH*
> easier for me & others, because we don't need an intermediate "save & run"
> step to invoke an editor on the patch.
>
> Attachment: YES. But "application/octet-stream": NO. (unless it's binary)
Sorry about that. I'll do my best to correct this on my end. (I usually
prefer to just inline the darned things to avoid these problems, but my UA
is also bad about wrapping lines, which munges them even worse.)
--Cliff
Re: [PATCH] RE: cvs commit: apr-util/buckets apr_buckets_file.c (fwd)
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Fri, Feb 16, 2001 at 02:37:30PM -0500, Cliff Woolley wrote:
> [...] The patch is
> attached due to a line wrap munging.
>
> --Cliff
>
[-- Attachment #2: fileread.patch --]
[-- Type: application/octet-stream, Encoding: quoted-printable, Size: 1.3K --]
Sorry, guys -- pleeeeeeeeeeeeze!!!!!!!!!!!!!!
Can you try to configure your MUA's to tag patches (like these) as
"text/plain" instead of "application/octet-stream"? It makes life *MUCH*
easier for me & others, because we don't need an intermediate "save & run"
step to invoke an editor on the patch.
Attachment: YES. But "application/octet-stream": NO. (unless it's binary)
Thanks for your understanding,
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: [PATCH] RE: cvs commit: apr-util/buckets apr_buckets_file.c
(fwd)
Posted by rb...@covalent.net.
+1
Ryan
On Fri, 16 Feb 2001, Cliff Woolley wrote:
>
> > -----Original Message-----
> > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > This was just committed to apr_util's bucket code. This should fix the
> > mod_include problem (at least it did for me). What was happening, was
> > that we read from the file, and converted it into a heap bucket. Then, we
> > destroyed the file bucket (free'ing *s at the same time), and then we used
> > s->start to create the second file bucket.
>
> It occurred to me while I was at lunch that there's no need to destroy the
> shared+file bucket at all if we're going to turn around and create a new one
> anyway. All we're missing is an apr_bucket struct to point to the
> shared+file bucket data we already have constructed. Doing it this way
> removes about two frees and three mallocs and a bunch of unneeded pointer
> arithmetic from each file_read() call on non-MMAP platforms. The patch is
> attached due to a line wrap munging.
>
> --Cliff
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] RE: cvs commit: apr-util/buckets apr_buckets_file.c
(fwd)
Posted by rb...@covalent.net.
+1
Ryan
On Fri, 16 Feb 2001, Cliff Woolley wrote:
>
> > -----Original Message-----
> > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > This was just committed to apr_util's bucket code. This should fix the
> > mod_include problem (at least it did for me). What was happening, was
> > that we read from the file, and converted it into a heap bucket. Then, we
> > destroyed the file bucket (free'ing *s at the same time), and then we used
> > s->start to create the second file bucket.
>
> It occurred to me while I was at lunch that there's no need to destroy the
> shared+file bucket at all if we're going to turn around and create a new one
> anyway. All we're missing is an apr_bucket struct to point to the
> shared+file bucket data we already have constructed. Doing it this way
> removes about two frees and three mallocs and a bunch of unneeded pointer
> arithmetic from each file_read() call on non-MMAP platforms. The patch is
> attached due to a line wrap munging.
>
> --Cliff
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------