On 2 Mar 2001, Jeff Trawick wrote:
> [EMAIL PROTECTED] writes:
>
> > rbb 01/03/02 10:27:42
> >
> > Modified:network_io/unix inet_ntop.c
> > Log:
> > need apr_strings for apr_snprintf.
>
> ouch... thanks!
Yeah 'cause you've _never_ had to fix one of my bugs. :-)
Ryan
__
[EMAIL PROTECTED] writes:
> rbb 01/03/02 10:27:42
>
> Modified:network_io/unix inet_ntop.c
> Log:
> need apr_strings for apr_snprintf.
ouch... thanks!
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> writes:
> question. samba, in its search for info during ./configure-time, fails
> certain tests (e.g. the setuid ones) if not run as root.
>
> same for apr?
nope; no such tests
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
On Fri, Mar 02, 2001 at 02:17:05AM -0800, Greg Stein wrote:
[...]
> My personal, uninformed opinion :-) would tend towards adding new
> OS-provided socket types to apr_socket_t (allowing all apps the benefit of
> the new socket types; not just those that can fill in a func table), and
[...]
That g
I've some further notes about pools.
The reason, why I asked for refcounting:
An object might want to live in two pools. Of course it
should only die, if both pools do not anymore reference
that object.
Of course, the object can do the refcounting itself,
pointing the pools destroy-fn-ptr to its
question. samba, in its search for info during ./configure-time, fails
certain tests (e.g. the setuid ones) if not run as root.
same for apr?
- Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> -
"i want a world of dreams, run by near-sighted visionaries"
"good. that's them sorted out.
On Fri, 2 Mar 2001, Greg Stein wrote:
> On Thu, Mar 01, 2001 at 10:32:21PM -0800, [EMAIL PROTECTED] wrote:
> > On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> > > On Thu, Mar 01, 2001 at 09:40:44PM -0800, [EMAIL PROTECTED] wrote:
> > > > We still need to APR namespace protection. We tried to not nam
Roy T. Fielding wrote:
>
> Correct me if I am wrong, but all these changes and problems are
> simply to reduce the three parameters of a standard autoconf macro
> to one parameter in an APR-specific macro? If so, then -1 --> that
> kind of change is why our buildconf setup is so much less portabl
Roy T. Fielding wrote:
>
> Then we should fix the cause of that goofyness, which is due to all
> APR defines being set to "0" or "1" instead of undefined/defined.
> Fixing that would remove the cause of all those other subtle typos and
> bugs, in addition to these above, and leave us with a standa
> > so, one bucket can deal with the NetBIOS header.
>
> Careful. We may be getting some terminology mixed up here.
we? nahh, just me
> I think we're
> definitely on the same page :-), but I'd like to clarify...
appreciate it.
> *) in the above example, the brigade has a HEAP or POOL or some
On Fri, Mar 02, 2001 at 09:16:27PM +1100, Luke Kenneth Casson Leighton wrote:
> On Fri, 2 Mar 2001, Greg Stein wrote:
>...
> > BRIGADE = { FILE, EOS }# FILE bucket and EOS (End Of Stream) bucket
> >
> > becomes
> >
> > BRIGADE = { "packet header bytes", FILE, EOS }
> >
> > We inserted a
> > i'm going over to sander's at the w/e, we'll see if we can thrash it out.
>
> Please let us know your result. We've talked about types of pools before.
> One that keeps the current semantics, one that maps straight to malloc/free,
> and one that handled shared memory.
>
> I didn't know about
On Fri, Mar 02, 2001 at 09:03:59PM +1100, Luke Kenneth Casson Leighton wrote:
>...
> in xmlvl, i investigated splitting out the pool code into stackable pools.
> sander and i came up with sma_mem_sys as a result.
>
> imagine that you want to do secure memory stacking, using the gpg
> memory-lockin
> I'd also like to take a moment just to say that I'm describing what we
> currently have.
much appreciate it. it's all network data, and you['ve basically already
implemented an advanced version of what i was prating-about-with, two and
a half years ago.
> Pick your poison, and if the brigades
On Fri, 2 Mar 2001, Greg Stein wrote:
> Getting long here. Watch out! :-)
other-thread.
> BRIGADE = { FILE, EOS }# FILE bucket and EOS (End Of Stream) bucket
>
> becomes
>
> BRIGADE = { "packet header bytes", FILE, EOS }
>
> We inserted a header without touching the file. The output
On Fri, 2 Mar 2001, Greg Stein wrote:
> Getting long here. Watch out! :-)
split in two :)
> Even the connection pool is a child of another. The pools can be described
> as a tree of pools, with a single global pool created at startup.
greg,
in xmlvl, i investigated splitting out the pool code
On Fri, Mar 02, 2001 at 06:25:56AM +1100, Luke Kenneth Casson Leighton wrote:
> > The issue here is, that the protocols, that are below SMB,
> > are more like sockets. From a clean point of view, they
> > should be implemented in the kernel, but none of us is
> > willing to write kerneldrivers for
Getting long here. Watch out! :-)
On Thu, Mar 01, 2001 at 08:17:10PM +0100, Elrond wrote:
> On Wed, Feb 28, 2001 at 07:40:21AM -0800, Greg Stein wrote:
>...
> > It might be interesting to examine the filters that we have in Apache right
> > now. They provide for the protocol-stacking, buffering,
On Thu, Mar 01, 2001 at 10:32:21PM -0800, [EMAIL PROTECTED] wrote:
> On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> > On Thu, Mar 01, 2001 at 09:40:44PM -0800, [EMAIL PROTECTED] wrote:
> > > We still need to APR namespace protection. We tried to not namespace
> > > protect things to begin with, and
On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> On Thu, Mar 01, 2001 at 09:40:44PM -0800, [EMAIL PROTECTED] wrote:
> > We still need to APR namespace protection. We tried to not namespace
> > protect things to begin with, and Apache and APR were conflicting
> > horribly.
>
> Because the method I des
On Thu, Mar 01, 2001 at 09:40:44PM -0800, [EMAIL PROTECTED] wrote:
>
> We still need to APR namespace protection. We tried to not namespace
> protect things to begin with, and Apache and APR were conflicting
> horribly.
Because the method I described was not used.
> Add to that, that we define
We still need to APR namespace protection. We tried to not namespace
protect things to begin with, and Apache and APR were conflicting
horribly. Add to that, that we define our own macros that no other
package should have.
We have been down the road of exposing non-namespace protected macros
be
> Changing from "1" and "0" to def, undef wouldn't change anything at all.
> The exact same logic is required, and the same general variables are
> required. The differences between the two are incredibly minor, because
> we want to use namespace protected macros.
If we changed to def/undef and w
On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> On Thu, Mar 01, 2001 at 09:39:22PM -0500, Cliff Woolley wrote:
> > On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> >
> > > Correct me if I am wrong, but all these changes and problems are
> > > simply to reduce the three parameters of a standard autoconf m
On Thu, Mar 01, 2001 at 09:39:22PM -0500, Cliff Woolley wrote:
> On Thu, 1 Mar 2001, Roy T. Fielding wrote:
>
> > Correct me if I am wrong, but all these changes and problems are
> > simply to reduce the three parameters of a standard autoconf macro
> > to one parameter in an APR-specific macro?
>
On Thu, 1 Mar 2001, Roy T. Fielding wrote:
> Correct me if I am wrong, but all these changes and problems are
> simply to reduce the three parameters of a standard autoconf macro
> to one parameter in an APR-specific macro?
That's one way to look at it, yeah, but that doesn't capture all of the
b
Correct me if I am wrong, but all these changes and problems are
simply to reduce the three parameters of a standard autoconf macro
to one parameter in an APR-specific macro? If so, then -1 --> that
kind of change is why our buildconf setup is so much less portable
than typical configure scripts,
27 matches
Mail list logo
