Re: Clean Install
On Fri, Jun 17, 2011 at 3:36 PM, Chas. Owens chas.ow...@gmail.com wrote: On Fri, Jun 17, 2011 at 08:14, Marek Stepanek marekstepa...@yahoo.co.uk wrote: snip #!/usr/bin/perl snip And yes, yes, perlbrew activated the right perl: perl -v This is perl 5, version 14, subversion 0 (v5.14.0) built for darwin-2level snip Take another look at the shebang line. You are asking for the version of perl installed in /usr/bin. This is the system version of perl (which is why you are getting 5.10). Your scripts need to start with one of the following paths: #!/home/USERNAME/perl5/perlbrew/perls/perl-5.14.0/bin/perl Or: #!/home/USERNAME/perl5/perlbrew/perls/current/bin/perl If you want your script to run with whatever Perl perlbrew has currently selected. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Clean Install
On Fri, Jun 17, 2011 at 5:34 PM, Marek Stepanek marekstepa...@yahoo.co.uk wrote: install_driver(mysql) failed: Can't load '/Users/mstep/perl5/perlbrew/perls/perl-5.14.0/lib/site_perl/5.14.0/darwin-2level/auto/DBD/mysql/mysql.bundle' for module DBD::mysql: dlopen(/Users/mstep/perl5/perlbrew/perls/perl-5.14.0/lib/site_perl/5.14.0/darwin-2level/auto/DBD/mysql/mysql.bundle, 1): Library not loaded: libmysqlclient.18.dylib Referenced from: /Users/mstep/perl5/perlbrew/perls/perl-5.14.0/lib/site_perl/5.14.0/darwin-2level/auto/DBD/mysql/mysql.bundle Reason: image not found at /Users/mstep/perl5/perlbrew/perls/perl-5.14.0/lib/5.14.0/darwin-2level/DynaLoader.pm line 194. at (eval 3) line 3 Compilation failed in require at (eval 3) line 3. Perhaps a required shared library or dll isn't installed where expected at intro6.pl line 12 There is something wrong with the DynaLoader: Don't shoot the messenger! :-) DynaLoader is just doing its job and reporting the problem. DBD::mysql can't load, because it's linked against libmysqlclient.18.dylib, and that .dylib is MIA - that's the problem. Is MySQL installed in the same place it was when you built DBD::mysql? sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Fri, Jun 10, 2011 at 10:34 AM, John Delacour j...@bd8.com wrote: At 11:45 +0100 10/06/2011, David Cantrell wrote: Several fixes come to mind: ... 4. just set PERl5LIB to whatever you fancy after that line. This will, however, mean that you override any changes that may be made to your startup files elsewhere at a later date. What would be the effect of setting a value (or no value) for PERL5LIB in ~/.MacOSX/environment.plist? That plist is for setting up environment variables for GUI apps. It has no effect on shell sessions. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Fri, Jun 10, 2011 at 11:11 AM, John Delacour j...@bd8.com wrote: At 10:38 -0400 10/06/2011, Sherm Pendley wrote: What would be the effect of setting a value (or no value) for PERL5LIB in ~/.MacOSX/environment.plist? That plist is for setting up environment variables for GUI apps. It has no effect on shell sessions. Obviously I'm missing something. If I do set it, it seems to have the same effect superficially as fink's exporting it via .profile/init.sh Yes, but since .profile is evaluated later, whatever it does will override what's set in the plist. Thus, changes in the plist will have no effect on shell sessions that set the same variable. Nor, as far as I can tell, will anything the OP does with respect to his @INC. My best guess about that his unable to create a distribution object relates to many of the files under ~/.cpan being owned by root. This whole Fink/@INC/PERL5LIB subthread is little more than a pointless distraction that won't solve the OP's actual problem. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Fri, Jun 10, 2011 at 2:27 PM, Jan Dubois j...@activestate.com wrote: On Fri, 10 Jun 2011, Sherm Pendley wrote: Yes, but since .profile is evaluated later, whatever it does will override what's set in the plist. Thus, changes in the plist will have no effect on shell sessions that set the same variable. I use this line in my .bash_profile to make sure I use the same PATH everywhere (and only have to edit it in one place): export PATH=`/usr/libexec/PlistBuddy -c 'Print :PATH' ~/.MacOSX/environment.plist` The same can be done for PERL5LIB. It can be - and I've copied that into my Collection of Handy Stuff. :-) But the question is, should it be done for PERL5LIB? That affects *all* Perls, and if you've included the path to modules compiled for (say) 5.12, but you're running 5.10, those modules won't work. That's exactly the problem that bit Fink some time ago - their init.sh used PERL5LIB to add their Perl module directories, which had modules they'd compiled with 5.6 - when Apple then released a version of Mac OS X that used Perl 5.8.1, those Fink-provided modules no longer worked. There was much wailing and gnashing of teeth over Fink breaking Apple's Perl, but in fact they didn't do that; they hadn't touched Apple's Perl at all, they had simply told *all* Perls to look for modules that only some Perls would be able to use. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Thu, Jun 9, 2011 at 6:43 AM, Marek Stepanek marekstepa...@yahoo.co.uk wrote: But perhaps this list could help me, to get @INC and $PERL5LIB clean of /sw ... How is it possible, that I have $PERL5LIB set to %ENV: PERL5LIB=/sw/lib/perl5:/sw/lib/perl5/darwin I only see two files: ~/.profile and ~/.tcshrc PERL5LIB can be set in either one; which one is executed depends on what shell you're using. The current default shell is Bash, which reads .profile - at one point in ancient history, the default was Tcsh, which reads .tcshrc. in the first file I only have one line: test -r /sw/bin/init.sh . /sw/bin/init.sh If you haven't changed your default shell, that's the culprit. It executes Fink's init.sh script, which exports the PERL5LIB environment variable. Again, this behavior goes back a while - they used to think it was a good idea for the system Perl to be able to see modules that Fink had installed under /sw/lib. I haven't used Fink in a while - I switched to MacPorts - but I *thought* they stopped doing that after a few Mac OS X releases, each with a new version of Perl that disagreed with those modules, showed them how problematic that was. If you've been migrating for a while, that line in .profile could be a remnant from an old install. At any rate, delete (# or comment) that line, exit from the shell session and start a new one, and that should clear up your PERL5LIB variable. To export the right PERL5LIB, can I add the following line to ~/.tcshrc set PERL5LIB = (/System/Library/Perl/5.10.0:/Library/Perl/5.10.0) That wouldn't accomplish anything - PERL5LIB just adds to the default paths, and the above are already in the default. Syntax seems alright, but I have still the /sw path at the beginning: Did you log out of the current shell session, and back in? These startup files are only processed when you start a new shell session, not every time they're changed. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Thu, Jun 9, 2011 at 7:40 AM, Daniel Staal dst...@usa.net wrote: Suffice it to say, if someone asks you to not CC them when you send to the list, it's polite not to. (At least for that discussion.) In general, I'd agree - but I also think it's appropriate to consider the tone reason for the request. By the time John got around to that, I had already debunked his theory about Fink, and asked him to stop the off-topic digressions about overpriced Mac hardware. I suspect he was just upset about that, and looking for any excuse to complain about something. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Thu, Jun 9, 2011 at 8:14 AM, Marek Stepanek marekstepa...@yahoo.co.uk wrote: Thank you Sherm! This is a step in the right direction. But my cpanplus Perl is still broken, with messages like: Unable to create a new distribution object for 'Archive::Tar', although I have no /sw in the %ENV or @INC any more. To be honest, I wouldn't have expected removing the /sw directories from @INC to fix anything. That's why I told John that worrying about Fink was pointless - there was nothing in your original report that suggested it might have been the source of the problem. Have you checked permissions on ~/.cpan? The error message sounds like it can't download and/or unpack the Archive::Tar package. If you're not running the CPAN shell as root (and you shouldn't be!), try making sure that the .cpan directory and everything under it is owned and writable by your user: cd ~ sudo chown -R your_username .cpan chmod -R g+w .cpan You need sudo for the chown because, if anything is owned by someone else, you'll need root authority to change its ownership. even does not show a %ENV at all. This is certainly not right, isn't it? That doesn't mean you have no environment variables at all, just none that Perl cares about. (If you recall, it was only showing PERL5LIB before, even though you probably had a lot more than that.) sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Thu, Jun 9, 2011 at 10:55 AM, Vic Norton v...@norton.name wrote: I recently installed Fink to see if it had pdffonts. This conversation has scared me; I have uninstalled Fink. I certainly don't want to start looking for Perl modules in /sw. Fear is the mind-killer. :-) Understanding what Fink does, and does NOT do, is key here. It doesn't damage or modify your system Perl in any way. All it does is add a single environment variable that Perl (any Perl, not just Apple's) looks for when it starts up. If you want the rest of Fink, but don't want its changes to PERL5LIB, just undo them. Leave the call to its init.sh in your .profile, and immediately after that, add a line that overrides its changes to PERL5LIB: export PERL5LIB='' sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Thu, Jun 9, 2011 at 11:54 AM, Charlie Garrison garri...@zeta.org.au wrote: Good morning, I haven't followed all of this thread (it was digressing there for a while). Would perlbrew be a solution for the OP. I've only been using it a short while but it makes installing and using a custom perl very simple. I've been meaning to check that out. It must do more than what I think it does, because installing a new Perl is already pretty simple: ./Configure -des --prefix=/where/ever make make test sudo make install I'll have to read up on it (thanks for the link) to see what else it does... sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Wed, Jun 8, 2011 at 10:02 AM, Marek Stepanek marekstepa...@yahoo.co.uk wrote: I have a new laptop. Congrats! I have a new iMac, so I know the feeling. :-) 1) The complier 'gcc-4.2' is not in your PATH. Add it to the PATH and try again. OR 2) The compiler isn't installed on your system. Did you reinstall Xcode, or did you migrate it from your old machine? If you migrated, you might want to try installing a fresh copy of Xcode. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Wed, Jun 8, 2011 at 11:31 AM, John Delacour j...@bd8.com wrote: I think you're going to have trouble until you get rid of everything Fink has installed and everything it's changed in /usr/bin. Fink neither changes nor installs anything in /usr/anything. It's all under /sw. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Wed, Jun 8, 2011 at 1:16 PM, John Delacour j...@bd8.com wrote: I have been thinking so all day after watching the announcement of iCloud, a complete non-happening designed, like everything Apple, for shop-happy groupees. It is free, up to a point, once you have bought your latest Mac, your latest iPhone and your latest iPad, paid the interest on the loans and the subscription to all the service providers for the connectivity needed to download tune after useless tune at an inflated price. Any chance we might keep this on-topic for once? I don't see how *any* of this whine-fest is relevant to the issue at hand. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Wed, Jun 8, 2011 at 11:49 AM, Melton Low softw.d...@gmail.com wrote: I use MacPort and I ended up deleting everything from MacPort before re-installing everything. A pointless exercise - Like Fink, MacPorts doesn't touch /usr. Everything relevant to MacPorts is found under /opt/local. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Wed, Jun 8, 2011 at 3:40 PM, John Delacour j...@bd8.com wrote: At 15:18 -0400 08/06/2011, Sherm Pendley wrote: On Wed, Jun 8, 2011 at 11:49 AM, Melton Low softw.d...@gmail.com wrote: I use MacPort and I ended up deleting everything from MacPort before re-installing everything. A pointless exercise - Like Fink, MacPorts doesn't touch /usr. Everything relevant to MacPorts is found under /opt/local. Please explain then how Marek gets /sw/lib/perl5/5.10.0 ... when he does perl -V from the command line. Are you saying that a script on his machine with the shebang #!/usr/bin/perl will completely ignore /sw/...? No. I'm saying that there are *many* ways to influence @INC without bothering any files under /usr. PERL5LIB, for one. PS. I don't need two copies of every posting to the list. Complain to the list admins. They're the ones who broke reply all, not me. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Wed, Jun 8, 2011 at 5:20 PM, John Delacour j...@bd8.com wrote: At 16:17 -0400 08/06/2011, Sherm Pendley wrote: PERL5LIB, for one. I'm sure that's very clear to everyone who already knows what you are talking about. Are you saying that by editing ~/.bashrc or some such file one could remove this environment variable that has been added by some fink or port or other animal? If that's what you mean, why not say so. Because there's nothing at all Mac-specific about it, and it's well-covered in the Perl man pages and many many tutorials, as well as having been discussed right here already, *many* times. If you can't be bothered to do even the most basic research, that's neither my fault nor my problem. I gave you the clue you needed, now go to Google and use it. Complain to the list admins. They're the ones who broke reply all, not me. You alone are responsible for who you send emails to. Blaming other people for your ignorance is a habit with you, isn't it? Yes, I'm responsible for who *I* send emails to. I'm not responsible for who the list sends emails to. A correctly-configured list will look at the To: and CC: headers of any mail it receives, and won't send an additional copy to anyone who's already received one. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: New Perl-Installation on new OS X
On Wed, Jun 8, 2011 at 11:55 AM, Marek Stepanek marekstepa...@yahoo.co.uk wrote: offtopicMy new laptop was a not really cheap: 2600 Euros Ouch! At the current rate, that translates to roughly $3800 USD - $1400 more than the highest-price MacBook Pro in the US store. I wonder, how much of that was import taxes tariffs? Probably there are old and new mixed up from migrating from my back-up. I'm probably over-cautious, but I never migrate - I always format and make a clean install, then do a clean install of all my apps. I back up my home directory, and copy it over, which preserves all my personal preferences and such. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: BOOL returned from Objective-C does not getted mapped properly (always true)
On Sat, Sep 18, 2010 at 7:07 PM, Sherm Pendley sherm.pend...@gmail.com wrote:
Found it! What's happening is that, for one- and two-byte return types
(i.e., char and short), *four* bytes are being stored in a Perl
variable. Since only one or two bytes were actually returned from the
method, the other two or three bytes of the value being returned to
Perl are essentially random.
The question is, why didn't the self-tests catch this? From the NSNumber.t test:
my $testNumber = NSNumber-numberWithChar(5);
if (defined $testNumber) {
ok(1);
} else {
ok(0);
}
# It should be able to return a bool, a char, a short, and a long
if ($testNumber-boolValue()) {
ok(2);
} else {
ok(0);
}
if ($testNumber-charValue() == 5) {
ok(3);
} else {
ok(0);
}
I can see why boolValue() would pass when it shouldn't - when this bug
bites, BOOL return values are always nonzero. But the charValue() test
verifies a specific value, not just nonzero. And, there are other
tests in this file, that use various numberWith*() methods to create
NSNumber instances, and *Value() methods to test them. They all pass.
Hmm. None of the *Value() methods take arguments, but isEqual() does.
Maybe the random values corrupting the return value from isEqual()
were left over from the argument that was passed in? I tried adding a
couple of tests to check this theory:
# Compare it with another number
my $compNumber = NSNumber-numberWithLong(5);
if ($compNumber-isEqual($testNumber)) {
ok(22);
} else {
ok(0);
}
$compNumber = NSNumber-numberWithLong(50);
if (!$compNumber-isEqual($testNumber)) {
ok(23);
} else {
ok(0);
}
These tests both use isEqual(), and the second one expects it to
return zero. Both tests pass!
I've verified the bug, and verified that it's been fixed in
Subversion. But that was with a GUI app that duplicates the conditions
exactly - using isEqual() to compare $sender to an outlet in an
IBAction method. Obviously those conditions tickle this bug in a way
that the self-tests don't. :-(
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net
Re: BOOL returned from Objective-C does not getted mapped properly (always true)
On Sat, Sep 18, 2010 at 3:32 AM, Thilo Planz thilopl...@googlemail.com wrote:
Hi, I have updated to the new CamelBones, but I am still having the problem
of NSObject-isEqual not working properly.
To recap the thread below, I am calling -isEqual on cocoa components
(I think NSButtons), and it returns values, which do not work as
booleans in Perl (maybe a memory address).
Found it! What's happening is that, for one- and two-byte return types
(i.e., char and short), *four* bytes are being stored in a Perl
variable. Since only one or two bytes were actually returned from the
method, the other two or three bytes of the value being returned to
Perl are essentially random.
This used to work back in the old days...
It's probably a holdover from the old FFCall library. Comments in the
code indicated that it promoted such return types to 32 bits.
Apparently libffi doesn't do that. I've fixed the bug and checked the
change into Subversion, and I'll roll a new release as soon as I've
verified that it applies to both PPC Intel, and for all of the
supported Mac OS X versions.
Any idea on how I can fix or workaround this issue?
One workaround is to assign a tag to the relevant controls in
Interface Builder, and compare it like this:
if ($sender-tag() == $self-{'thisButton'}-tag()) {
...
}
Tags are 32-bit values, so this bug doesn't bite them.
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net
Re: BOOL returned from Objective-C does not getted mapped properly (always true)
On Sat, Sep 18, 2010 at 7:07 PM, Sherm Pendley sherm.pend...@gmail.com wrote:
On Sat, Sep 18, 2010 at 3:32 AM, Thilo Planz thilopl...@googlemail.com
wrote:
Any idea on how I can fix or workaround this issue?
One workaround is to assign a tag to the relevant controls in
Interface Builder, and compare it like this:
if ($sender-tag() == $self-{'thisButton'}-tag()) {
...
}
Tags are 32-bit values, so this bug doesn't bite them.
Another possibility is to use a bit mask to ignore the additional bytes:
if ($sender-isEqual($self-{'thisButton'}) 0xf) {
...
}
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net
Re: BOOL returned from Objective-C does not getted mapped properly (always true)
Hmm... BOOL values should be fine - they're covered in the self-tests, and pass. Have you tried -isEqual: for other classes? NSApplication is a singleton, and Apple may not have anticipated anyone comparing it with itself, or with random strings of text. :-) I'll add some -isEqual: cases to the test suite, in any event. One can't have too many test cases. sherm-- On Sat, Dec 5, 2009 at 9:59 PM, Thilo Planz thilopl...@googlemail.com wrote: Hi there, For a long time, PerlPad has been segfaulting on recent Camelbones versions, and it seems that is caused BOOL return values no longer being mapped properly into Perl. It seems that functions such as NSObject-isEqual that return a BOOL return some kind of memory index to Perl. my $x = NSApplication-sharedApplication; print $x-isEqual($x); print \n; should return YES, prints 44858369 print $x-isEqual(random string); print \n; should return NO, prints 42636800 print true\n if $x-isEqual(random string); should evaluate to false in boolean context, but evaluates as true. I think in previous versions (of CB) this worked better. Is there any way I can rewrite my code to make at least isEqual work for now? Thanks, Thilo -- Cocoa programming in Perl: http://www.camelbones.org
[CamelBones] PAR Kits 1.1 Now available
PAR Kits are easily-installed bundles of popular CPAN modules that use the PAR.pm[1] module. They can be included in your CamelBones applications, or used in standalone .pl scripts. Included in the CamelBones PAR Kits are tools for working with XML, databases (including MySQL, PostgreSQL, and SQLite), and even Catalyst web applications. Download them from the CamelBones download site[2], and read more about them on the wiki[3]. 1. http://search.cpan.org/perldoc?PAR 2. http://download.camelbones.org/ 3. http://wiki.camelbones.org/index.php?title=Using_PAR_Kits Have the appropriate amount of fun! sherm-- -- Cocoa programming in Perl: http://www.camelbones.org
Ann: CamelBones 1.1.0
The full announcement can be found at: http://www.camelbones.org/node/4 sherm-- -- Cocoa programming in Perl: http://camelbones.org
Re: What does ord mean?
On Thu, Mar 5, 2009 at 2:17 PM, Bill Stephenson bi...@perlhelp.com wrote: Okay, but now I'm curious. What does ord mean? (or do) It's an abbreviation of ordinal, and returns the position of the character within its charset - i.e., its ordinal value, as opposed to its text value. Perl's ord() function is encoding-aware, but *only* if Perl knows what encoding the passed-in string is using, which it doesn't by default. If you use utf8 at the top of your script, Perl knows that literal strings are utf-8 encoded, and flags them appropriately. Likewise if you use the :utf8 I/O layer to open a file handle, like this: open($fh, :utf8, $filename) or die Could not open $filename: $!; Bytes that are input from $fh are then assumed to be utf-8 encoded, and Perl sets an internal flag on the scalar to indicate this. That's what happened to the OP. When scalars do *not* have their utf-8 flag set, ord(), length(), and other builtin functions fall back to assuming that they're encoded with one byte per character. If that assumption is incorrect - as it is in the OP's case, where the character takes two bytes in utf-8 encoding - then the results from these functions will likewise be incorrect. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: change a path
On Fri, Feb 20, 2009 at 11:51 AM, Dan Neville dnevi...@nytimes.com wrote: Hi, Does anyone know how to fix this: I am trying to install a couple of modules PerlMagick for one. The error I keep getting on all three of them is: lipo: can't open input file: /var/folders/LH/LHR2wOKBHPif1NtQky7mbZorFD2/-Tmp-//ccrI61Hv.out (No such file or directory) make: *** [Magick.o] Error 1 The default Perl is configured to build XS modules as universal binaries, but a library you're linking against (probably ImageMagick) is not built as a UB. This error is lipo complaining that one of the two binary components it's trying to assemble into a universal binary is missing, because it failed to build. You should have gotten an earlier compiler error telling you where the original failure was - the above is the last error. It's *far* more useful to trace errors from first to last, since later errors can be the extended result of earlier ones. You could edit /System/Library/Perl/5.8.8/darwin-thread-multi-2level/Config.pm to remove the -arch i386 and -arch ppc directives from the compiler and linker flags. Your modules will only be built for the native the architecture of the system you're using if you do that, but if they're only going to be used on that system, or on other systems just like it, that won't matter. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Sudden death of PDF::API2
On Mon, Feb 16, 2009 at 4:53 AM, Alan Fry a...@afco.demon.co.uk wrote: I am not sure what happened to Scalar::Utils when the security patch was applied but I have a suspicion it might have been deleted? Looks to me like the security patch included updated .dylibs for a number of core Perl modules, but didn't include the .pm files. So, for those who had updated those modules with newer versions from CPAN, that left a mismatch between the version number in the .pm and the .dylib. In some cases, it appears that the newer .pm (from CPAN) also tries to export functions that don't actually exist in the older (i.e. core Perl) .dylib. I suspect that these updates are created by an automated process that looks to see what files have actually been changed, and that process was run against a virgin OS install in which none of the core Perl modules had been updated from CPAN. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: perl v5.8.6 and tcl.pm on osx 10.4.11
On Jan 23, 2009, at 10:22 AM, zaid-g wrote: can anyone point me to a recently proven set of instructions to do this starting with downloading a compatible tcl tar file ? Have a look at 'perldoc CPAN.pm' for instructions on how to use the CPAN shell. sherm--
Re: Adding to @INC
On Jan 8, 2009, at 12:27 PM, Sam Seaver wrote: On Thu, Jan 8, 2009 at 11:24 AM, Sherm Pendley sherm.pend...@gmail.com wrote: On Jan 7, 2009, at 10:36 PM, Vic Norton wrote: Another curiosity. I just checked out the Perl5.8.8 files in /usr/ bin and /opt/local/bin. The /usr/bin one came with Leopard, which I bought from Apple a week or so ago. It was created on Dec 7, 2007, and it weighs 48 KB. The MacPorts perl was created on Sep 5, 2008, and weighs 1.1 MB. Why, I wonder, should one Perl5.8.8 be 25 times as big as another? MacPorts' perl is probably built with a static libperl. Apple's is built with a dynamic libperl. Would this mean that one version is 'faster' than the other? Apple has build-time information from building the entire OS that allows them to use prebinding on their libperl. That made a big difference on pre-Tiger releases, where non-prebound dynamic libraries carried a hefty performance penalty. Since most of us don't have the info that Apple has, Perl defaults to building a static libperl on Darwin. Apple overrides the default with -Duseshrplib for their build. In Tiger and newer, the dynamic loader is much improved and the reliance on prebinding eliminated. But Perl still defaults to building a static libperl, basically out of inertia. sherm--
Re: CamelBones...
Simplest thing would be to start with the Document based Perl app template. There are several ways you can get at the file's contents - as an NSURL, an NSString local file path, an NSFileWrapper, or an NSData object. All you do is get info on the target in Xcode, set up the extension (.whatever) and set the document's UTI. The UTI is a backwards-domain string similar to Java's package naming scheme. So you'd probably use com.nytimes.dneville.ProjectName or something similar. Once you've assigned the file type info, you'll have support for the standard File menu, recent documents, and drag-n-drop support for document files - it's all standard stuff, already built into Cocoa's NSDocument architecture. If you'd prefer not to use document-based apps, you can register as the shared NSApplication's delegate, and handle the dropped files by responding to the -application:openFile: and/or -application:openFiles: delegate messages. You can also configure your app to read and/or edit standard types like txt or jpg, by using specific Apple UTIs, instead of UTIs based on your own domain. For details about UTIs: http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/chapter_1_section_1.html sherm-- On Jan 10, 2008 9:31 AM, Dan Neville [EMAIL PROTECTED] wrote: Hi, I am writing an application in Perl and compiling it in CamelBones. I want to make it a DragDrop. I can't get the pasteboard to pass the file or folder information to the script. Does anyone have an example I could use as a template? Am I correct in thinking that the link is in the pList? I can't find this in any documentation. Thanks... Dan --
Re: Leopard Upgrade Killed my Modules
On Jan 9, 2008 4:44 PM, Elton Hughes [EMAIL PROTECTED] wrote: Hello All, I upgraded to Mac OSX 10.5, using the upgrade option, and the modules I downloaded from CPAN are now missing. Bummer. No problem though, I am not under a huge time problem and it would be good to get a little practice in. Leopard includes an upgrade to a newer Perl 5.8.8, so it's a good idea to reinstall your CPAN modules anyway. XS modules, in particular, are probably linked against older OS SDKs and Perl versions. So I have a couple of questions. First, where would a safe place be to my modules? Wherever ExtUtils::MakeMaker puts them. Whether you're driving it manually, or with the CPAN tool, Perl already knows where to install its own modules. So by default, the final sudo make install will do the Right Thing(tm). Second, I have started installing a few of my favorite modules and I am getting an error message from make. The error message is: make: *** No rule to make target `/System/Library/Perl/5.8.8/darwin- thread-multi-2level/CORE/config.h', needed by `Makefile'. Stop. What is happening here? And how best to solve it? Have you installed all the latest Xcode updates for Leopard? sherm--
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--
Re: CamelBones: Maintainer needed
On Dec 14, 2007 11:07 AM, Tom Yarrish [EMAIL PROTECTED] wrote: - Original Message - From: Sherm Pendley [EMAIL PROTECTED] To: macosx@perl.org Sent: Friday, December 14, 2007 9:52:43 AM (GMT-0600) America/Chicago 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-- 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) Oddly, there's not a whole lot of actual Perl code in it, although what's there is kind of obscure. Autoload is used to catch method calls that aren't implemented in Perl, and send them across the bridge, tied arrays and hashes to implement the Perl side of toll free bridging, and attributes are used to declare method signatures. Of course, there's a good amount of XS programming involved. You'd need to know your way around the perlembed, perlguts, and perlapi docs. And you'd definitely need to know your way around Cocoa, and the Objective-C runtime functions. Perl classes are registered with the ObjC runtime, and participate directly in the inheritance hierarchy; the key difference with such classes is that their selectors all share the same IMP (aka implementation function), which uses Perl's internal API (i.e. perldoc perlapi) to reflect the call to Perl. The ObjC runtime is also used to get a list of registered classes at startup, after which libperl functions are used to create all the packages and @ISA arrays that are needed for the autoloading to work when Cocoa methods are called from Perl. On the Cocoa side, there are NSArray and NSDictionary subclasses whose primitive functions use libperl functions to access Perl's arrays and hashes, respectively. To deal with that, you'd need to understand how Cocoa's class clusters work, and how to add a new concrete subclass to them. sherm--
Re: CamelBones: Maintainer needed
On Dec 14, 2007 11:52 AM, Jeremiah Foster [EMAIL PROTECTED] wrote: 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 Thanks for the support. I honestly don't know if how I'm feeling qualifies as clinical depression, or just plain old blues. One reason I brought it up in public is that it's been kind of feeding on itself. There's a bit of a stigma attached to emotional issues, so I've been reluctant to say anything. But keeping quiet meant keeping CB users in the dark about my reasons for the lack of progress. Guilt about keeping y'all in the dark made me feel worse... and so on. Breaking that cycle and being open about what's going on has helped a little. , you should be proud of CamelBones. Not to boast about it, but... I am proud of it! :-) It's my best technical achievement to date. In terms of social importance and effect on people's lives though, it still takes a back seat to my work on children's web sites at WGBH. That was dead-simple CGI work, but how could I not feel good about helping kids learn to read? 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. :) Fish in a barrel. :-) 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. There was actually a Debian package for 0.3. But, the GNUStep makefile has fallen way out of date, and I'm not sure that the whole support bundle scheme is really relevant there anyway. Given the system-wide package and dependency management on Debian (and other Linux distros), there isn't the need to have a single .app bundle that's binary-compatible with a variety of libperl versions, like there is for a Mac OS X CamelBones. 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. Even being able to share the job would be a load off my mind. One source of anxiety is just that there's no one else - if I have a breakdown, or get hit by a bus, or whatever, it'd be pretty darned hard for someone else to pick up the pieces. There are a lot of smart people here, and I'm sure the project would go on eventually, but it would be a lot harder than it really should be. One way that people could help out would be documentation. I've been using Drupal (yeah, I know, PHP, boo hiss...) on a community-oriented portal site I built for a friend. Its book module actually looks pretty nice for managing community-written docs. There could be more example apps too - the current selection is pretty thin. And, there could be more full-scale apps. A Perl-based office suite would be interesting, and far too big a task for one person. I've always wondered why there are no Perl-based word processors or text editors. Given Perl's facility with text, it seems like it would be a pretty obvious idea. 4. It is really important, I feel, that this project lives on. That's important to me also, which is why I'd rather step down than see it derailed by my current situation and mental state. sherm--
Re: Thanks Apple! You snubbed perl yet again!
On Oct 17, 2007, at 6:09 AM, [EMAIL PROTECTED] wrote: 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. The Scripting Bridge simply generates an Objective-C wrapper that has methods corresponding to an app's scripting dictionary. That class is callable from *any* language that can call Objective-C methods. 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. Sounds cool - the more the merrier. Not a single word about perl. No mention of CamelBones The fact that CamelBones is not included in Leopard isn't Apple's fault - it's mine. I didn't deliver a Leopard-ready CamelBones early enough for Apple to include it. They gave me a chance to do so, appointed an internal liason to be the contact point to deliver it to, and gave me free access to Leopard betas. On the other hand, built-in support for CamelBones is largely symbolic anyway. Neither Panther nor Tiger have it, so you'll have to embed the CamelBones framework in your app anyway, unless it's Leopard-only. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Thanks Apple! You snubbed perl yet again!
On Oct 17, 2007, at 11:43 AM, [EMAIL PROTECTED] wrote: I had also hoped for a new version of perl They're shipping the latest release (5.8.8, as noted by Ed Moy) - what do you want them to do, ship bleadperl? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Thanks Apple! You snubbed perl yet again!
On Oct 17, 2007, at 12:16 PM, Trey Harris wrote: Perhaps someone with the inside scoop can give some real beef (though I understand that that sort of inside baseball is something Apple strongly discourages). But I suspect it's just a case of marketing types taking a temperature on what's hot and making sure the hot things were mentioned repeatedly. Look at the other items on http://www.apple.com/macosx/features/300.html and it certainly looks that way. I'm not an insider, but that sounds right to me. Ruby is hot, Perl is not. (Why Python made the cut and not Perl, I'm not sure; I don't think Python's particularly hot anymore. But I don't pretend to understand marketing types.) One shouldn't read engineering decisions into marketing copy--if you've ever had to make purchasing decisions on behalf of a large company, you learn that quickly. I've mentioned this before, I think. The issue was one of sponsorship. There are Apple engineers who contribute (on their own time) to RubyCocoa and PyObjC. Those engineers stepped forward when management asked who would be willing to sponsor a foreign development language, quality-check external contributions and integrate them into Apple's internal build system, etc. A sponsor did come forward for Perl, shortly after my rant a few months ago. But my life (both personal and professional) has been rather hectic since, and I wasn't able to deliver the goods in time to ship with Leopard. Mea culpa. This does bring up something I don't think we've dealt with on this list in quite a few years though (when was it that OS X last came with Perl 5.6? Was it Jaguar? I can't recall)--for some period, probably well over a year at least, we'll be dealing with an OS X that does not have the most recent major release of Perl. Time to start working on the FAQ about how to install 5.10 alongside Apple's 5.8, since how do I get 5.10 on the Mac? will become a perennial question on this list as soon as 5.10 is released. Maybe somebody can work on an Installer package. Installing a newer Perl hasn't been a problem for a long time - since Jaguar. The problem back then was that the newer version - at the time, 5.8.0 - tried to install its core modules under /Library/Perl by default, mixing them up with any CPAN modules for 5.6 that had been installed in the same location. That problem was fixed, in two ways. First, as of 5.8.1, Perl reverted back to using the traditional /usr/local for its default install prefix. And second, Apple added version-specific subdirectories, so even if one were to use a prefix of /usr to install 5.10, its core modules still wouldn't overwrite any of 5.8.8's. The best thing Apple could do is remove the old article about upgrading Jaguar to 5.8. It was written before 5.8.1 was released, and reflects the /Library/Perl default location of 5.8.0. It's really no longer applicable. But, it's still the first article that comes up at apple.com when you google for macintosh upgrade perl, so a lot of people still follow its advice, thinking that something at apple.com is authoritative. At the very least, Apple should add this article is obsolete in big bold red letters at the top of the page. (How to install 5.10 *over* Apple's 5.8 may also be a topic to at least discuss If by discuss you mean strongly discourage, I agree with you. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: my variable at global level not being passed
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: LWP install error
One little supplemental question: %% echo $PATH /sw/bin:/sw/sbin:/sw/include:/usr/local/bin:/usr/local/mysql/bin:/ bin:/sbin: /usr/bin:/usr/sbin:/usr/local/bin:/usr/texbin:/usr/X11R6/bin Where is the $PATH-file to push the /sw to the end? The path is not saved in .tcshrc nor .profile ... If I remember well it was somewhere in / Library? May I edit this file by hand? Fink usually installs a line in your .profile that sources the Fink startup script. You could save $PATH t o $OLD_PATH before sourcing Fink's startup script, then after it runs just do $PATH=$OLD_PATH:/sw/ sbin:...etc... with the additions at the end. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: LWP install error
On Aug 28, 2007, at 9:08 AM, Marek Stepanek wrote: Have a new MBP, 17 inch :-) I need to install many many things new. First I installed a new Perl 5.8.8 in /usr/local/ - Apple's OSX is up-to-date and Xcode installed! First something, where I am not sure about: I made % mv /usr/bin/perl /usr/bin/perl_out % ln /usr/local/bin/perl5.8.8 /usr/bin/perl Is this right? Yes, that's normal. In fact, /usr/bin/perl is by default just a link to /usr/bin/perl5.8.8. live/apache.t11 1 live/jigsaw-md5-get.t21 2 live/jigsaw-md5.t21 2 Failed 3/41 test scripts. 3/831 subtests failed. I recall some talk about server-side problems with some of LWP's live tests. If I recall right, when you're configuring the module there's a prompt about whether to skip those or run them. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Can't Install DBD::mysql
On Jun 18, 2007, at 4:22 PM, Lola J. Lee Beno wrote: Joel Rees wrote: Multi-line ommand? sudo perl Makefile.PL \ --cflags=-I/usr/local/mysql/include -Os -arch i386 -fno-common \ --libs=-L/usr/local/mysql/lib -lmysqlclient -lz -lm properly in Terminal? I'm thinking that the lack of backslash terminates the command line. What's it doing (or not)? I was getting everytime I hit return. Once I retyped that line without the backslashes, it worked correctly. Unlike Perl, the command-line shell doesn't accept multi-line commands automagically. To use them you need to add a \ at the end of each line as a continuation character. Instead of taking what you've typed and running it, the shell changes the prompt to '' and accepts more input. When a line is entered without a trailing \, then the whole series of lines is joined together and executed as one command. So you can run the above command without the trailing backslashes in the first two lines above. That's what you'd do if you'd prefer to type it all on one line instead of three separate lines. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Can't Install DBD::mysql
On Jun 18, 2007, at 5:22 PM, Lola J. Lee Beno wrote: Sherm Pendley wrote: So you can run the above command without the trailing backslashes in the first two lines above. That's what you'd do if you'd prefer to type it all on one line instead of three separate lines. Ahh . . makes sense - thanks! So, I ended up by downloading the module directly from search.cpan.org (I didn't quite trust the download via cpan, specially with the weird characters appended at the end) and ran Makefile.PL and make manually. Here's the results I got: [05:10 PM] ~/.cpan/build/DBD-mysql-4.005 19 $ sudo perl Makefile.PL --cflags=-I/usr/local/mysql/include -Os -arch ppc -fno-common -- libs=-L/usr/local/mysql/lib -lmysqlclient -lz -lm Password: I will use the following settings for compiling and testing: cflags(User's choice) = -I/usr/local/mysql/include -Os - arch ppc -fno-common embedded (mysql_config ) = libs (User's choice) = -L/usr/local/mysql/lib - lmysqlclient -lz -lm mysql_config (guessed ) = mysql_config nocatchstderr (default ) = 0 nofoundrows (default ) = 0 ssl (guessed ) = 0 testdb(default ) = test testhost (default ) = testpassword (default ) = testsocket(default ) = testuser (default ) = To change these settings, see 'perl Makefile.PL --help' and 'perldoc INSTALL'. Checking if your kit is complete... Looks good Using DBI 1.56 (for perl 5.008006 on darwin-thread-multi-2level) installed in /Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DBI/ Writing Makefile for DBD::mysql [05:11 PM] ~/.cpan/build/DBD-mysql-4.005 20 $ sudo make cp lib/DBD/mysql.pm blib/lib/DBD/mysql.pm cp lib/DBD/mysql/GetInfo.pm blib/lib/DBD/mysql/GetInfo.pm cp lib/DBD/mysql/INSTALL.pod blib/lib/DBD/mysql/INSTALL.pod cp lib/Bundle/DBD/mysql.pm blib/lib/Bundle/DBD/mysql.pm cc -c -I/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DBI -I/ usr/local/mysql/include -Os -arch ppc -fno-common - DDBD_MYSQL_INSERT_ID_IS_GOOD -g -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include -Os - DVERSION=\4.005\ -DXS_VERSION=\4.005\ -I/System/Library/Perl/ 5.8.6/darwin-thread-multi-2level/CORE dbdimp.c /usr/bin/perl -p -e s/~DRIVER~/mysql/g /Library/Perl/5.8.6/darwin- thread-multi-2level/auto/DBI/Driver.xst mysql.xsi /usr/bin/perl /System/Library/Perl/5.8.6/ExtUtils/xsubpp -typemap / System/Library/Perl/5.8.6/ExtUtils/typemap mysql.xs mysql.xsc mv mysql.xsc mysql.c Warning: duplicate function definition 'do' detected in mysql.xs, line 225 Warning: duplicate function definition 'rows' detected in mysql.xs, line 612 cc -c -I/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DBI -I/ usr/local/mysql/include -Os -arch ppc -fno-common - DDBD_MYSQL_INSERT_ID_IS_GOOD -g -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include -Os - DVERSION=\4.005\ -DXS_VERSION=\4.005\ -I/System/Library/Perl/ 5.8.6/darwin-thread-multi-2level/CORE mysql.c Running Mkbootstrap for DBD::mysql () chmod 644 mysql.bs rm -f blib/arch/auto/DBD/mysql/mysql.bundle LD_RUN_PATH=/usr/local/mysql/lib /usr/bin/perl myld env MACOSX_DEPLOYMENT_TARGET=10.3 cc -bundle -undefined dynamic_lookup -L/usr/local/lib dbdimp.o mysql.o -o blib/arch/auto/DBD/mysql/ mysql.bundle -L/usr/local/mysql/lib -lmysqlclient -lz -lm chmod 755 blib/arch/auto/DBD/mysql/mysql.bundle cp mysql.bs blib/arch/auto/DBD/mysql/mysql.bs chmod 644 blib/arch/auto/DBD/mysql/mysql.bs Manifying blib/man3/DBD::mysql.3pm Manifying blib/man3/DBD::mysql::INSTALL.3pm Manifying blib/man3/Bundle::DBD::mysql.3pm Does this seem right to you? It looks fine so far, but you've only done the first step. Does the user account you're using to run the tests have access to the test database? If not, you'll need to specify the database user name and password to use by passing the --testuser=foo and --testpassword=bar options to Makefile.PL. If testing this produces errors that indicate a failure to log in to MySQL, do a sudo make distclean to start over from scratch. Rerun Makefile.PL, being sure to include the database user and password options. Also, only the final step needs to be run with sudo, and that only if you're installing in the default location, which you are here. As an exception, the first sudo perl Makefile.PL ... may have created some root-owned files, so if you start over for any reason it'd be best to use sudo make distclean to make sure distclean has the permissions to delete those. Or just nuke the folder from orbit and unzip a new copy... :-) It didn't seem to have gone through the testing portion. You didn't run the other steps; the full recipe is: perl Makefile.PL --with-whatever-args make make test sudo make install Sorry if this sounds obvious, but you shouldn't continue with the next step until you're happy
Re: Can't Install DBD::mysql
On Jun 13, 2007, at 7:33 PM, Lola J. Lee Beno wrote: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib Referenced from: /Users/lolajl/.cpan/build/DBD-mysql-4.005-cC14so/ blib/arch/auto/DBD/mysql/mysql.bundle Reason: image not found at /System/Library/Perl/5.8.6/darwin- thread-multi-2level/DynaLoader.pm line 230. at (eval 3) line 3 What should i do next? The error message is telling you what file is missing - it's the C client library that should have been installed with MySQL itself. So, what went awry during the MySQL installation to cause that file to be missing? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones: Will hack for food!
On May 9, 2007, at 11:55 AM, Bruce Van Allen wrote: 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! That, indeed, is the philosophy of CamelBones. I'll say it again, in the land of the free: Use your freedom of choice! --Devo sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones: Will hack for food!
On May 9, 2007, at 11:51 AM, Vic Norton wrote: On 5/8/07, at 5:25 PM -0400, Sherm Pendley wrote: 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'm a retired mathematician, myself. Is that something you can *really* retire from? Or are you doing the same thing you've always done, only now without bosses and schedules to distract you? :-) I can't even administer my own (iMac) system, but I use Perl constantly. I am not particularly interested in Camel Bones, but I do use the ShuX application quite often. You had something to do with that didn't you, Sherm? I believe I got it from your site. Yes, ShuX was the first CamelBones app. When I switched to Mac OS X, I found that a couple of years of using MacPerl and Shuck had thoroughly spoiled me for readable docs. I simply could not stand going back to reading them in fixed-pitch Monaco again. I had a little sign over my monitor for a while that said Times or Bust. :-) Funny thing is, I like Monaco for command-line work, and for editing text in BBEdit. It's only for reading docs that it really bothers my eyes. | Mathematician and Motorcyclist Have you seen the new Norton motorcycles? The Commando is *sweet*! :-) sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones: Will hack for food!
On May 7, 2007, at 11:44 AM, Chris Nandor wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sherm Pendley) wrote: I need donations to CamelBones. Or web hosting customers. Or consulting clients. Or a plain old-fashioned job. Or something - and I need it soon. Have you considered a Perl Foundation Grant? Surely this is more worthy than some of the other grants they've done. I've considered it, but one of the requirements is that the proposed project benefits a large segment of the Perl community. Honestly, I've never figured CamelBones would meet that requirement - Mac users are a pretty small niche, Cocoa developers a small niche within that, and Cocoa/Perl developers a small niche within that. On the other hand, it appears that quite a few of Perl's heavy hitters are using Macs. And it certainly couldn't hurt to ask. So I'll write up a proposal for this round, and see what happens. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones: Will hack for food!
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? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Speaking of support for Camel Bones
On May 8, 2007, at 5:23 PM, Bruce Van Allen wrote: On 5/7/07 Chris Nandor wrote: Have you considered a Perl Foundation Grant? On 5/7/07 Tim Bunce wrote: Seconded, FWIW. On 5/8/07 Tom Yarrish wrote: This just came through on my RSS reader. http://news.perl-foundation.org/2007/05/calls_for_proposals.html Let's get behind this. Sherm could do some work that moves CB forward, maybe the .scriptingbridge metadata. I can't send money right now -- I freelance and am also currently in a trough. But I've done lots of editing and grant-writing, so if you need that kind of help to tighten up a proposal, let me know. That would certainly be a help. I've never written a proposal like this before. I'd like to learn, so I'd prefer to write at least the first draft myself, but feedback from someone with experience would be very valuable. Also, I notice that the Perl Foundation guidelines don't mention letters of support, but if Sherm submits a proposal, letters to vouch for him CB would probably help (now Chris, don't auto-bury them ;-). I think he only does that for Red Sox polls. :-) 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. Maybe Apple could make a grant to TPF -- tax-deductible 'n' all -- designated for this project... I'll ask my sponsor at Apple about it. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones: Will hack for food!
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. So, why has Apple ignored CamelBones? They asked around internally for sponsor engineers to accept the job of reviewing a scripting bridge for code quality, running compatibility tests, etc. They found volunteers for Python and Ruby early on - but not for Perl. The good news is, there's a volunteer for Perl now too, and the pushed-back release date for Leopard has bought us a little breathing room. So there's still a chance for Perl to be a first class citizen. The bad news is, we arrived late to the party and there's a lot of catching up to do. The key is supporting the .scriptingbridge metadata. Objective-C is very introspective, so finding out about classes and methods at runtime is easy. Scriptingbridge is an XML format that describes the parts of a framework that aren't so easily found at runtime, such as C functions, enums, and globals. This was first introduced in RubyCocoa, and is currently available in the latest pre-release for RubyCocoa. The PyObjC team has agreed to support it as well. I wasn't privy to the conversation inside of Apple, but I get the impression that the tipping point was when they found those two communities had agreed on a common format for this, meaning that Apple could provide very good support for *any* bridge that adopts it, with a single effort. Or maybe they instigated that agreement - I honestly don't know. Regardless, I've agreed to support .scriptingbridge metadata as well - it's a great idea, and I'm not afflicted with NIH syndrome. The .scriptingbridge format and general scheme is public information - I've verified with Apple that it's not NDA'd. And it's not limited to Leopard; I intend to use it for Tiger and Panther versions of CamelBones as well. I can also tell you that Apple has included me on the private mailing list where its development is being organized. Also, I've been given access to the latest up to the minute version of the tool that generates metadata from header files. It's straight off the engineer's desk, newer even than the latest available Leopard build - which I've also been given access to. One thing I can't get into is which specific frameworks have been blessed with the addition of bridging metadata in Leopard. BridgingSupport is public information - how Leopard uses it is not. So don't ask me. :-) 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. It would be a nice symbolic gesture for Apple to include such things for CamelBones as well, and very valuable from an advocacy standpoint, but it wouldn't be a show-stopper if developers had to download those pieces separately - it's what you're doing right now. Either way, CamelBones apps will enjoy the same deep level of bridging support that's available to any bridge. 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. Seriously - I've made a lot of mistakes along the way. One of them - a big one - was allowing my own troubles to affect my enthusiasm for CamelBones, and even blaming it for my troubles. Another was not making regular releases. Yet another was not providing adequate docs and examples. I'm working hard to overcome these problems. This thread is an example of how I'm addressing the first. I didn't start by moaning about how CB hasn't made a lot of money, or threatening to stop working on it, as I've done in the past. That habit, I think, has shaken a lot of people's confidence. So I said the simple truth, that I'm in a hard spot, and need to find work and/or donations. I'm releasing far more often recently - approximately monthly. And, I've started adding more examples - the recent SimpleDBI is just the first. How depressing is it that there's not even a mention of perl in this quick round up by John Gruber (himself a keen user of perl)? http://daringfireball.net/2007/02/dynamic_scripting_languages And that's before Rails gets bundled by default with Leopard... In the interest of fairness, that was also before Catalyst was bundled with CamelBones. :-) sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
CamelBones: Will hack for food!
Okay, the subject is sensationalistic - I'm not in danger of starving, and neither are my cats. But, I am less than two weeks away from losing my internet connection and web server. I'm broke and unemployed, or whatever the term is for owning a business that has zero paying customers. I guess that's what I get for living in the sticks - there's apparently as much demand for software developers in WV as there is for evolutionary biologists in Kansas. I need donations to CamelBones. Or web hosting customers. Or consulting clients. Or a plain old-fashioned job. Or something - and I need it soon. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
New CamelBones demo: SimpleDBI
I've uploaded a new demo app to the CamelBones site: SimpleDBI. It uses the DBIKit and DevKit PARs provided with CamelBones. It shows how to use an NSTimer instance to fetch one row of query results at a time, without blocking the run loop and triggering a rainbow cursor. The unblocked run loop also allows for a cancel button click to be processed. The demo also uses an embedded WebView to display the results as an HTML table. The pre-built .app runs on both Panther and Tiger (universal), and includes drivers for both MySQL and PostgreSQL. This demo will be included in the next release of CamelBones, but for now you can download a snapshot of it from the CVS page of the web site: http://camelbones.sourceforge.net/download/cvs-install.html While you're at the web site, please consider donating to the project! Your donations are what makes CamelBones possible. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Perl OpenGL 0.55 - Need Mac testers
On Apr 17, 2007, at 11:04 AM, Bob Free wrote: A new Perl OpenGL 0.55 candidate has been released: http://graphcomp.com/opengl Incidentally, thank you for adopting this module. I first got it working on Mac OS X 10.0 some six or seven years ago, but the docs more or less said it had been abandoned. I sent my patch to the last listed owner, but never heard back from him. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Perl OpenGL 0.55 - Need Mac testers
On Apr 19, 2007, at 7:13 PM, John Delacour wrote: At 4:10 pm -0400 19/4/07, Sherm Pendley wrote: It needed a few tweaks to build, but once the build issues were sorted, the spinning texture-mapped cube test runs fine on my G4 w/ ATI Radeon 9000 Pro. Diff with the build changes is attached, if anyone else feels like testing it. For dummies like me can you please describe the process of installing. Where does the .diff file go etc? Diffs are used as input for the 'patch' command. On my machine: local:~/incoming/OpenGL-0.55 sherm$ patch -p1 ../OpenGL-0.55- Macosx.diff patching file MANIFEST Hunk #1 FAILED at 68. 1 out of 1 hunk FAILED -- saving rejects to file MANIFEST.rej patching file Makefile.PL patching file glu_util.h patching file include/GL/glut.h patching file utils/Makefile.macosx I'm not sure why the patch to the MANIFEST file was rejected, it just adds a single line. It won't cause test failures, but the 'utils/ Makefile.macosx' file won't be included in the distribution tarball without it. :-( sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
CamelBones - Does anyone still care about Jaguar?
Subject says it all. Would dropping Jaguar support bother anyone? Supporting it is becoming problematic. PAR requires a newer Perl than Jaguar shipped with, for one thing, as do an increasing number of CPAN modules. So the PAR modules and kits included with the latest CB don't support Jaguar. There's also the question of Unicode; Perl 5.6.* doesn't support it very well. Then there's a purely pragmatic reason: Disk space. My work drive has Tiger on it, of course. My alt OS drive is the 25GB that my Mac was born with, which has room for two OS partitions. Right now, that's Panther and Leopard. There are solutions, of course - shrinking the work drive partition to make room for a Jaguar partition there, replacing the alt OS drive were a second 120GB (the largest my Sawtooth G4 will support), etc. But any of those require effort, cost, or both, and I'm doubtful at this point that supporting Jaguar is worth it. Thoughts? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Mac::Carbon issues
On Mar 28, 2007, at 7:57 PM, Chris Nandor wrote: What cpan requires File::HomeDir::Darwin? CPAN.pm, or some script ... ? The latest CPAN.pm requires File::HomeDir, which in turn requires File::HomeDir::Darwin. I'm not certain when that change happened. You have -arch i686 -arch ppc, which makes it a universal build, as I understand it, and when we last ran into this problem, we figured out to add -msse2. Is that also a requirement for -arch i386? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Getting all file paths
On Mar 23, 2007, at 8:52 AM, [EMAIL PROTECTED] wrote: I'm still new to Perl and was just curious if the code below is ok to use. Also, can someone direct me to more information about file::find? I'd like to know if -d means directory (I assume it does) as well as -f and other options that may apply. Those aren't part of File::Find - they're File test operators. For a full list, have a look at perldoc -f -X, or just open up perlfunc in ShuX - they're the first function listed. Just don't ask me why they're called operators, but documented in perlfunc instead of perlop... :-( sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Interacting with other applications
On Mar 23, 2007, at 10:56 AM, David Cantrell wrote:
On Thu, Mar 22, 2007 at 05:55:18PM -0400, Sherm Pendley wrote:
On Mar 22, 2007, at 1:01 PM, Andrew Brosnan wrote:
I'd like to run a daily backup script on my laptop, but I'd like
it to
ask permission first. I'm wondering what is the best way to do this.
First off - can you always depend on a user being logged in? If so,
the simplest ideas tend to be the best. For a full-blown GUI app I'd
use CamelBones, but for a simple OK/Cancel dialog the old MacPerl
module is still the easiest:
#!/usr/bin/perl
use MacPerl;
my $verify = MacPerl::Answer('Do you want to run backups?', 'OK',
'Cancel');
print $verify, \n;
Consider what happens if I'm busily typing away, and the dialogue box
pops up and grabs focus, and then whatever its default is gets
selected
because i hit space or enter. So not only have you annoyed me by
popping something up and then removing it before I get a chance to
read
it, you'll now take an action without the user knowing about it but on
the assumption that he does, *and* you've eaten an arbitrary amount of
what I typed, which I'll have to type again.
Needless to say, this is a Very Bad Idea.
If this were something that might pop up at any random moment, I'd
agree. But it's a daily backup script - it's not unexpected, and
presumably it's scheduled to run at the same time every day. Andrew
doesn't need to be notified that it's going to run, he knows that
already; all he needs is veto power over it.
sherm--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
ANN: CamelBones 1.0.2
What is CamelBones? CamelBones is a Cocoa / Perl bridge for Mac OS X. Like most bridges, CamelBones is bidirectional - It makes Perl accessible from Objective- C, as well as making Cocoa accessible from Perl. You can write a native Cocoa database front-end using DBI for your corporate clients, embed Perl as an application scripting language for your bespoke tool chain, or build complete self-contained web-based apps using the included set of Catalyst modules. CamelBones on the web: http://camelbones.sourceforge.net New in 1.0.2: This release fixes some remaining memory management bugs in the CBPerlHash and CBPerlArray classes. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: GUI development and deployment
On Mar 20, 2007, at 4:35 PM, Kevin Walzer wrote:
1. Is CamelBones the only option for developing a native Perl GUI
on OS X? Does anyone use wxPerl, or Tcl::Tk (to get access to
native Aqua Tk)? I'm not interested in Perl/Tk because it's X11-based.
It's the only option *I* use. But I'm a bit biased. :-)
2. What options are available for deploying Perl applications as
standalone app bundles with all frameworks/libraries shipped with
the app? Is there a tool like py2app (Python) for Perl? I know
about tools such as PAR and perl2exe, but I don't know how these
translate into Mac app deployment.
As of CamelBones 1.0.1, the PAR module and its prerequisites are
included with CamelBones - Drop a zipped .par onto your project.
It'll be copied into your app's Resources/ subdirectory automatically
- Xcode's default for file types it doesn't know about.
Then, in your main.pl:
BEGIN {
use CamelBones qw(:All);
my $resDir = NSBundle-mainBundle()-resourcePath();
eval use PAR '$resDir/*.par';
}
PARs with XS modules can be complicated to create for Mac OS X -
you'll need version and arch-specific subdirectories for the 5.8.1
and 5.8.6 (universal) Perls in Panther and Tiger, depending on what
OS version(s) you want to support. Prebuilt PARs for some of the most
commonly-used XS modules are included in /Developer/CamelBones/Modules/.
sherm--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Interacting with other applications
On Mar 22, 2007, at 1:01 PM, Andrew Brosnan wrote:
I'd like to run a daily backup script on my laptop, but I'd like it to
ask permission first. I'm wondering what is the best way to do this.
First off - can you always depend on a user being logged in? If so,
the simplest ideas tend to be the best. For a full-blown GUI app I'd
use CamelBones, but for a simple OK/Cancel dialog the old MacPerl
module is still the easiest:
#!/usr/bin/perl
use MacPerl;
my $verify = MacPerl::Answer('Do you want to run backups?', 'OK',
'Cancel');
print $verify, \n;
sherm--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Ann: CamelBones 1.0.1
On Mar 15, 2007, at 10:19 PM, Robert Hicks wrote: I downloaded what the web page said was the latest version but the .dmg file is CamelBones-1.0.0.dmg. Fixed the link - sorry. At this point though, you're probably better off waiting for 1.0.2. There's a fairly obnoxious bug, caused by the fixes in 1.0.1 for other bugs, and so I'm testing and releasing 1.0.2 ASAP. Today, if I can manage that, tomorrow if not. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Ann: CamelBones 1.0.1
What is CamelBones?
CamelBones is a Cocoa / Perl bridge for Mac OS X. Like most bridged,
CamelBones is bidirectional - It makes Perl accessible from Objective-C,
as well as making Cocoa accessible from Perl. You can write a native
Cocoa database front-end using DBI for your corporate clients, embed
Perl as an application scripting language for your bespoke tool chain,
or build complete self-contained web-based apps using the included set
of Catalyst modules.
Where can I get CamelBones?
The place to get started is: http://camelbones.sf.net
What's New in 1.0.1?
Exceptions are bidirectional now. You can catch Perl die() and other
errors using standard Objective-C exception handling.
The PAR module and its prerequisites are included with CamelBones for
10.3 (Panther) and 10.4 (Tiger). (The current PAR module is not
compatible
with the Perl included with 10.2) So, you can include .par files in your
applications. Finding the .par modules needs to be done after CamelBones
initializes, so that NSBundle methods can be called to find the .app
bundle, like so:
# main.pl is a good home for this
BEGIN {
use CamelBones qw(:All);
my $resDir = NSBundle-mainBundle()-resourcePath();
eval use PAR '$resDir/*.par';
}
To bundle PAR packages into your app, just drag-n-drop them onto your
Xcode
project, or choose the Project/Add to Project... menu item. Xcode will
add them automatically to the Copy Resources phase of your project.
Pure-Perl PARS are easy to create - they're just .zip files renamed
to have
a .par extension instead. The directory structure inside of the .par
file
must reflect the package name space, i.e. Foo::Bar would be:
Foo/Bar.pm
XS modules are more work to create; they need to include binary-
compatible
versions for *all* of the OS versions you intend to support. Also, note
that XS modules for Tiger (and newer) OS versions will need to be
Universal
if your app is to run as a Universal Binary. A tutorial listing the
steps I
taok to create the UB modules found in the CamelBones module kits is
coming soon on the web site.
Module kits are now packaged as .par files, and greatly expanded. A
full
list of the included modules is available on the web site, but in short:
DevKit - Modules useful in a variety of problem domains.
DBIKit - DBI, DBD::* drivers for MySQL, PostgreSQL, and SQLite, and
additional DBIx::* modules for database programming.
MacPerlKit - The latest Mac::Carbon.
XMLKit - Many XML::* modules for working with XML.
CatKit - Catalyst, its prerequisites, and many plugins.
The old RendezvousBrowser example from the 0.3 series has been updated
to CamelBones 1.0, and renamed to NetService Browser.
A couple of memory-management bugs were fixed.
sherm--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: unitialized value error in Scalar Util module
On Mar 11, 2007, at 9:57 AM, Joel Rees wrote: On 平成 19/03/11, at 19:55, Sherm Pendley wrote: What it are you talking about that senses Perl 5.8.8? The scripts you're trying to run? Something you're trying to install? Are you certain that it's sensing Perl 5.8.8? How are you certain of that? The perl ./Configure and/or cpan. I couldn't find documentation on doing an uninstall, and when I tried to recompile with the binaries in place under /usr/local the ./Configure and/or cpan initialization scripts kept giving me bad results. Sorry to be so vague, but if you're an IT vet, Highly questionable these days. My memory for technical stuff seems to be going away. No worries. The details change - languages, applications, APIs, etc. - but the mindset never changes. Everything that happens on a computer is always a direct cause-effect chain of events. At least, until we finally perfect quantum computers with three-state (yes/no/ maybe) logic. That'll be the day I start my new career as a carpenter. ;-) you know the drill - troubleshooting is a methodical, step-by-step process, and you can't rely on guesswork for any step. Step one: Which Perl are your scripts running with #!? I spent a little time building a .bash_profile script that would insert /usr/local/bin between /bin and /usr/bin. I then checked that calling perl from the command line gave me 5.8.8 instead of 5.8.6, which is the one in /usr/bin. I even noticed that apache, when run from the command line instead of the system preferences, had the altered path, so I'm pretty confident anything that picked up the path from the environment would have been getting the perl under /usr/local. Since I always told ./Configure and the cpan initialization script to install under /usr/local, or, rather, checked that the default was set to that and left it that way, I assume cpan should know where it's supposed to get perl from. The admin user, rather than root, owns /usr/local during the compile and install, for what it's worth, so the install step was not sudone. Anyway, nuking it from orbit did the trick, so I apologize for the noise. My dynamic dns script (which specifies /usr/local/bin/perl on the shebang line) The shebang line is what I was asking about. I wish I had a dime for every time someone has posted here, having installed a new Perl, but finding that their new Perl couldn't find its own modules. Invariably, the problem is that the #! line is still pointing to /usr/ bin/perl. Apache doesn't normally need the $PATH. If you're using mod_perl, the full path to libperl is hard-coded at build time. And if you're using a CGI, the full path to the interpreter is needed in the #! line. Anyway, no, CPAN doesn't know *anything* about multiple Perls, or how to figure out which Perl you want to install modules for. All it knows about is the Perl it's running with - that's the one it will install modules for. If you run CPAN with /usr/local/bin/perl -MCPAN - e shell, you'll get modules installed to that Perl. If you run it with perl -MCPAN -e shell, then Bash will use the $PATH to figure out which perl to run, and that will be the one you wind up installing modules for. If you're using the cpan shell script instead of perl -MCPAN, have a look at that script's #! line. Another thing to try - do a !print $] from in the CPAN shell. The ! command is for evaluating arbitrary Perl code, and it's just an eval(), not a system(), so printing the version # that way will tell you what Perl is running the CPAN shell. I assume that there is an official way to uninstall perl that I just haven't been finding? (I have vague memories of doing so several years ago, but I sure couldn't find it this time.) None that I know of. Which is annoying, because the install puts stuff all over the place - $prefix/lib, bin/, and man/, at least. I generally use a unique prefix for each Perl install, just so I can cleanly delete the whole thing when I'm done with it. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: perl code on mac slow
On Feb 27, 2007, at 11:24 AM, [EMAIL PROTECTED] wrote: I have a server where the computer that I log into is a Mac Xserver 2.2 GHz Dual Processor machine with 2G ram. I wrote some perl code to figure out what is going on with Gridware. Essentially it compares what gridware thinks that it is doing with the files that are in the specific directory. I am kind of new to perl, so I may not have written the best code, but it works ok for me. Anyway, I developed the code on this mac machine. When I run the code to check on 625 files in one directory it took about a minute. I checked and the machine is 90% idle. Now when I run this identical code on my Xeon 1.8 GHz machine with 4 G ram where it checks 1125 files in one directory (unfortunately I don't have the exact same data on both systems) it takes just 10 seconds. This is on a slower machine with more users logged in! The mac box has perl ver 5.8.6. The xeons have perl 5.8.5. Is there something I can check on to see what is going on? Its almost like the mac doesn't use all of its resources when it runs the code. Mac OS X doesn't throttle processes that I know of, so if your CPU is at 90% idle, your script is probably waiting on either disk or network IO. You could try profiling your script with Devel::DProf to get a breakdown on where the time is being spent in your script. Another very simple benchmark is to run your script with time myscript.pl. That will report the real (i.e. wall clock) time spent, the user (i.e. your script) time, and the sys (i.e. OS) time. Time spent waiting on disk or network is reported as sys time here. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: mod_perl
On Feb 26, 2007, at 9:32 PM, Robert Hicks wrote: Do I need to rebuild everything to get mod_perl running on Tiger? You don't need to rebuild *anything*. Just enable it in /etc/httpd/ httpd.conf. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: @INC problem
On Feb 22, 2007, at 6:21 PM, Vic Norton wrote: Apple suggested I install something the other day. (Java or something like that.) I did it. Now I discover that many of my Perl scripts don't work. The problem is with @INC. It appears to have been upgraded to Perl 5.8.8. For example, when I try use Date::Parse qw(str2time); I get the message /Volumes/VTN Docs/ My Perl/Tests/test5.pl:6: Can't locate Date/ Parse.pm in @INC followed by a list of what @INC contains: /Volumes/VTN Docs/ My Perl/Tests /usr/local/lib/perl5/5.8.8/darwin-2level /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/darwin-2level /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/ That's not Apple's Perl, or anything that resulted from the recent Apple update. I've looked through the recent Apple update receipts, and didn't find anything Perl-related. You can use lsbom to check the contents of anything installed from .pkg or .mpkg packages, which includes Apple updates. The receipts are in /Library/Receipts, so to find the.boms for packages installed in the last 7 days: find /Library/Receipts -newerct '7 days ago' -name '*.bom' Then, to browse the list of files installed by a package using the less command: lsbom /Library/Receipts/JavaForMacOSX10.4Release5.pkg/Contents/ Archive.bom | less The package Date/Parse.pm is right where it has always been, along with a whole pile of other stuff, in /Library/Perl/5.8.6 So this is my question. How do I add /Library/Perl/5.8.6 to @INC, without having to add use lib /Library/Perl/5.8.6; to every script ? Possibly, someone replaced all your scripts #!/usr/bin/perl with #!/ usr/local/bin/perl. Maybe you did that to test them against the newer Perl and forgot to change it back, or maybe someone in your house has a strange sense of humor. :-) If your scripts still say #!/usr/bin/perl, then something has removed the original /usr/bin/perl and replaced it with a link to /usr/local/ bin/perl. You can check that with /usr/bin/perl -v. Fortunately, the original is also a link, to /usr/bin/perl5.8.6, so if it was disturbed, it's easy to make things right: sudo rm /usr/bin/perl sudo ln /usr/bin/perl5.8.6 /usr/bin/perl sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Running a PERL script from a PERL CGI
On Feb 7, 2007, at 10:19 PM, Ken Williams wrote:
On Feb 7, 2007, at 4:33 PM, Philippe de Rochambeau wrote:
if (param()) {
my $ret = ` perl
script_that_retrieves_a_file_by_ftp_and_sends_it_by_email.pl `;
Try losing the double quotes. Methinks that long-named script
isn't even running.
Yes, definitely. I didn't mention that because I had assumed that
they were there for illustrative purposes, but if they're not - ditch
'em.
sherm--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Problems using CPAN : part 1 - installing DBD::mysql
On Jan 30, 2007, at 8:26 AM, Jan Erik Moström wrote: Anyway, I want to use MySQL from Perl so I installed DBI, no problems. Then I tried to install DBD::mysql but it fails. Yep. The CPAN shell, as nice as it is in most respects, fails whenever a module needs arguments passed to Makefile.PL to install properly. Since it normally just runs perl Makefile.PL with no arguments, it needs a bit of hand-holding to correctly install modules that need arguments. In the CPAN shell, run look DBD::mysql. This will download and unpack the latest source for the module, and open up a new subshell in the build directory. Then you can configure the install manually: perl Makefile.PL args Where args are the options that tell the build script where to find the MySQL header (.h) files, what database, user name, and password to use for the self-tests, and so forth. Run perl Makefile.PL -- help for a brief list of options, or open INSTALL.html for more detailed help. Then you can run the install: make make test sudo make install Keep an eye on the output from each step. If one of these steps fails, don't continue with the next. Once you're done, you can exit back out to the CPAN shell. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones on MySpace
On Jan 17, 2007, at 10:59 AM, David H. Adler wrote: On Wed, Jan 17, 2007 at 02:07:30AM -0500, Sherm Pendley wrote: Well, I've finally given into peer pressure and created a MySpazz account and CamelBones group: http://www.myspace.com/camelbones http://groups.myspace.com/CamelBones I'm getting a bit discouraged because CamelBones isn't gaining much traction Unless I'm mistaken, the docs haven't been expanded in quite some time. Not true! I added this announcement to the home page just last night. :-) OK, kidding aside, you're 100% correct. The docs are part of the big chicken and egg puzzle. To get more buzz going, I need to put more work into the project, whether it's writing more docs, adding new features, or whatever. But, I don't feel very motivated to do that, since there's so little buzz going right now. I think a big part of the problem is that I myself don't have much need for it right now. The OSS mantra (well, one of them) is scratch your own itch, and as far as CB goes my own itch was scratched quite well by ShuX - I missed the Shuck app that came with MacPerl, and set out to find or write a replacement. Shuck itself was written using the Classic Toolbox; Carbonating it was out of the question, because at the time Apple was calling Carbon a transition technology and I had no desire to learn a toolkit that had already been end-of-lifed. (As it turned out, of course, Carbon has proven much more resilient than that.) So I have what I wanted, and my own day-to-day use of Perl is basically just web-related stuff. I've toyed with other ideas, but everything I've thought of have seems a bit contrived, like a solution in search of a problem. I think a big part of the reason is that I'm trying to imagine what problems CB might solve for other people, instead of knowing first-hand what problem it might solve for me. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: CamelBones on MySpace
On Jan 17, 2007, at 2:02 PM, kurtz le pirate wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sherm Pendley) wrote: Well, I've finally given into peer pressure and created a MySpazz account and CamelBones group: http://www.myspace.com/camelbones is the music essential ? Yes. :-) The profile is my personal one that I've had for a few months now - the people in my friends list there are actual friends and family, not a Perl hacker in the bunch. I'll occasionally write in my blog about my development efforts, but without a lot of geeky detail, since most of the audience for that isn't geeks. I'll limit the hardcore techie stuff to the group - that's why I created it, so my non-geeky friends won't have to read what to them is just techno-babble. The MySpazz stuff isn't a replacement for the SourceForge resources such as the mailing lists and bug trackers. It exists for the same reason that Perl Monger groups often have social gatherings. Or, at least the Boston PM group did. Maybe in other cities it's different, I don't know. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
CamelBones on MySpace
Well, I've finally given into peer pressure and created a MySpazz account and CamelBones group: http://www.myspace.com/camelbones http://groups.myspace.com/CamelBones I'm getting a bit discouraged because CamelBones isn't gaining much traction, and that leads to lack of motivation, which leads to not a whole lot (well... nothing) getting done, which leads to not many new users, which leads to... you get the idea. I'm looking for ways to gain some new users, some new ideas, and generally psyche myself up for the push to Leopardville. Maybe some networking through MySpazz will help. And who knows - it may even turn out that tons of people are using it, only I just don't know about 'em. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Conflict with Time::Local and Time::localtime
On Dec 31, 2006, at 4:19 AM, Michael Barto wrote: I have a Perl program that gets the date of a file using 'ctime' from use Time::localtime; But this program must also convert an Epoch time to a date and time using 'localtime' from use Time::Local;. The problem is it appears that only one of these modules can be used in a single program. Not both since a localtime subroutine exist as the same name in both modules. How can I support using both modules in the same program?. Here are the snippits: #!/usr/bin/perl use Time:localtime; use Time:Local; You're importing everything by default. Instead, only import the specific functions you need from each module: #!/usr/bin/perl use Time::localtime qw(ctime); use Time::Local qw(localtime); Have a look at perldoc Exporter for more, especially the section titled How to Import. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Bundle::XML and expat problems
On Nov 26, 2006, at 4:24 AM, Joel Rees wrote:
or what variable I must have walked on to make perl forget that
it was installed under /usr/local ?
Did you add -L/usr/local/lib to the default linker flags when you
built your Perl?
I was assuming that, since it would default to linking the
executables under /usr/local/bin that putting /usr/local/lib in the
search path would just be common sense. But I see from
beast:/usr/local/share family$ perl -e 'for (@INC) { print $_ .
\n }'
...
that /usr/lib isn't in the stock perl's library path either.
Nor should it be. We're talking about GCC's library search path, not
Perl's.
Okay, so what's the usual thing to do with stuff like expat? Build
expat to install under site_perl/5.8.8/ (or site_perl/5.8.8/expat?)
Why would you want to do that??? It's not a Perl module, it's a C
library. The default install for expat is fine.
or maybe link the already installed libraries in there? Or build
everything that depends on it by hand?
If you export LDFLAGS and CFLAGS variables with the -L -I options
into your shell environment, most things (including Perl) will pick
up on them. Here's an example from my shell startup script
~/.profile. I want to use both locally-installed libraries in /usr/
local, and DarwinPorts-installed libraries in /opt/local, so I add
both to my search paths:
export LDFLAGS=-L/usr/local/lib -L/opt/local/lib
export CFLAGS=-I/usr/local/include -I/opt/local/include
sherm--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Bundle::XML and expat problems
On Nov 25, 2006, at 2:28 AM, Joel Rees wrote: Expat must be installed prior to building XML::Parser and I can't find it in the standard library directories. You can download expat from: Can anyone tell me why cpan can't find the expat libraries in /usr/ local/lib? /usr/local/lib is not in the default search path for Mac OS X. or what variable I must have walked on to make perl forget that it was installed under /usr/local ? Did you add -L/usr/local/lib to the default linker flags when you built your Perl? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Bundle::XML and expat problems
On Nov 23, 2006, at 8:26 AM, Joel Rees wrote: opossum:~/.cpan/build/XML-Parser-2.34 jmr$ make test PERL_DL_NONLAZY=1 /usr/local/bin/perl -MExtUtils::Command::MM - e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/astress.FAILED tests 19-20, 24 Failed 3/27 tests, 88.89% okay t/cdata...ok t/declok t/defaulted...ok t/encodingmy variable $p masks earlier declaration in same scope at t/encoding.t line 94. t/encodingok t/external_entok t/fileok t/finish..ok t/namespaces..ok t/paramentok t/partial.ok t/skipok t/stream..ok t/styles..ok Failed Test Stat Wstat Total Fail List of Failed -- - t/astress.t 273 19-20 24 Failed 1/14 test scripts. 3/130 subtests failed. Files=14, Tests=130, 3 wallclock secs ( 1.36 cusr + 0.41 csys = 1.77 CPU) Failed 1/14 test programs. 3/130 subtests failed. make: *** [test_dynamic] Error 255 With that high a success rate, I'd just go ahead with the make install step. Obviously the bug - assuming that there is one, and it's not a problem with the tests themselves - is fairly obscure. Otherwise it would be biting every test. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Uh-oh, the C compiler 'cc' doesn't seem to be working.
On Oct 28, 2006, at 7:00 AM, Joel Rees wrote: PPC Mac Mini, Mac OS X 10.4.8, I'm following along in README.macosx and I've done this: export SDK=/Developer/SDKs/MacOSX10.4u.sdk Well, first things first. You asked if you *really* need to use the SDK. You need to use an SDK if you're cross-compiling, such as: a. Making a Universal Binary build of Perl, either to distribute or to use for building and distributing UB modules. b. Building Perl to run on a OS version other than the one you're building with. There is a possibility I erased part of the SDK SDKs are separate sub-packages in the Xcode package, so you can re- install them pretty easily, without installing the whole thing. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Perl, MySQl and Airport
On Oct 2, 2006, at 12:46 PM, Joseph Alotta wrote: I am getting this error, having tried all the combinations. Is there a control panel somewhere that I need to set permissions? I already tried things in Sharing. Hosea:/Library/MySQL/bin jja$ /Library/MySQL/bin/mysql -u root -D names -h Yeshua.local ERROR 1130: Host '10.0.1.4' is not allowed to connect to this MySQL server Hosea:/Library/MySQL/bin jja$ I've intentionally kept this brief, because it's off-topic for this list, having nothing at all to do with Perl on Mac OS X. You need to log in to MySQL as root (obviously, from a host where you're allowed to do that), and use the 'grant' SQL command to allow root to log in from '10.0.1.4'. Details can be found in any book about MySQL administration. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: DBD::mysql mysql_server_prepare=1 anyone?
On Oct 7, 2006, at 2:26 PM, Gustavo Delfino wrote: I now want to try with the -with-thread-safe-client option, but I don't know how to add it. It's not a Makefile.PL option. It's a configure option when you're building MySQL itself. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: perltidy and -w flag
Guys, how is any of this even a tiny bit relevant to the question Jay asked? Jay didn't ask what your favorite editor is, he asked how to configure perltidy to not add -w to his scripts, and leave his use warnings; line alone. I don't know what the answer *is* - I dug through all of the perltidy docs, faqs, and recipe books I could lay hands on, and didn't find any relevant options. But I can say with 99% certainty that switching editors is *not* the answer. Perltidy opens a Perl file, reads and formats it, and prints out the results. It couldn't care less what editor you used to create the original. sherm-- On Oct 5, 2006, at 3:34 PM, Joseph Alotta wrote: Some people like TextMate also. I think it costs $29. www.macromates.com/ Joe. On Oct 5, 2006, at 1:21 PM, Ted Zeng wrote: BBedit has a free version called textwrangler. You can download from their site. It is a very good editor. Ted zeng From: Michael Barto [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 10:56 AM To: Jay Savage; macosx@perl.org Subject: Re: perltidy and -w flag I know a lot of people that use Emacs on other Platforms because they have nothing else. But this is on a Mac and you have a lot of good well designed choices: BBedit is the most popular. Try the demo for a month and you will be sold. A student license is $50.00 (http://www.barebones.com/). I use Perl to generate Web pages with Javascript. Besides debugging the Perl code as I write, BBedit has an instantaneous Web page preview of my code which is awesome. You change an entry, it instantaneous updates. There is another soruce editing program called AlphaX (Freeware). It has been around for a long time and is wonderful to do Perl Editing (http://www.maths.mq.edu.au/~steffen/Alpha/AlphaX/). It contains extensive Perl code help documentation. There is a great Perl Editor/Debugger called Affrus (http:// www.latenightsw.com/affrus/) which integrates with BBEdit or is standalone. I use it find the really complex issues, since when it steps throught the code it shows me what is going on in memory in a really nice graphical way, etc. Unfortunately it is expensive (around $100.00) In all these editors, they have run at command line drop down, which is where I put my #!/bin/perl -w which is in my program. I have enclode the BBedit one as an example. Since Alpha is basically free right now, Jay Savage wrote: I've recently started using TextMaker to edit my Perl scripts after many years of Emacs. On the whole I'm happy, but one thing really bugs me: styling. I've never really used perltidy before--Emacs perl-mode and cperl-mode have done everything I wanted. TextMate, though, uses perltidy internally. I've got my flags pretty well set in ~/.perltidy, but I can't for the life of me figure how to get it to stop putting the '-w' flag on the shebang line. It also seems to occasionally eat my 'use warnings;' when it does it. Any thoughts? Thanks, -- jay-- This email and attachment(s): [ ] blogable; [ x ] ask first; [ ] private and confidential daggerquill [at] gmail [dot] com http://www.tuaw.com http://www.downloadsquad.com http:// www.engatiki.org values of â will give rise to dom! -- Michael Barto Software Architect image001.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. Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: How to know if a module is installed
On Sep 27, 2006, at 11:00 AM, Nobumi Iyanaga wrote:
This is a newbie question: how can I determine if a specific module
is installed on a client machine?
I would like to do something like this:
if (MacPerl installed is true) {
do this...;
}
else {
do nothing...;
}
Thank you in advance for any help.
Wrap a require() in an eval block, and then check to see if the eval
() succeeded. Untested, typed in Mail, etc.:
my $has_modulename;
BEGIN {
eval {
require Module::Name;
# If you'd ordinarily use Module::Name qw(foo bar baz);, pass
# the qw(foo bar baz) to import here.
import Module::Name qw(foo bar baz);
};
# If the eval failed, we don't have the module
if ($@) {
$ has_modulename = 0;
} else {
$ has_modulename = 1;
}
}
That's if you want to check within a script - if you want to quickly
check from a command-line, there's an easier way:
perl -MModule::Name -e 'print $Module::Name::VERSION, \n'
sherm--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Upgrading Perl 5.8.8
On Sep 26, 2006, at 9:20 AM, Ray Zimmerman wrote: On Sep 26, 2006, at 8:34 AM, John Delacour wrote: Apple's installation is in /usr/bin. There is no need either to replace it or to use any fink, darwinport etc. Just install it in /usr/local/bin, which is the default anyway. Read the install file. This is what I've been doing for years. Then I replace /usr/bin/ perl with a symlink to /usr/local/bin/perl. ... So my question is ... what is the best way to make sure my new install (in /usr/local/) has everything the OS expects? Leave /usr/bin/perl alone, and write your own scripts with #!/usr/ local/bin/perl. Can I just install a few extra CPAN modules and make the OS happy Why do that, when it's trivially simple to avoid making it unhappy to begin with? What do the rest of you do? I use 5.8.6. My scripts run fine with it, and why fix what ain't broke? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Upgrading Perl 5.8.8
On Sep 26, 2006, at 12:17 PM, Ray Zimmerman wrote: The reason I've done it this way is because I have a set of perl scripts and web apps that require a Perl environment that is identical across several machines, including my PowerBook and a few Linux servers. I *HIGHLY* doubt that the difference in minor point versions is going to break those scripts. It's possible, but very unlikely. Have you verified that it definitely will break them, or are you just guessing that it might? What I would do in this situation is check to see if 5.8.6 is close enough to develop with. If a script worked on one machine but not the other, I'd dig through the 5.8.7 and 5.8.8 change logs to find anything relevant to the problem. Then and only then, if a version mismatch (rather than a mismatch between env. variables, file locations, locale, etc...) were indeed the problem, I would consider going to the trouble of installing a newer Perl. I've built Perl from source hundreds of times and I know the process very well - but it's still time-consuming tedium that I'd rather avoid unless it's truly necessary. Sounds like the best approach is just to make my scripts/apps use / usr/local/bin/perl on all of my machines. Just for the sake of curiousity, I'd be interested in knowing what Tiger's perl install includes beyond what is part of the core perl-5.8.6. Anybody have a list somewhere? Look around in /System/Library/Perl/Extras/ sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Perl, MySQl and Airport
On Sep 26, 2006, at 12:45 PM, Joseph Alotta wrote: I have a application in Perl that prints reports from a MySQL database. I also have DSL that is accessed via Airport in my house. Recently I bought an iMac for my wife and I want her to help me print reports from this new computer. How do I get her computer to get data from the MySQL database that lives on my computer via Airport? MySQL client libraries use TCP/IP - they neither know nor care about the physical network layer. So you'd do this the same way you'd connect to any other remote server - just supply the host name (or IP address) as part of the dsn. my $dsn = DBI:mysql:database=foo;host=192.168.1.101; my $dbh = DBI-connect($dsn, $user, $password); If that's not working, some things to check: • Are the MySQL client libs and DBD::mysql installed on the client? • Is $user authorized to connect from another host? • Is MySQL itself configured to allow such connections in general? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Upgrading Perl 5.8.8
On Sep 26, 2006, at 4:38 PM, Vic Norton wrote: On 9/26/06, at 11:56 AM -0400, Sherm Pendley wrote: I use 5.8.6. My scripts run fine with it, and why fix what ain't broke? I just installed 5.8.8 in /usr/local. It went very smoothly and Perl 5.8.8 seems to work fine. Except that it can't see the packages in /System/Library/Perl/5.8.6 that I use all the time. It doesn't need to. It has its own copy of core modules. Stuff like Date::Format Date::Parse LWP ... Those aren't core modules. CPAN modules are installed under /Library/ Perl, which is the moral equivalent of the more traditional site_perl directory. I tried the 5.8.8 script #!/usr/local/bin/perl -w use strict; use lib /System/Library/Perl/5.8.6; use lib '/Library/Perl/5.8.6'; sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Upgrading Perl 5.8.8
On Sep 26, 2006, at 1:50 PM, Ray Zimmerman wrote: My practice of building my own perl, which began back in the days of Jaguar, grew out of the need to have my web dev environment (apache, mod_perl, php, mod_ssl, lots of CPAN modules, etc, etc) be consistent across my dev machine (OS X) and several servers (Linux). And IIRC this did come after a number of version inconsistency related problems. At the time, building my own custom versions of everything on each box seemed the best way to go. That makes perfect sense to me, but it's a very different situation. Jaguar shipped with 5.6, and most Linux distros were shipping with 5.8 by then. That's a major release, and a *much* bigger jump than from 5.8.6 to 5.8.8 - that's just a minor point release to fix some bugs and update some of the core modules. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: DBD::mysql OS X
On Aug 3, 2006, at 10:41 AM, Jay Savage wrote: On 8/3/06, Walter Copenhaver [EMAIL PROTECTED] wrote: Hello, Has someone manage to install DBD::mysql in Mac X Tiger. Can anyone point me to a tutorial or how to do this. Thanks Walter, Can you tell us specifically what problems you're having and what errors you're seeing? Installations usually go pretty smoothly. Just: perl -MCPAN -e 'install DBD::mysql' The only caveat I can think of is that the tests assume you're installing DBD::mysql against a fresh MySQL installation with the root password still unset. They assume no such thing. They don't even assume that the server against which you're going to run the tests is on the same machine. Detailed instructions are provided with the module that detail how to provide the user name, password, host name, and other information with which to run the tests. If you've already configured MySQL and set the root password, the tests will all fail. No, the tests will fail if you haven't provided the necessary information for them to connect. The root password *IS NOT* necessary. You don't have to run the tests as root either - current CPAN.pm versions allow you to run the first few steps of module building and testing as an ordinary user, and run the final step as sudo make install. The only requirement for the tests is that the test database (which need not be named 'test') exists, and that the test user is fully authorized to perform any operation on that database. It will need to create and drop tables, perform queries, insert and delete rows, etc. Since it's a pretty stable module, it's usually safe to just go ahead and force install Agreed - provided that the tests failed with failed to log in errors and not some other error. , but you may want to unset to root password during the installation to run the tests. Worst. Advice. Ever. You absolutely DO NOT want to open up a huge gaping security hole in your database. You'll also have to force install if the the server you're planning to use is on a different machine. Nonsense. If the server you want to run the tests against is on another machine, simply provide a hostname (and port number if needed) in addition to the username, password, and other connection information. In the CPAN shell, run the look DBD::mysql command. This will download the latest tarball and unpack it, then open up a subshell so that you can run the other commands manually. In the subshell, run open INSTALL.html to open the installation docs in your default web browser. Under the Source Installation section, there's a Configuration section, where a number of options are listed that you can pass to Makefile.PL. Determine what options you want to use, then run the commands. For example, if I wanted to connect to the 'testme' database on 'mydbserver.invalid', and log in as 'nobody_special' with password 'lemmein', I'd run this sequence of commands: perl Makefile.PL --testdb=testme --testhost=mydbserver.invalid -- testuser=nobody_special --testpassword=lemmein make make test sudo make install Depending on how you've configured your CPAN shell - i.e. whether you're already running as root or not - you may not need to use sudo with the last step. When you're done, use 'exit' or ctrl-d to leave the subshell and get back up to the CPAN shell. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: DBD::mysql OS X
On Aug 3, 2006, at 2:02 PM, Jay Savage wrote: On 8/3/06, Sherm Pendley [EMAIL PROTECTED] wrote: On Aug 3, 2006, at 10:41 AM, Jay Savage wrote: The only caveat I can think of is that the tests assume you're installing DBD::mysql against a fresh MySQL installation with the root password still unset. They assume no such thing. They don't even assume that the server against which you're going to run the tests is on the same machine. I believe you, but this clearly contradicts docs, and the information provided by MySQL themselves It's worth keeping in mind that MySQL AB is neither the author nor the maintainer of DBD::mysql. It's certainly nice that they've provided a brief summary of the most common scenario, but it's a mistake to view that summary as being authoritative. Assuming that you run cpan via sudo, that means the tests attempt to connect to the database as root, with no password. That's pretty clear from the docs and, in fact, matches observed behavior. Yes, it does. The MySQL AB summary is correct as far as it goes, but it *is* just a summary, and as such it's incomplete by nature. It describes the default situation, but it doesn't go into detail as to what options are available for overriding the defaults. Nor should it - that's what the module documentation itself is for. The final word, as always, is the documentation provided by the module author. That trumps any and all advice given by third parties - including my own. :-) Ok, I'll turn off the sarcasm, they're not really that obscure. But few things in life bug me more than CPAN modules that can be installed via normal CPAN methods. It's certainly a problem, I agree. Although, I view it as more of a social problem than a technical one. Clearly it wouldn't be very difficult in principle for a module to provide a list of its install options, along with a brief description of each and its default value. The problem is that there is no standardized means for a module to provide such a list, and therefore no means for something like CPAN.pm to determine what options are available and how they should be set. Module authors over the years have used various different approaches of specifying different options. Some modules (DBD::Pg) use environment variables, others use options passed to Makefile.PL (DBD::mysql), while others use an interactive QA session (CPAN.pm). Getting all of the various module authors to agree on a common standardized approach would be like herding cats. In the absence of such standardization, the best thing CPAN.pm can do is offer the look command, for downloading and unwrapping the latest version of a module which needs some manual hand-holding for the actual installation process. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Problems installing Net::SSH::Perl'
On Aug 3, 2006, at 4:45 PM, Michael Barto wrote: This modules fails to install from CPAN perl -MCPAN -e 'install Net::SSH::Perl' with error installation in installation of Math::GMP. Hence Net::SSH::Perl module cannot be installed. This problem needs to be corrected. Does anyone know how to get by this problem and how can it be reported to be fixed? This problem is also true for Sun Solaris (which I tried the same thing on). We develop on Mac's First, you need to install libgmp - Math::GMP is just a wrapper around that. Ideally, Math::GMP's Makefile.PL would detect that libgmp isn't present, and complain with an informative message instead of just failing to compile, but it doesn't. :-( That would absolutely be a problem worth being reported to the Math::GMP maintainer. Installing libgmp *might* be a bit of an adventure if you're using an Intel Mac. Google libgmp intel mac for details - the messages I found relate to gmp 4.2.0 and are dated April '06; the latest release is 4.2.1, which was released in May '06, so I don't know if those problems are still relevant or not. I'd try it out of the box first, and then read about the problems if that fails. I'm on an old G4, so I used the standard configure; make; make check; sudo make install routine which built installed libgmp without any problems. Once you've installed libgmp, you're ready to install Math::GMP. To do that, I needed to add to the linker flags that CPAN.pm would use. (You may not need to do this on your Solaris machines.) From inside the CPAN shell: cpan o conf makepl_arg LDDLFLAGS='-bundle -undefined dynamic_lookup -read_only_relocs suppress' The '-read_only_relocs suppress' is the important one here - the rest are there because I couldn't figure out how to *add* to the linker flags that Perl uses, instead of *replacing* the whole set of them. :-( Once I'd done that, I got a clean compile and all the self-tests passed: cpan test Math::GMP Running test for module Math::GMP Running make for C/CH/CHIPT/Math-GMP-2.04.tar.gz Is already unwrapped into directory /Users/sherm/.cpan/build/ Math-GMP-2.04 CPAN.pm: Going to build C/CH/CHIPT/Math-GMP-2.04.tar.gz Checking if your kit is complete... Looks good Writing Makefile for Math::GMP cp lib/Math/GMP.pm blib/lib/Math/GMP.pm AutoSplitting blib/lib/Math/GMP.pm (blib/lib/auto/Math/GMP) /usr/bin/perl /System/Library/Perl/5.8.6/ExtUtils/xsubpp - typemap /System/Library/Perl/5.8.6/ExtUtils/typemap -typemap typemap GMP.xs GMP.xsc mv GMP.xsc GMP.c cc -c -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno- strict-aliasing -I/usr/local/include -Os -DVERSION=\2.04\ - DXS_VERSION=\2.04\ -I/System/Library/Perl/5.8.6/darwin-thread- multi-2level/CORE GMP.c Running Mkbootstrap for Math::GMP () chmod 644 GMP.bs rm -f blib/arch/auto/Math/GMP/GMP.bundle LD_RUN_PATH= env MACOSX_DEPLOYMENT_TARGET=10.3 cc -bundle - undefined dynamic_lookup -read_only_relocs suppress GMP.o -o blib/ arch/auto/Math/GMP/GMP.bundle -lgmp chmod 755 blib/arch/auto/Math/GMP/GMP.bundle cp GMP.bs blib/arch/auto/Math/GMP/GMP.bs chmod 644 blib/arch/auto/Math/GMP/GMP.bs /usr/bin/make -- OK Running make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/gmppmok All tests successful. Files=1, Tests=350, 2 wallclock secs ( 0.49 cusr + 0.06 csys = 0.55 CPU) /usr/bin/make test -- OK sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Creating a Perl Module Problem
On Aug 3, 2006, at 5:54 PM, Elton Hughes wrote: print New Client Days: $client-get_days\n; -- But my output is this: [/Users/ehughes/Projects/Perl] # perl t_client.pl New Client Days: NOVA::Client=HASH(0x1801380)-get_days I must be a lot brain tired because I am forgetting something. Can anyone tell me where I went wrong? Perl is interpolating the value of $client into your string instead of the value returned by $client-get_days. Try this instead: print New Client Days: , $client-get_days, \n; sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: install problems: XML::LibXML::XPathContext
On Aug 1, 2006, at 10:55 PM, Michael Glaesemann wrote: On Aug 1, 2006, at 23:04 , Sherm Pendley wrote: Nothing so far has indicated a bug in the module. Quite the contrary - the crash dump suggests otherwise: Binary Images Description: 0x605000 - 0x6dafff libiconv.2.dylib/opt/local/lib/ libiconv.2.dylib 0x1008000 - 0x10f0fff libxml2.2.dylib /opt/local/lib/ libxml2.2.dylib ... 0x92a4a000 - 0x92b28fff libxml2.2.dylib /usr/lib/ libxml2.2.dylib 0x92b45000 - 0x92c32fff libiconv.2.dylib/usr/lib/libiconv. 2.dylib Figure out why this module is linked against both copies of libxml libiconv, and I'd bet you'll have solved this problem. Thanks for pointing this out. I don't have a lot of experience reading crash dumps, and your explanation is helpful as an introduction. Try moving /opt aside before building testing the module. Before you do, use otool to see which of these XML::LibXML::XPathContext is linked against - it may also be that one (or more) of its prerequisites (XML::LibXML for instance) is also linked the one in /opt. I've been trying to figure out where the XML::LibXML::XPathContext object files are located, but can't find it. (Am I correct in thinking that's what I should be looking for?) I'm looking in / Library/Perl/5.8.6. So far so good. What you're looking for is /Library/Perl/5.8.6/darwin- thread-multi-2level/auto/XML/LibXML/XPathContext.bundle. And looking at the otool man page, it looks like I want to use otool -L when I finally find it, correct? Yep. You can pass multiple file names to otool, so you can actually get a quick list of everything all your modules are linked against like this: find /Library/Perl/5.8.6 -name '*.bundle' -print0 | xargs -0 otool -L sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: install problems: XML::LibXML::XPathContext
On Aug 1, 2006, at 11:31 PM, Michael Glaesemann wrote: Is there a way to specify which libs the modules should be linking against, something like changing ones path? One way is to specify an additional -L option in the environment variable LDFLAGS. That's for adding to the library search path though - I couldn't find any options in 'man ld' to *remove* a directory from the library search path. I hope I simply missed it - it would seem a rather odd omission otherwise. If you've added an 'export LDFLAGS=-L/opt/local/lib' line to ~/.profile (or if DarwinPorts added it for you) that would export that environment variable to any shell scripts you run. You can check for that with 'env' or 'echo $LDFLAGS' from a command prompt. Since the linker checks in the directories in the order in which they're listed, you can tell it to prefer /usr/lib by adding it again at the beginning of the list. It will appear twice, but that does no harm. export LDFLAGS=-L/usr/lib -L/opt/local/lib You can add that line to ~/.profile if you want it to take effect for every session, or run it manually if you only want it to take effect for a single login session. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: anyone know where i can get 10.3 Developers Tools?
On Jul 28, 2006, at 8:41 AM, Adam Witney wrote: does anyone know if i can still download the Developer Tools for 10.3 or is there another way of getting the tool set i need for compiling custom modules? Yes, you can still download Xcode 1.5 (the last for Panther), and even the December 2002 Dev Tools (the last for Jaguar) at: http://connect.apple.com You'll need to register for the free online ADC membership if you don't have one already. Since you're using Panther, don't forget to modify Config.pm as described here: http://www.mail-archive.com/macosx@perl.org/msg05736.html sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Mac / Perl / 3D
On Jul 25, 2006, at 9:59 PM, Peter N Lewis wrote: I'm interested in producing some drawings/diagrams/pictures based on 3D data/objects generated from Perl. Something that would allow me to write code that generates boxes, cylinders, spheres, etc with various colours and material styles and generate an image (or potentially an animation). Any suggestions? The best bet seems to be to use SDL_Perl, although a brief look seems to indicate I'll be installing packages for the next month. Thanks for any hints or warnings, POV-Ray uses text-based source files that are fairly easy to create with Perl: http://povray.org sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Has anyone built DBD::ODBC?
Anyone have a recipe for building DBD::ODBC? sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Has anyone built DBD::ODBC?
On Jul 14, 2006, at 1:30 PM, Sherm Pendley wrote: Anyone have a recipe for building DBD::ODBC? I'm making some progress. Exporting ODBCHOME=/usr was enough to get it to build. But the tests still fail, and I haven't figured out why. Ah well, one step at a time. And, I'm all out of goats squirrels, so no luck on that angle. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Has anyone built DBD::ODBC?
On Jul 14, 2006, at 7:34 PM, brian d foy wrote: In article [EMAIL PROTECTED], Sherm Pendley [EMAIL PROTECTED] wrote: Anyone have a recipe for building DBD::ODBC? I built it yesterday on Solaris 10 without incident. What's the problem you're running into? I've got it building with -o /usr. There are a lot of signed vs. unsigned pointer mismatch type warnings - but those are new warnings in GCC 4.x, and I've seen them in a ton of stuff. I don't know if they're relevant. This may be a clue: Umm, this looks like a unixodbc type of driver manager. It's not - I'm configuring against the built-in iodbc in /usr, not unixodbc. And the tests fail with a dynamic linker symbol not resolved in dynamic_lookup error, which could easily be the result of using the wrong API. What I'm aiming for is a binary build I can include with the next CamelBones patch release. Frankly, I don't know a whole lot about ODBC on *nix - which is a big part of the problem, I'm sure. I need to hit the books. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Has anyone built DBD::ODBC?
On Jul 14, 2006, at 8:26 PM, Sherm Pendley wrote: I've got it building with -o /usr. There are a lot of signed vs. unsigned pointer mismatch type warnings - but those are new warnings in GCC 4.x, and I've seen them in a ton of stuff. I don't know if they're relevant. This may be a clue: Umm, this looks like a unixodbc type of driver manager. It's not - I'm configuring against the built-in iodbc in /usr, not unixodbc. And the tests fail with a dynamic linker symbol not resolved in dynamic_lookup error, which could easily be the result of using the wrong API. Aha! Yes - that was a clue. There's a /usr/lib/libodbc.a that's a symbolic link to /usr/lib/ libiodbc.a. As it happens, DBD::ODBC uses the presence of /usr/lib/ libodbc.a as a sign of unixodbc, and moving the symlink out of harm's way allowed Makefile.PL to correctly detect iodbc instead. The 01base.t test is working now without the unresolved symbol errors. Now I'll have to set up an actual DSN and run a real test against it. sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
ANN: CamelBones 1.0
CamelBones is a bridge framework for integrating Cocoa and Perl. It allows Cocoa applications can be written entirely in Perl, or in a combination of Objective-C and Perl. The 1.0 release is the result of over three years of development, and is now considered stable enough for production use. Future point releases will leave the framework essentially unchanged, focusing instead on adding additional utility applications and developer tools to the overall package. More information can be found at http://camelbones.sourceforge.net sherm-- Web Hosting by West Virginians, for West Virginians: http://wv-www.net Cocoa programming in Perl: http://camelbones.sourceforge.net
Re: Writing utf 8 files
On Jun 22, 2006, at 2:29 PM, Tommy Nordgren wrote: 22 jun 2006 kl. 20.15 skrev Sherm Pendley: On Jun 22, 2006, at 1:48 PM, Tommy Nordgren wrote: How do I write proper utf 8 characters to a file? I write only two characters, and they come out as four garbage characters when I view the file in an editor. Quick answer: open FH, :utf8, file; Complete answer: perldoc perluniintro perldoc PerlIO I've already tried that. That was what i was doing when I got garbage. Well, the above is correct as far as Perl goes - but it doesn't rule out other problems. Are you certain that the editor you're using is interpreting the file correctly, as UTF8? Also, are you certain that your input really is UTF8? For instance, I ran this script to generate a test file: #!/usr/bin/perl use strict; use warnings; use utf8; # This allows utf8 in string literals, like below open FH, ':utf8', '/Users/sherm/hello.txt' or die $!; print FH Hëllö, wörld!\n; close FH; When I open the file in BBEdit, I see gibberish, because BBEdit can't determine that it's UTF8 (there's no BOM), and misinterprets it as the default Mac OS Roman instead. But, if I change BBEdit's default encoding, or use the Reopen Using Encoding function, BBEdit displays the file correctly. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: Writing utf 8 files
On Jun 22, 2006, at 3:28 PM, Tommy Nordgren wrote: 22 jun 2006 kl. 20.29 skrev Tommy Nordgren: 22 jun 2006 kl. 20.15 skrev Sherm Pendley: On Jun 22, 2006, at 1:48 PM, Tommy Nordgren wrote: How do I write proper utf 8 characters to a file? I write only two characters, and they come out as four garbage characters when I view the file in an editor. Quick answer: open FH, :utf8, file; Complete answer: perldoc perluniintro perldoc PerlIO I've already tried that. That was what i was doing when I got garbage. I found the problem it is necessary to 1) use the use utf8 pragma; That's only needed if your actual Perl code is UTF-8 encoded, like my example was. If your UTF-8 data is coming from an external source, use utf8 has no effect. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
Re: Odd 'head' problem
On Jun 15, 2006, at 7:22 AM, Dennis Putnam wrote: I'm not exactly sure this is what happened but I can't think of anything else. After installing several packages from CPAN, my daily log maintenance began failing. After some investigation I found that '/etc/periodic/daily/500.daily' was getting an error from the '/usr/bin/head' command. When I ran 'head' manually the command was not the normal one. It appears that one of the perl packages replaced the normal 'head' command that works on files, with one that works on URLs. That's precisely what happened. The LWP package installs a script called HEAD that does an HTTP HEAD request. On case-insensitive file systems like HFS+, head and HEAD are the same. Has anyone encountered this, or can anyone determine if my surmise about one of the perl packages is correct? Thanks. Yes, many people have had this problem. It's not come up for several years, though, because recent versions of the LWP install script asks if you want to overwrite head and install HEAD when it detects a case- insensitive file system, and the default answer to that question is no. Here's what the questions look like: The lwp-request program will use the name it is invoked with to determine what HTTP method to use. I can set up alias for the most common HTTP methods. These alias are also installed in /usr/bin. Do you want to install the GET alias? [n] Do you want to install the HEAD alias? [n] Do you want to install the POST alias? [n] The moral of the story - *read* the questions, don't just keep bouncing on the 'y' and 'return' keys. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org
