How to suss out module dependencies...
I have a question for which I have not been able to find a good answer. I have a Perl application that uses many Perl modules. Most come from CPAN, some I have written, others come with Perl distributions (core?). I am faced with the need to transport this collection of Perl code from operating system A to operating system B, both of which are perfectly well supported by Perl. Over several months I have added to system A lots of modules that need other modules. Unfortunately, system B is rather devoid of most of the modules that I need for this application. I dread having to make an inclusive list of all the modules and all the modules that those modules need, and so on, and so on. This is something that CPAN does when I install a new module that has dependencies on other modules. BUT in my case I am NOT using the blib, lib, t, MANIFEST, etc., etc., distribution model of CPAN, so I cannot use those tools - including several others on CPAN that compliment or implement this functionality. So my question is: is there a way to ask the Perl compiler/interpreter to spit out all the modules (and the other dependent modules) in my application in some format (a structured tree, a linear text file, etc.)? Failing that, are there some external tools that can accomplish this given my main module as a starting point? Thank you in advance. Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: How to suss out module dependencies...
According to Hendrik Schumacher h...@activeframe.de on Thu, 05/27/10 at 17:05: A crude solution would be to print the contents of %INC somewhere in your application: perl -e 'use DBI; use Time::Local; print join (\n, keys %INC);' Good suggestion, but won't that list a whole bunch of other stuff that is not being used, but that exists in the INC tree somewhere? Maybe that's what you meant by crude. :-) Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: How to suss out module dependencies...
According to C. Chad Wallace cwall...@lodgingcompany.com on Thu, 05/27/10 at 16:41: The autobundle command of CPAN would give you a bundle file that lists of all the modules you've installed on system A. Then you can take that bundle file over to system B and install it using CPAN. Your bundle may end up with a lot of extra modules that your program doesn't need, but you can edit the bundle file and remove them. Or maybe you could see if you can get a profiler (like Devel::NYTProf) to tell you which modules are loaded when you load and run your module. Sounds like an early 20th century internal combustion vehicle... :-) I never heard of the autobundle command until now, but it does not sound like it would address all those other modules such as those I contributed and those that come with Perl installed on system A. Nor have I heard of Devel::NYTProf (or any other Perl profilers) but when I skimmed through the Devel::NYTProf POD on CPAN just now, it looks like Devel::NYTProf is more interested in performance and the time it takes for statements and/or subroutines to execute. This is not quite what I was looking for. Thanks for the great suggestions. Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: How to suss out module dependencies...
According to David McMath mcd...@stanford.edu on Thu, 05/27/10 at 18:27: We dealt with a similar problem, moving from comfortable old server to a shiny new one. Perlmonks had some interesting advice: http://perlmonks.org/?node_id=203148 which I think is pretty cool (even though I only barely understand what it's going). I like what I see there, and like you, it will take some meditation to find out the inner truth normally revealed to true believers... ;-) This might actually work! Thanks. One of our folks ended up, though, using the CPAN::FindDependencies module and writing some stuff that walks up through our use statements until it finds something that's not ours, then asks CPAN. You mention you're not using the normal CPAN model, but FindDependencies acutally goes back to a cpan site to get its answers, so maybe that's OK. According to the POD for CPAN::FindDependencies there is this: Any modules listed as dependencies but which are in the perl core distribution for the version of perl you specified are suppressed. So this would disincline me from trying to use CPAN::FindDependencies. But this gave me an idea! I looked for dependencies on CPAN and found this: http://search.cpan.org/~jlleroy/Devel-Dependencies-1.00/lib/Devel/Dependencies.pm This looks promising at first blush... Maybe this is helpful, Thanks again. Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: How to suss out module dependencies...
According to Bruce Sears bse...@epgy.stanford.edu on Thu, 05/27/10 at 18:41: One difference with what I did is that mine determines if the mod is a core mod and does not list it, if so. I was trying to parse through all of our homegrown packages and see what non-core mods (and versions) they depended on. didn't spend a lot of time making it prettier, so some calls were system calls to start perl within perl (seems yucky) and parsing STDOUT response, but it seemed to do the job, so it remained ugly... I agree with Dave about the fact that your setup should not need to be CPAN compliant in order for you to still get the dependeny list you want if you use CPAN::FindDependencies. Pardon me for being dense, but when you say what I did and mine what are you referring to. That is, which solution or which trick should I go back and re-consider? I have seen so many suggestions in the past half-hour that my head is spinning! :-) Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: How to suss out module dependencies...
According to C. Chad Wallace cwall...@lodgingcompany.com on Thu, 05/27/10 at 18:41: Actually, no. %INC only lists modules that have been loaded into the current instance, via the 'do', 'require', or 'use' operators.[1] Okay, my ignorance of %INC is showing. Thanks. The only extraneous stuff it includes is the pragmas (strict, features, warnings, etc.) but those are easily excluded because of their all-lowercase names. I agree - not a problem., Now that Hendrik mentioned it, it seems to me that %INC is probably your best bet. But what you would have to be sure of, in the script that loads your module to dump %INC, is that you also run your module through its paces to be sure that all dependencies are loaded--even if some are required instead of used--before you dump %INC. [1] see the %INC entry in perlvar. I have had to go back to the docs time and again to get the two straight in my head (USE and REQUIRE) since they evolved over time and I never did much module or package coding until recently. What I think you are saying is that once all/most of my code paths are traversed, then all/most of the associated modules will be part of %INC for me to try Hendrick's suggestion. I'd liken it to blowing up a kid's balloon just to see what is written on the surface of the rubber which is hard to read with the balloon is deflated. Of course, unlike here, one has to be careful not to inflate the balloon too much or bad things happen... ;-) I have several great suggestions now to try. Thanks! Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
issue with Class::DBI 3.0.17
Not sure if this is the right place to mention this, but today in starting apache 2.2.17 with mod_perl2 2.0.4 and DBI 1.615 installed, I received this output: Use of uninitialized value in lc at /usr/local/lib/perl5/site_perl/5.12.3/Class/DBI.pm line 196. This may be a warning not an error, since the same message comes out when I run # apachectl -t and it is followed by Syntax OK. Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: help with odd DBI perpare/execute errors
According to Martin J. Evans boh...@ntlworld.com on Wed, 06/03/15 at 09:48: Sounds ok but the error is invalid string ORA-0911 You tried to execute a SQL statement that included a special character. http://www.techonthenet.com/oracle/errors/ora00911.php lists various causes. Yep, I've been all over the net looking for this issue. I am not doing anything wrong -- the invalid string is the darn ?!!! DBD::Oracle::db prepare failed: ORA-00911: invalid character (DBD ERROR: error possibly near * indicator at char 370 in ' select distinct s.ITEMIDNUM, c.STATUSDES, s.ADDRESS128BIT, s.PREFIX_LEN, s.ENDADDRESS128BIT, s.CREATED_USER, to_char(s.CREATED_DATE, '-MM-DD HH24:MI:SS'), i.ITEMDES, i.COMMENTS, s.RESERVEDFOR, s.AGGREGATE_STATUS, i.STATUSCD, i.ITEMNAME from UMNET_ONLINE.IP6NET s, UMNET_ONLINE.ITEM i, UMNET_ONLINE.STATUS_CODE c where i.PARENTITEMIDNUM = *? and i.ITEMIDNUM = s.ITEMIDNUM and i.STATUSCD = c.STATUSCD and i.ITEMCATCD like 'IPv6' union select distinct s.ITEMIDNUM, c.ITEMRELTYPDES, s.ADDRESS128BIT, s.PREFIX_LEN, s.ENDADDRESS128BIT, s.CREATED_USER, ...' You can see the error complaining about the question mark above. There is a second question mark in the second select statement. I'm not sure I'd trust that - doesn't that mean you are expecting stdin and stout to be in order. Yes, and they are. If you can easily do it I would stick an eval around it and trap it that way. Also, if you trap it you can print the SQL using http://search.cpan.org/~timb/DBI-1.633/DBI.pm#Statement and the parameters using http://search.cpan.org/~timb/DBI-1.633/DBI.pm#ParamValues I'll have to look into that. But recall this: I am not getting to the execute() statement. The above error is on the prepare() statment. This is so very confusing to me... I would not bother changing from ? to named - I seriously doubt this is the issue. And you can see from the above that the question mark is back in the mix. http://search.cpan.org/~pythian/DBD-Oracle-1.74/lib/DBD/Oracle.pm#ora_verbose Can be set in the connect attributes. Thanks. :-) If I were you I'd try and simply the original case down as much as possible but getting a trace with ora_verbose might help identify the problem. Okay, I'll try that next. Regards, web... -- /\ ASCII RIBBON / William Bulley \ / CAMPAIGN AGAINST / XHTML E-MAIL AND / E-MAIL: w...@umich.edu / \ LISTSERV POSTINGS / 72 characters width template -|
Re: help with odd DBI perpare/execute errors
According to Bruce Johnson john...@pharmacy.arizona.edu on Wed, 06/03/15 at
10:10:
Make sure your original $query is delimited by double quotes, not single.
I've tried _everything_!!
Single quotes. Double quotes. q{} and qq{} (using the latter now).
But no matter what I try DBI complains about the darn question mark!
It is infuriating, I tell you! :-)
if you do $sth-prepare('select column from table where column = ?');
you'll get that error.
That's the only way the ? would get past DBI, I'd think, which is
what your oracle error seems to be indicating.
It is still not repsonding to any attempts to remedy the problem, sigh... :-(
Regards,
web...
--
/\ ASCII RIBBON / William Bulley
\ / CAMPAIGN AGAINST /
XHTML E-MAIL AND / E-MAIL: w...@umich.edu
/ \ LISTSERV POSTINGS /
72 characters width template -|
help with odd DBI perpare/execute errors
Environment Perl script trying to query Oracle 11g database:
FreeBSD 9.3-STABLE
DBI 1.633
oracle8-client 0.2.0
DBD::Oracle 1.19
I have no trouble connecting with the Oracle database. And I do
recover data when I use the temporary workaround described below.
I have a query/prepare setup outside a foreach loop where I execute()
the prepared query something like this, only more complex:
my $query = select column from table where column = ?;
my $sth = $dbh-prepare ($query);
foreach ()
{
$sth-execute($value);
}
I was getting invalid string ORA-0911 errors at the question mark.
I then replaced the question mark with a number (555) and made the
execute() call just $sth-execute();
This worked. But I really needed to bind to the $value variable
in the foreach loop.
In reading the DBI POD it said for Oracle the ? is turned into
:p1 (in this case). So I replaced the question mark with :p1.
The prepare statement no longer generated an error, instead the
execute statement generated the error:
DBD::Oracle::st execute failed: called with 1 bind variables
when 0 are needed [for Statement ... ] at script.pl line xxx.
Can any one help me figure out this confusing situation? BTW, I
have been using Perl for twenty years and DBI for perhaps ten,
and I have used this query/prepare/bind/execute methodology in
the past with success. Something is different, but I don't know
what to look for.
Regards,
web...
--
/\ ASCII RIBBON / William Bulley
\ / CAMPAIGN AGAINST /
XHTML E-MAIL AND / E-MAIL: w...@umich.edu
/ \ LISTSERV POSTINGS /
72 characters width template -|
Re: help with odd DBI perpare/execute errors
According to Martin J. Evans boh...@ntlworld.com on Wed, 06/03/15 at 09:15: So, when this fails, what is the value of $value. I just ran it again. The value is 547. Assuming you have RaiseError set, you can just put an eval around the execute and if $@ is set, print out $value. I don't. I have a print statement in front of the execute to show my what I am passing to the execute() method. Strictly speaking you do not need to do this - ? is fine. DBD::Oracle also supports named parameters e.g., ':myparam' which only has an advantage if you want to use :myparam more than once in the SQL. The query is quite complex -- two SELECT statements connected by a UNION statement -- and the column = ? syntax is used twice. I changed the ? to :myparam in both places and I still get the error: DBD::Oracle::st execute failed: called with 1 bind variables when 0 are needed [for Statement... Either because you omitted the value from execute In this case, it was not omitted. but more likely because you need to associate $value with the NAMED parameter i.e., call bind_param. That will be my next test, but I don't hold out much hope for that working either (I've never had to do this in the past). Tell us the column type of 'column' and the value of $value when the original code fails. If this does not enlighten you, reduce this to a small reproducible script and re-run with ora_verbose set to 7. Paste the output somewhere we can view it. The Oracle type for the column in question is NUMBER. I assumed that any integer value would be compatible. The value is 547 for the run that just failed. Never heard of ora_verbose -- where is this to be set? Just in my code somewhere, or on the DBI-connect() method, or where? Regards, web... -- /\ ASCII RIBBON / William Bulley \ / CAMPAIGN AGAINST / XHTML E-MAIL AND / E-MAIL: w...@umich.edu / \ LISTSERV POSTINGS / 72 characters width template -|
Re: help with odd DBI perpare/execute errors
According to Howard, Chris howa...@prpa.org on Wed, 06/03/15 at 10:44: Can you post a copy of your prepare statement? Sure. Here it is: $sth = $dbh-prepare ($query) or die Couldn't prepare statement: . $dbh-errstr; Regards, web... -- /\ ASCII RIBBON / William Bulley \ / CAMPAIGN AGAINST / XHTML E-MAIL AND / E-MAIL: w...@umich.edu / \ LISTSERV POSTINGS / 72 characters width template -|
Re: DBD::Oracle 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)
According to Kurt Jaeger dbi-us...@opsec.eu on Thu, 06/04/15 at 09:38: My guess: no-one had the need, time and skills to fix it. There's a newer linux-oracle-instantclient-sdk available in the ports (10.2.0.3), and maybe it helps to compile and link a newer DBD::Oracle. I have that one (actually, those three), but they are nine years old as well: 20061115_5 is coded into the ports name. And there's an newer version (12.1.0.2.0) pending commit: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=157544 Thanks! :-) Regards, web... -- /\ ASCII RIBBON / William Bulley \ / CAMPAIGN AGAINST / XHTML E-MAIL AND / E-MAIL: w...@umich.edu / \ LISTSERV POSTINGS / 72 characters width template -|
Re: DBD::Oracle 1.19 in FreeBSD Ports (was Re: help with odd DBI perpare/execute errors)
According to Kurt Jaeger dbi-us...@opsec.eu on Thu, 06/04/15 at 02:50: DBD::Oracle no longer supports Oracle client versions before 9.2 Try a version before 1.25 for 9 and 1.18 for 8! at ./Makefile.PL line 271. and there is no oracle9-client port on FreeBSD. Thanks. That makes sense. What doesn't make sense and begs the following question is: Why isn't there an oracle9-client port for FreeBSD? Is this an Oracle issue? Is this a FreeBSD issue? Or what? Thanks! Regards, web... -- /\ ASCII RIBBON / William Bulley \ / CAMPAIGN AGAINST / XHTML E-MAIL AND / E-MAIL: w...@umich.edu / \ LISTSERV POSTINGS / 72 characters width template -|
