Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread Bojan Smojver
Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>: Right - I wasn't being critical of your specific new fn, but just a general observation. In the past, we created renames_proposed to collect a list for review and comment before committing the changes; if you agree with the syntax _get _set et

Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread William A. Rowe, Jr.
Bojan Smojver wrote: Quoting Garrett Rooney <[EMAIL PROTECTED]>: Well, it can be done for 1.3.x, but it would need to be by adding macros for the NEW names, so the old symbols still exist at link time. We can't backport such a change to 1.2.x, since it involves adding new symbols. I wasn't

Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread William A. Rowe, Jr.
Bojan Smojver wrote: Quoting Garrett Rooney <[EMAIL PROTECTED]>: There's no reason for compat macros, this code has not been released in any version of APR, so compat is not an issue. I was referring to renaming all DBD functions actually (including the new ones), so that they follow the na

Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread Bojan Smojver
Quoting Garrett Rooney <[EMAIL PROTECTED]>: Or should we just keep the existing broken names until 2.x? It'll be less hassle... My level of caring is approaching zero rapidly ;-) He, he... Then we may as well do nothing until 2.x :-) -- Bojan

Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread Garrett Rooney
On 4/2/06, Bojan Smojver <[EMAIL PROTECTED]> wrote: > Quoting Garrett Rooney <[EMAIL PROTECTED]>: > > > 1.3.x is compatible with 1.2.x in the sense that programs compiled > > against 1.2.x must continue to run against 1.3.x. The reverse is not > > true, which is why in minor version number bumps w

Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread Bojan Smojver
Quoting Garrett Rooney <[EMAIL PROTECTED]>: 1.3.x is compatible with 1.2.x in the sense that programs compiled against 1.2.x must continue to run against 1.3.x. The reverse is not true, which is why in minor version number bumps we can add new functions. To remove functions (or macros for that

Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread Garrett Rooney
On 4/2/06, Bojan Smojver <[EMAIL PROTECTED]> wrote: > Quoting Garrett Rooney <[EMAIL PROTECTED]>: > > > Well, it can be done for 1.3.x, but it would need to be by adding > > macros for the NEW names, so the old symbols still exist at link time. > > We can't backport such a change to 1.2.x, since i

Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread Bojan Smojver
Quoting Garrett Rooney <[EMAIL PROTECTED]>: Well, it can be done for 1.3.x, but it would need to be by adding macros for the NEW names, so the old symbols still exist at link time. We can't backport such a change to 1.2.x, since it involves adding new symbols. I wasn't thinking any of this wo

Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread Garrett Rooney
On 4/2/06, Bojan Smojver <[EMAIL PROTECTED]> wrote: > Quoting Garrett Rooney <[EMAIL PROTECTED]>: > > > There's no reason for compat macros, this code has not been released > > in any version of APR, so compat is not an issue. > > I was referring to renaming all DBD functions actually (including th

Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread Bojan Smojver
Quoting Garrett Rooney <[EMAIL PROTECTED]>: There's no reason for compat macros, this code has not been released in any version of APR, so compat is not an issue. I was referring to renaming all DBD functions actually (including the new ones), so that they follow the naming proper convention

Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread Garrett Rooney
On 4/2/06, Bojan Smojver <[EMAIL PROTECTED]> wrote: > Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>: > > > When did we drift back to this naming convention? > > > > I thought we were trying to move twords lib_object_subobject_verb? > > > > E.g. apr_dbd_name_get? > > > > It's really aggrivating

Re: apr_dbd_init

2006-04-02 Thread Bojan Smojver
Quoting Nick Kew <[EMAIL PROTECTED]>: Proposed patch below. One more thing I've forgotten in my previous e-mail. Unless there is some kind of binary compatibility problem (I don't see it), this would be a good candidate for backporting to 1.2.x. -- Bojan

Re: apr_dbd_init

2006-04-02 Thread Bojan Smojver
Quoting Nick Kew <[EMAIL PROTECTED]>: Proposed patch below. [...snip...] --- apr_dbd.c (revision 390371) +++ apr_dbd.c (working copy) @@ -63,17 +63,32 @@ } #endif +static apr_status_t apr_dbd_term(void *ptr) +{ +/* set drivers to NULL so init can work again */ +drivers = NUL

Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h

2006-04-02 Thread Bojan Smojver
Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>: When did we drift back to this naming convention? I thought we were trying to move twords lib_object_subobject_verb? E.g. apr_dbd_name_get? It's really aggrivating to use an api that's pulling in both directions at once :( Sorry about that

Re: [PATCH]: apr_dbd column names, take 3

2006-04-02 Thread Bojan Smojver
Quoting Nick Kew <[EMAIL PROTECTED]>: In case you don't follow APR svn commits, I committed patches including yours to apr_dbd yesterday. Thanks! Awesome. -- Bojan

Bug report for APR [2006/04/02]

2006-04-02 Thread bugzilla
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

Re: [PATCH] get string showing supported dbm types in typical usage-syntax manner

2006-04-02 Thread Max Bowsher
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeff Trawick wrote: > On 3/31/06, Max Bowsher <[EMAIL PROTECTED]> wrote: > >> Better still, rather than taking a delimiter, return an array of >> strings, so that the client application can do whatever it wants with >> them - hypothetically, a GUI app