Re: DBI package problem?
On Mon, Sep 6, 2010 at 10:02 PM, Tim Bunce tim.bu...@pobox.com wrote: On Mon, Sep 06, 2010 at 03:29:11PM +0200, rosenfield.alb...@gmail.com wrote: Where do you get the 70%/30% ratio from? Uploaded a package to CPAN with - a test that fails when DBI is not installed, and - a Build.PL which does not indicate that DBI is a requirement (even though it is). And then you counted pass/fail stats that largely come from automated smoke testers I did. on virtual machines that have their modules removed after each run. Sounds very likely. I'd like to see details of the specific underlying problems that cause build failures with the current release. Ideally with some indication of which are the most frequent. You would be missing the point. (The point being not to pour lots of work into making the C version work everywhere, but to make it just *possible* to install only the PurePerl version on the 1% of systems where the C version cannot be made to work or other reasons motivate the use of the PurePerl version.) As I said before, I'll happily take a patch to Makefile.PL that detects the lack of a C compiler and then alters %opts so WriteMakefile() writes a Makefile that won't try to compile DBI.xs etc etc. But you would not be willing to make the PurePerl version of DBI separately available. I wonder why, as the latter seems like a much simpler and resilient approach. Anyway, thanks a lot for your input.
Re: DBI package problem?
Where do you get the 70%/30% ratio from? Uploaded a package to CPAN with - a test that fails when DBI is not installed, and - a Build.PL which does not indicate that DBI is a requirement (even though it is). I'd like to see details of the specific underlying problems that cause build failures with the current release. Ideally with some indication of which are the most frequent. You would be missing the point. (The point being not to pour lots of work into making the C version work everywhere, but to make it just *possible* to install only the PurePerl version on the 1% of systems where the C version cannot be made to work or other reasons motivate the use of the PurePerl version.)
Re: DBI package problem?
On Mon, Sep 06, 2010 at 03:29:11PM +0200, rosenfield.alb...@gmail.com wrote: Where do you get the 70%/30% ratio from? Uploaded a package to CPAN with - a test that fails when DBI is not installed, and - a Build.PL which does not indicate that DBI is a requirement (even though it is). And then you counted pass/fail stats that largely come from automated smoke testers on virtual machines that have their modules removed after each run. I'd like to see details of the specific underlying problems that cause build failures with the current release. Ideally with some indication of which are the most frequent. You would be missing the point. (The point being not to pour lots of work into making the C version work everywhere, but to make it just *possible* to install only the PurePerl version on the 1% of systems where the C version cannot be made to work or other reasons motivate the use of the PurePerl version.) As I said before, I'll happily take a patch to Makefile.PL that detects the lack of a C compiler and then alters %opts so WriteMakefile() writes a Makefile that won't try to compile DBI.xs etc etc. Tim.
Re: DBI package problem?
On Sun, Mar 28, 2010 at 11:40:35PM +0200, rosenfield.alb...@gmail.com wrote: In practice this results in circa 70% of smoke testers running the module with DBI installed. The remaining 30% however, fails with this error: = # Failed test 'use DBI;' # at t/00-load.t line 4. # Tried to use 'DBI'. # Error: Can't locate DBI.pm in @INC (@INC contains: [...snip...]) at (eval 4) line 2. # BEGIN failed--compilation aborted at (eval 4) line 2. = I could easily change the use DBI line into a conditional require DBI::PurePerl during BEGIN, but this does not fix the root of the problem, namely that the PurePerl version of DBI never gets installed. We don't know the *root* of the problem. The error you quote above just a symptom of an earlier problem. Where do you get the 70%/30% ratio from? I'd like to see details of the specific underlying problems that cause build failures with the current release. Ideally with some indication of which are the most frequent. Tim.
Re: DBI package problem?
On 10/05/2010 17:44, Tim Bunce wrote: On Sun, Mar 28, 2010 at 11:40:35PM +0200, rosenfield.alb...@gmail.com wrote: In practice this results in circa 70% of smoke testers running the module with DBI installed. The remaining 30% however, fails with this error: = # Failed test 'use DBI;' # at t/00-load.t line 4. # Tried to use 'DBI'. # Error: Can't locate DBI.pm in @INC (@INC contains: [...snip...]) at (eval 4) line 2. # BEGIN failed--compilation aborted at (eval 4) line 2. = I could easily change the use DBI line into a conditional require DBI::PurePerl during BEGIN, but this does not fix the root of the problem, namely that the PurePerl version of DBI never gets installed. We don't know the *root* of the problem. The error you quote above just a symptom of an earlier problem. Where do you get the 70%/30% ratio from? I don't know as cpanstats db shows for the last 2 versions: state, version, count(*) 'fail', '1.609', 44 'na', '1.609', 16 'na', '1.611', 1 'pass', '1.609', 1153 'pass', '1.611', 101 'unknown', '1.609', 11 'unknown', '1.611', 1 4% (rounded up) of failures for fails/passes in 1.609 discounting nas. The na status are all perls too old (not at least 5.8.1). Of the fails in 1.609 most are test failures (after compilation) and for problems Tim has addressed in 1.611. Of all the failures in 1.609 (44 of them) I got fed up of checking them after doing over half of them and finding no lack of compiler problems. In 1.611 the one compiler error is: *** You're using Microsoft Visual C++ compiler or similar but the LIB and INCLUDE environment variables are not both set. You need to run the VCVARS32.BAT batch file that was supplied with the compiler before you can use it. A copy of vcvars32.bat can typically be found in the following directories under your Visual Studio install directory: Visual C++ 6.0: vc98\bin Visual Studio .NET: vc7\bin Find it, run it, then retry this. If you think this error is not correct then just set the LIB and INCLUDE environment variables to some value to disable the check. and DBD::ODBC gets the same error from this particular smoker although on a different smoking platform. For DBI it is Win32 with MS VisC 12 and for DBD::ODBC it is Win32 with gcc. It is hardly surprising DBI and DBD::ODBC produce the same error as I think the test is in DBI but I've always been confused by the error when gcc is being used. I'd like to see details of the specific underlying problems that cause build failures with the current release. Ideally with some indication of which are the most frequent. Tim. There used to be an http://analysis.cpantesters.org/ (or something like that) but the link from the cpan testers wiki does not work now. I got the data from the cpantesters database but it does not seem to contain the actual failure report. If someone knows where the report info is I may be prepared to dig into this a little deeper but I don't as yet see any evidence that 30% of build failures are down to lack of a compiler. Martin
Re: DBI package problem?
Tim writes: I'm curious about the environment you're targeting that doesn't have a compiler. Can you enlighten me? Target is any one of the 3.5% of systems where DBI doesn't install for one reason or another (see cpantesters stats for latest stable build). I'd happily take a patch to Makefile.PL that detects the lack of a C compiler and then alters %opts so WriteMakefile() writes a Makefile that won't try to compile DBI.xs etc etc. A missing C compiler is just one out of many things that could cause a build to fail. How about using the package manager's built-in support for this kind of thing to catch all scenarios? AFAICT, no matter how much energy is put into a solution that lives inside the system (= DBI cpan package), it will never be able to beat something that lives outside the system (such as a package manager).
Re: DBI package problem?
On Tue, Mar 30, 2010 at 12:42:44AM +0200, rosenfield.alb...@gmail.com wrote: • dependencies I still think that DBI should be XS, and people should really try very very hard to make that work. Pure-perl DBI won't fly. Modules and applications that are now depending on DBI do not want to be depending on an extra layer, however thin it might be. Ah yes, I think we can easily agree that there should not be an extra layer. Just a proper selection mechanism that imports the best available module at compile time. As it is right now, PurePerl DBI is very hard to use because it doesn't install, except in cases where XS works (and PurePerl is thus pointless). I'm curious about the environment you're targeting that doesn't have a compiler. Can you enlighten me? DBI is Tim's product, but getting more and more a community effort. I bet he'd love your work on getting DBI::PurePerl working [...] Tim, what say ye? I'd happily take a patch to Makefile.PL that detects the lack of a C compiler and then alters %opts so WriteMakefile() writes a Makefile that won't try to compile DBI.xs etc etc. Tim.
Re: DBI package problem?
Here's a code example (attached). Extract it to some folder. Run the tests with Perl. Doesn't include an installer, so remember to include the library folder, FBI: $ perl -IFBI/ 00_test.pl message from XS core! $ perl -IFBI/ 01_test.pl another message from XS core! You can set the FBI_PUREPERL environment variable to force usage of XS, Perl or Automatic mode: $ export FBI_PUREPERL=0 $ perl -IFBI/ 00_test.pl message from XS core! $ export FBI_PUREPERL=1 $ perl -IFBI/ 00_test.pl message from XS core! $ export FBI_PUREPERL=2 $ perl -IFBI/ 00_test.pl message from PurePerl core! If the XS core fails to load for some reason (if you want to try you can put some random garbage in the XS module), a warning is displayed and the PurePerl core is used instead. fbi_example.tar.gz Description: GNU Zip compressed data
Re: DBI package problem?
On Sun, 28 Mar 2010 23:40:35 +0200, rosenfield.alb...@gmail.com wrote:
What is the preferred way of allowing a driver to use either
DBI::PurePerl or DBI?
Because DBI::PurePerl is inside the DBI package, the only way to
disable DBI is to make your C compiler unavailable.
requiring DBI::PurePerl will, when not found, install DBI, which
includes DBI and DBI::PurePerl. The first will only not be installed
if it cannot be compiled.
Module::Build does not support alternative requirements
(one-or-the-other), but it does allow:
=
requires = {
'DBI::PurePerl' = 0.0,
},
recommends = {
'DBI' = 0.0,
},
=
Which will essentially require the same distribution.
It looks like you have no option but to require nothing, and try to
require DBI::PurePerl during Makefile.PL time maybe.
In practice this results in circa 70% of smoke testers running the
module with DBI installed.
The remaining 30% however, fails with this error:
=
# Failed test 'use DBI;'
# at t/00-load.t line 4.
# Tried to use 'DBI'.
# Error: Can't locate DBI.pm in @INC (@INC contains:
[...snip...]) at (eval 4) line 2.
# BEGIN failed--compilation aborted at (eval 4) line 2.
=
I could easily change the use DBI line into a conditional require
DBI::PurePerl during BEGIN, but this does not fix the root of the
problem, namely that the PurePerl version of DBI never gets installed.
Why would someone install DBI::PurePerl with a working XS version?
Being able to install DBI::PurePerl is unfortunately kind of critical
to being able to use it in any way whatsoever..
Any good ideas?
Maybe too late now. But when Makamake took over Text::CSV, we discussed
the best interface. The old Text::CSV was heavily broken, and he wanted
Text::CSV to be the pur perl version of Text::CSV_XS.
We decided that the best plan was to create Text::CSV_PP to be the
pure-perl version of Text::CSV_XS and to Have Text::CSV choose the
fastest available on invocation. There is still a way to prefer either
by environment variables.
In order to do something similar with DBI, DBI should be renamed to
DBI::XS (or DBI_XS) and a new wrapper called DBI can at runtime select
either DBI::XS or DBI::PurePerl whatever is available. If this path
would be chosen, then it would be `normal' to also install
DBI::PurePerl because now the end-user has an option.
FWIW I am not the one going to implement this.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBI package problem?
On Mon, 29 Mar 2010 19:29:59 +0200, rosenfield.alb...@gmail.com wrote: FWIW I am not the one going to implement this. May I enquire why not? 1. I'm just a co-maint for DBI. I take no decisions in areas that affect that much. (I just a bit responsible for DBD::File and some docs. And I fix some bugs. 2. I have other modules that require my attention, where I still am the sole maintainer. 3. I have payed $work that takes up enough of my free time as well. Where do you see trouble brewing? • dependencies I still think that DBI should be XS, and people should really try very very hard to make that work. Pure-perl DBI won't fly. Modules and applications that are now depending on DBI do not want to be depending on an extra layer, however thin it might be. • speed DBI was (and still is) written to get the last nanosecond out of your database connection. Any slowdown will not be appreciated by the current user-base. If there be consensus, I'd be happy to expend some time and effort. Or perhaps donate money to someone with greater skill than myself to do it :-). DBI is Tim's product, but getting more and more a community effort. I bet he'd love your work on getting DBI::PurePerl working withing the current DBI framework without the current restrictions and/or drawbacks. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
