On Mon, 2008-05-12 at 12:45 -0500, William A. Rowe, Jr. wrote:
Is anyone else seeing testreslist spin for an excessive amount
of time? This is on
Linux 2.6.24.5-85.fc8 #1 SMP Sat Apr 19 12:39:34 EDT 2008 i686 i686 i386
GNU/Linux
Ditto here (i.e. just confirming your result).
--
Bojan
On Mon, 2008-05-12 at 17:38 -0500, William A. Rowe, Jr. wrote:
Do folks feel we should release an apr+apu this friday? If 1.3.0 has
settled in, then that is the release. If not, a final 1.2.x release
instead, in the interim?
Given Joe's latest comments regarding --with-ldap, I would be then
On Wed, 2008-05-14 at 10:42 +0800, zengwm wrote:
So making apr_pools.c and linking may require adding some arguments to
the command line to link the library, e.g. -L and -l..
You can try like this:
LDFLAGS=your_flags_here ./configure your_options_here
The run make etc.
--
Bojan
On Thu, 2008-05-15 at 09:08 -0400, Bob Rossi wrote:
Attached is the patch that fixes the problem, what do you think?
Yeah, we do this kind of thing for other databases already. I'll have a
look at it today.
--
Bojan
On Thu, 2008-05-15 at 09:08 -0400, Bob Rossi wrote:
So,
I get a link error, because it needs to link against -lcrypt.
What kind of system do you have? Where does the -lcrypt live on your
system?
BTW, doing the pg_config --libs will not give us the right thing here.
For instance, on my system,
On Thu, 2008-05-15 at 23:18 -0400, Bob Rossi wrote:
Ubuntu 7.04, /lib/libcrypt-2.5.so
OK.
OK, perhaps we should just add -lcrypt to the pg line? I could check to
see if this works on my system if you think this is a good idea.
Hmm, not sure if hardcoding here is the right thing to do. I
On Fri, 2008-05-16 at 16:32 -0400, Bob Rossi wrote:
I'm looking at dbd_pgsql_open.
http://apr.apache.org/docs/apr-util/trunk/group___a_p_r___util___d_b_d.html#gbddb1fdcb2f8a5f5b83127485c78e8ae
--
Bojan
On Fri, 2008-05-16 at 06:26 -0400, Bob Rossi wrote:
configure:40279: gcc -o conftest -g -Wall -pthread -DLINUX=2 -D_REENTRANT
-D_GNU_SOURCE conftest.c -lcrypt 5
configure:40285: $? = 0
configure:40313: result: -lcrypt
So, the test for crypt actually succeeds. Maybe the whole thing
On Fri, 2008-05-16 at 20:12 -0400, Bob Rossi wrote:
I'm glad to see someone beat me to it!
Glad to be of service :-)
--
Bojan
On Fri, 2008-05-16 at 20:33 -0400, Bob Rossi wrote:
Yes, that worked!
Cool. Thanks for testing!
Do you think this will get into the 1.3 snapshot?
Well, I think it should go in, hence I'll commit to trunk and ask other
committers to comment on in before backporting to 1.3.x/1.2.x. We need
to
On Fri, 2008-05-16 at 19:42 -0500, William A. Rowe, Jr. wrote:
Actually that's half-assed. We have to back out the changes that the DBD
detection causes for LDFLAGS and LIBS, etc, in order to ensure that later
tests aren't bogus.
We already did that, no?
We do it like this in build/dbd.m4:
On Sat, 2008-05-17 at 10:43 +1000, Bojan Smojver wrote:
ask other committers to comment
Well, I didn't have to ask, did I? ;-)
--
Bojan
On Fri, 2008-05-16 at 19:51 -0500, William A. Rowe, Jr. wrote:
No but since you did, my +1.
Thanks.
BTW, there is one place in PostgreSQL detection where we don't return
LDFLAGS and CPPFLAGS back to normal. I'll fix that too.
--
Bojan
On Sat, 2008-05-17 at 10:53 +1000, Bojan Smojver wrote:
BTW, there is one place in PostgreSQL detection where we don't return
LDFLAGS and CPPFLAGS back to normal. I'll fix that too.
Ignore this comment please - this is for the case we we don't fiddle
with CPPFLAGS/LDFLAGS.
--
Bojan
On Fri, 2008-05-16 at 22:43 -0400, Bob Rossi wrote:
I just upgraded to the 1.3 svn snapshot, to test out the new
functionality that was recently added. After I ran my unit tests I
noticed that the function apr_dbd_init() was not working properly for
me. Then I realized it's because this code,
On Sat, 2008-05-17 at 06:56 -0400, Bob Rossi wrote:
Huh, I build with --disable-shared --enable-static. Perhaps it doesn't
work in this configuration?
Possibly. Have you tried with --disable-dbd-dso?
--
Bojan
On Sat, 2008-05-17 at 06:56 -0400, Bob Rossi wrote:
char path[80];
Yeah, most likely should be APR_PATH_MAX+1, or something.
--
Bojan
On Sat, 2008-05-17 at 07:21 -0400, Bob Rossi wrote:
Just tried it, my tests pass now, which means this works. Should
--disable-shared force --disable-dbd-dso?
It does disable it - drivers don't work :-)
(Sorry, couldn't resist to be a smartarse).
Seriously, this could be done for
On Sat, 2008-05-17 at 10:03 -0400, Tom Donovan wrote:
I think this is a valid bug.
I agree.
--
Bojan
On Sat, 2008-05-17 at 18:29 -0500, William A. Rowe, Jr. wrote:
+1 and I concur with Tom's suggestion w.r.t. a preferred row offset 1.
Tom, do you want to fix this one or do you want me to do it?
--
Bojan
Quoting Bob Rossi [EMAIL PROTECTED]:
Aren't you worried about how that will break all the existing programs
out there using this interface?
This is one of those damned if we fix it, damned if we don't things :-)
That being said, this is clearly a bug, as APU's DBD is supposed to be
On Sat, 2008-05-17 at 20:43 -0400, Tom Donovan wrote:
I would be happy to take care of it as soon as I receive commit access. I'm
a new committer, and
the instructions advised patience - so I expect this usually takes some time
to get processed.
I committed something that _may_ work in
On Sun, 2008-05-18 at 11:24 +0200, Ruediger Pluem wrote:
I guess this should now be 0?
Depends, really. If we want things to break when users pass in 0, then
it should be the way it is, provided MySQL returns an error when row it
is given is -1. If we just want to not seek at all, then yes -
On Sun, 2008-05-18 at 12:02 +0200, Ruediger Pluem wrote:
Maybe we should return a driver independent error code in the case that the
row number is 1. A MySQL specific error code might be somewhat confusing
to the user as it might tell him that he used -1 as a row number.
BTW: As far as I see
On Sat, 2008-05-17 at 09:07 -0400, Bob Rossi wrote:
I've been using sqlite3 dbd for some time now. I find that the function
apr_dbd_get_row,
http://apr.apache.org/docs/apr-util/trunk/group___a_p_r___util___d_b_d.html#gd4cdc5f4e8981b93f5a467a8c8a768f1
is 1 based. That is, 1 is the first
On Mon, 2008-05-19 at 15:54 -0400, Bob Rossi wrote:
So basically I need -lSecur32 and ws2_32. What can I do about this?
I don't have any Windows machines (nor development tools), so I cannot
do this. I'm sure someone else on the list that does will pick this up.
Sorry...
--
Bojan
On Mon, 2008-05-19 at 16:07 -0400, Bob Rossi wrote:
You know, I really think you should be using the --libs there. What
could the downside be? It's not like you need to add all the --libs to
the apr libs. It's just setup temporarily to get the -lpq to link.
This returns libraries that were
On Mon, 2008-05-19 at 16:33 -0400, Tom Donovan wrote:
It appears to be a presumption that only one dbd provider is used in an
application. A private
per-provider lock seems like a much better idea for dbd drivers which use it
like SQLite Oracle do.
Actually, in my apps I use all drivers,
On Mon, 2008-05-19 at 15:56 -0500, William A. Rowe, Jr. wrote:
Then if we consider this non-portable, the prepared statement cache
certainly should not be a static, but scoped per apr_dbd_t?
I would prefer we /not/ offer dbd specific features, as the hacks around
the initial row offset
On Mon, 2008-05-19 at 16:22 -0500, William A. Rowe, Jr. wrote:
Well I'd rather it include more libraries than needed (which are not bound
on more sophisticated linkers) than an insufficient number.
OK, I'll do --libs then.
--
Bojan
On Mon, 2008-05-19 at 17:37 -0500, William A. Rowe, Jr. wrote:
yes; my question is, even if we do construct a cache, is module lifetime
appropriate? When accessed by several different consumers at once? (e.g.
two libraries that rely on dbd, or several different httpd modules and
On Mon, 2008-05-19 at 20:05 -0400, Bob Rossi wrote:
If you make the change, I'll test out the latest snapshots and all your
fixes for me. Thanks so much Bojan!
Done. And you are welcome.
--
Bojan
On Mon, 2008-05-19 at 20:47 -0400, Bob Rossi wrote:
This is almost correct. It's simply missing the -L to the postgresql/lib
directory. My program failed to link because it couldn't find -lpgport
which lives there.
If fact, PostgreSQL manual
On Tue, 2008-05-20 at 11:21 +1000, Bojan Smojver wrote:
If fact, PostgreSQL manual
(http://www.postgresql.org/docs/8.3/static/libpq-build.html) confirms
that we should be using just --libdir.
BTW, if --libdir alone doesn't cut it for you for some reason, I'll add
--libs back too
On Mon, 2008-05-19 at 18:48 -0700, Chris Darroch wrote:
Personally, I'd suggest just removing it from trunk too ... I'm
not sure exactly how a global cache could be made to work across
multiple databases, since they might be of different versions, etc.
It's not likely to be trivial, I
Here is a patch I've been toying with. Essentially, it does these
things:
- cleans up PostgreSQL detection a bit more
- uses APRUTIL_PRIV_INCLUDES for all CPPFLAGS driver stuff (i.e. we
don't need to expose that to users of APU)
- is careful not to place LDFLAGS of drivers into APRUTIL_LDFLAGS
On Tue, 2008-05-20 at 06:55 -0400, Bob Rossi wrote:
OK, I can try this, however, this patch still doesn't work on windows. I
get link errors on windows because the the libs aren't linked in.
$ ./pg_config --libs
-lpgport -lm -lSecur32 -lws2_32 -lshfolder
$ ./pg_config --libdir
On Wed, 2008-05-21 at 06:59 +1000, Bojan Smojver wrote:
OK, not a problem. We'll whack libs in there too.
Done. Hopefully that should be it.
--
Bojan
I'm getting this (APR 1.2.x):
-
strings/apr_snprintf.c: In function 'apr_vformatter':
strings/apr_snprintf.c:1253: warning: comparison with string literal
results in unspecified behavior
-
The line is:
On Tue, 2008-05-20 at 19:34 -0400, Bob Rossi wrote:
--- apr-util-1.3.x-2008-05-19-svn/build/dbd.m4 Tue May 20 17:15:38 2008
+++ apr-util-1.3.x-2008-05-19-svn.changed/build/dbd.m4 Tue May 20 19:18:23
2008
@@ -53,7 +53,8 @@
AC_PATH_PROG([PGSQL_CONFIG],[pg_config],,[$withval/bin])
On Tue, 2008-05-20 at 20:04 -0400, Bob Rossi wrote:
I noticed you changed everything but the AC_CHECK_LIB, do you believe
that is unnecessary, or are you thinking about it?
Not required. We set LDFLAGS specifically for the test (hence the
APR_ADDTO(LDFLAGS, [$pgsql_LDFLAGS])) and then we
On Tue, 2008-05-20 at 20:26 -0400, Bob Rossi wrote:
That's because as you can see the -lpq went at the
end which is incorrect.
The real problem is that we're adding libraries to LDFLAGS. We should be
adding them to LIBS. I meant to fix that long time ago, but I always get
put off by the fact
On Tue, 2008-05-20 at 21:47 -0400, Bob Rossi wrote:
That worked on windows! I don't have time to test linux now.
Thanks for testing. It works on Linux.
--
Bojan
On Wed, 2008-05-21 at 10:13 -0400, Bob Rossi wrote:
OK, I have confirmed 1 bug. If you pass '0' to apr_dbd_get_row, with
postgresql as the driver, the function returns 0, instead of -1 as it
should. My unit tests happen to test the cases that should fail, that's
how I caught this.
Try now. I
On Wed, 2008-05-21 at 07:43 -0500, William A. Rowe, Jr. wrote:
IMHO this is a user-facing change and demands an explicit statement in
the CHANGES file, eh? Was also staring this morning at the testdbd output
which reports results in a 0-based row list, perhaps that should change
so we don't
On Wed, 2008-05-21 at 16:29 -0400, Bob Rossi wrote:
Ok, all my unit tests pass on linux and windows. Thanks a million!
You are welcome. Thank you for testing!
--
Bojan
On Wed, 2008-05-21 at 17:59 -0500, William A. Rowe, Jr. wrote:
Any thoughts? This is required before release to allow `make test` to work
before the dbd (ldap etc) providers are installed.
Sorry, breakfast :-)
Generally speaking, we should be looking at explicit paths, because we
want to
On Thu, 2008-05-22 at 22:37 +, [EMAIL PROTECTED] wrote:
Modified: apr/apr-util/trunk/build/dbd.m4
URL:
http://svn.apache.org/viewvc/apr/apr-util/trunk/build/dbd.m4?rev=659293r1=659292r2=659293view=diff
==
---
On Wed, 2008-05-21 at 07:50 +1000, Bojan Smojver wrote:
I'm getting this (APR 1.2.x):
-
strings/apr_snprintf.c: In function 'apr_vformatter':
strings/apr_snprintf.c:1253: warning: comparison with string literal
results in unspecified behavior
On Thu, 2008-05-22 at 20:23 -0500, William A. Rowe, Jr. wrote:
I'll pull this as part of the dbm separation, as a matter of fact I already
had a build/dso.m4 in the tree here :)
Cool.
--
Bojan
On Thu, 2008-05-22 at 17:52 -0500, William A. Rowe, Jr. wrote:
Please, review. Thanks.
Gettin' these:
misc/apu_dso.c: In function 'apu_dso_init':
misc/apu_dso.c:84: warning: suggest parentheses around assignment used
as truth value
On Thu, 2008-05-22 at 22:06 -0500, William A. Rowe, Jr. wrote:
Can you recheck from the branch? should have been fixed in r659343
Check. All is well :-)
--
Bojan
On Fri, 2008-05-23 at 13:12 +0100, Joe Orton wrote:
Interesting - is that gcc 4.3?
Yep, Fedora 9.
The code is bogus because it assumes all
the expansions of the macro result in a string with the same address;
does this patch fix the warning?
Yes, it does.
--
Bojan
On Tue, 2008-05-27 at 15:08 -0400, Aaron Wiebe wrote:
#define _LARGEFILE64_SOURCE
You sure you want to do this in your source? Try picking up these things
from apr-1-config --cppflags. Setting things like this explicitly may
change sizes of structures inside APR headers causing overflows.
--
On Tue, 2008-05-27 at 16:36 +1000, Bojan Smojver wrote:
Before I get into researching this issue
(https://issues.apache.org/bugzilla/show_bug.cgi?id=44367), does anyone
know off the top of their heads if getservbyaddr() is now thread safe on
all platforms that we support?
For instance
On Wed, 2008-05-28 at 09:45 +1000, Bojan Smojver wrote:
So, given that we have at least one OS that would for sure require use
of thread safe functions, I think this should be fixed.
For instance, something like the attached.
Caveats:
- I have no idea if IBM's proprietary OSes actually have
On Wed, 2008-05-28 at 11:20 +1000, Bojan Smojver wrote:
For instance, something like the attached.
Don't you just hate it when you have to do this?
--
Bojan
Index: network_io/unix/sockaddr.c
===
--- network_io/unix/sockaddr.c
Just ran make check against trunk/1.3.x and got this:
./testall -v testshm
testshm : -Line 254: Error destroying shared memory block
(2): No such file or directory
FAILED 1 of 6
Failed TestsTotal FailFailed
On Wed, 2008-05-28 at 14:12 +1000, Bojan Smojver wrote:
Maybe shm_cleanup_onwer() should check (line 73 of shmem/unix/shm.c) to
see if the the file has already been removed and return APR_SUCCESS if
it was, instead of always calling apr_file_remove()?
Something like this (possibly required
On Wed, 2008-05-28 at 14:29 +1000, Bojan Smojver wrote:
Something like this (possibly required in other places too).
Sorry, forgot to modify the header file. BTW, this patch makes it pass
the tests.
PS. Obviously, similar things may need to be applied to other places in
the same function
On Wed, 2008-05-28 at 14:57 -0500, William A. Rowe, Jr. wrote:
but give a ping anyways
Any opinion on these two:
http://www.mail-archive.com/dev@apr.apache.org/msg20226.html
http://www.mail-archive.com/dev@apr.apache.org/msg20223.html
--
Bojan
On Wed, 2008-05-28 at 16:40 -0500, William A. Rowe, Jr. wrote:
Neither is an API-changing showstopper. If anyone has free cycles to
jump on them, great. Otherwise, in another release or so.
OK.
--
Bojan
On Wed, 2008-05-28 at 22:52 +, [EMAIL PROTECTED] wrote:
As 1.3 rolls, it's the end of this line. Also fix a notable
absense of data.
So, no more backports to 1.2.x, right?
--
Bojan
On Thu, 2008-05-29 at 01:57 +, [EMAIL PROTECTED] wrote:
Fix PR44367.
Obviously, relying on CTR here.
Caveats:
- no idea if IBM's proprietary OSes actually have thread-safe
version of getservbyname() function, just assumed that by looking at
other similar functions being marked safe
On Thu, 2008-05-29 at 21:15 -0400, Bob Rossi wrote:
One issue I've noticed with postgresql is that when you use it through
apr, and postgresql detects an error, it prints to stdout.
Do you think that apr should catch this, or do you think that my
application should get the handle, and catch
On Fri, 2008-05-30 at 01:50 -0500, William A. Rowe, Jr. wrote:
So if it's possible with the postgresql to mute the stdout information,
we really need to do so.
I'm not convinced of the usefulness of this, but here is the patch
nevertheless.
--
Bojan
Index: dbd/apr_dbd_pgsql.c
On Fri, 2008-05-30 at 12:00 +0100, Nick Kew wrote:
Wouldn't a better patch be to save the message internally so that
a subsequent dbd_pgsql_error picks it up?
AFAICT, this doesn't affect errors, just warnings and notices:
http://www.postgresql.org/docs/8.3/static/libpq-notice-processing.html
On Fri, 2008-05-30 at 14:32 +0100, Nick Kew wrote:
Now therein lies a good idea: we could set that at startup, and perhaps
provide an option in a connection string or environment to override it.
Does PQconnectdb provide any such option?
Given that 1.3.0 has been tagged, this is now 2.x
On Fri, 2008-05-30 at 17:26 -0500, William A. Rowe, Jr. wrote:
Unix tarballs are up, win32 .zip's with .mak files will follow.
Your votes please;
+/-1
[+1] Release apr-1.3.0 as GA
[+1] Release apr-util-1.3.0 as GA
Fedora 9, i686/x86_64, RHEL 5 i686/x86_64, APR:
On Fri, 2008-05-30 at 21:03 -0500, William A. Rowe, Jr. wrote:
But I agree that is not a showstopper, and it's still better off than when
we were limited to make install; make test.
Absolutely and nice work.
--
Bojan
And just a note that we still get these:
-
poll/unix/epoll.c: In function 'apr_pollset_add':
poll/unix/epoll.c:184: warning: dereferencing type-punned pointer will
break strict-aliasing rules
poll/unix/epoll.c:184: warning: dereferencing type-punned pointer will
break
On Sun, 2008-06-01 at 00:50 +, [EMAIL PROTECTED] wrote:
Supplementary to r661146:
- Include the necessary unistd.h
Doesn't this do it for you?
http://svn.apache.org/viewvc/apr/apr/trunk/include/arch/unix/apr_arch_shm.h?r1=428317r2=661146
--
Bojan
On Sat, 2008-05-31 at 23:49 +0100, Nick Kew wrote:
Needs an additional #include unistd.h. Without that, it gives compile
warnings on Linux (access() undeclared) and errors out on solaris
(neither access() nor F_OK declared).
On Sat, 2008-05-31 at 17:36 +1000, Bojan Smojver wrote:
And just a note that we still get these:
-
poll/unix/epoll.c: In function 'apr_pollset_add':
poll/unix/epoll.c:184: warning: dereferencing type-punned pointer will
break strict-aliasing rules
This patch avoids
On Sun, 2008-06-01 at 13:43 +1000, Bojan Smojver wrote:
This patch avoids the warning for me. Not sure if it makes any sense at
all...
Actually, there is no need for that (char *) cast.
--
Bojan
Index: include/apr_ring.h
On Sun, 2008-06-01 at 01:38 +, Nick Kew wrote:
Probably. But I hadn't seen that when I applied the patch shown to 1.3.
Sorry, I should have pointed here:
http://svn.apache.org/viewvc?view=revrevision=661146
And I'm not testing now: it's 2:39 a.m. here!
No kidding :-)
--
Bojan
Better fix?
--
Bojan
Index: include/apr_ring.h
===
--- include/apr_ring.h (revision 662145)
+++ include/apr_ring.h (working copy)
@@ -157,7 +157,7 @@
* @param link The name of the APR_RING_ENTRY in the element struct
*/
#define
On Mon, 2008-06-02 at 19:31 +, [EMAIL PROTECTED] wrote:
Backports: r662529
Does that mean you're planning on spinning 1.3.1?
--
Bojan
On Mon, 2008-06-02 at 17:37 -0500, William A. Rowe, Jr. wrote:
Not unless -1's appear.
OK, thanks. I was asking because there were a few commits to trunk that
would be worth backporting in case you were re-spinning. Unless people
object, I will do that soon, so that I don't forget before 1.3.1.
On Mon, 2008-06-02 at 18:50 -0500, William A. Rowe, Jr. wrote:
Please feel free! Such things are easily forgotten later on.
OK.
That patch is fine. And yes - it's worth debating how to communicate
the notice information from the engines (first question; how do these
correspond to other
On Mon, 2008-06-02 at 20:07 -0500, William A. Rowe, Jr. wrote:
and I'm looking for one answer; are we inhibited from shipping the
apr_dbd_xxx-1.dll binary for oracle, pgsql or sqlite3? If so I'll
adjust before uploading any binaries.
PosgreSQL is licensed under a BSD licence, so we are fine
On Mon, 2008-06-02 at 21:17 -0500, William A. Rowe, Jr. wrote:
In any case, there is nothing stopping us from shipping these three driver
connectors that I can find. Thoughts or comments?
Given that this is a Windows specific, I have no idea (just so you know
I'm not ignoring your question).
On Mon, 2008-06-02 at 20:10 -0500, William A. Rowe, Jr. wrote:
apr_dbd_mysql.c(142) : warning C4244: 'function' : conversion from '__int64
' to 'unsigned long ', possible loss of data
apr_dbd_mysql.c(256) : warning C4018: '=' : signed/unsigned mismatch
apr_dbd_mysql.c(416) : warning C4244:
How does this patch work for you? I don't have Windows so I cannot
test...
--
Bojan
Index: dbd/apr_dbd_mysql.c
===
--- dbd/apr_dbd_mysql.c (revision 662610)
+++ dbd/apr_dbd_mysql.c (working copy)
@@ -139,7 +139,8 @@
/* fetch
On Wed, 2008-06-04 at 06:58 +, [EMAIL PROTECTED] wrote:
Author: bojan
Date: Tue Jun 3 23:58:15 2008
New Revision: 663011
URL: http://svn.apache.org/viewvc?rev=663011view=rev
Log:
Update docs for 1.3.
Update docs for trunk.
I left 1.2 docs in place for now, just in case someone
On Wed, 2008-06-04 at 18:28 -0500, William A. Rowe, Jr. wrote:
Many linkage problems, but it compiles now. I'll work those out.
OK, thanks.
I'm not sure what to do about that FreeTDS thing. We use/ship PCRE
within Apache, but we don't have support for that in APR/APU. Were you
hinting at
On Thu, 2008-06-12 at 12:09 -0500, William A. Rowe, Jr. wrote:
we've found lots of nice small fixes to several platforms, and it would seem
good to release a 1.3.1 bugfix update fairly promptly. Here are some options
[X] tag it friday (13th)
[ ] tag it next wednesday (18th)
[ ] tag
On Thu, 2008-06-12 at 17:54 +, [EMAIL PROTECTED] wrote:
+SQL_C_CHAR, /*SQL_C_TYPE_TIME, /* APR_DBD_TYPE_TIME, \%pDi */
+SQL_C_CHAR, /*SQL_C_TYPE_DATE, /* APR_DBD_TYPE_DATE, \%pDd */
+SQL_C_CHAR, /*SQL_C_TYPE_TIMESTAMP, /* APR_DBD_TYPE_DATETIME, \%pDa */
On Thu, 2008-06-12 at 19:17 -0500, William A. Rowe, Jr. wrote:
This is looking great, do we feel it's ready for people to try out with
apr 1.3.1?
I have no idea if it actually works (it does compile and link). But hey
- that's how we'll find out :-)
--
Bojan
On Fri, 2008-06-13 at 10:26 +1000, Bojan Smojver wrote:
I have no idea if it actually works (it does compile and link).
It would be good if Windows folks could check this change that I made:
--
#ifdef HAVE_SQL_H
#include sql.h
#include sqlext.h
#elif defined(HAVE_ODBC_SQL_H
On Thu, 2008-06-12 at 20:27 -0400, Tom Donovan wrote:
I would be happy to take the /*'s out if it's confusing.
I already took them out.
Is there a reason not to have /* in a comment? They don't nest in C (but,
curiously - they're
suppose to nest in SQL - although few dbs actually do
On Thu, 2008-06-12 at 21:14 -0400, Tom Donovan wrote:
All set on Windows now - r667309
Thanks!
--
Bojan
On Thu, 2008-06-12 at 19:17 -0500, William A. Rowe, Jr. wrote:
This is looking great, do we feel it's ready for people to try out with
apr 1.3.1?
Tom,
Do you have an opinion on this?
PS. I would personally prefer to see ODBC DBC in 1.3.1.
--
Bojan
On Thu, 2008-06-12 at 23:14 -0400, Tom Donovan wrote:
I changed APU_DECLARE_DATA to APU_MODULE_DECLARE_DATA when I checked it into
apr (copying the mysql
driver). Am I missing something?
Sadly, nothing. The whole build thing is busted - even for FreeTDS
driver. I'm fixing now.
--
Bojan
On Fri, 2008-06-13 at 04:10 +, [EMAIL PROTECTED] wrote:
@@ -646,7 +649,7 @@
if (SQL_SUCCEEDED(rc) || rc == SQL_NO_DATA) {
-if (rc = SQL_SUCCESS_WITH_INFO
+if (rc == SQL_SUCCESS_WITH_INFO
( len_indicator == SQL_NO_TOTAL || len_indicator = bufsize)
On Fri, 2008-06-13 at 00:32 -0400, Tom Donovan wrote:
The second one doesn't change the behavior, just cleaning up -Wall
warnings, right?
That's right. Thanks for reviewing.
If nobody objects, I'm going to backport ODBC driver to 1.3.x then.
--
Bojan
On Fri, 2008-06-13 at 03:33 -0500, William A. Rowe, Jr. wrote:
If someone on unix with all three providers can confirm this is clean,
I'm happy to backport.
It's clean.
--
Bojan
On Fri, 2008-06-13 at 02:15 -0500, William A. Rowe, Jr. wrote:
But this is a great fix (below) - care to backport to branches/1.3.x ?
Done in r667437.
--
Bojan
On Fri, 2008-06-13 at 03:33 -0500, William A. Rowe, Jr. wrote:
If someone on unix with all three providers can confirm this is clean,
I'm happy to backport.
Done in r667456.
--
Bojan
Quoting Garrett Rooney [EMAIL PROTECTED]:
Honestly, I loathe tabs as much as the next guy, but I actually
dislike the idea of wholesale reformatting because it makes it harder
to figure out where a bit of code came from.
Exactly.
It's just a pain. I much more prefer reformatting to meet
401 - 500 of 930 matches
Mail list logo
