Re: apr_dbm and concurrency

[Greg Stein]

On Sat, Nov 11, 2023 at 4:21 AM Nick Kew  wrote:

> > On 9 Nov 2023, at 16:15, Greg Stein  wrote:
> >
> > Personally, I'd deprecate apr_dbm entirely, and direct all clients
> towards sqlite.
>
>...

> +1 to deprecting apr_dbm, provided we explain exactly why (so users
> are clear whether or not it matters to their use cases).  The alternative
> would
> be smart locking code within apr_dbm, and I doubt that anyone wants to
> put that effort in.
>
> Applications can still use a dbm of their choice without the APR layer.
>

Or, apps can stick to an older APR. ... we don't have to carry this forward
into future versions of APR (IMO).

To your point, it is probably a single page with code samples to show how
to do K/V with sqlite, to replace the apr_dbm calls. That's gonna be way
easier than locking code integrated into apr_dbm.

Cheers,
-g

Re: apr_dbm and concurrency

[Greg Stein]

Personally, I'd deprecate apr_dbm entirely, and direct all clients towards
sqlite.

The DBMs were intended for simple key/value stores 20 years ago. We have
much better tech now. Sqlite does K/V so much better, *and* it
handles processes/threads. I really don't see a reason for DBM nowadays.

Who can justify using (say:) ldbm over sqlite?

Cheers,
-g


On Thu, Nov 9, 2023 at 6:00 AM Joe Orton  wrote:

> On Mon, Sep 25, 2023 at 03:58:18PM +0100, Joe Orton wrote:
> > It is unspecified whether the apr_dbm.h interface is safe to use for
> > multiple processes/threads having r/w access to a single database.
> > Results appear to be:
> >
> > - sdbm, gdbm are safe
> > - bdb, ndbm are not safe
>
> I developed a better test case (event MPM + mod_dav + apr_dbm with
> parallel clients doing cycles of LOCK/UNLOCK)
>
> sdbm, gdbm and bdb all failed.
>
> gdbm and sdbm both use either fcntl- or flock-based locking, which
> doesn't work between threads. (apr_file_lock for sdbm)
>
> Unfortunately lmdb is also unsafe at least because *opening* database
> files has races. This is documented under the Caveats section of
> http://www.lmdb.tech/doc/ (which also says it relies on flock-based
> locking, though I only hit issues with it failing during open in
> testing)
>
> The only ways forward I see are either to give up (declare that apr_dbm
> is not safe to use from threads) which passes the buck to httpd, or
> implement a locking layer inside apr_dbm() and don't assume the
> underlying drivers do thread-safe locking at all.
>
>

Re: Bindings for Python or Ruby? And APR docco?

[Greg Stein]

Yeah, saw ... was explaining why such bindings would not exist.

APR is still svn-based so sending patches to the list is fine. An issue
works too, but feels heavier for everybody. The repos/asf/apr/ area is
committers-only.

Cheers,
-g


On Mon, Jul 3, 2023 at 1:35 PM Rodent of Unusual Size 
wrote:

> I mentioned a multi-language (single- or multi-process) environment; for
> example, some apps running C and some running Python on a Raspberry Pi.  If
> it were a single-language situation, naturally I'd use the native
> mechanisms.  And right now I'm thinking about the IPC functionality, not
> the memory management bits (which, admittedly, I expect are a very big part
> of APR's usage profiles).
>
> So what's the process for enhancing docco in the code?  Is it through
> GitHub pull requests, patches submitted to BZ/Jira, just commit to the dev
> branch (assuming CTR)?  In re-engaging with ASF, I'm finding the
> github-RW/github-RO-mirror/svn per-project setup a bit difficult to track
> and remember..
>
> Thanks!
> --
> Ken Coar ()
> OSS developer, opinionist, author
>
>

Re: Bindings for Python or Ruby? And APR docco?

[Greg Stein]

There are no bindings that I'm aware of. I don't think APR would add much
value to Python, which has its own semaphores and memory mapping. Python's
reference counting and garbage collection handle the memory management that
APR pools would be used for.

While I would doubt there is a book about APR itself, I would bet any book
that talks about writing a module for Apache has extensive coverage of APR
(if such a book exists; dunno). There is no docco besides the headers and
the code itself.

Cheers,
-g


On Mon, Jul 3, 2023 at 12:12 PM Rodent of Unusual Size 
wrote:

> Please be gentle, I haven't been around APR for quite a few years..
>
> I'm tentatively interested in a multi-language application that could
> benefit from APR, specifically things like semaphores and shared memory.
>
> Are there any OSS binding libraries making *any* APR functionality
> available to Python (primarily) or Ruby?  Either from the APR project
> itself, or provided by some other person or organisation?
>
> For that matter, are there any good *BOOKS* about APR out there?  I've
> found the documentation, apparently built from code-embedded comments, to
> be a bit .. sparse.  I might be interested in improving that, if someone
> would be willing to inform me (and possibly hold my hand for a bit )
> about the process for doing so..
>
> 's been a very, _very_ long time since I was involved with APR, so I'm
> going to have to feel my way back into being able to provide any value.
> With all the various different ways ASF projects have now of handling
> submissions, issues, and code repos, I'm sure my SVN-and-email 'muscle
> memory' is stale and obsolete..
>
> Thanks!
> --
> Ken Coar ()
> OSS developer, opinionist, author
>

Re: Get rid of APU api in favor of APR for apr/turk

[Greg Stein]

On Sun, Jan 16, 2022 at 11:02 PM William A Rowe Jr 
wrote:

> On Sun, Jan 16, 2022 at 10:46 PM Greg Stein  wrote:
> >
> > On Sun, Jan 16, 2022 at 3:38 PM William A Rowe Jr 
> wrote:
> >>
> >> On Mon, Dec 13, 2021 at 7:43 AM Mladen Turk  wrote:
> >> > On 08/12/2021 08:33, Ruediger Pluem wrote:
> >> > > I assumed this as a trunk/2.0 only proposal. Is my assumption wrong?
> >> >
> >> > Yes, trunk only.
> >> > Just a simple copy/paste leftover cleanup, mostly for internals
> >>
> >> Within that scope, yes, make it happen. Temp macros for the lifespan
> >> of 2.0.x seems appropriate,
> >> ending at release 2.1.0
> >
> >
> > Given the clarification this is for 2.x, then I'd say: skip the temp
> macros. They couldn't be removed in a point release anyways.
> >
> > That said, I'd be +0.5 for an "apu_legacy.h" to assist with people
> porting 1.x code to 2.x. Downstream users would just throw in that #include
> into appropriate source files, and call it a day. That header would be
> super easy to maintain going forwards (ie. rarely, if *ever* change), so
> wouldn't really be a maintenance burden.
>
> I think we totally agree... and apr_legacy.h can be dragged in by apr.h
> IMHO.
>

I dunno about putting that into apr.h (my thought is if your compile fails,
then add the header), but am only -0 .. no complaints.


>
> KISS.
>
> People will need to change their code to apr-2.x. But in the interim,
> apr-util 1.7.0
> aught to have a compat layer to let authors adopt apu_ -> apr_ conventions
> ahead of time. Do we concur?
>

If a release is coming up, then sure: adding new APIs to 1.7 is totally
in-bounds.

Cheers,
-g

Re: Get rid of APU api in favor of APR for apr/turk

[Greg Stein]

On Sun, Jan 16, 2022 at 3:38 PM William A Rowe Jr 
wrote:

> On Mon, Dec 13, 2021 at 7:43 AM Mladen Turk  wrote:
> > On 08/12/2021 08:33, Ruediger Pluem wrote:
> > > I assumed this as a trunk/2.0 only proposal. Is my assumption wrong?
> >
> > Yes, trunk only.
> > Just a simple copy/paste leftover cleanup, mostly for internals
>
> Within that scope, yes, make it happen. Temp macros for the lifespan
> of 2.0.x seems appropriate,
> ending at release 2.1.0
>

Given the clarification this is for 2.x, then I'd say: skip the temp
macros. They couldn't be removed in a point release anyways.

That said, I'd be +0.5 for an "apu_legacy.h" to assist with people porting
1.x code to 2.x. Downstream users would just throw in that #include into
appropriate source files, and call it a day. That header would be super
easy to maintain going forwards (ie. rarely, if *ever* change), so wouldn't
really be a maintenance burden.

Cheers,
-g

Re: Dropping Netware code from Windows apr/trunk

[Greg Stein]

On Thu, Dec 9, 2021 at 1:55 PM Ruediger Pluem  wrote:

> On 12/9/21 6:10 PM, Greg Stein wrote:
> > On Wed, Dec 8, 2021 at 7:08 AM Ruediger Pluem  <mailto:rpl...@apache.org>> wrote:
> >>...
> >
> > I think our API / ABI rules do not allow this for 1.8, only for 2.0.
> > But the question is if we are wiling to break them for a platform
> that is no longer maintained by us and is out of vendor support
> > for many years. Hence it likely will not affect our users if we do
> this in 1.8.
> >
> >
> > You could totally add APR_FOO in 1.8 as a new name for APU_FOO. Or more
> precisely: in apr_legacy.h define APU_FOO in terms of APR_FOO.
> >
> > Similarly, you could rename aprutil_foo() to apr_foo() and then create a
> wrapper aprutil_foo() that just calls apr_foo().
> >
> > The ABI would remain the same (all old functions are still present), yet
> more symbols (apr_foo) are introduced in 1.8. Check.
> > All APU_FOO symbols are present during compilation, and more symbols
> (APR_FOO) are introduced in 1.8. Check.
> >
> > And clearly, the wrappers and apr_legacy.h would be tossed in 2.0
>
> I am confused now. My reply above was about dropping Netware support for
> 1.8. The APR / APU topic was in the
>

I think dropping Netware in 1.8 would be prohibited by our versioning
guidelines. Elimination of a feature is pretty big.

That said: I'm +0 on removing it. I doubt anybody would actually complain.

The rest of email is simply how it could be done for 1.8 while keeping the
same API/ABI, to meet the versioning rules.


> Re: Get rid of APU api in favor of APR for apr/turk
>
> thread.
> But on the APR/APU topic: I guess
>
> #define apr_foo aprutil_foo
>

That might work? For some reason, my spidey-sense is saying there are
pitfalls in simply renaming a symbol in the preprocessor. Certainly, for
sure the debug and stack traces would be wonky. There wouldn't be any true
ABI entrypoint named apr_foo() etc. (think: dynamic lookup)


> would be sufficient as users of 1.8 that would use apr_foo in their code,
> could not expect to use 2.0 without recompiling against
> 2.0, while 1.7 users that use aprutil_foo could expect to run against 1.8
> without recompiling.
>

Right.

Note: I'm not really fussed about any approach (since I'm not the one doing
that work). I wrote the versioning guidelines 20 years ago. Just trying to
describe an approach that would create the new apr_foo() entrypoints and
symbols, yet maintain the API/ABI restrictions.

Cheers,
-g

Re: Dropping Netware code from Windows apr/trunk

[Greg Stein]

On Wed, Dec 8, 2021 at 7:08 AM Ruediger Pluem  wrote:
>...

> I think our API / ABI rules do not allow this for 1.8, only for 2.0.
> But the question is if we are wiling to break them for a platform that is
> no longer maintained by us and is out of vendor support
> for many years. Hence it likely will not affect our users if we do this in
> 1.8.
>

You could totally add APR_FOO in 1.8 as a new name for APU_FOO. Or more
precisely: in apr_legacy.h define APU_FOO in terms of APR_FOO.

Similarly, you could rename aprutil_foo() to apr_foo() and then create a
wrapper aprutil_foo() that just calls apr_foo().

The ABI would remain the same (all old functions are still present), yet
more symbols (apr_foo) are introduced in 1.8. Check.
All APU_FOO symbols are present during compilation, and more symbols
(APR_FOO) are introduced in 1.8. Check.

And clearly, the wrappers and apr_legacy.h would be tossed in 2.0

Cheers,
-g

ps. we do this kind of symbol migration all the time in svn. Works out just
fine. We haven't needed a 2.0, just a focus on *how* to keep things
compatible.

Re: Get rid of APU api in favor of APR for apr/turk

[Greg Stein]

If you're talking 1.7, then as long as an apu_legacy.h header is included
by $appropriate with #define symbols mapping APU_FOO to APR_FOO. This
header could be removed in apr 2.0, and user apps expected to s/APU/APR/
... the 1.x ABI would need simple apu_foo() wrappers around apr_foo()

Cheers,
-g


On Tue, Dec 7, 2021 at 10:50 AM Mladen Turk  wrote:

> Since apr-util API is now part of APR
> I propose to rename all that legacy APU_FOO to APR_FOO
>
>
>
> Regards
> --
> ^TM
>

Re: apr-2 ... cleanup

[Greg Stein]

Isn't the whole idea of moving to 2.0 to lose the dead weight, and allow a
break in API compatibility?


On Wed, May 13, 2020 at 4:28 AM Branko Čibej  wrote:

> On 13.05.2020 10:41, Mladen Turk wrote:
> > Hi,
> >
> > Related mostly to Windows port
> >
> > 1. Remove all those .dsp, .dsw .mak files from APR trunk
> >None of them works for years.
> >Replace all that with cmake
> > 2. Remove all _WIN32_WCE, APR_NOT_IN_WCE
> >Just a bunch of code for Windows CE that
> >never worked, and no chance it will compile with
> >current Windows code
> > 3. Drop all that APR_HAS_ANSI_FS and APR_HAS_UNICODE_FS
> >Code in trunk need at least _WIN32_WINNT=0x0601 API
> > 4. Drop all references to apr-iconv project
> >Unusable for years
> > 1. Remove all APU_XXX references
> >Since the apr-util is apr
> >remove all APU_XXX defines and API
>
> This will cause any coded that's upgrading from apr/apu 1.x to apr 2.x
> and uses those symbols to break. That's an unnecessary change of
> backwards compatibility.
>
>
> > 2. Netware and OS/2
> >Both platforms are dead for years
> >IMHO bunch of relic code no one use
> > 3. https://svn.apache.org/viewvc/apr/apr/trunk/include/apu.h?view=markup
> >More then 10 years ago ...
>
> See above about existing code that uses apr-util 1.x (q.v., Subversion).
> There's no reason to break API compatibility on that level and forcing
> all downstream users that want to keep supporting both 1.x and 2.x from
> peppering their code with #if's.
>
> -- Brane
>
>

Re: Proposal: apr-tools project

[Greg Stein]

On Thu, Jul 25, 2019 at 7:26 AM Nick Kew  wrote:

> > On 25 Jul 2019, at 12:22, Graham Leggett  wrote:
>
>...

> > Second question is structure. Part of APR? Alongside APR?
>
> Either within APR or your external effort: IMHO it would be excessively
> bureaucratic
> to put it within the ASF but separate from APR.
>

I tool "alongside" to mean like how apr-util is "alongside" apr. Not a
separate TLP.

But then again, 2.0 combines cuz the "alongside" was too much overhead.

Regardless: I'm with Nick: the tools don't sound very useful. I'd use
native tools for any database. I'd probably script something in Python for
encoding type stuffs.

I see apr as a *library* for C programs. Definite, clear need for this.

I do not believe we need to create cmdline tools, which can be fulfilled
with any number of alternatives.

Cheers,
-g

Re: svn commit: r1862071 - in /apr/apr/trunk: file_io/os2/dir.c file_io/unix/dir.c file_io/win32/dir.c include/apr_file_info.h test/testdir.c

[Greg Stein]

On Tue, Jul 2, 2019 at 8:04 AM Branko Čibej  wrote:
>...

> Perhaps this is the right time to note (again) that over in Subversion
> land, we found that functions should take _two_ pool parameters: one for
> allocating the returned values and one for temporary allocations. This
> is better than functions creating temporary subpools for temporaries,
> because it allows the API consumer better control over allocations.
>

https://subversion.apache.org/docs/community-guide/conventions.html#apr-pools

Re: svn commit: r1860745 - /apr/apr/trunk/file_io/win32/dir.c

[Greg Stein]

On Fri, Jun 7, 2019 at 6:02 AM  wrote:
>...

> \@@ -114,116 +93,73 @@ APR_DECLARE(apr_status_t) apr_dir_read(a
>  {
>  apr_status_t rv;
>  char *fname;
> +apr_wchar_t wdirname[APR_PATH_MAX];
>

That's a crazy huge stack frame. I recognize we were doing this before this
commit, but is it advisable? Should it be corrected?

Cheers,
-g

Re: svn commit: r1860150 - in /apr/apr/trunk: ./ CHANGES CMakeLists.txt include/apr.hwc xml/apr_xml_xmllite.c

[Greg Stein]

On Mon, May 27, 2019, 12:18 Ivan Zhakov  wrote:

> On Mon, 27 May 2019 at 20:13,  wrote:
> >
> > Author: ivan
> > Date: Mon May 27 17:13:43 2019
> > New Revision: 1860150
> >
> > URL: http://svn.apache.org/viewvc?rev=1860150=rev
> > Log:
> > Windows platform: Provide a native XML parser implementation based on
> > XmlLite [1].
> >
> > Start using it by default if we weren't explicitly told to build with
> either
> > libxml2 or expat.
> >
> > (This is a merge of the `xmllite` branch.)
> >
> > Doing so reduces the amount of dependencies required for building and
> using
> > APR, which I believe to be a good thing in this particular case. And it
> also
> > means that by default we would be relying on the native component of the
> OS
> > rather than on a 3rd-party library.
> >
> Hey all,
>
> Switching to XmlLite on the Windows platform has been one of those
> changes that I had in mind for the Win32 part in APR 2.0.
>
> Doing so reduces the amount of dependencies required for building and
> using APR, which I believe to be a good thing in this particular case.
> And it also means that by default we would be relying on the native
> component of the OS rather than on a 3rd-party library.
>
> Please let me know if there would be any objections against this change.
>

Great change! Keep going 

Cheers,
-g

Re: [vote] Win32 Decision Point

[Greg Stein]

On Wed, Apr 24, 2019, 14:31 William A Rowe Jr  wrote:
>...

>
>
> [X] Please drop 8-bit and focus only on utf-8 resource names on Win32.
>

It is a very good breaking change for 2.0. Leave that stuff behind. Devs
who need it can stick to 1.x or choose another solution.

Cheers,
-g

Re: Using APR pools "better"

[Greg Stein]

On Wed, Sep 26, 2018 at 10:20 AM Daniel Shahaf 
wrote:

> Jim Jagielski wrote on Wed, 26 Sep 2018 11:09 -0400:
> > At ApacheCon's welcoming event last night, Greg, Sander and I were
> > chatting and Greg reminded us that the Subversion project "learned a lot
> > about using APR pools" and it seems to me that a lot of that knowledge
> > is likely missing in httpd-land. I also know that some of that has been
> > backported back to APR itself, but I am wondering (as I am wont to do),
> > if we couldn't do a better job here. I am sure that there are things in
> > svn that could be easily and readily folded back into APR w/o breaking
> > anything.
> >
> > I know that some of that influenced Greg's PoCore work, but it would be
> > really cool if someone in Subversion could maybe point out some of those
> > improvements and "lessons learned" so that both APR and httpd could
> > benefit.
>
> For starters, here's what we've already written down:
>
>
> https://subversion.apache.org/docs/community-guide/conventions.html#apr-pools
>
> I would especially point out the result_pool/scratch_pool distinction:
> each function gets *two* pools, one in which to allocate the return
> value, and one whose lifetime is defined as "the pool may be deleted at
> any time after the function returns".
>
> For example, when one calls a function declared as:
> .
> apr_status_t find_foo(foo_t *outparam, ..., apr_pool_t *result_pool,
> apr_pool_t *scratch_pool)
> .
> then on return *outparam will be allocated in result_pool, and
> apr_pool_clear(scratch_pool) may be called as soon as find_foo()
> returned.


Yup.


>   Thus, scratch_pool is passed into the result_pool formal
> parameter of functions find_foo() calls, is the pool iterpools are created
> as subpools of, etc. .
>

This is a bit unclear, so skip this and go read the page :-)


> I'm sure Greg is subscribed to at least one of these lists and will add
> anything I forgot :)


All three, actually :-) ... and the pointer to the coding convention page
is exactly what I wanted to point the other groups at.

iterpool, scratch_pool, and result_pool are the KEY three concepts that we
learned while working on Subversion. Also relying on your *caller* to know
more about memory management / lifetimes. The conventions page does a
really great job of describing what we learned, and we're here to
expand/answer where it isn't (and #fixthedoc :-P ), and/or provide further
examples to clarify.

Cheers,
-g

Re: Reminder and caution

[Greg Stein]

Thanks for the explanation. Your OP said nothing about that, so was "hard
to follow".

On Wed, Jul 25, 2018 at 10:19 AM William A Rowe Jr 
wrote:

> It seems we have a lot of revert activity on trunk, relating to OpenSSL
> init, which is becoming hard to follow. It would be good if we start off
> major changes on the dev@ list for discussion first, which should help
> avoid some code churn.
>
>
>
> On Wed, Jul 25, 2018, 05:17 Greg Stein  wrote:
>
>> What is this email about?
>>
>>
>> On Tue, Jul 24, 2018 at 9:43 PM William A Rowe Jr 
>> wrote:
>>
>>> *Change Process*
>>>
>>> Most changes (bug fixes and minor, commonsense feature adds) do not
>>> require review. Developers are encouraged to request review for:
>>>
>>>- Large changes affecting many files
>>>- Changes to interfaces
>>>- Changes that commit APR to one option out of an exclusive set
>>>- Any change the developer wants a second (or Nth) opinion on
>>>
>>> Anyone may retroactively cause someone's change to be reviewed by
>>> requesting review after it was committed, and at their discretion may
>>> revert the change until it is approved.
>>>
>>> The above process is called "Commit Then Review" (or CTR). As of this
>>> time, the group does not see a need to ever use a "Review Then Commit"
>>> (RTC) process.
>>>
>>>
>>>

Re: Reminder and caution

[Greg Stein]

What is this email about?


On Tue, Jul 24, 2018 at 9:43 PM William A Rowe Jr 
wrote:

> *Change Process*
>
> Most changes (bug fixes and minor, commonsense feature adds) do not
> require review. Developers are encouraged to request review for:
>
>- Large changes affecting many files
>- Changes to interfaces
>- Changes that commit APR to one option out of an exclusive set
>- Any change the developer wants a second (or Nth) opinion on
>
> Anyone may retroactively cause someone's change to be reviewed by
> requesting review after it was committed, and at their discretion may
> revert the change until it is approved.
>
> The above process is called "Commit Then Review" (or CTR). As of this
> time, the group does not see a need to ever use a "Review Then Commit"
> (RTC) process.
>
>
>

Re: [RFC] apr_array_find()

[Greg Stein]

At one point, we used to use an svn_array_find() or some such. We
deprecated it. Creating a function to do comparisons, then set up a
function call... It was just annoying. Iteration over an APR array is easy,
and very clear. There is basically no code or mental overload. Using a
comparator function, there is.

-0 on the concept.

Cheers,
-g

ps. and if written, it *should* allow for structs; we use those often in
svn. Avoids alloc'ing a structure and sticking a ptr in the array.

On Fri, Apr 27, 2018, 13:46 William A Rowe Jr  wrote:

> SVN's extensions to apr largely exist here;
>
> http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_subr/
>
> Because they are based on apr and rooted in that ecosystem, there are a
> number of useful extensions in that repo that were never pushed upstream,
> but are not "withheld". Nobody had the time to submit and champion them.
>
> On Fri, Apr 27, 2018, 13:25 Jim Riggs  wrote:
>
>> > On 27 Apr 2018, at 11:50, William A Rowe Jr 
>> wrote:
>> >
>> > If we code this abstractly, comparator declaration is not type-safe,
>> but can
>> > be declared so that it is usable by table, hash, b-tree and many other
>> > approaches to data organization. With clever use of wrappers, we should
>> > be able to make a derivation (counted-byte-string tables, for example)
>> > behave in a type-safe manner at no performance penalty.
>> >
>> > We should cross check the subversion util feature set to ensure we don't
>> > have something ready to borrow, already.
>>
>> I fear things have now started going over my head. :-) I'll try to keep
>> up.
>>
>>

Re: expat removed from APR project (Re: [VOTE] Release Apache httpd 2.4.28 as GA)

[Greg Stein]

On Wed, Sep 27, 2017 at 12:10 PM, William A Rowe Jr 
wrote:
>...

> After deeper consideration, this was fundamentally wrong.
>
> For those less familiar with the Win32 build, we failed to decouple
> a "project" called "xml" which was, in fact, our idea of how expat
> should be built.
>

Strictly speaking, the xml module is an API that creates a memory-efficient
DOM of an XML document, so that mod_dav could easily consume it. The API
originated from mod_dav's needs.

Another way to view it, is that Expat is a streaming/callback model, but
mod_dav needed a random-access model. The xml code and API is that bridge.

>...

> Already, apr-util has crypto libs, dbm providers, dbd providers, all
> but one are external libraries maintained by external groups with
> their own recommended build mechansims.
>

More background: Expat *source* was added to the apr-util library back in
1999 or 2000 or somesuch. At the time, the library wasn't normally packaged
and easily available. The choice was made to include it, to help downstream
users in a "batteries included" form, but have enough autoconf magic to
also use a pre-installed Expat package.

Nowadays, it makes no sense to keep carrying around the Expat source.

Regarding whether to use Expat and/or libxml under the API covers ... I
don't have any insight or opinion on that. ... I just have insight on the
API and Expat's presence cuz, well, it's my fault :-)

Cheers,
-g

changing reply-to (was: expat removed from APR project...)

[Greg Stein]

On Wed, Sep 27, 2017 at 11:14 PM, William A Rowe Jr 
wrote:

> I'm sorry so much context was lost to dev@. PMC voted to apply
> reply-to-list context for dev@ many moons ago. Nick, would you help me to
> work with infra to ensure this is accomplished by a week from Friday?
>

Just file an INFRA ticket with a statement of what Reply-To behavior you'd
like, and a link to the discussion/vote showing that community decision.
Easy peasy.

Cheers,
-g

Re: Optimization, modern C and APR 2.0 onwards

[Greg Stein]

On Fri, Nov 20, 2015 at 4:19 PM, Yann Ylavic  wrote:

> On Fri, Nov 20, 2015 at 11:14 PM, William A Rowe Jr 
> wrote:
> > On Fri, Nov 20, 2015 at 2:55 PM, Yann Ylavic 
> wrote:
> >>
> >> On Fri, Nov 20, 2015 at 8:00 PM, Jim Jagielski  wrote:
> >> > If we are serious about having a serious update to APR, I
> >> > would recommend that we use more up-to-date data structures,
> >> > patterns and algorithms than those in apr1. For example,
> >> > Greg's pocore mini lib is an example of the types of improvements
> >> > we should consider.
> >>
> >> Could you share a pointer to it please?
> >
> >
> > https://github.com/gstein/pocore
>
> Thanks!
>

Jim may have other items in mind, but I believe its notable improvements
are:

* hash tables built upon modern research
* pools that avoid long-term memory fragmentation, including free()
capability
* structured error handling

As a solid test of the pocore library, I patched APR to use pocore's pools
and hash tables (see apr/branches/gstein-pocore/) and then ran Subversion's
extensive test suite. Except for tests depending upon hash table iteration,
I got it all working just fine. pocore's pools are faster than APR (tho
both are screaming fast, in the scheme of things), APR pools on top of
pocore kinda slowed down the tests :-P

I'd be more than happy to discuss its design, both now and future direction
(eg. memory coalescing is intended, but not yet implemented).

Cheers,
-g

Re: Pool freelist

[Greg Stein]

As I recall, Paul tested using tcmalloc or some other allocator to replace
apr_palloc(). No bueno.

The short answer is that pool-based allocation is *wicked* fast, compared
to any other attempt/mechanism for allocating memory. I managed to improve
over apr by removing an if-test or two, but any other approach will be
comparatively/miserably slow.

Now, that said: it sounds like you're not asking about apr_palloc(), but
really about apr_pool_create(). I believe that would likely be just fine
for something like HTTPD. On a per-request basis, it doesn't really
allocate many pools. But Subversion tends to create a pool for any for-loop
that might allocate memory. *Thousands* get created/destroyed across some
Subversion operation. On the client, another microsecond isn't going to be
a big deal, but the server exhibits this behavior too.

Is your goal to remove the burdens, and simplify the codebase? Or .. ???

Cheers,
-g



On Wed, Sep 3, 2014 at 2:37 PM, Jim Jagielski j...@jagunet.com wrote:

 Yeah, that thread, and Greg's work w/ pocore, are kind of
 the origins of this question. The thing is that awhile ago,
 (I mean way awhile ago), I recall us trying to simply replace
 pools w/ malloc/free (Paul was the main dude in this case)
 and we got terrible performance...

 It's now ~6 years later and so wondering if just bypassing
 the pool freelist is now viable, at least as a compile-time
 (or allocator) option.

 On Sep 3, 2014, at 3:11 PM, Ivan Zhakov chemo...@gmail.com wrote:

  On 2 September 2014 16:02, Jim Jagielski j...@jagunet.com wrote:
  Has anyone looked at simply disabling the apr_pools freelist
  totally lately and seeing what the performance is?
  This thread may be interesting:
  http://svn.haxx.se/dev/archive-2008-10/0070.shtml
 
  We also tested disabling apr_pools free list in our Subversion
  distribution for Windows and didn't noticed performance problems on
  simple tests. We didn't performed proper benchmarks and decided to
  keep standard APR pools, but with very low MaxMemFree value.
 
  --
  Ivan Zhakov
 

Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c

[Greg Stein]

On Apr 4, 2012 11:36 PM, Branko Čibej br...@apache.org wrote:
...
 Um, Greg? I often find that rereading evening mails in the morning
 before sending them is conductive to a civilized discussion. This has
 gone way beyond necessary.

Hm? That I'm beating a dead horse, or that I happen to use some colorful
words in my writing?

-g

Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c

[Greg Stein]

On Apr 3, 2012 9:22 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote:

 On 4/2/2012 6:48 AM, Graham Leggett wrote:
  We're not talking about proper branch management and helpful log
messages, both of which
  are a given. Instead we're talking about duplicating the revision
recorded within
  svn:mergeinfo inside the log message.

 Very, very few svn management tools do any reasonable job of providing
 at-a-glance review to the human user for svn property metadata, outside
 of the revprop svn:log.  At least, I haven't used one.

 The rules on any commit are Who what when where why.  Usually takes not
 more than a sentence, sometimes a submitted by, sometimes a PR ticket.

 If it appeared on the original commit, it must appear in the log message
 of all other commits.  Why would one delete that data?  To make it more
 troublesome using viewvc to rewind WTF just happened?

 So, backport log message == original log message + original commit rev no.

Here is an example of a good backport:
  http://svn.apache.org/viewvc?view=revisionrevision=1306142

It identifies what is backported, why, and the votes necessary to authorize
modifying the release branch. It is basically picked up straight from the
branch STATUS file.

YMMV, but the base concept is review, control, and repeatability.

Cheers,
-g

Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c

[Greg Stein]

On Apr 2, 2012 7:48 AM, Graham Leggett minf...@sharp.fm wrote:
...
 This project has come to an agreement in the past over how CHANGES files
are to be handled.

Blah, fucking, blah. Why are you even talking about CHANGES? I already
stated that I understand it differs in this project from how svn handles
it. You're trying to argue against something already conceded. The
discussion is about how you backport commits. And about mixing backports
with other edits.

My position is that the recent backports were done incorrectly, and I would
like to see that corrected in the future.

-g

Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c

[Greg Stein]

On Wed, Apr 4, 2012 at 18:09, Graham Leggett minf...@sharp.fm wrote:
...
 This type of comment embarrasses both the project and the ASF. If you want
 to discuss an issue, please discuss the issue. As soon as emails start
 getting abusive, EOT.

I did discuss the issue. And then you went off about CHANGES, which
I'd already accepted and moved on from. Now you're moving on to
discussing three words in my reply.

How about sticking to the original: do not mix backports and edits.
I've said that many times, and you continue to change the topic to
inane things. So yeah, all I hear is blah blah blah. And yes, I can
also use swear words in there, too blah fucking blah. What's the big
deal? There are no ad hominem attacks or anything else going on.

So get a grip, and don't worry about a little swearing. How about
doing backports properly instead?

-g

Re: svn commit: r1308088 - in /apr/apr-util/branches/1.5.x: ./ crypto/apr_crypto.c

[Greg Stein]

On Sun, Apr 1, 2012 at 08:03,  minf...@apache.org wrote:
 Author: minfrin
 Date: Sun Apr  1 12:03:32 2012
 New Revision: 1308088

 URL: http://svn.apache.org/viewvc?rev=1308088view=rev
 Log:
 Backport:
 apr_crypto: Ensure the *driver variable is initialised when the library
 has already been loaded. Fix ported from apr_dbd.

 Modified:
    apr/apr-util/branches/1.5.x/   (props changed)
    apr/apr-util/branches/1.5.x/crypto/apr_crypto.c

 Propchange: apr/apr-util/branches/1.5.x/
 --
  Merged /apr/apr/trunk:r1308087

How is this a merge of -087 ? Where is the CHANGES edit?

-g

Re: svn commit: r1308088 - in /apr/apr-util/branches/1.5.x: ./ crypto/apr_crypto.c

[Greg Stein]

On Sun, Apr 1, 2012 at 16:49, Graham Leggett minf...@sharp.fm wrote:
 On 01 Apr 2012, at 10:46 PM, Greg Stein wrote:

 URL: http://svn.apache.org/viewvc?rev=1308088view=rev
 Log:
 Backport:
 apr_crypto: Ensure the *driver variable is initialised when the library
 has already been loaded. Fix ported from apr_dbd.

 Modified:
    apr/apr-util/branches/1.5.x/   (props changed)
    apr/apr-util/branches/1.5.x/crypto/apr_crypto.c

 Propchange: apr/apr-util/branches/1.5.x/
 --
  Merged /apr/apr/trunk:r1308087

 How is this a merge of -087 ? Where is the CHANGES edit?

 In apr-util v1.4.

I'm aware that the edit made it to 1.4 ... I'm asking: this commit is
a merge of -131, but the edit to CHANGES is missing. Therefore, it is
NOT a proper merge. Where did the edit to CHANGES go?

-g

Re: svn commit: r1308088 - in /apr/apr-util/branches/1.5.x: ./ crypto/apr_crypto.c

[Greg Stein]

On Sun, Apr 1, 2012 at 16:52, Greg Stein gst...@gmail.com wrote:
 On Sun, Apr 1, 2012 at 16:49, Graham Leggett minf...@sharp.fm wrote:
 On 01 Apr 2012, at 10:46 PM, Greg Stein wrote:

 URL: http://svn.apache.org/viewvc?rev=1308088view=rev
 Log:
 Backport:
 apr_crypto: Ensure the *driver variable is initialised when the library
 has already been loaded. Fix ported from apr_dbd.

 Modified:
    apr/apr-util/branches/1.5.x/   (props changed)
    apr/apr-util/branches/1.5.x/crypto/apr_crypto.c

 Propchange: apr/apr-util/branches/1.5.x/
 --
  Merged /apr/apr/trunk:r1308087

 How is this a merge of -087 ? Where is the CHANGES edit?

 In apr-util v1.4.

 I'm aware that the edit made it to 1.4 ... I'm asking: this commit is
 a merge of -131, but the edit to CHANGES is missing. Therefore, it is
 NOT a proper merge. Where did the edit to CHANGES go?

-087, I meant.

A proper merge should include all changes. Not just a portion of the
revision. Where did CHANGES go?

Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c

[Greg Stein]

On Sun, Apr 1, 2012 at 11:23,  minf...@apache.org wrote:
 Author: minfrin
 Date: Sun Apr  1 15:23:45 2012
 New Revision: 1308135

 URL: http://svn.apache.org/viewvc?rev=1308135view=rev
 Log:
 Backport:
 apr_crypto: Ensure the *driver variable is initialised when a statically
 compiled library is initialised for the first time.

 Modified:
    apr/apr-util/branches/1.4.x/   (props changed)
    apr/apr-util/branches/1.4.x/CHANGES
    apr/apr-util/branches/1.4.x/crypto/apr_crypto.c

 Propchange: apr/apr-util/branches/1.4.x/
 --
  Merged /apr/apr/trunk:r1308131

-131 has no edit to CHANGES.

When performing backports, you should commit *just* the backport. If
you want to make other changes, then keep them in a separate commit.

Combining changes like this is poor branch policy. It means that we
can no longer trust that a backport is *JUST* the backport. We have to
investigate to determine whether other changes were made in the
commit.

-g

Re: svn commit: r1308088 - in /apr/apr-util/branches/1.5.x: ./ crypto/apr_crypto.c

[Greg Stein]

On Sun, Apr 1, 2012 at 16:55, Graham Leggett minf...@sharp.fm wrote:
 On 01 Apr 2012, at 10:52 PM, Greg Stein wrote:

 -087, I meant.

 A proper merge should include all changes. Not just a portion of the
 revision. Where did CHANGES go?

 CHANGES was committed to apr-trunk by mistake, and I meant to take it out.

Then you need to document such things in the log message. I've made
the proper edit.

-g

Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c

[Greg Stein]

On Sun, Apr 1, 2012 at 17:04, Jeff Trawick traw...@gmail.com wrote:
 On Sun, Apr 1, 2012 at 4:55 PM, Greg Stein gst...@gmail.com wrote:
 On Sun, Apr 1, 2012 at 11:23,  minf...@apache.org wrote:
 Author: minfrin
 Date: Sun Apr  1 15:23:45 2012
 New Revision: 1308135

 URL: http://svn.apache.org/viewvc?rev=1308135view=rev
 Log:
 Backport:
 apr_crypto: Ensure the *driver variable is initialised when a statically
 compiled library is initialised for the first time.

 Modified:
    apr/apr-util/branches/1.4.x/   (props changed)
    apr/apr-util/branches/1.4.x/CHANGES
    apr/apr-util/branches/1.4.x/crypto/apr_crypto.c

 Propchange: apr/apr-util/branches/1.4.x/
 --
  Merged /apr/apr/trunk:r1308131

 -131 has no edit to CHANGES.

 When performing backports, you should commit *just* the backport. If
 you want to make other changes, then keep them in a separate commit.

 Combining changes like this is poor branch policy. It means that we
 can no longer trust that a backport is *JUST* the backport. We have to
 investigate to determine whether other changes were made in the
 commit.

 That adds an extra step to looking at the code changes for a CHANGES
 entry, if indeed the merger/backporter remembered to list the code
 change in the CHANGES commit.  (Otherwise it is more painful.)

I'm not sure that I follow that statement.

My point is: if you do a backport of a commit, then do *just* the
backport. Throwing other work into that commit leads to insanity.

 I guess you mean that the trust part comes not from backports in
 general but only from a a touchless merge.  Generally a backport
 may require minor changes to reflect other differences in the branch.

For that kind of problem, in Subversion, we create a
branch-of-the-branch then backport the revision, then make the
necessary edits to make the backport conform to the branch. Thus, when
we touch branches/1.N.x, we are doing a simple backport merge. Again:
no other changes in that revision beyond JUST the backport.

So yes: I'm saying touchless merges are the proper way to manage branches.

These two backports today were reckless. Both of them were not
touchless to use your term. And worse: that fact was not documented
in the log message. Backport is all it said. Not what revision was
backported. Not that other changes were made beyond that
(unidentified) revision.

I can maybe understand a policy that says CHANGES should be edited
directly on the branch (since, at this point, trunk CHANGES and branch
CHANGES are completel dissimilar). But those edits should not be part
of backport merges.

-g

Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c

[Greg Stein]

On Sun, Apr 1, 2012 at 17:22, Graham Leggett minf...@sharp.fm wrote:
 On 01 Apr 2012, at 11:13 PM, Greg Stein wrote:

 These two backports today were reckless. Both of them were not
 touchless to use your term. And worse: that fact was not documented
 in the log message. Backport is all it said. Not what revision was
 backported. Not that other changes were made beyond that
 (unidentified) revision.

 What about svn:mergeinfo?

So? Do I need to run 'svn diff' on every commit to see what happened?
If you're arguing that, then don't add a log message. Leave it blank.
Make people run diff on every change to see what happened.

The simple fact is that branches need to be held to a higher standard
than trunk. We don't do random development on branches. We simply
backport changes. The log message should note WHAT was backported. (I
have edited the log message for today's two backports, so they now
reflect what happened in those commits)

svn:mergeinfo records the backports, but it is hardly as informative
as the log message. Especially when other changes are blended in.

-g

Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c

[Greg Stein]

On Apr 1, 2012 6:00 PM, Graham Leggett minf...@sharp.fm wrote:

 On 01 Apr 2012, at 11:29 PM, Greg Stein wrote:

  What about svn:mergeinfo?
 
  So? Do I need to run 'svn diff' on every commit to see what happened?

 Isn't that the very definition of svn diff? To tell us what happened?

If you need details that not summarized in the log message. Of course.

My point is that svn:mergeinfo is not a replacement for proper branch
management and helpful log messages.


 Personally, I'm am utterly exhausted by constantly being told by this
person and then that person that some or other completely undocumented
pattern isn't being followed. All I want to do is fix some bugs, get a
release out the door, and help some long suffering Windows folks who are
having problems with static builds.

Oh, cry me a river. Proper branch management produces repeatable, solid
releases for this users.

You're exhausted by two commit reviews?! Seriously? You're exhausted by
an email discussion? That somehow, feedback on constructing releases is a
poor use of your limited bugfixing time?


 Between you and Jeff and whoever else wants to chime in, formulate a
proper *workable* backport strategy. *document* it properly so that it can
be found easily at http://apr.apache.org, and I will happily follow
whatever you've decided to do.

http://subversion.apache.org/docs/community-guide/conventions.html#log-messages
http://subversion.apache.org/docs/community-guide/releasing.html#release-branches
http://subversion.apache.org/docs/community-guide/releasing.html#porting-changes

There's a good section on managing the CHANGES file, but I can see the need
for a special policy given the trunk/branch disparity.

-g

bugs in apr_crypto_get_driver()

[Greg Stein]

I've identified two problems in apr_crypto_get_driver(), and need
somebody to review my thinking and make the appropriate corrections.

First up is this block:

rv = apu_dso_load(dso, symbol, modname, symname, pool);
if (rv != APR_SUCCESS) { /* APR_EDSOOPEN or APR_ESYMNOTFOUND? */
if (rv == APR_EINIT) { /* previously loaded?!? */
name = apr_pstrdup(pool, name);
apr_hash_set(drivers, name, APR_HASH_KEY_STRING, *driver);
rv = APR_SUCCESS;

That apr_hash_set() will store a NULL, since the only way here is when
*driver == NULL. Further, it certainly shouldn't set rv to APR_SUCCESS
since nothing got loaded and returned in *driver.

The second problem is the series of DRIVER_LOAD() calls at the bottom
of the function. None of these appear to set *driver to the
appropriate value. (and beware macro arg name shadowing)

Cheers,
-g

Re: Using autoconf/automake/libtool

[Greg Stein]

Automake is one of the worst pieces of code I've ever had the misfortune to
use. I have a litany against it, that I don't want to type on my tablet
right now :-P

Create a dist.sh script for creating distributions. That will get the
repeatability up. Or something like Subversion's release.py:
  http://svn.apache.org/repos/asf/subversion/trunk/tools/dist/

But automake is absolutely not the answer.

Cheers,
-g
On Mar 16, 2012 8:02 AM, Graham Leggett minf...@sharp.fm wrote:

Re: Using autoconf/automake/libtool

[Greg Stein]

I'm not talking about a tool. Just a script. If svn's scripts are too big
for you, then how about serf:
  http://serf.googlecode.com/svn/trunk/dist.sh

APR could use something like that.
 On Mar 16, 2012 9:32 AM, Graham Leggett minf...@sharp.fm wrote:

Re: Using autoconf/automake/libtool

[Greg Stein]

On Fri, Mar 16, 2012 at 15:17, Graham Leggett minf...@sharp.fm wrote:
 On 16 Mar 2012, at 9:05 PM, William A. Rowe Jr. wrote:

 This was asked and answered before, this project rejects automake.

 Can you cite when this took place?

 Sure I could, but you have the same email archives I do.

 And I can't find the discussion you're referring to in those archives. Like I 
 said, can you cite please?

http://mail-archives.apache.org/mod_mbox/apr-dev/200012.mbox/%3cpine.lnx.4.30.0012152349240.2652-100...@rossini.schumann.cx%3e
http://mail-archives.apache.org/mod_mbox/apr-dev/200103.mbox/%3c20010310060247.x27...@lyra.org%3e

Plus lots of other references of people saying no way on automake.
None of those comments are explained, beyond relying on people's
personal experience (and hatred) of automake.

-g

Re: Using autoconf/automake/libtool

[Greg Stein]

Let me reiterate my earlier point, since this is straying from the main point:

A simple dist.sh script should be sufficient. We do not need automake
to take the place of a simple shell script.

serf's dist.sh is almost precisely what APR could use: it produces a
.bz2 and a .zip file. No complicated options or other processing
(unlike svn's release.py and dist.sh pair which manages the *process*
rather than just producing tarballs).

-g

On Fri, Mar 16, 2012 at 16:38, Greg Stein gst...@gmail.com wrote:
 On Fri, Mar 16, 2012 at 15:17, Graham Leggett minf...@sharp.fm wrote:
 On 16 Mar 2012, at 9:05 PM, William A. Rowe Jr. wrote:

 This was asked and answered before, this project rejects automake.

 Can you cite when this took place?

 Sure I could, but you have the same email archives I do.

 And I can't find the discussion you're referring to in those archives. Like 
 I said, can you cite please?

 http://mail-archives.apache.org/mod_mbox/apr-dev/200012.mbox/%3cpine.lnx.4.30.0012152349240.2652-100...@rossini.schumann.cx%3e
 http://mail-archives.apache.org/mod_mbox/apr-dev/200103.mbox/%3c20010310060247.x27...@lyra.org%3e

 Plus lots of other references of people saying no way on automake.
 None of those comments are explained, beyond relying on people's
 personal experience (and hatred) of automake.

 -g

Re: Using autoconf/automake/libtool

[Greg Stein]

On Fri, Mar 16, 2012 at 16:59, William A. Rowe Jr. wmr...@gmail.com wrote:
 On 3/16/2012 3:38 PM, Greg Stein wrote:

 Plus lots of other references of people saying no way on automake.
 None of those comments are explained, beyond relying on people's
 personal experience (and hatred) of automake.

 Part of this is that apr evolved naturally from two different masters
 who guided its initial functionality and scope... Apache HTTPD and
 Subversion.  I'm betting you will find far more detailed arguments
 and specific experiences with automake on those dev lists.  Many very
 specific automake - autoconf complaints date to the 1999 effort to
 create Apache2-nspr and can be found in pre-ASF archives.

Subversion started with automake. We ripped it out because it was
causing way more harm than good.

Cheers,
-g

Re: APR hash vs httpd implementation

[Greg Stein]

I think that question is best answered by the people who develop
mod_cache, aka d...@httpd.apache.org.

That said, I'll offer a guess: that is along-lived hash table that
will see plenty of churn over time. An APR hash table would continue
to grow and consume memory, but you really don't want that to occur in
mod_cache. Thus, to keep memory reasonably constrained, it avoids
using pools.

Cheers,
-g

On Mon, Dec 5, 2011 at 13:52, sridhar basam s...@basam.org wrote:

 Anyone know why the mod_cache code has an almost identical implementation of
 the apr_hash* functions? Seems like the only difference is that the
 mod_cache implementation isn't using APR pools and has a fixed size  table.
 Are there any advantages using one over the other?

 thanks,
            Sridhar

Re: APR on CI

[Greg Stein]

On Fri, Jun 24, 2011 at 10:23, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 6/24/2011 5:38 AM, Branko Čibej wrote:
 On 23.06.2011 23:36, William A. Rowe Jr. wrote:
 anyone who wants to beat me to it, my initial thought is to borrow
 from the subversion project.

 Subversion has a build setup that does exatly what you're describing,
 i.e., generates almost any flavour of MSVC project files (and Unix
 makefiles) from a generic source tree description. Sure it's not SCons,
 but I don't see the SCons build working on Windows anyway.

 So why would APR not want to adopt a build system that's been working
 just fine for a decade?

 That's my thought, too.

Some of this was started in build/gen-build.py years ago. We use that
on Unix today, but with some more work, it could be extended to
generate Windows files.

Cheers,
-g

Re: Proposal: splitting APR and former apr-util libraries

[Greg Stein]

On Thu, Jun 2, 2011 at 07:51, Graham Leggett minf...@sharp.fm wrote:
...
 If people are starting their own portability libraries, then it shows that
 apr is not fit for purpose in its current form, and that needs to be
 addressed by the apr project. I don't recall much discussion happening over
 combined vs split, suddenly we were combined, and as I recall nobody
 provided an explanation as to what problem they were trying to solve by
 doing so.

I tried to bring up discussion about concentrating on just OS
portability and dropping all the other gunk a couple years ago. See
the thread titled APR: Portable across Operating Systems, or
Libraries? back in January 2009. It kinda devolved into just talking
about platforms.

The part about combining... I don't know where exactly that came from.
I remember some discussion, but I was already thinking the
functionality should be dropped (whether merged or not).

 It seems what we're working towards is combining apr and apr-util, removing
 most of the stuff that was in apr-util, ending up pretty much back with apr,
 which leads me to ask why we ever bothered combining the two in the first
 place.

Dunno. Go do the research in the svn logs. Somebody did the commit.
Look for the discussion around then, or ask that committer.

I've never supported it, so I just stopped worrying about it since the
community seemed supportive of that direction... *shrug*

Cheers,
-g

Re: Proposal: splitting APR and former apr-util libraries

[Greg Stein]

On Wed, Jun 1, 2011 at 18:37, Graham Leggett minf...@sharp.fm wrote:
 Hi all,

 A while back, the apr and apr-util projects were combined into a single
 project, however this amplified a problem we have been suffering for a
 while.

 APR attempts to provide portable access to the following:

 - Low level APIs, such as memory management, file access, process/thread
 handing, etc, relying on basic OS functionality provided by glibc and
 friends.

This is what apr used to be.


 - High level APIs, such as XML parsing, dbm and friends, SQL database and
 LDAP drivers, and crypto, relying on specific libraries providing each
 service.

And this is what apr-util used to be.


 The problem with mixing the two together is that many applications only care
 about the low level stuff, they don't want to link to BerkleyDB or expat
 just to get access to APR pools. This problem was in turn made worse when
 apr and apr-util was combined. It made sense that basic APIs like base64,
 date handling, string handling, etc should have moved to APR from apr-util,
 but what didn't make sense was moving everything.

 Some APIs, such as the dbd SQL library, the LDAP library and the crypto API
 can be separated out from APR at build time on some platforms, and this is
 done by vendors like Redhat, who ship a range of APR packages containing the
 parts you need. This doesn't go far enough.

 What I propose is that we take the APIs in the second group, including but
 not limited to XML, dbm, dbd, ldap and crypto, and spin these out into
 specific dedicated projects of their own under the APR umbrella, with their
 own release cycles, tags and branches. This would solve the following
 problems:

You're just talking about bringing back apr-util.

Making these N different packages doesn't do much beyond just what the
old apr-util did. I guess it solves a bit of dependency stuff.

...

Personally, I gave up on the combined vs split argument a long time
ago. This community wanted to combine everything, and I felt
differently. It happens. I also felt that APR has got a lot of old,
clunky code that needs to be cleaned up. As a result, I started my
PoCore project to deal with just the low-level portability concerns,
with a full revisit of all the concepts based on experience with APR,
HTTPD, svn, and serf. High-level stuff can be left to applications or
other third-party libraries.

Cheers,
-g

Fwd: Prior to apr 2.0 / httpd 2.4...

[Greg Stein]

I saw dev and was thinking this was on dev@apr... but it was @httpd.

Anyways... APR peeps: see below.


-- Forwarded message --
From: Greg Stein gst...@gmail.com
Date: Mon, Mar 21, 2011 at 10:38
Subject: Re: Prior to apr 2.0 / httpd 2.4...
To: d...@httpd.apache.org, William A. Rowe Jr. wr...@rowe-clan.net


On Sun, Mar 20, 2011 at 21:13, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 3/20/2011 7:43 PM, Dan Poirier wrote:
 On Sun. 2011-03-20 at 07:47 PM EDT, William A. Rowe Jr. 
 wr...@rowe-clan.net wrote:

 [1] Note particularly that expat appears to be abandoned, no releases
 in almost 4 yrs, with a significant security issue hanging over it we
 patched in apr.  No effort appears to be expended in providing any
 alternate non-expat apr_xml interfaces.

 For APR to continue bundling expat seems easiest, in the absence of
 anyone motivated to do something more.

 I wish we had a better understanding of where expat is headed, or if it
 is truly abandoned.  It seems strange to rely on an orphaned dependency.

 Anyone have any inside knowledge or informed opinion?

I'm a committer on Expat, but (as you've noted) the project has had no
attention for quite a while. I wasn't aware of a security problem in
there, however.

Even if I dropped a new release of Expat, would we want to rely on the
external build (and latest release being propagated) or continue to
ship a patched Expat within APR?

Switching to libxml2 would be possible (it is MIT licensed), but would
require a lot more coding work in the xml support. Users of APR (1.x)
also depend on Expat being available, and a switch would require them
to rewrite their XML parsing code. Maybe that is acceptable for apps
to switch to 2.0?

In short: I can make a release happen, but would that matter to the APR project?

Cheers,
-g

Re: Fwd: Prior to apr 2.0 / httpd 2.4...

[Greg Stein]

On Mon, Mar 21, 2011 at 20:04, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 3/21/2011 6:06 PM, Greg Stein wrote:
...
 Even if I dropped a new release of Expat, would we want to rely on the
 external build (and latest release being propagated) or continue to
 ship a patched Expat within APR?

 'build' - you mean package?  Yes, we default to an external apr today
 if one is found.  With none detected, ./configure works up apr's distro.

 For 2.0 I'd like to see us shift our expectation if we build in tree,
 to expat/ sitting in parallel to apr/ - but that's minor.  It would
 allow downstream users to either bundle or leave expat 2.0.2 unbundled
 and apr project wouldn't have to worry about new security issues at
 some point in the future when 0.9/1.x are less frequently distributed.

Oh, I'm all for unbundling. I think it is mostly about whether APR
wants to bundle the best Expat rather than potentially linking
against a non-secure version. Of course, I guess that could happen
today. Maybe we could simply detect the Expat version and provide a
warning (hey! get 2.0.2. we'll go with this, but you should update.)


 Switching to libxml2 would be possible (it is MIT licensed), but would
 require a lot more coding work in the xml support. Users of APR (1.x)
 also depend on Expat being available, and a switch would require them
 to rewrite their XML parsing code. Maybe that is acceptable for apps
 to switch to 2.0?

 Of course those users could continue to link to expat.  Are you saying
 they doing cross aprexpat manipulation?  That sounds as unsound as our
 current ldap practices.

As a concrete example: Subversion directly uses the Expat APIs. We
depend upon apr-util to find/provide those APIs by including expat
into its exported link switches, or to compile/bundle Expat directly
into the apr-util library. That allows Subversion to skip a whole
bunch of config-time logic to locate/link against Expat.

Applications that expect this kind of behavior (find me Expat) would
need to be be recoded to discover Expat for themselves. And/or
discover libxml2.

...
 In short: I can make a release happen, but would that matter to the APR 
 project?

 It matters to expat from a credibility perspective, and it allows httpd to
 toss in 2.0.2 expat sources into their srclib/ distribution.  I don't know
 that apr cares.

Alrighty. Thanks.

Cheers,
-g

Re: reducing memory fragmentation

[Greg Stein]

On Fri, Feb 18, 2011 at 16:55, Stefan Fritsch s...@sfritsch.de wrote:
 On Thursday 17 February 2011, Jim Jagielski wrote:
 Please also look at Greg's pocore memory allocation stuff...
 his hash stuff is also quite nice. Would be useful to be
 able to use that as well

 That looks like a much bigger change than what I have just commited.
 But I agree that before trying to optimize apr's allocator, one should
 try pocore's.

 Have you thought about how to do this? Probably every apr pool would
 be a wrapper for a pocore pool. But what about the other users of
 apr_allocator, like bucket allocators?

There is a branch in apr for wrapping pocore's pools and hash
tables[1]. Obviously, the indirection slows it down, but it does
demonstrate how it would work. (and it does: I've run the entire svn
test suite using this wrapping)

Just one comment: use pocore's child pools rather than its post
notion. I need to get rid of the posts and simply speed up child
pools.

The basic problem with the apr allocator is its granularity. The reuse
of memory is also a problem. pocore will store arbitrary-sized
segments and unused fragments and whatnot into a red-black tree to
quickly grab it and reuse it.

My experiments show that mmap/munmap are NOT speed-advantageous on
MacOS. But if you're looking at long-term memory usage and avoiding
fragmentation... I don't have a good way to test that. That said,
pocore should not be subject to fragmentation like apr. Its coalescing
feature (designed w/ the APIs present, but not yet coded) will avoid
much fragmentation.

Cheers,
-g

[1] http://svn.apache.org/repos/asf/apr/apr/branches/gstein-pocore/
... see memory/unix/apr_pools.c and tables/apr_hash.c

Re: why do we need this pain?

[Greg Stein]

On Wed, Oct 6, 2010 at 20:01, Guenter Knauf fua...@apache.org wrote:
 Am 07.10.2010 01:36, schrieb Mike Meyer:

 For the record - I'm against the change. RFC 2823 says the Reply-To
 header is an originator field, and the list is *not* the originator of
 the message.

 the list *is* the originator since it sends the mail to me, and not you

No. The list is a distribution mechanism.

Adjusting the Reply-To means that I cannot directly email the author.
I need to cut/paste their email address, but that might not be right.
They may have set a Reply-To on where they really wanted replies. If a
mailing list alters it, then information is lost.

 personally, so this is probably again something to discuss ...
 though I really dont want to start flame wars now about if an RFC expresses
 things right or if its practical; for too many others its not practical and
 I think that counts. I have to deal with a bunch of other mailing lists, and
 with all I can just hit 'reply' without having to care about, so its really

I hit reply or I hit reply to all. Simple. It works all the time
on lists without a reply-to set.

On lists *with* reply-to set, then I need to cut/paste to get a
message only to the author. Fuck that.

 anoying that I have to care about with this one list - and in fact what
 happens is that I always 1st spam the original author before I realize after
 a while that I didnt hit the list (even just now happened). Also I find it
 equally annoying that I always get 2 identical mails from such lists: one
 via list, and one directly from author;

And I see only one. Get a real MUA.

 not to mention other spamming
 effects such that the reciepient's mailer collects my mail address
 automatically (probably as default setting, and without knowing by the
 user), and in case of a virus attack my address is amongst those harvested
 by the virus ...

Now you're just making shit up. Your address always come through the
mailing list. The only topic here is what sits in the Reply-To field,
not the Sender or the From or the envelope.

Oh boo hoo, you can't reply to the list with just Reply. Get over it.
Hit reply to all and you'll be fine.

Cheers,
-g

Re: why do we need this pain?

[Greg Stein]

On Wed, Oct 6, 2010 at 19:12, Guenter Knauf fua...@apache.org wrote:
 Am 06.10.2010 21:40, schrieb Sander Temme:

 Please make Reply-To default to the list.  It's a discussion list,
 with discussions taking place on-list.  So responses should go to the
 list.

 ok, since we are 3 now who would like to have it changed, and the rest seems
 not to care about, how can we proceed? Whom do I have to ask for the change?
 who is list manager?

24 hours is NEVER enough time to call it Done. Minimum is always
72... you should know that.

And not care is different from are you fucking kidding me? this
stupid discussion again? No, I think it is because people are tired
of the Reply-To discussion crap and are simply hoping not to have to
deal with it.

-g

Re: why do we need this pain?

[Greg Stein]

We do not munge Reply-To on dev@ or priv...@. I'm not subscribed to
users@, so I dunno.

Commit messages (which originate from the commit script) have a
Reply-To to redirect responses to the dev@ list, to keep discussion
off the commits@ list.

On Thu, Oct 7, 2010 at 12:44, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 Two major consumers of apr are the httpd and svn projects.  Many/most
 of our subscribers are their subscribers.  We know how httpd list
 processing is configured... how is the svn dev@ list configured?

Re: why do we need this pain?

[Greg Stein]

On Thu, Oct 7, 2010 at 10:32, Jeff Trawick traw...@gmail.com wrote:
 On Thu, Oct 7, 2010 at 4:52 AM, Greg Stein gst...@gmail.com wrote:
...
 Oh boo hoo, you can't reply to the list with just Reply. Get over it.
 Hit reply to all and you'll be fine.

 I just love it when people get all rude for no reason at all.

That's not rude. That is just un-sympathetic. This kind of mailing
list behavior is common on the Internet, so people should be able to
deal with it. And they should be able to deal with reply-to-munging,
which is also quite common.

Somebody saying consensus is reached [after 24 hours], so who do I
contact to change this? is rude in my book. It never gave the
community time to comment on the issue. And changing the dynamics of
how the community talks to each other *is* something to give enough
time to. 72 hours. Minimum.

 Oh please be rude to me too, Greg!!!  Here goes:  I hate reply-all as
 well because I always end up having to fix the To: and yank out the
 duplicate recipients with my mail client.

That's a statement of opinion. You gotta try harder to be rude :-)

Cheers,
-g

Re: why do we need this pain?

[Greg Stein]

... [query about svn lists]

On Thu, Oct 7, 2010 at 17:29, Greg Stein gst...@gmail.com wrote:
 We do not munge Reply-To on dev@ or priv...@. I'm not subscribed to
 users@, so I dunno.

 Commit messages (which originate from the commit script) have a
 Reply-To to redirect responses to the dev@ list, to keep discussion
 off the commits@ list.

Correction: the list is configured to munge reply-to (ie. it isn't the
commit script inserting it). Occasionally, people also email commits@,
and those have a (redirecting) Reply-To to try to send discussion back
to d...@.

Cheers,
-g

Re: [Patch] apr_filepath_merge() on c:path fails consistently on Windows if the current directory is c:/windows instead of C:/Windows

[Greg Stein]

Applied in r960665 to trunk.

Backports will be needed before future branch releases (unsure what
the schedule is for that).

Thanks,
-g

On Mon, Jul 5, 2010 at 08:43, Bert Huijben b...@qqmail.nl wrote:
        Hi,

 As mailed in November 2009 [1], simple apr_filepath_merge() calls on paths
 like C:/Windows fail for users that use a shell that turns their active
 directory in a c:/users/bert style instead of the more common
 C:/users/bert (note the lower case 'C').

 The current APR code just assumes that drive letters returned by the Windows
 current path functions are always uppercase, which is not the case. This
 issue is reported every few months on different Subversion mailinglists and
 probably seen much more often by users that can't explain any of this.

 The patch attached to this mail removes the assumption that the drive
 letters must always be uppercase and adds a test which shows the error
 behavior. Easier ways to reproduce are adding a program shortcut with a
 lower case letter in the 'Start In' box, using CygWin or using 'CD /D
 c:\windows' in a dos prompt.
 (See also dirent_uri-tests.exe 36 in Subversion)


 I'm willing to work on more patches to improve APR and especially APR's
 performance on Windows, but if even this most important patch for me (and
 other Windows Subversion users) takes more than half a year to apply even
 with periodic pinging (some on private@), I can probably better spend my
 time starting my own APR patches for Windows project.


 For other long delayed Windows specific patches from me and others see [2]
 and [3] (but these didn't receive the same amount of review as [1]).

        Bert


 [1] http://marc.info/?t=12573771791r=1w=3
 [2] http://marc.info/?t=12714317221r=1w=2
 [3] http://marc.info/?l=apr-devm=127219937825412

Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows

[Greg Stein]

Applied to trunk in r960671.

I'm unclear on backporting/releases right now, so that hasn't been
done. We should do that before new branch releases.

Thanks,
-g

On Sat, Jun 5, 2010 at 05:57, Ivan Zhakov i...@visualsvn.com wrote:
 On Tue, Apr 20, 2010 at 13:07, Bert Huijben b...@qqmail.nl wrote:
 -Original Message-
 From: Bert Huijben [mailto:b...@qqmail.nl]
 Sent: vrijdag 16 april 2010 17:28
 To: dev@apr.apache.org
 Subject: Why does apr_file_read() with !APR_XTHREAD on Windows

       Hi,

 While profiling subversions file usage performance on Windows, one major
 slowdown shows:

 When a file is opened with APR_BUFFERED on Windows all read and file
 operations are slowed down by a mutex (or actually a critical section),
 even
 though the function is not documented to be thread safe unless you use
 APR_XTHREAD.

 I'm trying to find out why this is implemented this way on Windows, but
 not
 on the other platforms.

 * Are all file operations supposed to be slow but thread safe on Windows?
 * Or is this just to cover up old compatibility issues in other systems.
 (httpd defaults to threading on Windows)
 * Can we change this without breaking backwards compatibility?
 (I'm willing to write patches, etc.)
 * Or is it a better route to add a new flag that disables this mutex
 around
 the buffering.

 Looking at the subversion history of this mutex, I found that it was
 introduced in r60083 (may 2000) and the documentation on why the mutex
 was
 added is nonexisting.

 Going forward ten years since that revision, we got hyperthreading and
 multicore systems and the critical section which used to be fast
 (implemented as an interlocked exchange) is now much slower because it
 has
 to perform actual CPU and caching synchronization.


 I would like to remove this performance penalty of using the mutexes for
 Subversion (which explicitly documents that you can't use its instance
 objects in multiple threads at the same time)... What are the recommended
 steps I should take?

 Ping. No response at all in this thread.

 Any suggestions on what steps to take to reduce the slowdown?

 Any updates? I've prepared patch (see attachment) and made some
 performance testing. Reading file byte-by-byte many times gives the
 following rough numbers:

 single core CPU
 
 unpatched:   205  (time ticks)
 patched:       72    (time ticks)
 Performance improvement: 64%

 2 core CPU
 =
 unpatched:   217  (time ticks)
 patched :      92    (time ticks)

 Performance improvement: 57%

 Any chance to get this committed to trunk and backport to 1.3.x?

 --
 Ivan Zhakov
 VisualSVN Team

Re: Why does apr_file_read() with !APR_XTHREAD use mutexes on Windows

[Greg Stein]

On Mon, Jul 5, 2010 at 16:33, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 7/5/2010 2:49 PM, Greg Stein wrote:
 Applied to trunk in r960671.

 I'm unclear on backporting/releases right now, so that hasn't been
 done. We should do that before new branch releases.

 I'm 99.5% sure the mutex locking existing before I had added the XTHREAD
 flag.  The .5% leaves me wondering if we should do this to 1.x.

We want it in Subversion.

Who are the other APR users that might be affected by such a thing?
Which relied on the undocumented behavior?

Cheers,
-g

Re: python3.1

[Greg Stein]

On Fri, May 21, 2010 at 00:23, Philip M. Gollucci
pgollu...@ridecharge.com wrote:
 Howdy,

 So
 http://docs.python.org/release/3.0.1/whatsnew/3.0.html#porting-to-python-3-0

 specifically says not to try to
 if 2.x
  stuff
 else 3.x
  other stuff
 fi

 Attached is a diff for gen-build.py using 2to3. I'm not exactly sure how
 to fanagle this without duplicating the into 2 files gen-build2.py and
 gen-build3.py.  configure.in would need to me modded to call the right
 one based on the python version.

 I'm looking at this specifically b/c
 http://www.freebsd.org/cgi/query-pr.cgi?pr=146621cat=

 Also you need this diff to build/buildcheck.sh
 $ svn diff
 Index: buildcheck.sh
 ===
 --- buildcheck.sh       (revision 946860)
 +++ buildcheck.sh       (working copy)
 @@ -10,7 +10,7 @@
  echo            to build APR from SVN.
  exit 1
  else
 -py_version=`python -c 'import sys; print sys.version' 21|sed 's/ .*//;q'`
 +py_version=`python -c 'import sys; print(sys.version)' 21|sed 's/
 .*//;q'`
  echo buildconf: python version $py_version (ok)
  fi

This patch is safe to apply. In 2.x, you're simply printing a
parenthesized expression. In 3.x, you're invoking the print function.
No problem.

...

In your patch, everything is safe to apply except for the import
changes. For that, I would suggest:

try:
  import ConfigParser from ConfigParser
except ImportError:
  # try the 3.0 equivalent
  import ConfigParser from configparser

and then change the code to simply instantiate ConfigParser() rather
than $x.ConfigParser()

The try/except is a very minor weirdness in order to support both
Python versions.

Cheers,
-g

Re: [PATCH] apr_hash_this_{key,klen,val}

[Greg Stein]

On Tue, Mar 9, 2010 at 16:42, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 3/9/2010 3:37 PM, Hyrum K. Wright wrote:

 I'm also planning a followup which const-ifies the apr_hash_index_t params 
 to these functions, as well as apr_hash_this().  Thoughts?

 Note const'ness will only be alterable with apr 2.0 forwards.

It is *totally* fine to add a 'const' to a parameter that was not
there before. That does not change the ABI whatsoever, and it will not
break the API for callers. It merely gives them more information at
compile time.

Cheers,
-g

Re: [PATCH] apr_hash_this_{key,klen,val}

[Greg Stein]

On Fri, Mar 12, 2010 at 11:39, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 3/12/2010 5:21 AM, Greg Stein wrote:

 It is *totally* fine to add a 'const' to a parameter that was not
 there before. That does not change the ABI whatsoever, and it will not
 break the API for callers. It merely gives them more information at
 compile time.

 int oldfunc (const char *result);

 int brokefunc ()
 {
    char *res = oldfunc();
 }

 doesn't compile on a single platform I know of.

Of course not. I have NO IDEA what the hell you're talking about. Why
would you even attempt to assign an int function return to a char
* variable? And that function is declared to take a parameter which
you didn't give it. It's just nonsense code.

 Your statement makes no sense; how does adding const'ness to char *result
 not come with source code level compatibility breakage?

We're talking about a function prototype that current says:

APR_DECLARE(void) apr_hash_this(apr_hash_index_t *hi, const void **key,
apr_ssize_t *klen, void **val);

and add a const to a parameter, thusly:

APR_DECLARE(void) apr_hash_this(const apr_hash_index_t *hi, const void **key,
apr_ssize_t *klen, void **val);


THAT is a compatible change.

There are a number of APIs in APR which could grow more const-ness in
their params.

Cheers,
-g

Re: Future tag plans

[Greg Stein]

On Fri, Nov 13, 2009 at 00:16, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 Greg Stein wrote:

 The SVN API uses apr_pool_t. That typedef could disappear in APR 2.x,
 breaking our 1.x APIs.

 Thus, we cannot and will not support APR 2.x in the SVN 1.x series.

 could - cannot/will not ?  what a leap.

 Gheesh, seriously, sounds like your polite point of [oh, and 0.9 but we
 don't talk about that :-]

 Maybe apr_pool_t goes poof, most likely it doesn't, and either way it's
 entirely possible to do this.  You are simply being woodenheaded :)

My point was that *anything* could change and create a source/binary
compatibility problem. And in all likelihood, something *will* change
that we rely upon. One more argument to one function would bring down
the house. That is all it takes.

There isn't wiggle room here.

Cheers,
-g

Re: Future tag plans

[Greg Stein]

On Thu, Nov 12, 2009 at 14:27, William A. Rowe Jr. wr...@rowe-clan.net wrote:
...
 With SVN folks joining us at the foundation, I sure hope they pipe up
 with their interests and concerns around apr to help along 2.0.  In fact
 given the 1.7 release plan in Feb(?) timeframe, this could make sense.

Eh? Subversion is not going to move to or use 2.x until... never.

Our versioning guidelines (the same as APR, btw) forbid a move to APR
2.x. Clients that link against svn 1.x (and thus, APR 1.x) need to
continue working throughout the svn 1.x line. And third-party clients
use a lot of APR code which also means source and binary compatibility
from our APR layer.

We also have no plans whatsoever to move to svn 2.x. That implies a
break in our compatibility with huge ramifications across the svn
ecosystem. We have no desire to do that.

IOW, for all intents and purpose, svn will never move beyond APR 1.x.

Cheers,
-g

ps. we sorta/kinda/somehow support APR 0.9, but we don't like to talk
about that :-P

Re: Future tag plans

[Greg Stein]

On Thu, Nov 12, 2009 at 23:51, Arfrever Frehtes Taifersar Arahesis
arfrever@gmail.com wrote:
 2009-11-12 21:59:20 Greg Stein napisał(a):
 On Thu, Nov 12, 2009 at 14:27, William A. Rowe Jr. wr...@rowe-clan.net 
 wrote:
 ...
  With SVN folks joining us at the foundation, I sure hope they pipe up
  with their interests and concerns around apr to help along 2.0.  In fact
  given the 1.7 release plan in Feb(?) timeframe, this could make sense.

 Eh? Subversion is not going to move to or use 2.x until... never.

 Our versioning guidelines (the same as APR, btw) forbid a move to APR
 2.x.

 Subversion's versioning guidelines don't disallow supporting both APR 1 and 
 APR 2.

Yes, it does.

The SVN API uses apr_pool_t. That typedef could disappear in APR 2.x,
breaking our 1.x APIs.

Thus, we cannot and will not support APR 2.x in the SVN 1.x series.

And no, you cannot paper that over with preprocessor macros. Binary
compatibility is required.

I have no idea why you think we could possibly support both.

-g

Re: svn commit: r745119 - /apr/apr/trunk/configure.in

[Greg Stein]

On Mon, Feb 23, 2009 at 17:40, Mladen Turk mt...@apache.org wrote:
...
 OK. I've remove it,
 although still don't understand why something optional is
 such a big deal, namely because it doesn't change anything
 regarding default build.

When the ABI can potentially change, then application developers need
to be wary of what they're linking against. As long as we can
confidently tell people the ABI is rock solid, then those devs won't
have to worry. Introducing ABI variability into the APR ecosystem is a
Bad Thing.

  If you are bundling up a custom application, you can easily add some
 later shell script to move around files however you want them to be called.

 It's not that easy. It requires patching the configure.in,
 but we'll have to live with that. The point is that moving isn't
 enough. One needs to rewrite the apr-config and .lai file as well,
 so making a patch to configure.in is much easier.

If APR is being packaged into a .jar for private use, then what do you
need apr-config for?

Cheers,
-g

Re: svn commit: r746589 - in /apr/apr/trunk: ./ include/ include/arch/unix/ include/arch/win32/ misc/unix/ misc/win32/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadpr

[Greg Stein]

On Mon, Feb 23, 2009 at 13:16, Mladen Turk mt...@apache.org wrote:
 Joe Orton wrote:
...
 -1

 I announced that twice on this list during the last year,
 so you should spoke then thought.

And people miss email. Or they thought it might be implemented
differently. Or WHATEVER.

It doesn't matter. There is no time limit on standing against a
change. It is possible to veto something that was checked in *months*
ago. That change would then have to be backed out before release, or
some solution/compromise reached instead.

I'm also with Joe: stuff like this can be built *on top of* APR,
rather than being part of it. Create a shared memory segment, and pass
a cmdline switch. Or leave a descriptor open with the name of the
segment which the parent/child can write/read. These solutions could
be done as part of apr-util, no?

Cheers,
-g

Re: SCons Updates... 2

[Greg Stein]

Check for ebcdic? Are we *really* going to continue support for that?
Seriously, folks.

On Sun, Jan 11, 2009 at 08:04, Ryan Phillips r...@trolocsis.com wrote:
 More updates...

 * Add detection of IPv6
 * Fix return code checking of TryRun's... Scons expects 1 as success (meh)
 * Add ebcdic,  nonblock inherited check, tcp_nodelay, union semun,
  TCP_CORK/TCP_NOPUSH, getrlimit/setrlimit, in_addr, sockaddr_storage,
  rlimit struct, ... and more
 * Add sctp check
 * Add accept filter check

 -Ryan

Re: SCons Updates... 2

[Greg Stein]

On Fri, Jan 23, 2009 at 13:24, Jeff Trawick traw...@gmail.com wrote:
 On Fri, Jan 23, 2009 at 5:31 AM, Greg Stein gst...@gmail.com wrote:

 Check for ebcdic? Are we *really* going to continue support for that?
 Seriously, folks.

 What is the better criteria?
 * offends sensibility of at least one APR contributor
 * actively used by and depended on by multiple APR contributors (and may be
 a partial sponsor of the warm, dry environment necessary for APR hacking,
 though that's probably a difficult determination to make for certain)

If it is still being used, then... well, geez.  *shudder*

And in response to your question, duh. not like I have any super-vote
here. just opening a discussion.

Cheers,
-g

Re: APR: Portable across Operating Systems, or Libraries?

[Greg Stein]

Why? Maintenance cost. Plain and simple.

Is APR truly used on these other platforms? I've gotta believe there
is some data on that somewhere.

Then, there is the age-old answer, those edge cases can stick to APR
1.x and HTTPD 2.x. Modern operating systems would use APR 2.x and
HTTPD 3.x.

Cheers,
-g

On Fri, Jan 23, 2009 at 13:24, Ryan Bloom rbl...@gmail.com wrote:
 Why do you want to jettison edge platforms?  The original goal was to keep
 HTTPd as portable as 1.3 was, which meant APR had to support mainframes,
 OS/2, etc.  All of those edge platforms are what made APR challenging to
 create and maintain, but they also provide a lot of value for the people who
 want their code to work on mainframes, but don't want to write their own
 portability library.

 Removing this support takes away a web server (at the very least) from
 openBeOS, OS400, OS/2, etc.  While these platforms may not be mainstream
 these days, dropping support for them from HTTPd (the natural result of
 dropping support from APR) seems like a decision that can only be made after
 discussion with APR's users, not the developers of APR itself.

 Just a few thoughts from the gallery.

 Ryan

 Ryan Bloom
 r...@apache.org
 r...@rkbloom.net
 rbl...@gmail.com


 On Fri, Jan 23, 2009 at 6:26 AM, Graham Leggett minf...@sharp.fm wrote:

 Greg Stein wrote:

 When thinking about 2.0, I'm having a hard time with the idea of
 pulling apr-util into regular apr. We've got a lot of stuff in
 apr-util that has nothing to do with Portability. Basically, I see
 apr-util doing one of two types of things:

 * common API to access functionality (dbd, ldap, crypto)
 * useful functionality built on APR

 I think it would be great if we could concentrate on just a core APR
 that offers OS portability, and that we also jettison edge platforms
 (keep posix and windows only). And that we trim out functionality
 (i.e. apr_tables) that have nothing to do with portability (tho we
 keep pools as a lifetime mgmt capability for OS objects).

 Thoughts?

 I think both apr and apr-util are still both based on the idea of
 portability.

 In apr, the focus is on making individual or small sets of functions
 available in a portable way, while the focus of apr-util is to have large
 or complex sets of functionality (access a database, access an LDAP
 server, encrypt a string) available in a portable way.

 That said you're right that some parts of it, like tables, fall into the
 category of useful stuff rather than portable stuff. Perhaps an idea
 could be to move the useful stuff into (a want for a better name)
 apr-useful, which would be the useful stuff library built on top of the
 portability provided by apr.

 Regards,
 Graham
 --

Re: SCons Updates... 2

[Greg Stein]

On Fri, Jan 23, 2009 at 14:41, Jeff Trawick traw...@gmail.com wrote:
 On Fri, Jan 23, 2009 at 7:40 AM, Greg Stein gst...@gmail.com wrote:

 On Fri, Jan 23, 2009 at 13:24, Jeff Trawick traw...@gmail.com wrote:
  On Fri, Jan 23, 2009 at 5:31 AM, Greg Stein gst...@gmail.com wrote:
 
  Check for ebcdic? Are we *really* going to continue support for that?
  Seriously, folks.
 
  What is the better criteria?
  * offends sensibility of at least one APR contributor
  * actively used by and depended on by multiple APR contributors (and may
  be
  a partial sponsor of the warm, dry environment necessary for APR
  hacking,
  though that's probably a difficult determination to make for certain)

 If it is still being used, then... well, geez.  *shudder*

 And in response to your question, duh. not like I have any super-vote
 here. just opening a discussion.

 Here's a better opening to such a discussion ;)

 Hey guys, here are some platforms/nuances/whatever currently in APR that I
 think we might be able to drop in 2.0.  Which are still being
 used/maintained? ;)

hehehehe.

Re: SCons Updates... 2

[Greg Stein]

Understood. But if you're writing new code (for APR 2.x), then why
wouldn't you develop the codebase in Unicode? Link with old
libraries might be an answer, though I'd say it is outside the scope
of APR to interact with that old library.

Frankly, it would be nice if the APR 2.x API was pure Unicode charset,
encoded as UTF-8 across the board.

I'm not disputing that EBCDIC is still in use (as you eminently point
out). Just that I fail to see it has a strict, useful requirement for
APR 2.x.

Cheers,
-g

On Fri, Jan 23, 2009 at 14:58, Steve Comstock st...@trainersfriend.com wrote:
...
 Greg,

 I'm just a lurker here, and I am also a mainframe bigot.

 I'd like to point out a few things about IBM mainframes
 and in particular z/OS, then I'll go back to lurking.

 Of course you know modern mainframes have hardware
 instructions that process data in ASCII and Unicode
 (UTF-8, UTF-16, and UTF-32), IEEE binary floating
 point, IEEE decimal floating point, and other
 instructions that can easily convert data between
 little endian and big endian for portability, and
 more.

 You're aware that mainframes can run Linux, either
 natively or under z/VM.

 I'm sure you acknowledge that z/OS still processes
 a huge percent of corporate, customer, and government
 data in the largest organizations.

 Did you know you can run UNIX under z/OS? That z/OS
 comes with a free HTTPD server? That IBM recently
 made available a port of Apache to run under z/OS,
 as a no-charge product? Of course, Java, C, and C++
 are available under z/OS. But even more mundane
 languages such as Assembler, COBOL, and PL/I on
 z/OS support Unicode, XML, and the ability to
 create, say, CGIs. While accessing DB2, a fully
 relational database that also supports Unicode,
 XML, and LOB data objects natively.

 At the same time, code that was written 35 years
 ago continues to run with no recompile or relink.
 Now that's code reuse!

 I find all that pretty impressive. Here's a link to a
 paper on this:

  http://www.trainersfriend.com/Papers/Future_of_Mainframe.pdf

 or for a list of several papers I've written that are
 mainframe centric:

  http://www.trainersfriend.com/General_content/Book_site.htm


 But, of course, we're not here to start any relgious wars.
 I'll just go back to lurking now.



 Kind regards,

 -Steve Comstock
 The Trainer's Friend, Inc.

 303-393-8716
 http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

 == Check out the Trainer's Friend Store to purchase z/OS  ==
 == application developer toolkits. Sample code in four==
 == programming languages, JCL to Assemble or compile, ==
 == bind and test. ==
 ==   http://www.trainersfriend.com/TTFStore/index.html==

Re: apr-util uses apr's version in name of shared libraries?

[Greg Stein]

Yeah. That doesn't look right.

On 9/19/07, Jeff Trawick [EMAIL PROTECTED] wrote:
 (alternative subject: Jeff asks dumb FAQ about apr-util version expectations)

 AFAICT, apr-util is picking up

 ./build/rules.mk:APR_DOTTED_VERSION=1.2.11
 ./build/rules.mk:LINK = $(LIBTOOL) $(LTFLAGS) --mode=link
 $(LT_LDFLAGS) $(COMPILE) -version-info 2:11:2 $(ALL_LDFLAGS) -o $@


 from apr's rules.mk in order to determine its library name.

 So something which is supposedly apr-util 1.2.10 has a shared library
 called libaprutil-1.so.0.2.11



-- 
Greg Stein, http://www.lyra.org/

Re: io abstractions

[Greg Stein]

On 6/26/06, James Mansion [EMAIL PROTECTED] wrote:

The API is not unified because some platforms (notably, Windows) do
not allow for unification of the various types. There were problems

In all fairness, that's misinformation.  Its true iff your regard
select() as the unification point, but select() is only a band-aid


That's not very cool. Please don't tell me it is misinformation when
I was *THERE* when this code was put together, and that is the reason
we have numerous types.

And your treatise on async versus sync doesn't really matter/apply. We
have synchronous APIs. Period. Yes, it would also be nice to have
async, but that is orthogonal to the problem at hand.

-g

--
Greg Stein, http://www.lyra.org/

Re: io abstractions

[Greg Stein]

The API is not unified because some platforms (notably, Windows) do
not allow for unification of the various types. There were problems
with doing a select() type of operation on files, iirc (tho you could
with pipes and sockets). For basic read/write, unification is no
problem. I don't think you can unify the creation, and certainly not
the type-specific APIs.

Having N entry points version N enum variatns is no big deal. I would
prefer the N functions instead of a parameterized function. Note that
you cannot open stdout on Windows unless you use the special
function.

readv makes sense, as it is easy to simulate if the platform does not have it.

Cheers,
-g

On 6/25/06, david reid [EMAIL PROTECTED] wrote:

I've done some work over last 24 hours and have an outline of
abstracting the io functions. The aim is to remove the distinction
between files, socket and pipes - replacing them with a single apr_io_t
type. The exercise of figure out how it should work certainly opened my
eyes to how complex we've made the whole thing!

I've simply added the new code at present, but in order to gain much
we'd need to ditch the older code, hence it's really a change for 2.x
and beyond.

So far I have basic creation and closing working, but now the
architecture is in place getting read/write working shouldn't be hard.
There's also a small test app to make sure it's all working as expected.

Providing the same level of access we have at present isn't as easy as
it looks, and finding a simple api that covers everything may well be
impossible, but I'm hopeful we can cover most things under a nice simple
api. Exactly how much the perf will be hurt by the changes - I'm not
sure at present but may know once I have read/write working.

A few things have cropped up though that I'm not really sure about.

Why don't we have readv?
Why don't we just have a flagged version of the functions to open
stdxxx? Having both seems a touch silly and dramatic overkill.

Unless people scream about this not being the right direction to go I'll
try and find some time to progress the work a little more over the next
few days.

david




--
Greg Stein, http://www.lyra.org/

Re: current dbd initiatives

[Greg Stein]

On 6/8/06, Bojan Smojver [EMAIL PROTECTED] wrote:

Quoting Chris Darroch [EMAIL PROTECTED]:
...
 5) Renaming functions like apr_dbd_get_entry() to apr_dbd_entry_get().
 Is this the kind of thing that can be done with a minor version number
 change, i.e., in 1.3?

I think Garrett already answered this one - only possible when jumping
major versions. So, this is something for 2.0.


You can introduce the new names in a minor rev, deprecating the old
names. In 2.0, you would then remove the old names.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Re: current dbd initiatives

[Greg Stein]

On 6/14/06, Nick Kew [EMAIL PROTECTED] wrote:

...
   5) Renaming functions like apr_dbd_get_entry() to apr_dbd_entry_get().
   Is this the kind of thing that can be done with a minor version number
   change, i.e., in 1.3?

I thought we established that apr_module_verb_noun is the form used most
commonly throughout apr-util in any case!


Whatever. That is a separate discussion/debate; I was merely trying to
provide options within the versioning guidelines.

For the above case, the function implementation can be renamed to
apr_dbd_entry_get(), then a new function can be added, named
apr_dbd_get_entry, which simply calls the other with its params.
Update the header to rename the function, and add a new entry for the
old with a @deprecated remark.

Don't try to use #define here tho. Some users may want/need the func
address, so you can't use macros. Also, as Bill points out, you can't
convert the old func to a macro.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Re: Does or will APR support thread cancellation?

[Greg Stein]

On 5/22/06, Garrett Rooney [EMAIL PROTECTED] wrote:

On 5/19/06, Weihan Wang [EMAIL PROTECTED] wrote:
 Hi,

 I didn't see thread cancellation API but did see some code segments of
 APR that intend to implement it. Will APR API support cancellation in
 the near future? Thanks.

I don't know of anyone working on such a feature for APR.


Right. Generally, cancellation is considered very unsafe. Most APIs
nowadays do not support it.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Re: svn commit: r348499 - in /apr/apr/trunk: CHANGES poll/unix/select.c test/testpoll.c

[Greg Stein]

On Fri, Nov 25, 2005 at 07:55:28PM -0800, Brian Pane wrote:
...
 A procedural question on backports: are 0.9/1.0/1.1/1.2 using C-T-R
 rules, or R-T-C?

IMO, it should always be CTR.

If somebody disputes a fix for an older release, then put the burden
on them to do so. I much prefer more freedom in applying fixes. Put
the work on keeping stuff *out* than on bringing stuff *in*.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Home for apr-based wrappers?

[Greg Stein]

On Tue, Nov 01, 2005 at 08:49:27AM +, Joe Orton wrote:
...
 I think that apr-util should continue to be an everything plus the 
 kitchen sink repository for APR-based code which:

+1

 a) the committers of this project think is generally useful, and
 b) meets the expected standards of code quality, and
 c) is relatively small in magnitude (i.e. I'd be worried about
 dumping in tens of thousands of lines of new code)

Yup. (c) is why apr-iconv was busted out to a separate project. But
IMO, throwing more into apr-util is just fine for now.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: RFC: drop autoconf 2.13 support on trunk

[Greg Stein]

On Thu, Nov 25, 2004 at 10:44:21AM +, Joe Orton wrote:
 I'd like to propose also to drop autoconf 2.13 support on the trunk.

+1

(across the board, actually; no reason for httpd either)

-- 
Greg Stein, http://www.lyra.org/

Re: renaming apr_filetype enum entries

[Greg Stein]

On Sun, Sep 19, 2004 at 04:41:49PM -0500, William A. Rowe, Jr. wrote:
 At 04:20 PM 9/19/2004, Stas Bekman wrote:
 So if that's fine with everybody and now Bill has pulled down his veto, the 
 only thing to wait for is the APR_1_1 branch to appear? Any plans for that?
 
 APR_1_0 should be created soon, before new progress.
 
 HEAD should be 1_1 till we release it.

Know your tools, boys. We don't have to create a 1.0 branch right now.
Head can be 1.1. If we want 1.0 releases, *then* we create a branch. It is
easy to do that, based on the 1.0 tag. There is no need at all to hold any
development whatsoever.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: renaming apr_filetype enum entries

[Greg Stein]

On Sun, Sep 19, 2004 at 06:01:01PM -0400, Stas Bekman wrote:
 Greg Stein wrote:
...
 IMO, projects should just use the API of the oldest major revision that
 they can, and forget a bunch of compat stuff. If a project codes against
 version 1.0, then it will work for everything after that.
 
 mod_perl 2.0 needs to support apr 0.9.x (as long as 2.0.x requires it) and 
 it'll probably support 2.2 as well. So if those defines are added in apr 
 1.1 we can't use them w/o the compat layer, to support older libapr.

That's what I'm saying: don't use them. Make your life easier and forget
the compat layer. For some people, they'll go ahead and code to the new
1.1 API, and they'll use the better symbol names.

But, your call. :-)

...
 It will transparently work with both if we use APR_REG and friends. I
 don't want to add a bunch of #ifdef code to httpd if it isn't needed.
 
 Right, but there were just few opinions so far of whether both should be 
 supported or not. I just thought that the decision wasn't cast in stone yet.

Both *WILL* be supported. There is no question to that. That's an absolute
baesd on the compat rules. The only way to avoid supporting both is to
shoot for a 2.0 release, and I'll veto any change that forces a 2.0 so
darned soon. I would expect to live in 1.x land for at least a couple
years. When our API gets too kludgy because of deprecation or whatever,
*then* we move to 2.0 and clear that out.

I believe the only question on the table is whether the short form macros
(e.g. APR_REG) are part of the API, or whether they are deprecated.

But they *will* still exist.

...
 Well, what you're really doing is providing a 1.1 API to all users. I
 understand the motivation, but I'm not personally interested in that for
 httpd.
 
 You mean, you'd like to keep the old short defines used across httpd? and 
 inside libapr?

Just in httpd. APR can use the new macros, of course.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: renaming apr_filetype enum entries

[Greg Stein]

On Fri, Sep 17, 2004 at 07:54:10PM -0400, Stas Bekman wrote:
 As discussed back in June enum names in the apr_filetype_e entry are 
 polluting the APR_ defines namespace and it's hard to grok what APR_REG 
 means when it's used in the code. I've finally started to work on these as 
 I'm finishing the perl glue manpage for the apr_finfo interface.
 
 So any objecttions to the s/APR_/APR_FILETYPE_/ rename?
 
 In order to support older versions one will need to also provide a compat 
 layer:
 
 #ifndef APR_FILETYPE_NOFILE
 #define APR_FILETYPE_NOFILE  APR_NOFILE
 #endif

I think you have that backwards. Shouldn't it be:

#define APR_NOFILE APR_FILETYPE_NOFILE

i.e. the APR_FILETYPE_* macros are canonical and you're grandfathering the
  other macros

And the #ifndef wrappers are not needed. Just define the old names in
terms of the new.

...
 From what I understood, this should be applied only to the HEAD. Is that 
 correct?

Yes.

wrowe commented on the versioning implications of this. To be precise:

1) the new symbolic constants would appear in 1.1
2) httpd 2.2 (and 2.1) is planned to be built against 1.0
3) if mod_perl uses the new names, it needs to be built against 1.1
4) httpd 2.2 (and 2.1) will be able to work just fine with 1.1 without any
   recompilation being needed, but you may be fighting a battle against
   people distribution a 2.2/1.0 combo.
5) httpd 2.0 uses APR 0.9 (though it might be buildable against 1.0)

Choose your path for mod_perl, but point #4 seems like it will pose
trouble for your users.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: renaming apr_file_permissions defines

[Greg Stein]

On Fri, Sep 17, 2004 at 09:21:17PM -0500, William A. Rowe, Jr. wrote:
 At 07:53 PM 9/17/2004, you wrote:
 and the rename of apr_file_permissions group:
 
 s/APR_/APR_FILEPROT_/
 
 Veto - defer for 2.0

There is no reason to wait until 2.0. The versioning guidelines allow us
to provide new symbolic names in 1.x versions.

As long as APR_REG and friends exist in all 1.x versions, then everything
is fine. If 1.1 happens to include a new APR_FILETYPE_REG, then there
isn't a problem.

IOW, I'd encourage you to reconsider your veto. I don't see the problem
that you're trying to prevent.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: renaming apr_filetype enum entries

[Greg Stein]

On Sun, Sep 19, 2004 at 05:20:59PM -0400, Stas Bekman wrote:
 Greg Stein wrote:
...
 And the #ifndef wrappers are not needed. Just define the old names in
 terms of the new.
 
 yes, yes, inside apr they won't be needed. They will be needed inside 
 projects supporting more than one apr generation.

IMO, projects should just use the API of the oldest major revision that
they can, and forget a bunch of compat stuff. If a project codes against
version 1.0, then it will work for everything after that.

...
 4) httpd 2.2 (and 2.1) will be able to work just fine with 1.1 without any
recompilation being needed, but you may be fighting a battle against
people distribution a 2.2/1.0 combo.
 
 But this can be solved inside 2.2 by adding the ifdef-define-endif future 
 compatibility blocks as I've posted in my original proposal. So 2.2 will 
 transparently work with apr 1.0 and apr 1.1.

It will transparently work with both if we use APR_REG and friends. I
don't want to add a bunch of #ifdef code to httpd if it isn't needed.

...
 Choose your path for mod_perl, but point #4 seems like it will pose
 trouble for your users.
 
 it doesn't have much to do with mod_perl, besides us trying to keep the 
 Perl API consistent with C API, so it's easy to move between the two, 
 needing to know only one API.

Well, what you're really doing is providing a 1.1 API to all users. I
understand the motivation, but I'm not personally interested in that for
httpd.

 So if that's fine with everybody and now Bill has pulled down his veto, 
 the only thing to wait for is the APR_1_1 branch to appear? Any plans for 
 that?

I'd like to see us move the APR modules over to SVN. We can then move the
trunk to branches/1.0.x/, and leave the trunk for 1.1 development.

I believe the last vote go-round had support for moving to SVN, so it was
just a matter of make it so. (I'd have to go look, and if anybody
*doesn't* want to move to SVN, then please reiterate your concerns)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: cvs commit: apr-util/build/rpm apr-util.spec.in

[Greg Stein]

On Thu, Jul 01, 2004 at 10:45:06PM -, [EMAIL PROTECTED] wrote:
...
   +++ buildconf   1 Jul 2004 22:45:06 -   1.13
   @@ -74,3 +74,20 @@

# Remove autoconf cache again
rm -rf autom4te*.cache
   +
   +# Create RPM Spec file
   +if [ -f `which cut` ]; then
   +  echo rebuilding rpm spec file
   +  ( REVISION=`build/get-version.sh all include/apu_version.h APU`
   +VERSION=`echo $REVISION | cut -d- -s -f1`
   +RELEASE=`echo $REVISION | cut -d- -s -f2`
   +if [ x$VERSION = x ]; then
   +  VERSION=$REVISION
   +  RELEASE=1
   +fi
   +cat ./build/rpm/apr-util.spec.in | \
   +sed -e s/APU_VERSION/$VERSION/ \
   +-e s/APU_RELEASE/$RELEASE/ \
   + apr-util.spec )
   +fi

There is no need for the parens. That's just some extra baggage...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: apr-config and apr-1-config

[Greg Stein]

On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote:
 At 04:55 PM 7/1/2004, Joe Orton wrote:
 On Thu, Jul 01, 2004 at 11:45:44PM +0200, Graham Leggett wrote:
  Joe Orton wrote:
  
  I've noticed that the most recent CVS of 1.0.0 installs both 
  /usr/bin/apr-config, and /usr/bin/apr-1-config. Is this intentional?
  
  Yes, for the moment.
  
  How do you suggest the RPM should handle this? - at the moment 
  installing a v0 RPM and a v1 RPM simultaneously will cause a conflict. 
  Should we just leave it as is for now?
 
 Yes, just leave it for the moment I guess.
 
 If we leave it, and side-by-side installs are broken, this does not seem
 like a good initial release point for 1.0 :(


for the moment

Joe said it *twice*. Was it that non-obvious?


-- 
Greg Stein, http://www.lyra.org/

Re: cvs commit: apr/build jlibtool.c

[Greg Stein]

That license needs to be updated.

On Tue, Jun 29, 2004 at 12:41:11PM -, [EMAIL PROTECTED] wrote:
 martin  2004/06/29 05:41:11
 
   Added:   buildjlibtool.c
   Log:
   Commit the missing jlibtool.c from Justin's 
 http://www.apache.org/~jerenkrantz/jlibtool.c --
   It was referenced by configure --enable-experimental-libtool already.
   Also, it helps in building on platforms not directly supported by libtool
   (for those, libtools behaves utterly stupidly).
   
   Obtained from: http://www.apache.org/~jerenkrantz/jlibtool.c
   Reviewed by:jfclere apache.org
   
   Revision  ChangesPath
   1.1  apr/build/jlibtool.c
   
   Index: jlibtool.c
   ===
   /* 
* The Apache Software License, Version 1.1
*
* Copyright (c) 2000-2002 The Apache Software Foundation.  All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution,
*if any, must include the following acknowledgment:
*   This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgment may appear in the software itself,
*if and wherever such third-party acknowledgments normally appear.
*
* 4. The names Apache and Apache Software Foundation must
*not be used to endorse or promote products derived from this
*software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache,
*nor may Apache appear in their name, without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
* 
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation.  For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/

-- 
Greg Stein, http://www.lyra.org/

Re: 1.0 progress

[Greg Stein]

On Wed, Jun 16, 2004 at 12:24:31AM +0100, David Reid wrote:
...
 The proposed change to apr_initialise is presently veto'd by Greg, though
 there are a lot of +1's. I'm still hopeful Greg can explain his veto. That
 said there isn't a patch available yet, so I'm forced to say that this is
 bumped to 1.1, even though it could well be an api change. I'm guessing it
 could (possibly) be done by adding another function, so maybe we can avoid
 the change.

Heh. I had no idea what this was about. Needed to go look it up. Here is
my response/rationale for the veto:

[EMAIL PROTECTED], Message-ID: [EMAIL PROTECTED]

http://marc.theaimsgroup.com/?l=apr-devm=102928661608249w=2

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: documented 1.0 showstoppers

[Greg Stein]

On Thu, Jun 03, 2004 at 11:20:26PM +0100, David reid wrote:
...
  As Justin pointed out, the users seem to be just fine with it sitting in
  there. *TODAY*. So why would they suddenly be unhappy with it tomorrow?
 
  Release the damned thing as-is.
 
  1.0.0 won't be perfect, but maybe 1.0.1 or 1.1.0 or 2.0.0 will be. As Jeff
  says, we'll never get there, and never find out at this rate.
 
 Well, let's have a look at what's been proposed and see what makes sense.
 While I respect Justin's ideas of simply rolling, we have waited a LONG
 time for a 1.0 release so why jump at this point? The point of the
 timetable and it's 2 phases is to build in thinking time to try and get
 as many of these issues aired and resolved prior to a 1.0 release.

Because it has been empirically proven that wait for X does not work.
Without a change in point-of-view, we'll never get it released. Thus, the
just ship the frickin' thing is a way to break out of the deadlock.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: documented 1.0 showstoppers

[Greg Stein]

On Fri, Jun 04, 2004 at 11:51:18AM -0700, Stas Bekman wrote:
 
 There is one more problem. Not the whole API is tested and many APIs are 
 tested only partially. IMHO, you want to run coverage tests first and only 
 after passing a sensible coverage threshold, should 1.0 be released.

Feel free.

APR(UTIL) has been around a long time. Whatever people are interested in,
it has been used, and therefore tested. If it hasn't, then hey... it might
not matter than much.

And when people start to use it? If it is broken? Hey. That is what 1.0.1
is all about.

If you want to increase coverage testing, then go ahead. By all means. But
I'm with David: what exists on June 16 is going to be 1.0.0. If you don't
like what that will be, then apply your efforts to fix it.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: documented 1.0 showstoppers

[Greg Stein]

On Fri, Jun 04, 2004 at 12:43:22PM -0700, Stas Bekman wrote:
...
 You have a problem here, 1.0.1 will have to be backwards compatible with 
 1.0.0. So if now you have API problems which went so far unnoticed (or 
 ignored) you can't commit to them in 1.0.0.

You're assuming that a problem in the API exists. But you also talk about
coverage which is generally about the implementation.

Implementation bugs are easy to fix in a 1.0.1. API changes would require
a 1.1 release. Which we can also do IF we find a problem.

 Sure, here is a perfect solution for that problem. Introduce a new doxygen 
 marker. And start marking those solid, used and tested APIs as ready for 
 1.0. Release 1.0  which will have both kinds. The ones that are untested 
 should be marked as 'subject to change', and then there is no requirement 
 to have them tested.

That seems a bit silly. What makes you believe that the library is so
buggy that we have to mark areas as steer clear. People have been using
this thing for years.

As far as I'm concerned, there appear to be a couple dodgy places, but
that doesn't mean that we have to go and revamp the entire docset with new
markers.

 If you want to increase coverage testing, then go ahead. By all means. But
 I'm with David: what exists on June 16 is going to be 1.0.0. If you don't
 like what that will be, then apply your efforts to fix it.
 
 My efforts to fix it go totally ignored so far.

What are you talking about? You're a committer on APR. If you want to
increase the coverage of the test suite, then start writing tests and
committing them. I don't see what is stopping you.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: documented 1.0 showstoppers

[Greg Stein]

On Fri, Jun 04, 2004 at 12:49:09PM -0700, Stas Bekman wrote:
...
 Also, IMHO, all those folks who are pushing for 1.0 should instead help 
 writing tests. It's not fun, but asking to release 1.0 just because the

Sorry, but you don't have the right to tell me what I have to do. I
think that APR is ready as-is for a 1.0 release. You think otherwise.
That's fine. But if you want changes, then it is incumbent upon YOU to
make those changes. Not me.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: documented 1.0 showstoppers

[Greg Stein]

On Thu, Jun 03, 2004 at 01:35:06PM -0400, [EMAIL PROTECTED] wrote:
 On Thu, 3 Jun 2004, Justin Erenkrantz wrote:
...
  Can we fix it in 2.0?  Sure.  No reason that a 1.0 release prevents that.
  And, we might be able to fix it in 1.1, but it depends how we handle the
  specifics.  However, 1.0 does not have to be perfect!
 
 It can't be fixed in 1.1, because the whole API needs to be re-thought.
 As for why I haven't fixed it yet, I don't have the time.  I'm really
 sorry, but a new job and a new child kind of do that to you.  I'm not
 asking 1.0 to be perfect, but I am asking that we not release an API that
 we know for a fact does not work.  That just isn't honest to our users.

As Justin pointed out, the users seem to be just fine with it sitting in
there. *TODAY*. So why would they suddenly be unhappy with it tomorrow?

Release the damned thing as-is.

1.0.0 won't be perfect, but maybe 1.0.1 or 1.1.0 or 2.0.0 will be. As Jeff
says, we'll never get there, and never find out at this rate.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: cvs commit: apr apr.pc.in

[Greg Stein]

Are you sure those are unused? In a lot of cases, things like libdir are
defined in terms of exec_prefix. (or do we fully deref them?)

On Tue, Jun 01, 2004 at 09:51:21PM -, [EMAIL PROTECTED] wrote:
 thommay 2004/06/01 14:51:21
 
   Modified:.apr.pc.in
   Log:
   clean out some unused variables
   
   Revision  ChangesPath
   1.2   +0 -4  apr/apr.pc.in
   
   Index: apr.pc.in
   ===
   RCS file: /home/cvs/apr/apr.pc.in,v
   retrieving revision 1.1
   retrieving revision 1.2
   diff -u -r1.1 -r1.2
   --- apr.pc.in   29 May 2004 23:16:38 -  1.1
   +++ apr.pc.in   1 Jun 2004 21:51:21 -   1.2
   @@ -1,9 +1,5 @@
[EMAIL PROTECTED]@
   [EMAIL PROTECTED]@
   [EMAIL PROTECTED]@
[EMAIL PROTECTED]@
   [EMAIL PROTECTED]@
   [EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@

-- 
Greg Stein, http://www.lyra.org/

Re: cvs commit: apr-site/docs/coverage ...

[Greg Stein]

On Tue, Mar 09, 2004 at 11:11:51AM -0800, [EMAIL PROTECTED] wrote:
 
 Ok, this has added the data to the website.  If somebody can update the 
 running
 site we will have the coverage data on the site.

Done!

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Licensing of find_apr.m4 and find_apu.m4?

[Greg Stein]

On Sun, Mar 07, 2004 at 06:34:56PM -0600, [EMAIL PROTECTED] wrote:
 Justin Erenkrantz [EMAIL PROTECTED] writes:
...
  As a solution, the Creative Commons Public Domain dedication comes to
  mind (http://creativecommons.org/licenses/publicdomain/.  I'm not
  sure if that goes too far, but perhaps not.
  
  Thoughts?  -- justin
 
 +1.  Oh, want something more specific than +1? :-)  How about this:
 
# This file is in the public domain; the Apache Software Foundation 
# gives unlimited permission to copy, distribute and modify it.

Looks good as a start. How about if the statement includes all parts
aspects of copyright (i.e. public performance, etc).

Hmm. Section 2 of the Apache License looks pretty good. Mebbe we can say
it is subject to only that:

2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of, publicly
display, publicly perform, sublicense, and distribute the Work and
such Derivative Works in Source or Object form.

Of course, then we have section 3 to deal with (patent licenses). So just
section 2 might not be workable.

I'm thinking we might want to stick with the Apache License, but state
that certain pieces do not apply. Specifically, I think it may only be 4d
that should be stricken.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: gdbm licence issue

[Greg Stein]

It isn't dragging on at all. The APR PMC has asked the FSF about it via
their licensing@ address. Awaiting a response now...

Cheers,
-g

On Thu, Feb 26, 2004 at 10:01:19AM +0100, Dirk-Willem van Gulik wrote:
 This is dragging on a bit - while it is important in my
 opinion. To resolve this you - perhaps give your PMC
 some input as what you would like them to do:
 
 -Ask the board; my guess is that our answer will be;
   not a derived work if we are talking about #include ...
   and strict API use.
 
   But I sure would like to know for sure that a ./configure  make
   for bin releases by our volunteers which we distribute from the
   ASF would pick this up by accident. So this may lead to a
   --dist-build flag or something; or a script like the build one
   on 1.3
 
 -Ask the board to ask the FSF - which is clearly
   a double edged sword; as they have an oracle like
   expectation to have their answer taken on face value.
 
 -Simply ignore it - it is not an issue.
 
 -Simply sidestep the issue and ditch gdbm (I personally prefer
   Berkely DB et.al. anyway).
 
 If you see some more possible paths going forward - add them - and
 I suggest to have a few +1/-1's to guide your PMC.
 
 Dw

-- 
Greg Stein, http://www.lyra.org/

Re: gdbm licence issue

[Greg Stein]

On Mon, Feb 23, 2004 at 10:53:39PM +0100, Sander Striker wrote:
 On Mon, 2004-02-23 at 22:25, Jim Jagielski wrote:
  Joe Orton wrote:
   
   Bringing this up in the appropriate forum.  IANAL, but...
   
   gdbm is licensed under the GNU GPL.  apr_dbm_gdbm.c uses the GDBM
   interface, hence is a work based on GDBM, hence all of apr-util must be
   redistributed only under the terms of the GPL.
   
  
  We just use the gdbm API, don't we? As such, I don't think that
  GPL applies. If it did, wouldn't PHP/Perl/Python, etc all need
  to be re-distributed under GPL? We don't require it, but instead
  allow it to be used if available. If a 3rd party takes APR and
  compiles it so it *requires/uses* gdbm, then GPL kicks in. After
  all, we aren't redistributing it.
 
 This is my understanding aswell.

Same here, but would love to have my understanding corrected, if it is a
problem.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Compile-time vs. run-time checks

[Greg Stein]

On Mon, Feb 23, 2004 at 01:33:31PM -0600, Scott Lamb wrote:
 I'm putting together a patch to use SO_(RCV|SND)TIMEO for 
 apr_socket_timeout where available; I expect I'll find it has better 
 performance on some platforms, as it would no longer require using 
 non-blocking IO and preceding every read() and write() with a select(). 
 (I intend to try benchmarking Apache on Darwin, where the system call 
 overhead seems to be quite high.)
 
 On some older versions of platforms (Linux 2.2), these #defines exist 
 but do not work - it's not possible to set them. Can I assume that if 
 APR is built with a kernel in which it does work (Linux 2.4), it will 
 be run with one as well? Or should I include a runtime check for this 
 option?

Icky. I don't think it is really possible to make that assumption.
Thankfully, I also believe this is reasonably solved with a global
variable (i.e. race conditions around coming up with the same flag don't
apply :-), and the value certainly won't change over the process'
lifetime).

I would recommend a dynamic solution for now. We may be able to make that
compile-time for certain platforms, where we know all versions handle
the flag properly [when present].

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: updated port of gen-build.py

[Greg Stein]

On Sun, Feb 22, 2004 at 08:41:08AM -0500, Jeff Trawick wrote:
...
 Should I assume that this is broken on the same platforms where gen-build.py 
 is 
 broken (where a mix of unix and system-specific code is used)?

Eh? I'm not sure that I understand this brokenness ... can you explain?

As I understand it, if a mix is needed, then we pull in the relevant unix
code with a .c file that simply does a #include. For example, see
file_io/os2/fullrw.c. I don't recall that we ever had a Makefile that
built code from *another* directory, so the only option was to use a
#include to pull that code in.

Thanks,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: updated port of gen-build.py

[Greg Stein]

On Sun, Feb 22, 2004 at 08:54:37PM +0100, Sander Striker wrote:
...
 I thought we did have makefiles (or maybe it is the windows build) that
 does just that, build what is in $platform, and additionally compile all
 files in unix/ that doesn't have a counterpart in $platform.

Well, the Windows and NetWare builds are hand-maintained, so they can pull
files from wherever they want :-). In truth, this might complicate the
auto-generation of their builds. We may have to do the #include trick for
these platforms, too (or add some more logic to gen-build).

For the others, I don't recall, but I'm curious to find out more from the
people who know more than me :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/