On Tue, Sep 05, 2006 at 06:28:37PM -0700, [EMAIL PROTECTED] wrote:
Hi, I'm having troubles trying to upgrade the DBI module in Perl. When I
do the following (as root):
/usr/bin/perl -MCPAN -e 'install DBI'
it downloads the new module, builds everything, and then starts running
the make
On Sun, Sep 17, 2006 at 10:59:48AM -0700, Dean Arnold wrote:
(I've added dbi-dev as this seems relevant)
Tim Bunce wrote:
On Sat, Sep 16, 2006 at 08:31:54PM -0400, Sam Tregar wrote:
On Sat, 16 Sep 2006, Dean Arnold wrote:
I think your best bet might be to work with the DBD::mysql
-- Forwarded message --
From: Mail Delivery Subsystem [EMAIL PROTECTED]
Date: Sep 18, 2006 2:34 PM
Subject: Delivery Status Notification (Failure)
To: [EMAIL PROTECTED]
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed
Tim Bunce wrote:
Which brings me back to the notion of non-blocking requests. Assuming
many/most client libs do support an async capability, and a OOB
cancel, then it should be possible to standardize the behavior
externally.
Attempting to standardize, let alone implement, non-blocking
Dean Arnold [EMAIL PROTECTED] wrote:
Which brings me back to the notion of non-blocking requests. Assuming
many/most client libs do support an async capability, and a OOB
cancel, then it should be possible to standardize the behavior
externally.
Attempting to standardize, let alone
On Sep 18, 2006, at 6:18 PM, Tyler MacDonald wrote:
Dean Arnold [EMAIL PROTECTED] wrote:
Which brings me back to the notion of non-blocking requests.
Assuming
many/most client libs do support an async capability, and a OOB
cancel, then it should be possible to standardize the behavior
Henri Asseily [EMAIL PROTECTED] wrote:
The problem is not to know when a request is done processing.
The problem is killing requests that are processing for too long.
If you want kill them safely, you may not be able to kill them until
they're done, which defeats the purpose.
If you kill
Just finished a rather irritating debugging session trying to track
down a warning triggered by DBIx::Timeout. Turns out this code
doesn't exactly do what I mean:
$dbh-{PrintError} = 0;
Looks like it turns PrintError off, huh? Actually, as far as I can
tell it turns it on. The relevent C
On Mon, 18 Sep 2006, Sam Tregar wrote:
Looks like it turns PrintError off, huh? Actually, as far as I can
tell it turns it on. The relevent C code is (from dbih_set_attr_k):
else if (strEQ(key, PrintError)) {
DBIc_set(imp_xxh,DBIcf_PrintError, on);
Sheesh, ignore me. I see that's
On Mon, 18 Sep 2006, Sam Tregar wrote:
On Mon, 18 Sep 2006, Sam Tregar wrote:
Looks like it turns PrintError off, huh? Actually, as far as I can
tell it turns it on. The relevent C code is (from dbih_set_attr_k):
else if (strEQ(key, PrintError)) {
DBIc_set(imp_xxh,DBIcf_PrintError,
On Mon, Sep 18, 2006 at 05:05:52PM -0400, Sam Tregar wrote:
On Mon, 18 Sep 2006, Sam Tregar wrote:
On Mon, 18 Sep 2006, Sam Tregar wrote:
Looks like it turns PrintError off, huh? Actually, as far as I can
tell it turns it on. The relevent C code is (from dbih_set_attr_k):
else if
On Mon, 18 Sep 2006, Tim Bunce wrote:
Yes, and the same applies to AutoCommit. Whether it's a good thing or
not is debatable but it's been that way forever. The 'workaround' is
to explicitly state the attributes you want.
Hmmm, interesting. What would you think about making PrintError
12 matches
Mail list logo
