Re: Problems installing DBD::mysql
Have you installed the mysql libraries on your OS X system first? You need more that just the perl bindings to MySQL, you need to have MySQL installed on your machine, along with whatever libraries needed to run it. That is to say, runtime and buildtime dependencies. BTW, you may want to look into Postgres since MySQL was recently bought by Oracle. Regards, Jeremiah On Jan 31, 2011, at 07:12, Marek Stepanek wrote: Hello all! This is my first posting here, after a long silent time, receiving the postings of this group. I have a problem, which I am unable to resolve on myself: I want to install since four days now DBD::mysql on my MBP, with 64bit Intel chip. I tried with both version of MYSQL Community Server: mysql-5.5.8-osx10.6-x86_64.tar.gz (the 64bit version) and mysql-5.5.8-osx10.6-x86.tar.gz(the 32bit version) I think I am not doing something wrong, installing the MYSQL Server. (: Meanwhile I am a Professional, doing it :) But installing DBD::mysql fails already with make, and both servers: the 64bit and the 32bit ... First my Perl: % perl -v This is perl, v5.10.0 built for darwin-thread-multi-2level The installing procedure of DBD::mysql fails like follows. I am in the folder ~/.cpanplus/5.10.0/build/DBD-mysql-4.018: 1. % perl Makefile.PL Here one warning is perhaps important: Multiple copies of Driver.xst found in: /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBI/ /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level/auto/DBI/ at Makefile.PL line 907 Using DBI 1.611 (for perl 5.01 on darwin-thread-multi-2level) installed in /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBI/ 2. I fire up the MYSQL-Server to grant the privileges for the test user: % mysql grant all privileges on test.* to 'mstep'@'localhost' identified by 's3kr1t'; 3.% make And here are starting serious problems: I get plenty of following warnings: dbdimp.c: In function 'alloc_param': dbdimp.c:212: warning: format not a string literal and no format arguments 4.% make test 4.(Var) % sudo make test Both are failing with following messages: PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/00base.t .. 1/6 # Failed test 'use DBD::mysql;' # at t/00base.t line 21. # Tried to use 'DBD::mysql'. # Error: Can't load '/Users/mstep/.cpanplus/5.10.0/build/DBD-mysql-4.018/blib/arch/auto/DBD/mysql/mysql.bundle' for module DBD::mysql: dlopen(/Users/mstep/.cpanplus/5.10.0/build/DBD-mysql-4.018/blib/arch/auto/DBD/mysql/mysql.bundle, 2): Library not loaded: libmysqlclient.16.dylib # Referenced from: /Users/mstep/.cpanplus/5.10.0/build/DBD-mysql-4.018/blib/arch/auto/DBD/mysql/mysql.bundle # Reason: image not found at /System/Library/Perl/5.10.0/darwin-thread-multi-2level/DynaLoader.pm line 207. # at (eval 7) line 2 # Compilation failed in require at (eval 7) line 2. # BEGIN failed--compilation aborted at (eval 7) line 2. Bailout called. Further testing stopped: Unable to load DBD::mysql FAILED--Further testing stopped: Unable to load DBD::mysql make: *** [test_dynamic] Error 255 Could somebody help me out? Please! Best greetings from Munich marek Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: New to Mac - need help compiling a package
On Apr 27, 2009, at 22:23, Shai Simchi wrote: Hi, I am new to Mac (not to perl). I have a package Net- Twitter-2.12.tar.gz which I want to start using but not sure how to make the package available on my perl installation. Have you looked at installing with CPAN? Jeremiah
Re: New to Mac - need help compiling a package
On Apr 28, 2009, at 18:52, Shai Simchi wrote: I would love to look into this option as well. Do you have any documented procedure to share? Sure, try the command `cpan` on the command line. I think it is pre- installed on the Mac. If not, it is not hard to install. Here is more info on CPAN; http://theoryx5.uwinnipeg.ca/CPAN/perl/lib/CPAN.html To install something, i.e. a module. issue this command; perl -MCPAN -e shell My::Module Hope that helps, if not, post any questions you have here. Jeremiah Thanks, Shai On 4/28/09 1:50 AM, Jeremiah Foster jerem...@jeremiahfoster.com wrote: On Apr 27, 2009, at 22:23, Shai Simchi wrote: Hi, I am new to Mac (not to perl). I have a package Net- Twitter-2.12.tar.gz which I want to start using but not sure how to make the package available on my perl installation. Have you looked at installing with CPAN? Jeremiah
Re: Leopard, Apache and CGI Uploads
Hello Bryan, On Apr 24, 2008, at 10:59 PM, [EMAIL PROTECTED] wrote: I have a Perl file upload script I'd been using for years under Apache 1 in Tiger. I haven't modified it in ages. No mod_perl, just CGI.pm and the default Perl installation. It's always worked fine for files of any size (some as many as a gigabyte and taking more than an hour to upload), but since upgrading to Leopard, with its Apache2 nonsense, Um, apache2 rocks. It has a much better configuration layout, particularly for virtual hosts, and is a more secure web server. Once you get used to it you'll agree. the script fails on large files -- anything over a megabyte -- with this being output to the browser: CGI.pm: Server closed socket during multipart read (client aborted?).. This is the only error message logged, too. I've tested this with multiple clients on different operating systems and it's the same every time, unless the file's smaller than 1MB, in which case the script executes as it should. I added a debugging line to the upload hook that runs when I first create my CGI query object, and it reports the bytes increasing up to a point, after which it keeps logging these messages but the number of bytes stays static. It's never the exact same number but the files always seem to fail above 1 megabyte, with about 1.4 being the upper limit I've seen so far. Any ideas? Thanks Well I know that CGI.pm has tools to limit the size of uploads, or more specifically tools for controlling uploaded files as they get spooled to disk, but it appears that you did not change those settings so I am not sure if that is your problem or not. Here are some things you can add to your perl script to get more information: Use Carp, diagnostics, and warnings, if you haven't already: use warnings use diagnostics use CGI::Carp 'fatalsToBrowser' That last use directive, (the one for CGI::Carp), will print warnings to your browser which may help if you chose to diagnose the problem with a browser. You'd probably want to turn that off once the problem is solved, it reveals juicy information about the cgi environment. You can change the type and amount of messages your error log receives in the httpd.conf file for your specific domain - I think the default is warn, but you can set higher levels which might give you some more info, look for this stanza: ErrorLog /var/log/apache2/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn Set it to info or debug for more info on errors. apache2 does not use httpd.conf anymore, at least on other operating systems, but Apple has decided in their infinite wisdom to fork apache2 and they bundle configuration in httpd.conf. Bad Apple. So you will have to look in / etc/apachce2/httpd.conf to find if there are any settings there that are limiting your uploads, though a cursory check of my httpd.conf file under Leopard shows nothing that might point to limits on uploads, but as I mentioned, Apple takes liberties with apache so you never know. :) Hope that helps, Jeremiah
Re: How to run Perl script at Mac OS (Darwin) Release?
On Mar 7, 2008, at 7:35 PM, Gary Yang wrote: Hi, Below is my Perl script. The script named, test1.pl test1.pl #!/usr/local/ActivePerl-5.10/bin/perl -w print $^O\n; I have to type, perl test1.pl in order to run it. I got command not found if I simply typed test1.pl. Can someone tell me why and how to fix it? Indeed, as Chas. mentioned, the script you have written must be 'executable'. There is a distinction between a script that is plain text, like yours, and a script that can 'execute' that plain text as if it were instructions to the computer. When you called your script, you did it like this: test1.pl But your computer did not understand that you wanted to execute all the commands in your script, it just saw plain text. To tell your computer to execute your script, you have to change the permissions. That is, you have to give permission to execute the script. The way to do that is to use a command called 'chmod'. chmod 'CHanges file MODes' - it turns a plain script into an executable script. Do a `man chmod` to find out more, or just do what Chas. suggested: chmod a+x test.pl Now you can call your script and your computer will understand, Aha! it will say. I am to execute each command in this file as if someone wrote it on the command line! To call your script, do this: ./test.pl See the dot and the slash before your script's name? That says, 'execute this script right here.' Now you should see the output from your script. Jeremiah
RE: CamelBones: Maintainer needed
-Original Message- From: Tom Yarrish [mailto:[EMAIL PROTECTED] Sent: den 14 december 2007 17:07 To: Sherm Pendley Cc: macosx@perl.org Subject: Re: CamelBones: Maintainer needed Sherm, Can you give an idea on the experience one would need to maintain it? I'm assuming you wouldn't want a relative newbie to Perl to take it over. (of course if it doesn't matter, I might be interested) You're going to want to know a lot about how write applications for OS X. At the very least you will want to have some passing familiarity with Objective-C, XCode, and other Apple tools, like interface builder. CamelBones is designed to make the underlying Objective-C API accessible to perl. Obviously the more you know about the Objective-C API the easier it is, at least that is what I would imagine. Jeremiah
RE: CamelBones: Maintainer needed
Hello list, and hello Sherm, 1. That sucks. I am sorry to hear you feel that way. Not because of CamelBones but because you sound depressed. I know you have been looking for work - have you found any? A mailing list is not the best forum for this kind of discussion perhaps, but I hope you feel better, you should be proud of CamelBones. 2. I would be happy to maintain it. It would be a really interesting project. I have been working with it for a bit, long enough to point out known bugs at least. :) I am certain there are more qualified CamelBones hackers out there, but I am familiar with it and it is something I like working on. Plus I do some packaging for debian and I know a bit about the internals of Mac OS X. 3. I think some kind of team maintainership is good. If Tom wants to work on it, cool. If others want to work on it, cool. We do this in the debian perl group and while it is more obvious how to share responsibility when you are working on lots of packages, I still think there is a way to work it out with something like CamelBones as well. 4. It is really important, I feel, that this project lives on. This is one of the better ways to build graphical interfaces on the Mac. Jeremiah -Original Message- From: Sherm Pendley [mailto:[EMAIL PROTECTED] Sent: den 14 december 2007 16:53 To: macosx@perl.org Subject: CamelBones: Maintainer needed I haven't had a real job in years, and I'm at a point now where I don't even care about that, about CamelBones, about Perl, or really about much of anything else computer-related. I've had more than enough time to ship a Leopard-compatible CamelBones, but I just haven't been able to find the enthusiasm to get it (or anything else) done. I sit down at the computer, start up Xcode, and I think, what's the point? I've spent a lifetime writing code, and it's gotten me nowhere; what possible difference would a few more hours make? I've obviously got issues to deal with, and CamelBones users deserve, more than anything else, a maintainer whose head is on straight. Someone who cares about it and enjoys working on it. That isn't me, and it's way past time for me to admit that. Any volunteers? sherm--
FW: ldapsearch equivalent with Net::LDAP
-Original Message-
From: Jeremiah Foster
Sent: den 27 november 2007 09:20
To: 'Dennis Putnam'
Subject: RE: ldapsearch equivalent with Net::LDAP
I am trying to do the equivalent of this search:
ldapsearch -x -LLL -b dc=ldaphost,dc=mydomain,dc=com uid
Caveat Emptor: I am no LDAP genius.
Here is one of the many variations I tried:
use strict;
use Net::LDAP;
my $ldap=Net::LDAP-new(ldaphost.mydomain.com) or die $@;
Try replacing $@ with $!. You are using $@ which is the eval error
message, but I don't see where you are using eval. $! will tell you what
went wrong since it is the sys/libcall error message.
my $mesg=$ldap-bind();
if ($#ARGV0) {
$mesg=$ldap-search(
base=dc=ldaphost,dc=mydomain,dc=com,
attrs=[uid]
);
print $mesg-entries(),\n;
}
else {
}
$ldap-unbind();
I am just starting so my code is incomplete but it should be enough to
get something. However, I get nothing, not even an error. Can someone
see what I am doing wrong? TIA.
See what your code spits out now and diagnose from there. Hopefully that
is a start.
Jeremiah
Re: Thanks Apple! You snubbed perl yet again!
On Oct 19, 2007, at 5:12 PM, Chris Devers wrote: On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote: On Oct 19, 2007, at 2:51 AM, Chris Devers wrote: On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote: I can draw a picture for you: http://finkproject.org/ In which case, your real argument appears to be the Fink people don't seem to be doing what I need fast enough. In which case, the response is you should contribute to Fink then. Duly noted. I would like to try to do a unifier, a front end that searches all the various porting systems (fink, macports, darwinports.com) and gets the latest version of a package. [...] I, as a developer, should maintain the latest version of perl on my machines. I give in! Yes, if that's really what you need. I still think it isn't the end of the world to just work with the bundled version of Perl (along, of course, with whatever CPAN modules you need). It's not like 5.8.6 or 5.8.8 are such awful, archaic versions to work with in the first place. So target the release version, or do like everyone else that's concerned about this and install your own Perl. It's not hard to do, and it's really not that different than how things are on Debian. Yes it is. debian's packages are updated constantly, not just in point releases. So if there is a problem a new package is made available relatively quickly. Maybe my Debian experience is too limited then, but this seems like a slightly glossed over version of things to me. The last time I spent a lot of time with debian (roughly 2003-2005), it was still on 3.0/Woody. Yes, there was a constant stream of package updates, but IIRC they were all security patches, critical bugfixes (with a *really* conservative definition of critical -- merely braindead usability brokenness never seemed to be worth patching), etc. It seems like most of the updates we were getting were via backports.org rather than official updates to Woody itself. Maybe things have evolved since then, but at the time it seemed like if an update wasn't for security or a real showstopping bug (e.g. keeps the machine from booting, or a critical daemon from running), then it was seen as a mere features update and got deferred until 3.1/Sarge. If you wanted those features updates, you had to get them from backports or roll your own. Maybe as a backlash, I seem to remember that this is around when Ubuntu et al branched off to be a more current platform. Things have changed significantly. As an example, we have a tool in the debian-perl group that compares our version of a perl module with the module on CPAN. This is automated and is done daily. (http://pkg- perl.alioth.debian.org/qa/versions.html) This way we can see which modules need updating and do the update as part of our normal team work keeping perl fresh in debian. This seems like exactly the stance that we're talking about here, and as frustrating as it can seem, there are really good reasons to do things this way, not least being stability predictability for developers, who can assume confidently that release X is going to have Perl v.Y, etc. As far as Ubuntu is concerned, they just take a snapshot of debian and work out the bugs, freeze the code, and release it on a planned release date. Since it is a frozen version of debian and Ubuntu quickly becomes outdated in comparison with debian unstable, though they do issue updates for security and other bugs which they get from debian or initiate themselves. Stability is good, but elusive. Is a patched version less stable than an unpatched version? Most new versions of software are bug fixes of the same code that has been working anyway, maybe I shouldn't say most but we can agree it is many. Jeremiah
Re: Thanks Apple! You snubbed perl yet again!
negative in regards to those two fine programming languages, in this thread. I am just asking for a reasonable, up-to-date, development environment so that I do not have to shell into a linux server to do the job I need to do. So target the release version, or do like everyone else that's concerned about this and install your own Perl. It's not hard to do, and it's really not that different than how things are on Debian. Yes it is. debian's packages are updated constantly, not just in point releases. So if there is a problem a new package is made available relatively quickly. All you have to do is call `apt-get update` and you have the new packages with dependency handling built in! (Even better than CPAN's because CPAN's can only handle perl dependecies while apt-get can handle system dependencies.) If a bug appears in apache I have to wait for a new point release or infrequent security update from Apple or hope that the fix has propagated to fink which doesn't move as fast as debian and is a couple of upstream releases behind[0]. If Apple supported fink with resources, or just unified the way free software is installed on OS X, I am convinced it would see a positive response from developers and system administrators, leading to new software for the platform, more deployment, profits, etc. Right now, you have to go through Darwinports.com, Macports, fink, or compile from source. If a free operating system built by volunteers can do this why can't Apple? And why is everyone on my case because I want that? Honestly? Is it _that_ unrealistic? Are these things that no one else cares about? Have I lost my marbles? Jeremiah [0] fink: apache2 2.0.55 OS X apt-get: apache2 2.2.4 ubuntu 7.10 apt-get: apache2 2.2.6 debian/sid compile from source 2.2.6*
Re: Thanks Apple! You snubbed perl yet again!
On Oct 18, 2007, at 3:29 AM, Ken Williams wrote: On Oct 17, 2007, at 10:43 AM, [EMAIL PROTECTED] wrote: On Oct 17, 2007, at 5:25 PM, brian d foy wrote: In article B12928BB-8EB2-48E4- [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: It looks like I will have to stick with debian for developing my LAMP applications. If you want to work on the Mac, you still can. It doesn't sound like you want to though. It may sound like that to you, but if I didn't want to develop (in perl) on the Mac, why would I bother writing about this at all? Perhaps brian thought it was odd that you'd refuse to develop on a platform because of the wrong marketing statements, when all the right tools are there for both you and any target users. I have the deepest respect for brian d foy. I have met him personally in Copenhagen and I think highly of all of his work on behalf of the perl community. That said, I take exception to his rhetorical reply to my post. If you look carefully, you'll see I said I would have to stick with debian when developing my LAMP apps. This means I am trying to replicate my debian environment (Apache 2 with MP2, TT2, other gunk) on my Mac. This requires more work than it should perhaps. Not least because fink is not apt-get and some things are in fink, some are in Macports and some are in neither. I rely on debian sid and apt-get to have the latest software from CPAN, and when it doesn't, I try and package it for debian which is why I am part of the debian-perl team. I am happy to compile from source, but I loose all the work on security and compatibility from upstream when I do - not a good trade off. When I work on my Mac, I expect everything to just work. Perhaps this is wrong when it comes to a development environment for the reasons stated in this thread and elsewhere on this list but I thought impatience was virtue for a programmer. In any case, I never refused to develop for the Mac. Insert snarky emoticon here. Jeremiah
Re: Thanks Apple! You snubbed perl yet again!
On Oct 18, 2007, at 8:56 PM, Chris Nandor wrote: Not sure what you mean by losing things from upstream. Just that when I chose to compile software on my own, I lose all the debian security work. They look over packages and report vulnerabilities, I can just update with apt-get and get a new version - if I compile from source then I have to follow security warnings for the software I installed on my own. This is not a big deal if we are just talking about two or three applications, but if you are supporting a platform or a distribution, having the debian security do security for thousands of packages becomes a service that money cannot buy. Jeremiah
Re: Thanks Apple! You snubbed perl yet again!
On Oct 18, 2007, at 11:40 PM, Chris Devers wrote:
On Oct 18, 2007, at 4:43 PM, [EMAIL PROTECTED] wrote:
On Oct 18, 2007, at 8:56 PM, Chris Nandor wrote:
Not sure what you mean by
losing things from upstream.
Just that when I chose to compile software on my own, I lose all
the debian security work.
They look over packages and report vulnerabilities, I can just
update with apt-get and get a new version - if I compile from
source then I have to follow security warnings for the software I
installed on my own. This is not a big deal if we are just talking
about two or three applications, but if you are supporting a
platform or a distribution, having the debian security do security
for thousands of packages becomes a service that money cannot buy.
Sorry, I'm confused -- why not just use Debian then?
Yes.
You're basically saying you want their custom build distribution
service, but that is (naturally, one might think) only available on
their Linux distribution.
When you say 'their', who do you mean? If you mean debian, well yes.
Everyone who uses debian stable gets this custom build system, that
is the point of debian.
Apple already maintains the core OS software, including bundled
open source packages like Perl,
Apple maintains Apple's version of the so-called open source
software, but it does very little maintenance of community software
or perl in general. Can you point to Apple licensed software on CPAN
for example? I can point to lots of debian licensed software,
software built on (and sometimes for) debian that makes its way up to
the rest of the world. Why can't Apple do that?
but if that isn't enough for you, and Debian is, then what exactly
are you asking for?
I want 5.10 to work without hassle on OS X (Leopard).
I want my code to be run cross platform (I am talking CGI here -
still there are big differences between LAMP and {M,A}AMP)
I want the time and effort I invested in learning perl to be useful
for developing native applications on Mac OS X. (I am willing to
learn how to use CamelBones to accomplish this. Right now I think it
best I learn Objective-C.)
I am asking for easy to do stuff here, I am not asking for Apple to
fix that fact that MySQL runs more slowly on Apple hardware because
Apple uses the *BSD threading model when MySQL is built on the Linux
threading model and therefor is significantly faster on linux.[0] I
am not asking Apple to optimize their software to run faster on Core
Duo than linux. I am not asking Apple to Open source Aqua. I am just
asking for a reasonable, up-to-date, development environment so that
I do not have to shell into a linux server to do the job I need to do.
Jeremiah
[0] http://jeremy.zawodny.com/blog/archives/000203.html
Thanks Apple! You snubbed perl yet again!
Some yummy facts about Leopard: Scripting Bridge Use Objective-C, Ruby, and Python programs to automate Mac applications. The new Scripting Bridge enables them to easily generate AppleEvents using a concise, AppleScript-like syntax. Ruby on Rails Work in a developer's dreamland. Leopard is the perfect platform for Ruby on Rails development, with Rails, Mongrel, and Capistrano built in. Not a single word about perl. No mention of CamelBones, using the Scripting Bridge for perl, or the fact that perl has CPAN with 12,000 + high quality modules while ruby has 4,000+ on rubyforge. Apple trumpets its POSIX conformation yet what UNIX is worth its weight in cat5 cable if it doesn't come with perl? It looks like I will have to stick with debian for developing my LAMP applications. Jeremiah
Re: Thanks Apple! You snubbed perl yet again!
On Oct 17, 2007, at 5:25 PM, brian d foy wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Scripting Bridge Use Objective-C, Ruby, and Python programs to automate Mac applications. The new Scripting Bridge enables them to easily generate AppleEvents using a concise, AppleScript-like syntax. Mac OS X comes with Mac::Carbon, I thought. IS the issue that you won't have the right things available to you on the other side when you distribute applications? Yes, it does come with Mac::Carbon, and yes there is CamelBones. I just think that Apple seems to ignore mentioning perl in their fancy marketing campaigns. I get frustrated by that since there is a misunderstanding about perl in the marketplace and companies like Apple are in a position to do something about it. Apple trumpets its POSIX conformation yet what UNIX is worth its weight in cat5 cable if it doesn't come with perl? Mac OS X comes with Perl. Perhaps you meant to say CamelBones, but I don't think POSIX cares about that. It looks like I will have to stick with debian for developing my LAMP applications. If you want to work on the Mac, you still can. It doesn't sound like you want to though. It may sound like that to you, but if I didn't want to develop (in perl) on the Mac, why would I bother writing about this at all? I just had hoped for more publicity for perl from Leopard. I had also hoped for a new version of perl and Apache 2.0 out of the box. Okay, getting 5.10 into Leopard isn't realistic and maybe Apache will be updated for Leopard, and yes, a stable platform is a worthy goal for users (I am beginning to convince myself I am wrong) but I think that Apple could have provided more for developers in regard to perl. Jeremiah
Re: Leopard Perl version...
On Oct 15, 2007, at 3:01 AM, Robert Hicks wrote: Cool and thanks for the answer. I *wish* it was 5.10 as that has some very nice features that I am excited about. I will definitely upgrade to 5.10 when it ships final. Robert 5.10 is going to be really great. And you can always get some stuff from CPAN for perl6 as well, because Perl 6 is going to be amazing. Edward Moy wrote: % perl -v This is perl, v5.8.8 built for darwin-thread-multi-2level ... It's been at 5.8.8 for quite a while. 5.10 is just around the corner, but too late for Leopard. Ed On Oct 12, 2007, at 2:04 PM, Robert Hicks wrote: Is it being bumped up to 5.8.8? I am just curious... Robert
Re: Is there a True Boolean type in Perl?
On Oct 15, 2007, at 11:25 PM, Gary Blackburn wrote:
On Oct 15, 2007, at 4:27 PM, Michael Barto wrote:
As both Java and Javascript both have a 'true' and 'false' or
Boolean data type, is there any interest in evolution of Perl to
have a true Boolean. Or what is the preferred method to do this in
Perl. The C programmers want me to use 0's and 1's.
In my experience the most common convention is to use undef and 1
as your boolean values, as in:
my $is_scared;# is_scared is initially set to undef, which
evaluates as false
if ($monsters_under_my_bed) {
$is_scared = 1;
}
Yeah, it's probably bad karma to use undef when you mean 0 but
this approach is very perl-ish, easy to read, and even recommended
by Damian Conway in his Perl Best Practices book (page 40... just
checked. :-D)
You can, if you really want to, do this:
my $true = 1;
my $false;
Still, it is not much of a substitute for knowing what exactly is
_inside_ your variable and testing it to make sure. Plus, boolean
values are un-perlish. Look at this for example:
if ($var) {
print Yep!;
} else {
print Nep!;
}
That is perlish, testing if $var is defined and doing some thing
based on that. You can of course make it clearer with
if ( defined ($var))
But to be really perly and terse, this is the idiom:
print Yep if ($var);
Jeremiah
Re: Leopard Perl version...
On Oct 14, 2007, at 11:55 AM, [EMAIL PROTECTED] wrote: The subject line was Leopard Perl version, Sorry, I misunderstood. so I said it's been 5.8.8 for quite a while. It is no secret that we (Apple) try our best to keep up-to-date with perl (and other opensource projects) at every major release. Well, it is a bit of a secret. For example; httpd -v Server version: Apache/1.3.33 (Darwin) It is also no secret that we have never updated (though I might personally like to) the same opensource projects between major releases (ie, software updates). Why is that? Does Apple not provide the resources to make this possible? Personally I think they should because the Mac is a great development platform. I think Apple would win more developers to the platform if it were more open and a bit more up-to-date. Not shipping Apache 2 seems obstinate to me. Jeremiah
Re: Leopard Perl version...
Hmm, are you sure you did not update your perl yourself? I have a Macmini from April 2007 (OS X 10.4.10) and it says: $ perl -v This is perl, v5.8.6 built for darwin-thread-multi-2level On Oct 13, 2007, at 8:42 PM, Edward Moy wrote: % perl -v This is perl, v5.8.8 built for darwin-thread-multi-2level ... It's been at 5.8.8 for quite a while. 5.10 is just around the corner, but too late for Leopard. Ed On Oct 12, 2007, at 2:04 PM, Robert Hicks wrote: Is it being bumped up to 5.8.8? I am just curious... Robert
Re: Leopard Perl version...
On Oct 13, 2007, at 8:42 PM, Edward Moy wrote: It's been at 5.8.8 for quite a while. 5.10 is just around the corner, but too late for Leopard. Neither one is out yet, but I assume Leopard is pretty well frozen? (5.10 is rumored to be frozen too, but don't hold your breath. :^) ) Jeremiah
Re: my variable at global level not being passed
The more package-oriented way is probably to use the DBI package at
the top of your script. Perhaps you could do something like this:
#!/path/to/perl
use strict;
use warnings;
use DBI;
# connect to database
my $dbh = DBI-connect('DBI:mysql:db_name','user','password')
or die Could not connect to database! : . DBI-errstr;
Now you can use the $dbh variable locally. This would make your life
pretty easy and it works with 5.8.6. It makes you life easy because
you can diagnose database connections in the script you are writing
and not in some other far off script you didn't write. It also allows
you to specify very granular variables like a specific user who may
only have SELECT rights to the database which is one way to
increase security. Or you may have to change the password or even
change the database driver. All those things are doable with DBI. Do
a `perldoc DBI` to find out more.
The latest (stable) version of perl is 5.8.8 and soon 5.10 is due to
appear soon, I don't understand why Apple ships such old versions of
perl. Bad Apple.
Jeremiah
On Oct 5, 2007, at 4:06 AM, Sherm Pendley wrote:
On Oct 4, 2007, at 6:57 PM, Michael Barto wrote:
I am working with an old Perl Library (program module) written in
Perl4 and Perl 5 depending who was hacking the code. My program
that calls it, uses -w and strict and has identified many syntax
errors and so forth in the old library which I fixed. My problem
is that this library needs two variables passed as globals to it
to use in one of the subroutines, One of them is the $dbh variable
created when the database is open. Another is a hash. Both these
variables were initiated at the Main top most level of the program
with my. Unfortunately, this causes an error and the libraries
does not see the global.
My() isn't package scoped, it's file scoped.
Our() is package scoped, so add a package declaration at the top of
each of your files, and in each of them declare $dbh with our.
Basically, like this, at the top of each file that uses the shared
variable:
package SuperNifty;
our $dbh;
Alternatively, you could define $dbh in a module, and include it in
the module's @EXPORT or @EXPORT_OK, so that an alias to it is
exported into the module user's namespace.
sherm--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CGI.pm
On Sep 28, 2007, at 8:17 AM, Michael Barto wrote: This seems like a flame, but I will try and answer your question. The reason why we are doing the HTML subroutines and so many others with key at the start (e.g. JSCript, DB, make, get). is mostly to support long term maintenance and parse out pieces of the code for a very large project (divide and conquer) The modules libraries are maintained in a consistent manner. The variables $new_page and $from_page also are significant in this large code. It just helps the many people that have to touch this code have an easier path getting though any maintenance. The main program is nothing more than large set subroutine calls broken down in sections. The subroutine calls are shared by many modules of the large project. The best practices procedure is to use MVC. (Model, View, Control) - this provides separation of logic and presentation and significantly aids in the long term maintenance of your code. Look at Damian Conway's book; Perl Best Practices. By not following best practices you run the risk of making your code write only. An experienced perl programmer would have a hard time reading it and re-factor it according to best practices. Following best practices will significantly increase readability, maintenance, and quality of your code. Jeremiah
Re: CGI.pm
On Sep 27, 2007, at 6:41 PM, Michael Barto wrote:
Perl snippet question:
-
#!/usr/bin/perl -w
use strict;
use CGI;
use CGI::Carp 'fatalsToBrowser';
my $new_page = new CGI();
sub HTMLendFORM ($) {
my $new_page = $_[0];
print $new_page-end_form;
}
HTMLendFORM ($new_page);
print \n\n;
-
This above code produces div/div/form. This ti me is odd,
since i only really want /form. Does anyone have an explanation
or another way to use the CGI.pm library and produce only /form.
Yes I could just use a print statement. But I am kind of curious to
why?
Why are you doing it this way? You do not need a sub and it is best
to use $q (or the functional interface) since if anyone has to read
your code they will recognize $q immediately but wonder what
$new_page is for. And why are you printing two new lines? New lines
do not show up in HTML.
Try this:
print $q-end_form();
That usually produces /form
Re: CGI.pm
From perldoc CGI:
A Lurking Trap! Some of the form-element generating methods
return multiple tags. In a scalar context, the tags will be
concatenated together with spaces, or whatever is the current value
of the $ global. In a list context, the methods will return a list
of elements, allowing you to modify them if you wish. Usually you
will not notice this behavior, but beware of this:
printf(%s\n,end_form())
end_form() produces several tags, and only the first of them
will be printed because the format only expects one value.
On Sep 27, 2007, at 6:41 PM, Michael Barto wrote:
Perl snippet question:
-
#!/usr/bin/perl -w
use strict;
use CGI;
use CGI::Carp 'fatalsToBrowser';
my $new_page = new CGI();
sub HTMLendFORM ($) {
my $new_page = $_[0];
print $new_page-end_form;
}
HTMLendFORM ($new_page);
print \n\n;
-
This above code produces div/div/form. This ti me is odd,
since i only really want /form. Does anyone have an explanation
or another way to use the CGI.pm library and produce only /form.
Yes I could just use a print statement. But I am kind of curious to
why?
--
Michael Barto
Software Architect
circle.gif
LogiQwest Inc.
16458 Bolsa Chica Street, # 15
Huntington Beach, CA 92649
http://www.logiqwest.com/
[EMAIL PROTECTED]
Tel: 714 377 3705
Fax: 714 840 3937
Cell: 714 883 1949
'tis a gift to be simple
This e-mail may contain LogiQwest proprietary information and
should be treated as confidential.
Re: Problem installing DBI (again)
Yeah, that link looks good. You can grep your Makefile.PL and compare your path to the mysql header files to where they exist on your system. I bet that is the problem, make can't find your mysql header files. Jeremiah On Sep 25, 2007, at 2:27 PM, Lysimachos Zografos wrote: Hello, See if this helps a bit. It worked for me. http://jayallen.org/journey/2006/04/dbd-mysql-build-problems-on-mac- book-pro On 9/25/07, Mo Chicharro [EMAIL PROTECTED] wrote: Hi All, I have to send my macbook pro off for repair (suffering form the usual lack of apple manufacture standards) and am trying to install the DBI module on a G5 tower in the office. However, am running into deadends. I Have installed the developer tools amd when I run # sudo perl -MCPAN -e 'install DBI' the terminal is giving me: Writing Makefile for DBI -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible Kind regards, Mo
Re: Problem installing DBI (again)
On Sep 25, 2007, at 3:20 PM, Charlie Garrison wrote: Good evening, On 25/9/07 at 2:55 PM +0200, Jeremiah Foster [EMAIL PROTECTED] wrote: Yeah, that link looks good. You can grep your Makefile.PL and compare your path to the mysql header files to where they exist on your system. I bet that is the problem, make can't find your mysql header files. Except that mysql header files have nothing to with compiling DBI. You're thinking about DBD::mysql. Good point. I just assumed that we were talking about mysql here. I suggest bypassing CPAN and running make manually. Use CPAN as shortcut to get that directory though: $ sudo perl -MCPAN -e 'shell' (or just sudo cpan) cpan look DBI DBI-1.59$ perl Makefile.PL DBI-1.59$ make DBI-1.59$ exit When you run the 'make' command you will get some output that should explain what the problem is. The way described above is the right way to go - it is the logical next step. Jeremiah
Re: unable to install Math::GMP
On Sep 5, 2007, at 5:45 AM, Louis-Philippe wrote: Hi, I was on my way to install Net::SSH::Perl when an error with Math::GMP stopped me... I then installed libgmp successfully, tried again... no luck. then changed a couple of lines in Math::GMP Makefile.PL as written in this previous mailing : http://www.nntp.perl.org/group/perl.macosx/2006/08/msg9995.html no luck again... when I compile I get this with the error: env MACOSX_DEPLOYMENT_TARGET=10.3 cc -L/opt/local/lib -bundle - undefined dynamic_lookup -L/usr/local/lib GMP.o -o blib/arch/auto/ Math/GMP/GMP.bundle \ -lgmp\ /usr/bin/ld: /usr/local/lib/libgmp.a(mode1o.o) has local relocation entries in non-writable section (__TEXT,__text) I think your error is here ^^ (the call to ld) collect2: ld returned 1 exit status make: *** [blib/arch/auto/Math/GMP/GMP.bundle] Error 1 any IDEA? You may want to check the ld documentation to see if you can find that error message. Google produces some interesting output if you search on the ld error string. I think this link might offer some help: http://prlmnks.org/ html/543267.html It unfortunately looks non-trivial. l-p Jeremiah Foster [EMAIL PROTECTED] --- Key fingerprint = 9616 2AD3 3AE0 502C BD75 65ED BDC3 0D44 2F5A E672
Re: [Job posting] Blizzard, Mac Team
On Aug 22, 2007, at 7:39 PM, Rob Barris wrote: http://www.blizzard.com/jobopp/mac-software-engineer.shtml This is a Tools Test engineer position as part of the Mac SW group at Blizzard. Looks like a good job, shame I live in Sweden - the commute would be murder. =) Jeremiah Foster [EMAIL PROTECTED] --- Key fingerprint = 9616 2AD3 3AE0 502C BD75 65ED BDC3 0D44 2F5A E672
Re: Can't locate object method expand via package CPAN::Shell
On Aug 12, 2007, at 8:33 PM, Noah wrote:
thanks jonasbn,
but the module is still not located. what else am I doing wrong?
Macintosh-2:~ root# cat ./update.no.version.sh
#!/sw/bin/perl
This is confusing - you are writing a perl script but it ends in .sh?
Usually perl scripts end in .pl so that humans know it is a perl
script. I started debugging your script thinking it was shell.
use CPAN::Shell;
# install my favorite programs if necessary:
for $mod (qw(Net::FTP MD5 Data::Dumper)){
my $obj = CPAN::Shell-expand('Module',$mod);
$obj-install;
}
Since you now use use CPAN::SHell the expand now works. :)
# list all modules on my disk that have no VERSION number
for $mod (CPAN::Shell-expand(Module,/./)){
next unless $mod-inst_file;
# MakeMaker convention for undefined $VERSION:
next unless $mod-inst_version eq undef;
print No VERSION in , $mod-id, \n;
}
# ./update.no.version.sh
Can't locate CPAN/Shell.pm in @INC
Perl cannot find the package you downloaded called CPAN/Shell.pm. I
would be you used two methods to get your perl source:
fink and CPAN. If you use fink, fink stuffs things in /sw/, but CPAN
puts things in a different place. (See perldoc -q @INC.)
@INC is a set of perl libraries, only in perl they're called modules,
that you have on your system. You need to make sure that all the
modules that you downloaded are in @INC by telling perl where your
modules live. On my Mac I have perl modules in /sw/lib and in /usr/
lib/perl5/site_perl/ which is where Apple installed them.
Just make sure your @INC includes the CPAN::Shell.pm and you should
be okay.
(@INC contains: /sw/lib/perl5-core/5.8.8/darwin-thread-
multi-2level /sw/lib/perl5-core/5.8.8 /sw/lib/perl5/site_perl/5.8.8/
darwin-thread-multi-2level /sw/lib/perl5/site_perl/5.8.8 /sw/lib/
perl5/site_perl/5.8.8/darwin-thread-multi-2level /sw/lib/perl5/
site_perl .) at ./update.no.version.sh line 3.
BEGIN failed--compilation aborted at ./update.no.version.sh line 3.
Jeremiah Foster
[EMAIL PROTECTED]
---
Key fingerprint = 9616 2AD3 3AE0 502C BD75 65ED BDC3 0D44 2F5A E672
Re: globbing with Apple's HFS+
Just wanted to second Kenny's good advice regarding File::Find. It is a
very good tool and will make life a lot easier for you.
Jeremiah
Sun, May 20, 2007 at 01:06:35PM -0400: Kenny Gatdula mangled some bits into
this alignment:
Hi Doug,
I really couldn't tell you if this is a known problem, but, this
seems to be a job for File::Find.
Hope this helps,
Kenny
use File::Find;
use File::Basename;
my @directories_to_search = '/Users/kennyg';
find(\wanted, @directories_to_search);
sub wanted {
my $file = $_;
my $dir = $File::Find::dir;
next unless $file =~ /\.pl/;
my $dirname = basename($dir);
my $filename = fileparse($file,'.pl');
next unless $filename eq $dirname;
print Found $file in $dir\n;
}
On May 19, 2007, at 9:15 PM, Doug McNutt wrote:
The Camel book is a bit scary describing performance of filename
globbing with the *.pl or the glob(*.pl) syntax with or without
use Cwd in the preamble. Portability is declared questionable.
I find that the only thing that works is * within a loop where
each file is tested by hand.
Consider this bit of doggerel. I'm looking for special cases of a
*.pl file that appears where * means the short name of the
enclosing directory. Note especially the last command in the
second while loop. It works not! What happens is that the second
pass through the while() loop begins in the previous directory at
the point where it was cut short after finding the file I want. If
I comment out the last statement, so that all of the files in the
directory are processed, everything works.
my ($trial, $ddd, $lookfor, $error, $nextdir);
@thefolders = ();
@directories = ();
while ($trial = *)
{
if (-d $trial)
{
push @thefolders, $trial;
# print REPORT $trial\n;
}
}
for $ddd (@thefolders)
{
$lookfor = $ddd.pl;
$nextdir = $mybase/$ddd; # $mybase, global, is full path to
initial directory.
$error = chdir $nextdir;
while (*)
{
if ($_ eq $lookfor)
{
push @directories, $ddd;
# print REPORT Added directory $ddd, $lookfor in $ddd\n;
# last; # Fails. while() continues where it left off in
the previous pass
}
}
}
If I try finding *.pl, $lookfor, or glob($lookfor) I get a
real mess with hits from directories that bear no resemblance to
the most recent chdir which returned without error.
Making the second while loop operate within the while looking for
directories is even worse.
I'll probably get around to looking more deeply but there's little
point if someone here knows that it's all a known problem on MacOS
neXt. (10.3.9 here because I need to talk to my SE/30 file
server.) Oh It's perl 5.8.1-RC3.
--
Applescript syntax is like English spelling:
Roughly, though not thoroughly, thought through.
Re: Speaking of support for Camel Bones
Well said Bruce. Count me in. Jeremiah Wed, May 09, 2007 at 09:30:33AM -0700: Bruce Van Allen mangled some bits into this alignment: On 5/8/07 Tim Bunce wrote: On Tue, May 08, 2007 at 05:38:42PM -0400, Sherm Pendley wrote: On May 8, 2007, at 5:23 PM, Bruce Van Allen wrote: I think we can confidently answer the Benefits to the Perl Community issue. That's my biggest concern. CB is mostly of use to the subset of the community who are using Macs, and need to write GUI apps. My concern is whether that's a big enough subset to warrant a grant. Don't just think about the Benefits to the Perl _Developer_ Community. Also think in terms of increasing the size of the Perl _User_ Community by enabling quality Mac apps to be implemented in/with perl. Tim. Exactly. I don't have an actual count, but what comes to mind is the huge number of people now dipping their toes into SQL and programmable database systems simply because of the (L)AMP connection of mySQL and PHP. Appreciate what they're missing (besides being limited to a Web framework): CB + DBI = the real thing. And there would be plenty of other growth vectors opened up. But moving past the why, some work needs to be done before the sales pitch/evangelism. Sherm will need to write a proposal and submit it to the Perl Foundation. The rest of this message has my suggestions for how this could happen. The next deadline for submissions is June 8, 2007. Per TPF guidelines, the proposal needs to include some things that have to be thought through and written out: - Synopsis A short description. - Benefits to the Perl Community - Deliverables Quantifiable results e.g. Improve X modules in ways Y and Z, Write 3 articles for X website. - Project Details A more detailed description. Additional non-trivial items are a schedule for the project and a description of Sherm's background and qualifications to do the project. A quick look at recently funded TPF grants suggests that this might take a total of 2500 to 4000 words -- the length of a serious journal article. To do this in one month, it would be handy to have some milestones that give Sherm a timeline for writing, and provide those of us who want to help a structure for some parallel processing. 1. Project Definition. To start, the project will need to be defined; in my view this should be the realistic next set of steps in CB's development. The rest of the proposal follows from the project definition. - Sherm's part: I imagine Sherm has next steps in mind, so the task now would be for him to write out a description and circulate it. - Our part: We can help if he needs encouragement to think big or if he needs to choose what to take _off_ the plate for now. 2. Outlines, lists, or blurts for the sections listed above. This is just to get started; the point is to see what needs to be said and where it should be said in the sections of the proposal. - Sherm's part: Sherm should do this in whatever way he's most comfortable putting ideas into words. Concreteness and clarity more important than golden sentences. Ask for support where you have gaps. - Our part: Review and especially check for what's missing/incomplete in the _ideas_ for each section. Conceive of examples. Check references. 3. Writing Writing is re-writing. - Sherm's part: Develop drafts. Write to an audience that is both demanding of you and also believes in you. - Our part: review drafts, feed back quickly, stay on topic. 4. Proposal Composition The written pieces need to be strung together in order and printed out in a format different from the previous composition, so the emerging proposal may be read with fresh eyes. - Sherm's part: Piece it together, send it out, and then take a break. - Our part: Read, review, encourage, stay on topic. 5. Credentials This is a part that is important but outside the particulars of the proposed project, namely Sherm's qualifications. - Sherm's part: circulate something. Don't be modest, don't BS. - Our part: Read and review; also write our own brief and focused support notes/letters. 6. Project Schedule Budget The proposal will need a schedule for the project that makes sense, and a budget for Sherm's time that is credible. At this starting point (May 9), I think attention should be on conceiving a sufficiently large project to move CB forward -- but I don't know what that is, or how long it would take. Looking at past TPF grants will give some context for this. But focus on the project for now, and come back to this after progress on the above steps. OK, those are enough milestones for now. All meant in the spirit of creating a framework, nothing rigid or right about it. How about some dates? 1. Project Definition. Mon, May 14. 2. Outlines, lists, or blurts for the sections listed above. Fri May 18. 3. Writing Fri May 25 4. Proposal
Re: Fwd: CamelBones: Will hack for food!
Another way to promote CB that I just thought of, why not get an article in The Perl Review? I know it's not a huge audience, but I do know chromatic usually lists what's in the latest issue when he puts out the O'Reilly Perl newsletter. I just thought of something else too, maybe an interview on Perlcast? I could ask Josh McAdams if he's interested in doing the interview (or maybe we could arrange for someone to interview you). Both are really good ideas. I spoke to brian d foy at Nordic Perl Workshop at the end of April about writing an article for the Perl Review and he seemed receptive. That is to say he welcomes articles, not that I should write it since I don't know if I am qualified to write it. Josh McAdams also was at the NPW and seems like a cool guy, Perlcast is growing in audience and this seems a perfect thing to do. Jeremiah
Re: CamelBones: Will hack for food!
Sun, May 06, 2007 at 05:07:46PM -0400: Sherm Pendley mangled some bits into this alignment: On May 6, 2007, at 3:25 PM, Alex Robinson wrote: I wish even more that Apple had picked you up and made CamelBones a first class citizen. Good news: That may still happen. Good news indeed. Before I go any further I ought to introduce myself since I am new to the list. My name is Jeremiah Foster and I'm a perl hacker and OS X softie - perfect for this list eh? =) So, why has Apple ignored CamelBones? What all this means is, first-class scripting support is actually language-neutral, and even though Leopard will be the first OS version to include it, nothing about it will require Leopard. At the edges, specific support for RubyCocoa and PyObjC basically means that their frameworks and project templates are included with Leopard. Why did the OS X loving bit of the perl community sit by and let PyObjC become the default bridge. I blame the CamelBones management - i.e. myself. Great to see such candor from a developer, it is commendable. I blog and write a bit on O'Reilly's web site, maybe I can work out a blog posting about CamelBones? Hopefully that would add traffic/users/donations which would be a good thing. Let me know if you are interested sherm. I am afraid I cannot offer financial support at this time since I am also not gainfully employed in a permanent fashion, just some writing and such, but if I can help in other ways I would love to. Perhaps you can post a wish list to this mailing list so that those who can hack, provide bandwidth, etc. can contribute if that is useful to you. In any case, I am very interested in perl, OS X, and CamelBones and am willing to use my little soap box to further their vitality. Regards, Jeremiah
Re: CamelBones: Will hack for food!
Tue, May 08, 2007 at 05:25:35PM -0400: Sherm Pendley mangled some bits into this alignment: On May 7, 2007, at 6:23 AM, David Cantrell wrote: On Sun, May 06, 2007 at 08:25:49PM +0100, Alex Robinson wrote: Why did the OS X loving bit of the perl community sit by and let PyObjC become the default bridge. Because the vast majority of perl people who moved to OS X did so because it was Unix That Worked On A Laptop and not because it was Mac. Too many of us still sneer at anything non-Unix. It's not just in Mac circles either - there's a very widespread misconception that Perl is useful for system admins, web developers, and little else. One thing I find personally frustrating is the corollary, that Perl *programmers* must be admins or web devs. I find that frustrating because I'm not an admin, and while I don't mind web work, I don't want to focus on it exclusively. So, what can be done to change that? It's basically a PR/evangelism problem, which is well outside my area of expertise. Any suggestions? One or two cool apps will help. Coda is an excellent example of creating a buzz amongst creatives and developers. I also think Perl 6 is going to be really, really amazing but that may not directly aid CB, maybe present it with its own set of problems. But it would be pretty cool if CB had Perl 6 support and people could build OS X apps in Perl 6 with Cocoa bindings, w00t. Also the chattering classes, that is to say bloggers, of which I am an ignominious member, need to promote CB, perl, and Mac OS X development in general since OS X is a great platform for development and perl is a great language and CB is the perfect tool, etc. Jeremiah,
Re: CamelBones: Will hack for food!
Hi all, I have blogged a bit about Camel Bones here on O'Reilly. Please comment if you would so that the python person who commented is not the sole comment. Nothing personal against python but it sucks. http://www.oreillynet.com/mac/blog/2007/05/developing_with_camel_bones_pe_1.html Jeremiah
Re: CamelBones: Will hack for food!
Wed, May 09, 2007 at 08:55:54AM -0700: Bruce Van Allen mangled some bits into this alignment: On 5/9/07 Jeremiah Foster wrote: I have blogged a bit about Camel Bones here on O'Reilly. Please comment if you would so that the python person who commented is not the sole comment. Nothing personal against python but it sucks. But let's not turn this into a battle in the best language wars. All tools to all people, as needed, where useful! Absolutely Bruce. I didn't mean to turn this into a language war. Just trying to be funny and glib. I apologize. Jeremiah
