On Aug 10, 2010, at 3:09 PM, Jan Dubois wrote:
>> You have DBD::Oracle installed but no Oracle libraries?
>
> Yes, DBD::Oracle is included in ActivePerl, but it will of course
> only work if you install the client libraries as well.
Ah, I see.
David
On Tue, 10 Aug 2010, David E. Wheeler wrote:
> On Aug 9, 2010, at 4:44 PM, Jan Dubois wrote:
>
> > DBI->installed_versions will attempt to load *all* installed
> > drivers.
>
> You have DBD::Oracle installed but no Oracle libraries?
Yes, DBD::Oracle is included in ActivePerl, but it will of course
On Aug 9, 2010, at 4:44 PM, Jan Dubois wrote:
> DBI->installed_versions will attempt to load *all* installed drivers.
You have DBD::Oracle installed but no Oracle libraries?
> But I see now that that test is only executed if you are running from a GIT
> or SVN checkout, so maybe it doesn't reall
On Mon, 09 Aug 2010, David E. Wheeler wrote:
> On Aug 9, 2010, at 4:21 PM, Jan Dubois wrote:
>
> > On Mon, 09 Aug 2010, David E. Wheeler wrote:
> >> Tim, I think we're ready for another dev release, especially since I added
> >> this test to the MANIFEST.
> >
> > Running tests on the latest Activ
On Mon, 09 Aug 2010, Jan Dubois wrote:
>
> On Mon, 09 Aug 2010, David E. Wheeler wrote:
> > Tim, I think we're ready for another dev release, especially since I added
> > this test to the MANIFEST.
>
> Running tests on the latest ActivePerl shows 2 issues:
Sorry, forgot to mention one "untidine
On Aug 9, 2010, at 4:21 PM, Jan Dubois wrote:
> On Mon, 09 Aug 2010, David E. Wheeler wrote:
>> Tim, I think we're ready for another dev release, especially since I added
>> this test to the MANIFEST.
>
> Running tests on the latest ActivePerl shows 2 issues:
>
> 1) t/01basics.t fails to load D
On Mon, 09 Aug 2010, David E. Wheeler wrote:
> Tim, I think we're ready for another dev release, especially since I added
> this test to the MANIFEST.
Running tests on the latest ActivePerl shows 2 issues:
1) t/01basics.t fails to load DBD::Oracle (because I don't have the Oracle
client
libr
In data 09 agosto 2010 alle ore 22:42:59, David E. Wheeler
ha scritto:
On Aug 9, 2010, at 1:06 PM, Cosimo Streppone wrote:
Which nasty part?
Ehm... scrap that :)
Your patch with 'unless' reversed to 'if' works fine.
Thanks! Committed in r14317.
Confirmed. r14317 passes all tests.
--
On Aug 9, 2010, at 1:06 PM, Cosimo Streppone wrote:
>> Which nasty part?
>
> Ehm... scrap that :)
> Your patch with 'unless' reversed to 'if' works fine.
Thanks! Committed in r14317.
> Just for clarity, here's the full DESTROY() of 16destroy.t:
Yep, thanks.
>>> Will try and let you know.
>>
In data 09 agosto 2010 alle ore 17:27:52, David E. Wheeler
ha scritto:
On Aug 9, 2010, at 8:21 AM, Cosimo Streppone wrote:
package Foo;
sub DESTROY { exit; }
my $foo = bless {}, 'Foo';
I couldn't try this yet, but, I don't think this
would segfault.
What I *guess* happens is tha
On Aug 9, 2010, at 9:51 AM, Jan Dubois wrote:
> I tried to look into this on the weekend, but ran out of time. I didn't
> get *any* segfaults though, neither from 16destroy.t nor from any of the
> samples below.
>
> I *did* only get 18 passing tests instead of 20 from 16destroy.t though.
Yes, I
On Mon, 09 Aug 2010, Cosimo Streppone wrote:
> On Sat, 07 Aug 2010 23:12:48 +0200, David E. Wheeler
> wrote:
>
> > On Aug 7, 2010, at 2:07 AM, Cosimo Streppone wrote:
> >
> >> My really *ignorant* wild guess is that "exit" just avoids the
> >> troubles bits of DESTROY() that are causing segfaults
On Aug 9, 2010, at 8:21 AM, Cosimo Streppone wrote:
>>package Foo;
>>sub DESTROY { exit; }
>>my $foo = bless {}, 'Foo';
>
> I couldn't try this yet, but, I don't think this
> would segfault.
>
> What I *guess* happens is that the 'exit' will cause
> the script to immediately exit, sk
On Sat, 07 Aug 2010 23:12:48 +0200, David E. Wheeler
wrote:
On Aug 7, 2010, at 2:07 AM, Cosimo Streppone wrote:
My really *ignorant* wild guess is that "exit" just avoids the
troubles bits of DESTROY() that are causing segfaults
without actually solving the problem.
So the issue is that i
On Aug 7, 2010, at 2:07 AM, Cosimo Streppone wrote:
> Hi DBI Win32 hackers,
>
> David E. Wheeler wrote:
>
>> I *think* it works the way it does because on Win32 it's not really a fork,
>> but a thread, and when you exit in a child thread, it exits the parent, too.
>> Correct?
>
> Sounds reaso
Hi DBI Win32 hackers,
David E. Wheeler wrote:
I *think* it works the way it does because on Win32 it's not really a
fork, but a thread, and when you exit in a child thread, it exits the
parent, too. Correct?
Sounds reasonable?
Alexandr's patch works fine for me. Passes all tests.
That's fa
Hello
I think, I did a workaround for real issue - exit does not always
behave correctly on Windows in DESTROY in child after fork.
If you look into patch idea, you will see that I just added one line
"fail "Child should be inactive on DESTROY";". IMHO, this could not
result in false PASS :). And
On Aug 6, 2010, at 5:42 PM, Jan Dubois wrote:
> Against my better judgment I couldn't prevent myself from peeking at
> the magical patch. I don't understand what it is doing, and I don't
> have any candies so sacrifice right now either.
>
> However, I'm always suspicious when I see code like thi
On Fri, 06 Aug 2010, Alexandr Ciornii wrote:
>
> (It is beginning to feel colder in your room. It's a strange feeling,
> like someone is present here, although you are alone... You now begin
> to hear some voices. It is some other person, from far, far away
> trying to tell something important to
19 matches
Mail list logo
