Re: MacPerl::DoAppleScript and Perl v5.10.0
Hi Alan,
I would try to have a perl or shell script invoked in your bundle that invoked
the perl for you with:
VERSIONER_PERL_PREFER_32_BIT=yes /usr/bin/perl ...
or somesuch. Or better if you can set that environment in your bundle and have
it propagated to your perl script. It should do the same as yours, but without
changing the user's preferences, which would probably be bad.
It would probably be possible to make a subset of Mac-Carbon run under 64 bits,
but much of it would not work, and it's a lot of work for what may be little
return.
Here's a post I wrote about this some time back:
http://pudge.net/glob/2009/09/maccarbon-modules-and-mac-os-x-106.html
Good luck!
On Mar 6, 2011, at 06:38, Alan Fry wrote:
I have made a small Applet containing a Perl script intended for use by folk
not necessarily conversant with Perl. The script is inside the applet bundle,
is called by AppleScript and works as intended.
Unfortunately the Perl script itself calls 'MacPerl::DoAppleScript' which
causes an error if the version of Perl is 5.10.0, which is the case of course
on 'Snow Leopard' machines. The problem can be resolved by setting
'Prefer-32-Bit' to 'Yes' in 'com.apple.versioner.perl.plist'. The question is
how to achieve this, bearing in mind some (possibly most) of the users will
be unused to Perl and terrified of using the Terminal.
I have resolved this difficulty for the moment by placing another Perl script
in the applet bundle which reads simply
if (qx(file /usr/bin/perl) =~ /executable x86_64/) {
qx(defaults write com.apple.versioner.perl Prefer-32-Bit -bool yes)
}
The notion behind this is that if the default version of the perl executable
is compiled for Intel 64 bit architecture it probably is 64 bit perl (?) and
Prefer-32-Bit should therefore be set to 'Yes'. This script is run before the
main Perl script is launched by which time 'com.apple.versioner.perl.plist'
will have been updated.
The first question is this. Is it acceptable to change the setting of
'com.apple.versioner.perl.plist' on someone else's machine? What if the owner
wants to use 64 bit Perl? It is not sensible to restore the setting of
Prefer-32-Bit to 'No' at the end of the run because the owner may have
already set it to 'Yes' anyway.
The second question is this. Is there a better way to resolve the problem of
how to contrive a portable Perl script incorporating a
'MacPerl::DoAppleScript call?
Suggestions would be most welcome.
Alan Fry
--
Chris Nandor
pu...@pobox.com
http://pudge.net/
Re: location of 'com.apple.versioner.perl'
On Fri, Jul 9, 2010 at 6:42 AM, Packy Anderson packyander...@gmail.com wrote: On Fri, Jul 9, 2010 at 6:39 AM, Alan Fry a...@afco.demon.co.uk wrote: However for the life of me I cannot find the file 'com.apple.versioner.perl.plist' on that machine. It is not in /Library/Preferences. What am I missing? Did you also look under ~/Library/Preferences? It's ~/Library/Preferences/com.apple.versioner.perl.plist Here's how you prove it, and any other questions like this: 1/ In one Terminal window, run `sudo filebyproc.d | grep -i plist` 2/ In another Terminal window, run the defaults command in question 3/ In the original window, hit ctrl-C to cancel, then examine the results. Here's what filebyproc.d reported for me: $ sudo filebyproc.d | grep -i plist dtrace: script '/usr/bin/filebyproc.d' matched 3 probes 1 18510 open:entry backupd-helper /private/var/db/.TimeMachine.Results.plist dtrace: error on enabled probe ID 1 (ID 19296: syscall::open_nocancel:entry): invalid address (0x7fff5fc2dc7f) in action #2 at DIF offset 24 1 19296 open_nocancel:entry defaults /Users/cdevers/Library/Preferences/com.apple.versioner.perl.plist.GWghJmY 1 18510 open:entry mdworker /Users/cdevers/Library/Preferences/com.apple.versioner.perl.plist $ Tweak the grep filter as needed and you can use this trick to isolate all kinds of weird what file is that damned thing looking at type questions. -- Chris Devers
Re: Dumb path question
The solution I went with, which seems to work for initial testing, is
roughly as follows:
use File::Basename;
use Cwd qw[realpath];
my $opts_tool = get_optstool();
system(/usr/bin/open '$opts_tool') and die Couldn't execute $opts_tool: $!;
sub get_optstool {
my $optstool = Optimize Mac.app;
my $cur_path = dirname(realpath $0);
my $rel_path = ../Resources;
my $opts_loc = $cur_path/$rel_path/$optstool;
return $opts_loc;
}
Written that way so that If I later want to call out to a different
tool, it's clearer to me what will need to be tweaked to do so.
Keep in mind that, by being wrapped in a Pashua GUI on the Mac, the
GUI user will be invoking this from wherever it happens to be on their
filesystem, which in turn means that the Finder or Launch Services or
what have you ends up being responsible for handing off the runtime
environment to the script.
This approach seems to work so far for the use cases I'm picturing --
the /Applications folder, a random folder with a space character in
the path, a USB drive, and a network drive.
(Part of me wonders if this whole thing would have worked better in
Camelbones as one app instead of two, but one of the constraints is
that some of the things it will do won't require admin access, but
other things will, so I have to be able to prompt for a password if
certain options are selected, then hand that off to the helper app[s]
accordingly. I didn't really see how to get a single app to force that
prompt if it's needed.)
--
Chris Devers
On 3/10/09, Doug McNutt dougl...@macnauchtan.com wrote:
At 20:25 + 3/10/09, John Delacour wrote:
At 21:10 -0600 9/3/09, Doug McNutt wrote:
At 22:24 -0400 3/9/09, Chris Devers wrote:
How can a Perl script reliably, portably resolve the path inside which
it is running?...
$0 That's a zero. Has always worked for me to produce a full path
to a running perl script.
...There is a module cwd...
or rather Cwd. $0 will give the name but not the full path, so I'd suggest
the following:
#usr/bin/perl
use Cwd;
my $currentdir = cwd();
print $currentdir/$0\n;
Interesting. It turns out that I rarely call a stored perl script
without specifying a full path in the call. I'm getting a full path
in $0 when I do that. There may be more to think about. The stuff I
just checked calls the script itself which has been made executable
rather than making a call to perl with the argument being the path to
the script. I also don't know about a stored script placed in a
directory that's included in $PATH but is not in $PWD.
portable seems to be the key here. Modules good for that.
--
- Stocks are getting pilloreid -
--
--
Chris Devers
Re: Dumb path question
On Mon, Mar 9, 2009 at 10:33 PM, Chas. Owens chas.ow...@gmail.com wrote: $0 holds the path to the currently executing file (including the filename). Often this is a relative path, so you will want to call Cwd's realpath on it to get the absolute path. Then call dirname on it to find the directory the script is in. All of this is in Core Perl, so it should be portable to any platform Perl works on. #!/usr/bin/perl use strict; use warnings; use File::Basename; use Cwd qw/realpath/; print dirname(realpath $0), \n; Ta, that did it. I was forgetting about Cwd, now it seems to work fine. Thanks! -- Chris Devers
Dumb path question
This isn't necessarily a Mac-specific question, but I've gotten rusty
and I'm having a brain fart here.
How can a Perl script reliably, portably resolve the path inside which
it is running? Not the PWD of the caller, mind you, but the actual
current full path of the script itself?
Context: I have a pair of utility apps meant to be run in tandem. The
first is a Pashua questionnaire that shows some forms and saves results
to a file. The second is a Platypus script that gets admin access (hence
needing another app -- I couldn't see how to get Pashua to prompt for
admin access), then uses the results from the first app to do some
`defaults write ...` `sudo networksetup ...` type system calls.
Because the apps are meant to be distributed run together, I've placed
the second one inside the Contents/Resources/ folder of the first one,
which finishes with (simplifying slightly):
my $helper = $ENV{'PWD'}/../Resources/Helper.app;
system(/usr/bin/open $helper') and die Couldn't run $helper: $!;
If I first put the first app in /Applications, this works fine.
The problem is I can't rely on $ENV{'PWD'} having something useful. If I
move the parent app from /Applications (to the Desktop, a USB drive, a
disk image, or a Samba volume), or if I invoke the Pashua script from a
shell, then the $helper variable typically ends up with something
useless (often but not always just /../Resources/Helper.app) and the
second app never executes.
I've thought of a few ways around this (e.g. wrap the whole thing in an
installer package so I can force depend on a single path), but they
all seem cumbersome to varying degrees. Ideally, it should behave like,
say, Firefox, where it will run the same way no matter where the user
wanted to put (or not bother to put) the app bundle.
Is there a common way to do this? What $ENV variables can be relied on
to have the full path to the running Perl script from which a working
relative path can be derived? Is there some other way that this is
already a Solved Problem, or should I just muddle through?
Any help very much appreciated :-)
Pashua:
http://www.bluem.net/en/mac/pashua/
http://macresearch.org/command_line_tutorial_part_iii_windows_of_opportunity
Platypus:
http://www.sveinbjorn.org/platypus
http://www.macresearch.org/command_line_tutorial_part_i_native_mac_apps_for_command_line_tools
http://www.macresearch.org/command_line_tutorial_part_ii_making_progress_and_finding_options
--
Chris Devers
Re: perl and apple mail?
On Mar 10, 2008, at 7:24 AM, Joel Rees [EMAIL PROTECTED] wrote: Are any of you using perl plugins with apple's mail browser? What, you mean aside from SpamAssassin procmail? I've always felt it was easiest to just filter everything on the mail server, and not bother with whatever filtering abilities the mail client I'm using this month may or may not offer. But then, I suppose this isn't a viable approach if you can't run software on the server. If you can get off the ground at all in filtering with AppleScript, its fairly easy to just write '...do shell script...' and switch to Bash / Perl / etc from there. That may be a good approach here. That or fetchmail piping into local SpamAssassin/procmail/etc filters, but oh look I'm getting silly again. -- Chris Devers
Re: Mac OS alias from Perl
On Dec 8, 2007, at 7:06 PM, Celeste Suliin Burris [EMAIL PROTECTED] wrote: Use a symbolic link instead. Perl handles those natively, and they can be accessed from the command line. The Finder just treats them the same as aliases. Not quite. I forget the details at the moment, but Finder aliases are kind of like firm links: while hardlinks point to inodes, and softlinks point to file pathnames, aliases point to the logical file in a more robust way than symlinks. For example, if the reverent file moves, symlinks break, but aliases shouldn't. If you really want aliases, I think the CPAN modules of Dan Kogai and Chris Nandor are the place to start. I forget who wrote what, but modules like (I think) MacOS::File and Mac::Glue can either make the right calls directly, or leverage Applescript / OSAscript to do this for you. Or if symlinks/softlinks are enough, just use the traditional Perl / Unix methods to make those. -- Chris Devers
Re: Detecting OS X version from perl
On Nov 17, 2007, at 7:37 PM, Michael Barto wrote: Just a quick question. Is there a command line at a terminal window of MacOSX that can do this- tell you more about the hardware? Quick report: $ system_profiler -detailLevel mini Obsessive detail report: $ system_profiler -detailLevel full Also list software packages and their revisions and also patches? You can get a lot of this from skimming through the /Library/Receipts folder, e.g.: $ grep -A1 'BundleShortVersion' /Library/Receipts/*.pkg/Contents/ version.plist | grep string This works better up through Tiger; the package format changed with Leopard and there may be a new, better way to access that now (maybe run `lsbom` on files under /Library/Receipts, but that doesn't seem to have version data). You can also just query the app directly, modifying the example above, as: $ grep -A1 'BundleShortVersion' /Applications/*.app/Contents/ version.plist | grep string Which now that I think about it probably the way to go, as it's largely the same data as the Receipts folder, but also includes things that don't have an installer (e.g. Firefox, Skype, Adium) and things with a third-party installer (Microsoft Office, the Adobe CS suite, StuffIt, etc). * * * * * On a different tack, since this thread has come back up, I forget if it was mentioned the first time around, but the system version and build should always be available from: $ cat /System/Library/CoreServices/SystemVersion.plist This is useful if you ever need to check, say, a remote file server, or a machine in Firewire target mode, where you can't query system_profiler, sw_vers, etc. If you do the same for the Finder -- $ cat /System/Library/CoreServices/Finder.app/Contents/ version.plist -- it may or may not be in step with the SystemVersion (it probably would be, but checking the system itself is more direct). -- Chris Devers
Re: Thanks Apple! You snubbed perl yet again!
On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote: On Oct 19, 2007, at 2:51 AM, Chris Devers wrote: On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote: I can draw a picture for you: http://finkproject.org/ In which case, your real argument appears to be the Fink people don't seem to be doing what I need fast enough. In which case, the response is you should contribute to Fink then. [...] I, as a developer, should maintain the latest version of perl on my machines. I give in! Yes, if that's really what you need. I still think it isn't the end of the world to just work with the bundled version of Perl (along, of course, with whatever CPAN modules you need). It's not like 5.8.6 or 5.8.8 are such awful, archaic versions to work with in the first place. So target the release version, or do like everyone else that's concerned about this and install your own Perl. It's not hard to do, and it's really not that different than how things are on Debian. Yes it is. debian's packages are updated constantly, not just in point releases. So if there is a problem a new package is made available relatively quickly. Maybe my Debian experience is too limited then, but this seems like a slightly glossed over version of things to me. The last time I spent a lot of time with debian (roughly 2003-2005), it was still on 3.0/Woody. Yes, there was a constant stream of package updates, but IIRC they were all security patches, critical bugfixes (with a *really* conservative definition of critical -- merely braindead usability brokenness never seemed to be worth patching), etc. It seems like most of the updates we were getting were via backports.org rather than official updates to Woody itself. Maybe things have evolved since then, but at the time it seemed like if an update wasn't for security or a real showstopping bug (e.g. keeps the machine from booting, or a critical daemon from running), then it was seen as a mere features update and got deferred until 3.1/Sarge. If you wanted those features updates, you had to get them from backports or roll your own. Maybe as a backlash, I seem to remember that this is around when Ubuntu et al branched off to be a more current platform. This seems like exactly the stance that we're talking about here, and as frustrating as it can seem, there are really good reasons to do things this way, not least being stability predictability for developers, who can assume confidently that release X is going to have Perl v.Y, etc. * * * * * As for supporting Fink (or something like Fink), I think that's a super idea, but it seems like an idea that has been floating around for years and never gotten off the ground, for whatever reason. Maybe I'm just assuming that if it hasn't happened by now, maybe it never will... -- Chris Devers DO NOT LEAVE IT IS NOT REAL
Re: Thanks Apple! You snubbed perl yet again!
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Scripting Bridge Use Objective-C, Ruby, and Python programs to automate Mac applications. The new Scripting Bridge enables them to easily generate AppleEvents using a concise, AppleScript-like syntax. Not a single word about perl. This has been explained, but let's talk about what we WILL have: Mac::Glue. I don't know much about Scripting Bridge -- I await seeing some examples for other languages -- but I am not sure Scripting Bridge in whatever form would even be preferable to Mac::Glue. I imagine it does some things better than Mac::Glue (and perhaps some things outside of Mac::Glue's scope?), but that just gives me ways to improve Mac::Glue. I imagine, for example, it might do dynamic autogeneration of glues, which is something I want to add to Mac::Glue. I am likely going to start a Mac::Glue feature expansion project soon, and will be looking for wishlist items. Stay tuned. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Thanks Apple! You snubbed perl yet again!
On Oct 18, 2007, at 4:43 PM, [EMAIL PROTECTED] wrote: On Oct 18, 2007, at 8:56 PM, Chris Nandor wrote: Not sure what you mean by losing things from upstream. Just that when I chose to compile software on my own, I lose all the debian security work. They look over packages and report vulnerabilities, I can just update with apt-get and get a new version - if I compile from source then I have to follow security warnings for the software I installed on my own. This is not a big deal if we are just talking about two or three applications, but if you are supporting a platform or a distribution, having the debian security do security for thousands of packages becomes a service that money cannot buy. Sorry, I'm confused -- why not just use Debian then? You're basically saying you want their custom build distribution service, but that is (naturally, one might think) only available on their Linux distribution. Apple already maintains the core OS software, including bundled open source packages like Perl, but if that isn't enough for you, and Debian is, then what exactly are you asking for?
Re: Thanks Apple! You snubbed perl yet again!
On Fri, 19 Oct 2007, [EMAIL PROTECTED] wrote:
On Oct 18, 2007, at 11:40 PM, Chris Devers wrote:
Sorry, I'm confused -- why not just use Debian then?
Yes.
Yes isn't a conventional answer to a why not question, but... sure.
You're basically saying you want their custom build distribution
service, but that is (naturally, one might think) only available on
their Linux distribution.
When you say 'their', who do you mean? If you mean debian, well yes.
Everyone who uses debian stable gets this custom build system, that is
the point of debian.
Yes, Debian was the last [proper] noun there, so the pronoun their
does indeed mean Debian. Well done.
Back to the point, this is what I'm confused about. If what you want is,
pretty narrowly described, Debian's distribution system, then why are
you looking elsewhere? Are you saying Apple should adopt it wholesale?
I can't picture Debian taking the effort to port what they're doing to a
new platform, and expectially not a proprietary one, so it would have to
be a case of Apple either backporting Debian's patches packages, or
duplicating the effort with the same intent but from scratch. I'm not
sure I can picture either of these things happening.
Apple already maintains the core OS software, including bundled open
source packages like Perl,
Apple maintains Apple's version of the so-called open source software,
but it does very little maintenance of community software or perl in
general.
You must not have been paying attention to this thread.
Within a stable release of the OS (10.3.x, 10.4.x, 10.5.x, etc), there's
only security updates -- which, iirc, is exactly what Debian does.
When transitioning between major releases (10.3 - 10.4, 10.4 - 10.5),
things are updatedto the currently available stable version -- which,
iirc, is also exactly what Debian does.
How is this so different?
As for community software, you've got me there. I can't think of any
examples at all of Apple offering things to the community. Aside from
Webkit. And launchd. Oh and Bonjour. Oh and CUPS, if you're in to that
whole printing thing on your Debian machines. Oh and well I guess
Darwin the mach kernel also count. Oh and I think some patches back to
the GCC suite, last I checked. But aside from those examples, you're
right, there's absolutely no community software available from Apple,
and certainly there doesn't seem to be any on CPAN.
I want 5.10 to work without hassle on OS X (Leopard).
Maybe we need to define hassle, but the concensus from everyone else
seems to be that installing your own copy is unlikely to be difficult,
once it comes out. Remember: a lot of the core Perl developers are Mac
users, so they'll already have been testing it there during development
rather than just porting to it post-release.
I want my code to be run cross platform (I am talking CGI here - still
there are big differences between LAMP and {M,A}AMP)
Care to elaborate? Most generic CGI scripts will run with only minor
modification on most versions of Perl, including Windows.
If you want the same code to run verbatim on a bunch of different
platforms, I think the general wisdom is that you're going to have to
target a common denominator, which will mean both [a] a version of the
software that is available on the shipping versions of everything you
target, and [b] a subset of the language functionality that has been
proven to work on all the target platforms you're thinking of.
If you go against either of those assumptions, then of course things are
not going to be as smooth as you're hoping for.
I want the time and effort I invested in learning perl to be useful
for developing native applications on Mac OS X. (I am willing to learn
how to use CamelBones to accomplish this. Right now I think it best I
learn Objective-C.)
Native contradicts cross-platform, but whatever. As Sherm said,
you'll be able to do this, but it's not going to be bundled (and
therefore you may have a harder time packaging anything written this way
for general release distribution on Leopard, unless you also bundle up a
copy of Camelbones et al).
Keep in mind that Ruby Python will also work for this, and blasphemy
they're both pretty good languages, too /blasphemy.
I am just asking for a reasonable, up-to-date, development environment
so that I do not have to shell into a linux server to do the job I
need to do.
So target the release version, or do like everyone else that's concerned
about this and install your own Perl. It's not hard to do, and it's
really not that different than how things are on Debian.
--
Chris Devers
Re: Detecting OS X version from perl
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (David Cantrell) wrote:
Is there any simple way that people can think of to detect which major
version of OS X my perl code is running on?
ie whether it's 10.0, 10.1 etc, I don't care about the difference
between 10.3.3 and 10.3.4.
This is nice in that it doesn't depend on external processes (sw_vers,
Finder) or files.
use Mac::Gestalt qw(%Gestalt gestaltSystemVersion);
(my $version = sprintf(%x, $Gestalt{gestaltSystemVersion()})) =~
s/^(\d+)(\d)(\d)$/$1.$2.$3/;
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Detecting OS X version from perl
On Oct 14, 2007, at 6:56 PM, David Cantrell [EMAIL PROTECTED] wrote: On Sun, Oct 14, 2007 at 10:45:30AM -0700, Edward Moy wrote: % perl -e 'chomp($vers = `sw_vers -productVersion`); print $vers\n' That will get you either 10.x or 10.x.y. You just need to strip off the .y if it is there. Perfect, thanks! If for whatever reason that lets you down (e.g. trying to get the version of a host you have mounted via AFP / NFS / Samba / etc), you should also be able to poke in /System/Library/CoreServices/SystemVersion.plist which is basically the same info as sw_vers reports, but wrapped in XML. -- Chris Devers
Re: Leopard Perl version...
On Sat, 13 Oct 2007, [EMAIL PROTECTED] wrote: Date: Sat, 13 Oct 2007 20:50:22 +0200 From: [EMAIL PROTECTED] To: Edward Moy [EMAIL PROTECTED] Cc: MacPerl Perl macosx@perl.org Subject: Re: Leopard Perl version... Hmm, are you sure you did not update your perl yourself? I have a Macmini from April 2007 (OS X 10.4.10) and it says: $ perl -v This is perl, v5.8.6 built for darwin-thread-multi-2level *ahem* Go back and read Mr Moy'ss email address. He may be in a position to answer this question definitively. :-) -- Chris Devers
Re: CamelBones: Will hack for food!
On May 9, 2007, at 4:32 PM, Daniel T. Staal wrote: Macs desperately _need_ a an app to manage third-party software updates. Something that you could run periodically to keep software up to date, avoiding having every seprate program connect to the internet on startup and check for itself. A good idea. But http://metaquark.de/appfresh/ may have beat you to it. :-) -- Chris Devers
Re: CamelBones: Will hack for food!
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. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Mac::Carbon issues
At 16:12 -0400 2007.04.09, Sherm Pendley wrote: 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. Odd. 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? As I recall, it seems to be only an issue for universal builds. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Mac::Carbon issues
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (wren ng thornton) wrote: So I seem to have mucked up my perl. I was cpanning around updating things and Mac::Carbon failed to install. But in doing so, it looks like it uninstalled the previous version that was in there, so now I can't start cpan up since it requires Mac::Files for File::HomeDir::Darwin. I then tried getting the Mac::Carbon tarball to install from, but it spews a bunch of errors too (see bottom). I remember seeing these sorts of errors in the past, but I don't recall how they got fixed. What cpan requires File::HomeDir::Darwin? CPAN.pm, or some script ... ? As to the build problem, I think it is in here: Platform: osname=darwin, osvers=8.7.1, archname=darwin-2level uname='darwin fuchikoma.local 8.7.1 darwin kernel version 8.7.1: wed jun 7 16:19:56 pdt 2006; root:xnu-792.9.72.obj~2release_i386 i386 i386 ' config_args='-Accflags=-arch i686 -arch ppc 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. You wrote: # In order to fix the makefiles for the local perl I had # to add -msse2 to CCCDLFLAGS, CCDLFLAGS, and CCFLAGS on # all the makefiles since I couldn't get my # modifications of Makefile.PL to stick. After # modifications the first two of those flags only had # -msse2, and CCFLAGS was: # # -msse2 -fno-common -DPERL_DARWIN -no-cpp-precomp -arch # i686 -arch ppc -nostdinc # -B/Developer/SDKs/MacOSX10.4u.sdk/usr/include/gcc # -B/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/gcc # -isystem/Developer/SDKs/MacOSX10.4u.sdk/usr/include # -F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks # -fno-strict-aliasing -pipe # -Wdeclaration-after-statement -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: How to gather some basic info (front-most app and title)
Tim, sorry, I missed this post before. I don't read the list too often (through an RSS reader, and I've been neglecting most of what's in there lately!). Here's some code that will do what your AppleScript does: #!/usr/bin/perl use warnings; use strict; use Mac::Glue ':all'; my $sysevt = new Mac::Glue 'System Events'; my $app_name = $sysevt-prop( name = item = 1, application_process = whose(frontmost = equals = 1) )-get; my $app_glue = new Mac::Glue $app_name; my $window_name = $app_glue-prop(name = window = 1)-get; As you can tell, that's basically what you were already doing. There's actually a script I wrote called happening that was covered a bit in an O'Reilly Mac OS X Hacks book. Unfortunately, the Mac::Glue version will only work for getting the frontmost window for applications where you've already created a glue for it (with `gluemac` on the command line). The script runs in the background and sets my iChat status to my app and its frontmost window, if I want it to. Does lots of other similar things too, like looking at what I am listening to or watching. http://dev.macperl.org/files/scripts/happening Cheers, --Chris In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Tim Bunce) wrote: On Thu, Nov 16, 2006 at 10:32:25PM +, Tim Bunce wrote: Hello. I'm hoping someone can point me in the right direction to get me started... I want to write a perl script that can gather the following simple info: Has the screen blanker blanked the screen? What's the front-most application? What's its window title? I've been using a mac for a couple of years now but never needed to do any mac-specific development. Mac-Glue and Mac-Carbon distributions look wonderful (thanks Chris!) but somewhat daunting to the OSX novice. I'm sure it's trivial. Hopefully someone can show me just how trivial ;-) Tim. p.s. I'm planning to implement a little script that'll log the info at regular intervals and, from time to time, dump it into a SQLite db. Another script will extract and summarize the info - including determining what 'project' was being worked on - and report summary info aggregated in various ways. FYI here's what I've put together so far from fragments of info gathered from AppleScript docs and web: set win_name to tell application System Events set app_name to name of the first process whose frontmost is true -- is ScreenSaverEngine if screen saver is running -- is SecurityAgent if prompting for a password to unlock end tell try tell application app_name set win_count to count of windows if (win_count is greater than 0) then set win_name to name of window 1 end if end tell end try Tim. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Fwd: Code Examples for NewAlias
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Laurence Haynes) wrote: Thanks for the code example. This was very helpful. This seems to work. However, there is a small problem. In Finder the alias appears as a file alias not a dir alias . The alias functions correctly but does not look right. Yeah, this is a problem with the Finder in general, not specific to this code: basically, the Finder can get out of sync with what the file should actually look like. There's a Nudge contextual menu item that you can use (free download), but from your code, you can also do: use Mac::Glue; my $finder = new Mac::Glue 'Finder'; $finder-obj(file = $alias)-update; Cheers, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Code Examples for NewAlias
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Paul McCann) wrote: http://use.perl.org/~pudge/journal/10437 Thanks Paul. I knew I had this code somewhere, but couldn't find it. :-) Here's a slightly cleaned-up version. #!/usr/bin/perl use warnings; use strict; use MacPerl qw(GetFileInfo); use Mac::AppleEvents qw(typeAlias); use Mac::Errors; use Mac::Files; use Mac::Resources; my $target = '/Users/pudge/Desktop/foo'; my $alias = '/Users/pudge/Desktop/foo alias'; # get target's creator, type, and alias my($creator, $type) = GetFileInfo($target); my $alis = NewAlias($target) or die $Mac::Errors::MacError; # make resource file, open it, add the resource, and close it FSpCreateResFile($alias, $creator, $type, 0) or die $Mac::Errors::MacError; my $res = FSpOpenResFile($alias, 0) or die $Mac::Errors::MacError; AddResource($alis, typeAlias, 0, '') or die $Mac::Errors::MacError; CloseResFile($res); # set alias attribute my $finfo = FSpGetFInfo($alias) or die $Mac::Errors::MacError; $finfo-fdFlags( $finfo-fdFlags | kIsAlias ); FSpSetFInfo($alias, $finfo) or die $Mac::Errors::MacError; -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Eudora glue
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (John Delacour)
wrote:
I'm trying to work out how to make a new message using the Perl glue
I've created for Eudora. It's going to take me a little while to
adapt to the Perl syntax, so I hope you don't mind my asking a few
dumb questions.
In AppleScript it would be
make message at end of mailbox :Out
and in the glue I made for Frontier the basic verb eudora.MS.new() is:
on new() {
M = core.create ('CSOm', 'euMS', 0, 0, insertionloc ('end ',
['euMB'][:Out]))}
What would the syntax be in Perl?
Sorry John, haven't read the list in a week.
Here's an example:
use Mac::Glue ':all'; # get location()
my $eudora = new Mac::Glue 'Eudora';
my $box = $eudora-obj(mailbox = 'Out');
my $mail = $eudora-make(
new = 'message',
at = location(end = $box)
);
You can probably see how this compares:
['euMB'][:Out] is like $eudora-obj(mailbox = 'Out')
insertionloc('end ', ['euMB'][:Out]) is like location(end = $box)
core.create('CSOm', 'euMS', ...) is like $eudora-make(new = 'message')
etc.
The full example of creating, composing, and sending mail is in the
distribution, in ex/eudora_send_mail, along with a bunch of other examples.
Feel free to ask any such questions, though you might want to Cc: me when
you mail the list, since I only glance at the list about once a week or so.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: iCal modules
At 19:03 +0100 2006.08.10, John Delacour wrote: At 8:45 pm -0700 9/8/06, Chris Nandor wrote: For the latter part, you may wish to just use Mac::Glue to script iCal. You can create calendars, add new events, and so on. Chris, where do I get glue for BBEdit and other things? My glues directory contains only these + the pods: URL_Access_Scripting FontSyncScripting Finder dialects ColorSyncScripting additions TextCommands System_Events Keychain_Scripting Image_Events You simply need to run gluemac /path/to/app. You may need sudo, too. For example: sudo gluemac /Applications/BBEdit.app This creates the glue file and the POD file (which can be read with gluedoc BBEdit). The ones you have by default are the two most common/important apps (Finder and System Events), and some scripting additions. All other apps, you have to do yourself one time (and after upgrades too, if you wish). -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: iCal modules
At 21:37 +0100 2006.08.10, John Delacour wrote: Ah! That sounds terrific. I guessed there must be some way to build the glue, as in Frontier. Yeah, I borrowed a bunch of ideas from Frontier. The only problem is that I get sudo: gluemac: command not found Eremita:~ jd$ man gluemac No manual entry for gluemac Eremita:~ jd$ so how do I get that working? All my Mac::Carbon etc. stuff is fully up to date so far as I know. If you are using the Mac::Carbon that comes with Tiger, then it is in /System/Library/Perl/Extras/bin/. If you installed it from the CPAN, then ... I dunno, it probably should be in your path. It wouldn't hurt to install latest Mac::Glue (and Mac::Carbon too), if you are using the one that shipped with Tiger (esp. if you have an Intel Mac, since the one that shipped doesn't work!). -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: iCal modules
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Mike Schienle) wrote: I'm checking out modules for working with iCal. I want to scrape a financial calendar web site at http://www.briefing.com/Investor/ Public/MarketAnalysis/Calendars/EconomicCalendar.htm and put the dates into an iCal calendar. For the latter part, you may wish to just use Mac::Glue to script iCal. You can create calendars, add new events, and so on. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: anyone know where i can get 10.3 Developers Tools?
On Fri, 28 Jul 2006, Ken Williams wrote: Wasn't it included in /Applications/Installers/ on 10.3? Or was that just for certain hardware models? Yes, for machines that shipped with 10.3. It should also be on the restore discs for the same machines. In a pinch, it doesn't have to be the right disc, either. E.g. if you have an iBook and an iMac and can only find the iBook's installation CDs, you can use them to install XCode on the iMac. (You wouldn't be able to install OSX itself, but that isn't the problem here anyway.) Hope this helps.. -- Chris Devers DO NOT LEAVE IT IS NOT REAL
Updates for Mac-Carbon, Mac-Glue, etc.
Last night I released new Mac-Carbon, Mac-AppleEvents-Simple, and Mac-Glue updates, mostly for endian fixes for typeAbsoluteOrdinal values (such as gFirst, gAny) and typeLongDateTime values (which are quads). I also added a new function to Mac::Speech, to direct speech output to an AIFF file instead of the speakers, which I am using for my online radio show (podcast to some of you), where I generate questions from people using speech synthesis (http://pudge.net/ask/). -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Mac::Carbon for Intel ... Done?
At 8:10 -0500 2006.06.23, Ken Williams wrote:
On Jun 19, 2006, at 9:40 PM, Paul McCann wrote:
Hi Chris,
Go play with it, if you have an Intel Mac. Let me know if you find
anything wrong, and let me know soon, since I have less than a
week left
with this Intel Mac.
The module (Mac-Carbon-0.75) was fine through make on my intel
Mac (modulo all the deprecated warnings of course, which I
imagine should be ignored).
However make test failed with the following problem:
AppleEvents/t/desc.NOK 2# Failed test 'require '$Bin/
helper.pl';'
# in AppleEvents/t/desc.t at line 11.
# Tried to require ''$Bin/helper.pl''.
# Error: Can't locate $Bin/helper.pl in @INC
Chris: it's not interpolating the $Bin variable and the quotes are
literal quotes too.
But the problem was: why did it work on *my* computer?
Turns out to be a combination of my typo, and an old version of Test::More.
First, I reversed the quotes. I initially had:
require $Bin/helper.pl;
I changed that to:
require_ok($Bin/helper.pl);
That would have worked (I now know) on a newer Test::More, but it did not
work on mine, so I changed it to:
require_ok('$Bin/helper.pl');
I meant to put the single quotes inside the double quotes, but I didn't
notice because ... it worked! The reason why is because Test::More changes
that to:
eval EOT;
package main;
require \$Bin/helper.pl;
EOT
So then $Bin is evaluated in its proper context. Neat.
Anyway, rather than making people upgrade their Test::More for this one
test, I reverted it back to a plain require() for 0.76, which is on your
CPAN shelves now.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Mac-Carbon-0.76
Thanks for all the input, I got a lot of small bugs fixed, in tests and docs mostly, and a small one in code. No major code changes, no Intel-specific code changes. The Intel box goes back to Apple in a few days, so ... test now! -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Installation of Mac::Growl fails
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Joergen W. Lang) wrote: After lurking for over two years it seems to be the time to uncloak and ask a little question. I was trying to install Chris Nandors Mac::Growl on my Dual 1.8 G5/Tiger, Perl out of the Box. cpan install Mac::Growl gives me the following errors: I've not touched Mac::Growl in awhile, and I never wrote the original PerlObjCBridge code. So offhand I do not know what the problem is, but this might give you some clues: http://trac.growl.info/ticket/330 Please let me know whether that helps. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Mac::Carbon for Intel ... Done?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Paul McCann) wrote: Hi Chris, Go play with it, if you have an Intel Mac. Let me know if you find anything wrong, and let me know soon, since I have less than a week left with this Intel Mac. The module (Mac-Carbon-0.75) was fine through make on my intel Mac (modulo all the deprecated warnings of course, which I imagine should be ignored). Yeah. However make test failed with the following problem: Someone else had the same problem. First, did any other test fail? I imagine AppleEvents/t/desc and AppleEvents/t/event failed. Any others? I had a report about Speech.t. Second, do you have the file AppleEvents/t/helper.pl? If so, then I am supposing FindBin is not working for you as it works for me, which puzzles me, but not enough that I will spend much more time on it, I'll just throw something together to make it work. Finally, you can hardcode the path to helper.pl in desc.t and event.t and run the tests again. Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Mac::Carbon for Intel ... Done?
OK, I've uploaded Mac-Carbon-0.75 to the CPAN. http://use.perl.org/~pudge/journal/29967 Go play with it, if you have an Intel Mac. Let me know if you find anything wrong, and let me know soon, since I have less than a week left with this Intel Mac. A new Mac::Glue release is following. It is currently broken on Intel, too. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: AppleScript Interface
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Thane Norton) wrote:
Up until now, I have done all of my perl-AppleScript interfacing
using osascript. I am planning on writing an script that does a lot
of Scripting in OmniGraffle, and was wondering if anyone has any
experience with the CPAN AppleScript packages that are available.
Specifically I am looking at Mac::AppleScript or
MacPerl::AppleScript. Thoughts?
The two are about the same. The differences are primarily that (I think)
Mac::AppleScript is not really supported any longer, because it was written
before Mac::Carbon was ported to Mac OS X (and is now included in Mac OS X,
as of Tiger), and it's a bit slower.
There's also the Mac::OSA::Simple::applescript() function, which calls the
OSA functions directly, and is about as fast as MacPerl::DoAppleScript.
Of course, osascript is *far* slower than both. Of course, this is not
because osascript itself is slow, but because perl has to call out to the
shell. Plus, osascript is harder to use than the others, since you have to
do all that escaping.
The non-osascript methods are all good though; MacPerl::DoAppleScript() is
just preferred because it is already included in Tiger and it's the fastest
of the four methods.
Here's some benchmarking I did a little while ago, and I just reran the
Benchmark in Tiger and it's basicaly the same.
http://www.nntp.perl.org/group/perl.macperl/2938
Also, as noted, there's Mac::Glue, which is usually a bit slower than
calling AppleScript functions directly, but can be faster in some cases,
too, by being able to do looping and other things Perl does better, in Perl.
Mac::Glue calls the Apple event API directly.
But, of course, its main feature is that you can write Perl instead of
AppleScript.
Finally, the Mac::OSA::Simple method allows you to compile scripts and
execute them, thereby giving you the best possible performance. (You can
also compile a script that can accept variables, for those cases where you
need to call the same script many times but with different values passed to
it, by setting up handlers.)
So those are the main issues, to my mind: ease/style of use, availability,
and performance. Here's an update on the benchmarks, which test only raw
performance of getting the value of a property.
#!/usr/bin/perl
use strict;
use warnings;
use Benchmark qw(timethese cmpthese);
use Mac::AppleScript 'RunAppleScript';
use MacPerl 'DoAppleScript';
use Mac::OSA::Simple qw(applescript compile_applescript);
use Mac::Glue;
my $finder = new Mac::Glue 'Finder';
# cache name property object so we don't need to recreate it every time
my $prop = $finder-prop(name = of = 'startup disk');
my $script = 'tell application Finder to get name of startup disk';
my $compiled = compile_applescript($script);
my %tests = (
applescpt = sub { applescript($script) },
applescptc = sub { $compiled-execute },
doscript = sub { DoAppleScript($script) },
runscript = sub { RunAppleScript($script) },
glue = sub { $finder-prop(name = of = 'startup disk')-get },
gluec = sub { $prop-get },
osascript = sub { `osascript -ss -e '$script'` }
);
my $results = timethese(500, \%tests);
cmpthese($results);
Benchmark: timing 500 iterations of applescpt, applescptc, doscript, glue,
gluec, osascript, runscript...
applescpt: 3 wallclock secs ( 1.40 usr + 0.38 sys = 1.78 CPU) @ 280.90/s
(n=500)
applescptc: 1 wallclock secs ( 0.40 usr + 0.04 sys = 0.44 CPU) @
1136.36/s (n=500)
doscript: 3 wallclock secs ( 1.01 usr + 0.36 sys = 1.37 CPU) @ 364.96/s
(n=500)
glue: 7 wallclock secs ( 2.89 usr + 1.12 sys = 4.01 CPU) @ 124.69/s
(n=500)
gluec: 7 wallclock secs ( 2.39 usr + 1.09 sys = 3.48 CPU) @ 143.68/s
(n=500)
osascript: 281 wallclock secs ( 0.13 usr 3.31 sys + 96.68 cusr 53.40 csys
= 153.52 CPU) @ 145.35/s (n=500)
runscript: 27 wallclock secs ( 8.15 usr + 6.58 sys = 14.73 CPU) @ 33.94/s
(n=500)
Rate runscript glue gluec osascript applescpt doscript
applescptc
runscript 33.9/s-- -73% -76% -77% -88% -91%
-97%
glue125/s 267% -- -13% -14% -56% -66%
-89%
gluec 144/s 323%15%-- -1% -49% -61%
-87%
osascript 145/s 328%17%1%-- -48% -60%
-87%
applescpt 281/s 728% 125% 96% 93%-- -23%
-75%
doscript365/s 975% 193% 154% 151% 30% --
-68%
applescptc 1136/s 3248% 811% 691% 682% 305% 211%
--
(Note: much of Mac::Carbon, and Mac::Glue, does not work yet on Intel; my
port should be done in a week.)
Hope that helps,
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group
Re: file creator id, etc
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (John Delacour)
wrote:
Without loading Mac::Carbon you can get (and set) type and creator
with osascript in the shell, but it might be quicker (if milliseconds
are important) just to print the data to an anonymous file and have
NC read that, if it can.
Not sure why anyone would do that, since Mac::Carbon comes with the Mac, and
the call to GetPerlInfo() is much simpler to use, and executes much faster.
$ time perl -MMacPerl=:all -e 'print join |, GetFileInfo(shift)' file
R*ch|TEXT
real0m0.197s
user0m0.091s
sys 0m0.030s
$ time perl -e '$file = shift; print `osascript -e '\''tell app Finder to
get {file type, creator type} of (posix file $file)'\''`' file
TEXT, R*ch
real0m0.523s
user0m0.196s
sys 0m0.112s
Perhaps you didn't think it would be so fast because you thought one had to
load ALL of Mac::Carbon? The MacPerl module itself is very small. But,
even the bigger modules load really fast on Mac OS X these days.
Loading/importing the entire distribution -- Speech, Sound, InternetConfig,
OSA, AppleEvents, Notification, Process, Resources, and so on -- on my
PowerBook G4/1GHz:
$ time perl -MMac::Carbon -e1
real0m0.938s
user0m0.570s
sys 0m0.093s
Of course, Mac::Carbon does not work on Intel systems ... not for another
couple of weeks anyway.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: file creator id, etc
On Fri, 9 Jun 2006, Joel Rees wrote: Not a perl topic, but isn't there a Finder setting that determines whether Get Info allows access to this or not? Not a Perl solution (or is Ruby close enough to count?), but RCDefaultApp may help with problems like this: http://www.rubicode.com/Software/RCDefaultApp/ -- Chris Devers
Porting Mac::Carbon to Intel
Hiya folks. Just letting anyone who is curious know: I got a loaner Intel Mac mini from Apple for the next month, and have begun porting Mac::Carbon, and the initial results are very encouraging. In my first evening I eliminated all test failures, and fixed two other untested-for bugs. That they were untested tells you I have more work to do, and I hope to take the opportunity to shore up the test suite, but last night I got Mac::Glue working, so it's going well. I'll be giving a short (20 minutes, I think) talk on this at YAPC later this month, just after the computer is due back at Apple. So by then, I plan to have new Intel-compatible releases of the Mac::Carbon/AppleEvents/OSA/Glue modules on the CPAN, along with my notes and so on. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Waiting until Acrobat closes file
On Sun, 28 May 2006, David Cantrell wrote:
if instead you're doing something like ...
system('open', '/Applications/Acrobat.app');
then you'll need to:
wait around until Acrobat appears in the process table;
wait around until that PID disappears;
Really??
In my experience, the `open` command immediately returns control to the
controlling process (the shell, or whatever else invoked it (pine etc))
without waiting for the `open`ed application to finish, or for that
matter even to finish launching.
If you're going to use acroread, then [a] you have to install it, and
[b] you have to view the document in X11. Yuck. Surely that isn't really
the best way to approach this, is it? I'd have thought that the `open`
command was the perfect answer to this question...
system('open', '/Applications/Preview.app');
etc.
--
Chris Devers
DO NOT LEAVE IT IS NOT REAL
Re: Storable problem on Intel Mac Mini
On Fri, 12 May 2006, Joel Rees wrote: On 2006.5.12, at 10:01 AM, Mike Schienle wrote: I just installed an Intel Mac Mini as a replacement for a dual 1.8 GHz G5 at my colocation place a couple days ago. Can I ask a silly question in public, or would off-list be more appropriate? Onlist, please -- if your question is my question, we might both be fascinated by the answer... :-) -- Chris Devers DO NOT LEAVE IT IS NOT REAL
Re: Storable problem on Intel Mac Mini
On Fri, 12 May 2006, Joseph Alotta wrote: My instant reaction to that would have been putting a stripped-down whitebox running OpenBSD as a logging firewall between the G5 and the 'net, to check for attacks on the mail and ftp subsystems. Can you tell me what a whitebox is? Generic cheapo x86 computer. Possibly home-built from scrap parts. http://en.wikipedia.org/wiki/Whitebox_computer I have my personal web site on my old clamshell iBook, and it runs a dynamic DNS client every ten minutes via cron. That basically keeps the disk spinning constantly. Burned out a drive last year, and I'm worried it will burn out a drive this year. So I'm thinking of putting the client on a RAM disk, although, since I wrote the client in perl, I suspect that I'd then have to copy perl itself to the RAM disk as well. RAM disks are so cheap now. I saw a 64MB USB on google for $8.97. Tht's a flash RAM devive, not a RAM disk. Different thing. http://en.wikipedia.org/wiki/RAM_drive -- Chris Devers DO NOT LEAVE IT IS NOT REAL
Re: Storable problem on Intel Mac Mini
On Fri, 12 May 2006, Joseph Alotta wrote: Why wouldn't it work to put the client code and perl on the USB keydrive and then every ten minutes, your system will get it from there instead of from your hard drive? I realize the USB keydrive is slower to load, but does that matter here? I don't see any reason at all that one couldn't do this. I was only pointing out that a RAM drive is a different thing :-) -- Chris Devers DO NOT LEAVE IT IS NOT REAL
Re: Terminal (spurious command line) problem
On Tue, 18 Apr 2006, Sherm Pendley wrote:
On Apr 18, 2006, at 2:30 PM, Brian McKee wrote:
Start Terminal.app and check under preferences (apple-,)
If you don't see it there, quit Terminal, backup and delete
~/Library/Preferences/com.apple.Terminal.plist
It's not a great idea to manipulate preference files directly. Their
location, filename, format, etc. are considered an implementation
detail that's subject to change without notice. Apple has already made
at least two changes, from old-style plists to XML-based plists, and
then from that to a binary file format.
The Apple-recommended way to deal with the user defaults database from
a shell prompt is to use the defaults tool, like this:
defaults delete com.apple.Terminal
Naturally, there are both Cocoa and Carbon APIs to do this
programatically also.
All of which is true.
That said, I still find this easier potentially safer:
mv ~/Library/Preferences/com.apple.Terminal.plist{,.MOVED}
The main benefit being that if this doesn't actually solve the problem,
you can trivially reverse the change with a
mv ~/Library/Preferences/com.apple.Terminal.plist{.MOVED,}
(And all that said, renaming preference files and deleting caches under
your ~/Library/Caches tree are both common diagnostic tricks when things
aren't working. In most cases, zapping files in either of these trees
shouldn't cause any problems, since if the needed files are missing, the
applications will regenerate a known-good version of the preference or
cache file -- the same way it did the first time you used them. But
then, at a glance, it doesn't look like Terminal uses caches, so that
wouldn't apply here, but the broader point still stands -- preferences
and caches are generally easy safe to rename or remove when trying to
diagnose software problems.)
--
Chris Devers
who *ahem* does this sort of thing for people for a living :-)
Intel Macs Break Mac::Glue etc.
It looks like Intel Macs do not properly send Apple events using the
included Mac::Carbon library (which I maintain). This, from the command
line, should bring the Finder to the front:
perl -MMac::AppleEvents::Simple -e 'do_event(qw/misc actv/, { bund
= q[com.apple.Finder] })'
It's equivalent to this AppleScript:
tell application Finder to activate
Much of Mac::Carbon does work fine, but ... this doesn't work at all. I
don't know if it is due to a bug in the Intel Macs, or a changed behavior,
or a bug in my code (most likely in AESend(), in AppleEvents.xs).
That also means Mac::Glue doesn't work.
I don't have real access to an Intel Mac, so I have no hope of fixing it
anytime soon.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
help: SIGALRM on OS X
Hello,
I'm pretty much a newbie when it comes to Mac OS X so go easy on me. I have
a Perl applicaton that communicates with the Asterisk VoIP phone system
through AGI (Asterisk Gateway Interface) very similar to CGI. Asterisk
starts my perl application and the two communicate over STDIN and STDOUT
file handles. When the user on the phone presses the # key my AGI perl
application is suppose to start recording what the users says until they
press # again. The way this works, is the perl applications writes the
RECORD command to STDOUT and Asterisk starts to record and then the perl
program waits on STDIN for the response which would be the # key when the
user presses it. I call the alarm(3) perl command (having set $SIG{ALRM}
= \handleAlarm; earlier) before issuing the RECORD command to have perl
call my handleAlarm() routine to perform some tasks three seconds after the
recording starts (like check that the file actually has some sound and to
notify others that a messages is currently being recorded).
We've been using this application on a Linux machine for over a year and
recently I tried to port the whole thing to a Macmini with OS X 10.3.
Almost everything works great except, when the alarm goes off the wait on
STDIN stops prematurly before Asterisk has actually stopped recording. If I
comment out the alarm command the wait on STDIN works fine.
I've posted this already in the Asterisk and AstMasters mailing list but I
think it may be more perl related then Asterisk related and having something
to do wtih the whole alarm subsystem on Mac OS X vs Linux. Asterisk is
writen in straight C so perhaps they are both using the same alarm timer.
Any thoughts or suggestions would be greatly appreciated because I'm
stumped.
Thanks,
Chris
Re: CPAN modules ...
On Sat, 31 Dec 2005, John Delacour wrote: Try this: #!/usr/bin/perl print `/usr/bin/./printenv` ^^ ^^ Why the '/./' here? Isn't `/usr/bin/printenv` equivalent, clearer, and simpler? -- Chris Devers DO NOT LEAVE IT IS NOT REAL
Re: CPAN modules not included with OS X
On Thu, 29 Dec 2005, James Reynolds wrote: Does anyone know why Apple chooses or not chooses to include modules? I really dislike installing them. And more and more I find I need to. So how would I go about pressuring Apple to include more. No vendor includes a full CPAN library with the stock Perl. Linux, Solaris, etc, they're all doing the same thing. If you install your own copy of Perl, it too will only have a partial standard core fraction of CPAN. Get used to CPAN. You aren't going to find a vendor that provides a full CPAN install -- new ones appear daily, so keeping up is impossible anyway. There has been talk of including fewer CPAN modules with future versions of Perl, to get people into the habit of installing things when previously they might not have wanted to go beyond the core modules. *shrug* -- Chris Devers DO NOT LEAVE IT IS NOT REAL
Re: CPAN modules ...
On Fri, 30 Dec 2005, Joel Rees wrote:
[CP_ERROR] [Mon Dec 26 14:07:55 2005] Fetching of
'ftp://ftp.cpan.org/pub/CPAN/authors/id/G/GA/GAAS/CHECKSUMS'
failed: Command failed:
[...]
This hand installation usually works, but it would be very convenient if
I could make CPANPLUS ar CPAN work. Any suggestions?
Choose a less busy mirror?
And/or check that passive-mode FTP is enabled? (Hint: $ENV{FTP_PASSIVE}
is the one you need, if I remember right...)
--
Chris Devers
DO NOT LEAVE IT IS NOT REAL
Re: XML::Simple install problems
On 11/9/05, Shawn O'Donnell [EMAIL PROTECTED] wrote: Another question: I've a lot of bad luck with cpan not installing modules. If I install OS X 10.4, will I get a clean perl installation to work with? I didn't bother with the default Apple install of perl (mostly because I knew I'd botch it eventually), so I installed perl for my primary user on my powerbook. It took a bit of reading through the install docs, but the options to install a local, personal perl weren't that bad. I couldn't figure out how to install a system-wide perl without running my administration account, so I've got perl under chris/opt/perl-5.8.7/... Do an interactive install, give it a path to install to, say yes a lot, watch it go. Good luck. -- Chris Cantrall [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: How to find out if an application is running
I just uploaded Mac::Apps::Launch. Now IsRunning() returns the PSN, instead
of simple true/false (1/0).
Here's a fun, simple, and efficient script to kill the Dock (which should
relaunch immediately):
use Mac::Apps::Launch 1.92;
use Mac::Processes;
use POSIX 'SIGTERM';
my $psn = IsRunning('com.apple.dock');
kill SIGTERM, GetProcessPID($psn);
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: How to find out if an application is running
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ted Zeng) wrote:
ps doesn't list the processes like Illustrator.
Yeah, like Sherm said.
These are the two most common methods that I've used, along with a sort-of
port of JD's AppleScript to Mac::Glue.
#!perl -wl
# simple
print 1 if grep 'Photoshop', `ps auxw`;
# heh
use Mac::Glue ':all';
my $syse = new Mac::Glue 'System Events';
print 1 if $syse-obj(processes = whose(
creator_type = contains = '8BIM' # can't see way to do bundle ID?
))-get;
# my favorite
use Mac::Apps::Launch;
print IsRunning('com.adobe.photoshop');
The latter is almost surely your best solution. No calls to external apps,
is included with Tiger, and doesn't rely on possibly conflicting paths and
app names.
It uses Mac::Processes to loop over running applications, and is probably as
efficient in that regard as the other methods, since they all basically have
to do the same thing too. But that it doesn't have to call out to another
app makes it that much more efficient.
It can also accept a four-char code, in this case, IsRunning('8BIM'), like
the Mac::Glue code does.
For the Mac::Apps::Launch code to work, you need version 1.90; 1.91 is
included in Tiger, so you should be fine if you're using that. Older
versions of the module can still handle the four-char code syntax.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: How to find out if an application is running
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Chris Nandor) wrote:
Oops, typo. This:
print 1 if grep 'Photoshop', `ps auxw`;
should be:
print 1 if grep /Photoshop/, `ps auxw`;
And I forgot to mention -- just because it may be useful -- you can also
convert between PID and PSN. Also in Mac::Processes, there are
GetProcessPID() and GetProcessForPID(). The former converts a PSN to a PID,
and the latter a PID to a PSN.
Much of the Mac:: API can accomodate either if necessary (Mac::Glue can
target by PSN or PID, and a process object from System Events can give you
a PSN or PID), but if you need to convert from one or the other, you can use
this API.
One example I like:
use Mac::Processes;
while (my($psn, $psi) = each %Process) {
kill 15, GetProcessPID($psn) if $psi-processName =~ /Photoshop/i;
}
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Sendkeys
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Vince) wrote:
Some dude working in my company needs a program that does this-
-There are over a 100 PDF files in some folder on a Mac Machine
-The program to be written is supposed to invoke Adobe Acrobat
Professional 7 (Mac version) and open each file from the directory
-Once each file is opened in Acrobat 7, it is supposed to push Alt + E
(or similar) and then 'n' (or similar) in order to enable commenting on the
PDF file.
-The program is then supposed to push Alt +F and then 'S' to save the
file
-This is to happen for all the files in that folder.
Someone supposedly told the dude that this script in Perl was easy to write!
This is likely fairly simple to do in Perl, with Mac::Glue, as long as the
app is scriptable and as long as it can do what you want to do via Apple
events, and as long as you can figure out HOW to do those things.
You can use AppleScript too, but I find Mac::Glue to be much easier to use,
once you get the hang of it, since you can handle your logic flow and
filesystem accesses much easier in Perl. Note that AppleScript will not be
able to do something (in general) that Mac::Glue cannot do.
If you're running Tiger with the default Perl, you already have Mac::Glue
installed, though you may wish to update it. If yes to Toger and no to
updating Mac::Glue, you will need to run this first:
cd /System/Library/Perl/Extras/bin/
sudo ./gluedialect
sudo ./gluescriptadds
sudo ./gluemac '/System/Library/CoreServices/System Events.app'
sudo ./gluemac /System/Library/CoreServices/Finder.app
And then the line above becomes something like:
sudo ./gluemac /Applications/Acrobat\ Professional
Else, after installing/updating Mac::Glue, just do:
sudo gluemac /Applications/Acrobat\ Professional
As I don't have the app in question, I can only guess how to do what you
ask; it's different for every app. So below I give some guesses.
I see the 6.0 dictionary here:
http://macscripter.net/app_dictionaries/dictionary.php?id=196_0_1_0_C
It has no real clues; you might need to get into UI scripting, which is far
more of a pain. You can tell the UI to hit a key combination, or select a
menu, type a letter, and so on. The below assumes you won't need to do that.
use File::Spec::Functions;
use Mac::Glue ':all';
my $dir = '/Users/pudge/Desktop/PDFs';
# using Safari for testing ... it opens each PDF, and closes it
my $acrobat = new Mac::Glue 'Safari'; #'Acrobat Professional'; # etc.
$acrobat-activate;
opendir my $dh, $dir or die Can't open $dir: $!;
chdir $dir or die Can't chdir $dir: $!;
for my $file (readdir $dh) {
# or whatever ...
next unless $file =~ /\.pdf$/i -f $file;
my $pdf = $acrobat-open($file);
## ideally, $pdf will contain a reference to the just-opened
## document, but not for every app, so as a backup:
$pdf ||= $acrobat-obj(window = 1); # get front window
## the above could also properly be:
# $pdf ||= $acrobat-obj(document = 1, window = 1);
## no idea how to do this part; see gluedoc $appname on the
## command line for docs for the app, here's a wild guess;
## if someone could show me the AppleScript dictionary for the
## app, I could take a look; this is the part that may need to
## be done with UI scripting
# $pdf-prop('commenting')-set(to = 1);
## usually, you can close with saving, but you may
## need to save explicitly, or you vice versa (again,
## app-dependent); the combined close with saving
## is the most efficient method
# $pdf-save;
$pdf-close(saving = enum('yes'));
}
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Get/set file type/creator in plain Perl?
The best thing to do for FInfo is *not* to dereference is, but to call the supplied methods. `man Mac::Files` and look for FInfo, and see: FInfo Information for a file, including: OSType fdTypethe type of the file OSType fdCreator file's creator U16fdFlags flags ex. hasbundle,invisible, locked, etc. Point fdLocationfile's location in folder Best to use $info_ref-fdType and $info_ref-fdCreator. The resulting scalar on derference, JPEG8BIM, is not really what it appears, as it has packed bits for fdFlags and fdLocation, and is length 16, not 8. OK, yes, it is a bit odd to use a SCALAR ref for that, but you should be using the methods so you don't need to care. :-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Cat and Dos2unix Command Line Utilities?
On Fri, 8 Jul 2005, Joseph Alotta wrote: On Jul 8, 2005, at 9:26 PM, Chris Devers wrote: #!/bin/sh perl -pi -e tr/\r//d I tried to call perl directly. But this does not work at all. Does anyone know why? #!/usr/bin/env perl -pi -e tr/\r//d See, I was only trying to save you a line. :-) Yeah, but it doesn't really matter how complex the script is, so long as you can just do a $ dos2unix file.txt and get back a clean result. If I was going to make any modifications to the file, rather than simplify it, I'd force it to quit rather than edit any binary file, as $ dos2unix file.jpg can be *really* disastrous the way it is now :-) But if I cared *that* much, I'd just get dos2unix from Fink and be done with it. As it is, I almost never use this script in the first place, so leaving it as is works fine for me :-) -- Chris Devers
Re: psync and MacOSX::File installing with cpan
On Fri, 8 Jul 2005, Joseph Alotta wrote: So I tried to install MacOSX::File and got these errors. Does anyone know what I am doing wrong? I get the same result: macgarnicle:~/.cpan/build/MacOSX-File-0.69 root# make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/catalogok 3/7# Failed test 4 in t/catalog.t at line 33 # t/catalog.t line 33 is: $asked eq avbstcLinmed ? ok(1) : ok(0); t/catalogFAILED test 4 Failed 1/7 tests, 85.71% okay t/copy...ok t/file...ok t/info...ok 6/10# Failed test 7 in t/info.t at line 38 # t/info.t line 38 is: ok($asked eq avbstcLinmed); t/info...FAILED test 7 Failed 1/10 tests, 90.00% okay t/spec...ok Failed Test Stat Wstat Total Fail Failed List of Failed - t/catalog.t71 14.29% 4 t/info.t 101 10.00% 7 Failed 2/5 test scripts, 60.00% okay. 2/29 subtests failed, 93.10% okay. make: *** [test_dynamic] Error 2 macgarnicle:~/.cpan/build/MacOSX-File-0.69 root# We both got failures on t/catalog 3/7 and t/info 6/10. The first failed test is: use MacOSX::File::Catalog; ... my $asked = askgetfileinfo(dummy); $asked eq avbstcLinmed ? ok(1) : ok(0); The second failed test is nearly identical: use MacOSX::File; use MacOSX::File::Info; ... my $asked = askgetfileinfo(dummy); ok($asked eq avbstcLinmed); So... something wrong with askgetfileinfo() on Tiger maybe ? -- Chris Devers
Re: question on Perl's ssh
On Fri, 24 Jun 2005, Ted Zeng wrote: Why the system behaves differently when I ssh to a machine from Terminal than when I ssh to the same machine by Perl's SSH module? It sounds like the script is getting the default system $PATH variable, while the shell is getting the $PATH defined in your login scripts. Specifying the full path to the tool you want may circumvent this. Alternatively, your script can declare what $PATH to use, but without seeing the code, I'm not sure how best to do this. In any case though, if it's an option for you, using a full path would be easier than setting it manually. -- Chris Devers
Re: Script menu no longer runs perl scripts in Tiger?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Riccardo Perotti) wrote: I just installed Tiger last week. To my surprise, the Script Menu doesn't run perl scripts anymore. (I had tons in Panther for just about everything!!) I've tested various to no avail. Any clues? I'd hate to have to wrap every perl script in Apllescript :-( I noticed the same thing, but have not yet had a chance to try to debug it. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Mac::Glue, g_t, and dates
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Ricardo SIGNES) wrote:
I can do this in AppleScript:
tell application iTunes
tell playlist Library
get tracks whose played date is greater than date
January 1, 2005
end tell
end tell
I can't reproduce this kind of query in Mac::Glue, as far as I can tell.
I tried using a string and a timestamp in place of the date, but to no
avail. What should I be doing?
Not sure what you tried, but basically, you use track whose(played_date =
g_t = $date). The question is how to construct $date. AppleScript can
afford to make more assumptions than we can, so param_type() helps us
defined types when necessary.
For dates there's two steps: get the epoch time (with timelocal here), and
then pass it to param_type to define it as typeLongDateTime.
use Mac::Glue ':all';
use Time::Local;
my $itunes = new Mac::Glue 'iTunes';
my $library = $itunes-obj(playlist = 'Local Library');
my $time = timelocal(0, 0, 0, 1, 0, 105); # jan 1 2005
my @tracks = $library-obj(track =
whose(played_date = g_t = param_type(typeLongDateTime, $time)),
)-get;
# check our work
for (@tracks) {
print $_-prop('name')-get, : ;
print scalar localtime $_-prop('played date')-get, \n;
}
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Parsing Jpeg files for comments
On Wed, 8 Jun 2005, Robin wrote:
I've googled about for this but to no avail:
Try search.cpan.org next time :-)
I'm making a perl frontend to a mySQL server to serve up images. Some
of the images are jpegs with keywords stored as comments in the file,
and I want to be able to access those comments through perl. Is there
a module which already exists which does this?
Yes: Image::Info.
http://search.cpan.org/~gaas/Image-Info/lib/Image/Info.pm
Quoting from that page...
SYNOPSIS
use Image::Info qw(image_info dim);
my $info = image_info(image.jpg);
if (my $error = $info-{error}) {
die Can't parse image info: $error\n;
}
my $color = $info-{color_type};
my($w, $h) = dim($info);
Accessing the comment field is a one-line change to this block.
Helpful?
--
Chris Devers
np: 'Everything to Play For'
by Douglas Adams
from 'H2G2: The Tertiary Phase'
Re: ActiveState is announcing support for Mac OS X
On Wed, 8 Jun 2005, Sherm Pendley wrote: On Jun 8, 2005, at 9:41 AM, Janet Goldstein wrote: People would use ActivePerl for OS X for the same reason Windows users use ActivePerl Windows users use ActivePerl because Windows doesn't ship with Perl. FWIW, ActiveState Perl is also available for Solaris; they also make software available for AIX, HP-UX, etc. I'm not sure if these systems tend to ship with Perl, but I know that Perl often runs on them. In that light, I'm actually a little surprised that they didn't have a version for Mac OS X sooner than this. The timing of the announcement seems curious to me... -- Chris Devers
Re: ActiveState is announcing support for Mac OS X
On Wed, 8 Jun 2005, John Delacour wrote: Why does not Apple update Perl through sofware update? As I understand it, the rationale is that a lot of things depend on the release of Perl that shipped with the system -- installers, startup scripts, periodic daemons, etc. If Perl were to be upgraded, then all the things that depend on it would need additional rounds of QA testing with each release, but they don't have the resources to support this. Let's say, as a plausible example, that the iTunes installer uses Perl for initial setup. As it is now, any iTunes update on Panther needs to be tested with Perl 5.8.1, and any update on Tiger needs to be tested against 5.8.6; all other releases can be ignored. If Apple were to release revisions to Perl as they come out, then they'd have to start testing each Panther version against all Perls 5.8.1, and all Tiger versions would have to be tested aginst 5.8.6. (And that's not even mentioning Jaguar, which might [?] still get iTunes updates, so that would be all Perls from 5.6.1 and up.) Clearly, things start multiplying fast. And every combination in the matrix of release versions would have to be tested, as different people will have different system update levels, some will have skipped some packages, etc. So, while I do wish that they made it simpler to put a newer version of Perl somewhere like /usr/local, I can sympathize with the rationale for not tampering with the version that ships as standard with each major iteration of the system. -- Chris Devers
Re: ActiveState is announcing support for Mac OS X
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Jan Dubois) wrote: Today ActiveState is announcing support for Mac OS X. ActivePerl 5.8.7 for Mac OS X is now available for free download from: http://www.ActiveState.com/Products/ActivePerl/ And besides, ActiveState will make sure Perl and XS will run on Mac OS X/Intel! -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Universal Binary vs. Perl5
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Dan Kogai) wrote: What's gonna happen to XS? -- It already uses .bundle so in theory it can handle multiple architectures but in practice? Dunno. I do know that building for multiple platforms worked with the same basic configuration under NeXT (or so I am told). I don't recall if those were fat binaries, but I think they may have been. The bottom line is I won't worry about Mac-Carbon for, oh, a year or two. I see no reason to rush. Heck, my stuff is included with Mac OS X in Tiger now, so I figure there's a chance they will fix any problems in it. ;-) I'll let Apple shake out the bugs and perhaps give me/us some access to a machine (I'd think we could probably get at least one machine for Perl developers to work with ...). Maybe Ed can give us some clues, when the time is right. (Maybe if it would make us feel better, we can start working now to get a dev box, with permission to have multiple people get access to it (me, Dan, Sherm(?), a pumpking or two ... ?) I don't want to get into a big argument about the decision itself. Well, OK, maybe I do, but I won't do so here. And I see no reason to think the sky is falling. When Mac OS X first came out, Fred Sanchez gave us patches to get perl running. We figured it all out, in time, and there's plenty of time. That's not to say there aren't a lot of concerns, and Lord knows I have mine (the ones Dan raise here, especially). But I've no reason to think that we won't be able to take care of what needs to be taken care of. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: CamelBones on Intel? Maybe not.
On Wed, 8 Jun 2005, John Horner wrote: My main question about the change to Intel is why the developer pack, whatever it was, costs so much? What do you get for your $999? I was expecting something free to download to developer members. They throw in a Pentium4 / 3.x gHz computer with the deal. Phrase it that way and it's actually kind of cheap... :-/ -- Chris Devers still baffled by what this all means
Re: ModPerl on Tiger
On Wed, 18 May 2005, Rich Morin wrote: Does anyone know whether (a) ModPerl is already part of Tiger? Yes. Just as it has been with every version of OSX. And for once, the stock Perl is in line with the current stable release! Unlike with Panther, where you had to do weird output buffering tricks in httpd.conf to get mod_perl to work, everything works fine in Tiger. (Though I've yet to try installing RT, that'll be the real test. I was never able to get it to work right on Panther...) ...was there supposed to be a (b) in there somewhere? -- Chris Devers
Re: Mac::Carbon installation woes
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sergej Zoubok) wrote: I'm running OS 10.3.8 with Xtools 1.5, GCC 3.3, and Perl 5.8.0 Whether I use the CPAN shell or try a manual installation I get the following error on make: make[1]: *** No rule to make target `../xsubpps/typemap', needed by `AppleEvents.c'. Stop. make: *** [subdirs] Error 2 The list archives and Google both point to an earlier thread from April which referenced the same error but had no clear resolution. Has anyone else seen this? I just tried with perl 5.8.0, and yeah, I see it too. It was a change in the build scripts for version 0.72, and I have a fix. You could try 0.71, or wait for 0.73 to come out soon, or update ExtUtils::MakeMaker (though I have no idea if that might cause other problems, so I wouldn't personally recommend it). 0.72 and 0.73 have only build fixes, except for a small feature addition in 0.72, so there's really no great reason to wait for 0.73. Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Macperl list false advertising?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Joel Rees) wrote: Anyone know why http://www.perl.org/community.html describes the macperl list as Mac Perl - OS 7-9 and X discussion Probably just old. You could try to contact whoever controls the page. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Mac::Glue and Tiger
At 1:48 -0400 2005.05.02, Sherm Pendley wrote: *However*, there's a note at the top of Carbon.h mentioning that type cast, so I assume you had a good reason for adding it in the first place... I should find out who wrote that note and ask him why he did it. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Mac::Glue and Tiger
Tiger ships with Mac::Carbon and Mac::Glue. Huzzah! Some notes: * Mac::Carbon requires gcc 3.3 or below, it doesn't work with gcc 4. I don't know why, and anyone who wants to fix this or give me clues would make me happy. For now, my personal box is using gcc 3.3 instead (sudo gcc_select 3.3), because I have no desire to try to deal with the problem. Of course, if using the Mac::Carbon that is already included in Tiger, you don't need to care, because it has already been built. Presumably with gcc 3.3. :-) * Mac::Glue doesn't include any glues. You have to create your own. The scripts needed to do so are included too. cd /System/Library/Perl/Extras/bin/ sudo ./gluedialect sudo ./gluescriptadds sudo ./gluemac '/System/Library/CoreServices/System Events.app' sudo ./gluemac /System/Library/CoreServices/Finder.app -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Mac::Glue script
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Mark Wheeler) wrote: OK, I installed Xcode - 1.1 then upgraded to 1.5, and ran the cpan Mac::Glue again and still had problems. Here are snipits of the the output: You didn't include any actual error output. It continues on for a while installing modules (presumably) and then gives this final output: --- Running make for C/CN/CNANDOR/Mac-Glue-1.23.tar.gz Is already unwrapped into directory /Users/markwhee/.cpan/build/Mac-Glue-1.23 CPAN.pm: Going to build C/CN/CNANDOR/Mac-Glue-1.23.tar.gz -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible Somewhere in the snipped output, there would be the make output, showing an error. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Mac::Glue script
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Mark Wheeler) wrote:
The script will open Internet Connect, dial a number (given by the
script).
I don't know if you can do that with Internet Connect. This sorta works:
my $ic = new Mac::Glue 'Internet Connect';
my $conn = $ic-prop('BlueTooth configuration')-get;
my $status = $conn-prop('status');
my $state = $status-prop('state');
my $number = '*99#';
$conn-connect(to_telephone_number = $number) if $state-get == 0;
while (1) {
last if $state-get == 8;
sleep 1;
}
(That works for my Bluetooth modem, you can try it with 'PPP configuration'
too, I'm sure it should work the same.)
But in my test, it dials the main configuration no matter what the value of
$number. And I cannot select multiple configurations. (These are apparent
limitations in Internet Config itself, not Mac::Glue.)
When a connection is established, a sound file will be played
5 X (or what ever number of repetitions).
You can do this to some degree with Mac::Sound. I think you can't do it
with any old sound, that you need to have it in a resource file. The
Sound.t file shows an example. Another option is to use SysBeep(30) or
somesuch, to just get the system beep.
After the connection is lost
(phone is hung up after listening to the sound file), the connection is
closed, Internet Connect quits and the script ends.
Just keep checking $state-get until it is false, apparently. I didn't look
too hard to get an accurate and complete list of $state values. It's 0 when
not connected, 8 when connected, and 1-7 while in different connection
phases (dialing, authentication, etc.).
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Mac::Glue script
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Mark Wheeler) wrote: Thanks for the input. I'll start working on it and see what I can come up with. One question: Is Mac::Sound a module? I've not heard of it. It's included with Mac-Carbon, which is a prereq for Mac::Glue. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: command-line tweaking of Open With... settings?
On Sat, 23 Apr 2005, Rich Morin wrote: Clues? Suggestions? It's a lateral approach to the problem, but RCDefaultApp may be able to help you: http://www.rubicode.com/Software/RCDefaultApp/ The core of RCDefaultApp is `lstool`, which you can invoke directly: $ /Volumes/RCDefaultApp-1.2.1/RCDefaultApp.prefPane/Contents/Resources/lstool Usage: lstool read [lsscheme [type]] lstool write lsscheme type app lsscheme is one of: internet, url, extension, mime, ostype app is the path to an application or a name to be looked up $ I suspect that this can be used to do what you need. Somehow... -- Chris Devers
Re: Tiger version
On Tue, 12 Apr 2005, Lola Lee wrote: I've been looking at http://www.apple.com/macosx/developertools/ and unfortunately it doesn't say which Perl version. Surely this tidbit is buried elsewhere on the site? It would be nice if that page had version numbers for some of the main Unix software they're going to be distributing: Perl, Python, Ruby, GCC, etc. Now that a release date is imminent, maybe they can update the page to have this information. Didn't the promo pages for 10.3 have all of this kind of thing? -- Chris Devers
Re: [OT?] libxml2/libxslt and OSX
On Thu, 17 Mar 2005, wren argetlahm wrote:
This is only somewhat off topic, but I was wondering if there were any
packages out there for Mac OS X with the necessary development C
headers for libxml2 and libxslt? I can only seem to find rpms of the
same. If not (brace yourselves) how difficult would they be to
create*?
The system should already have the libxml2 libraries, but you get both
the libraries and headers if you install XCode. (You get, among other
things, /usr/lib/libxml2.{2.dylib,la} and /usr/include/libxml2/* files.)
For libxslt, it may compile cleanly on its own, but personally I just
get it from Fink, which is a port of the Debian APT/dpkg toolkit. With
Fink, an `apt-get install libxslt libxslt-bin libxslt-shlibs` should
download and install .debs that have been patched compiled for OSX.
Incidently, RPM probably won't help much on OSX. I'm not aware of any
porting framework that uses it. Aside from Fink, the other main one,
GNU/Darwin, is (ironically?) based on the BSD ports system. I've not
heard of anyone porting over the RedHat porting framework to OSX.
--
Chris Devers
Re: problem with installing DBD::mysql
On Tue, 15 Mar 2005, Mark Wheeler wrote: I don't know if this will help, but here is a link that I found to a problem with installing DBD::mysql on Panther. Let me know if it works/is helpful, as I need to install it, too. I did the research for installing it (that's how I found the link) but haven't got around to it yet. Here's the link: http://www.truerwords.net/articles/osx/install_dbd_mysql.html Let me know if this is the fix. No. No. No. It's close, but it's not the right fix. But that page actually *links* to the right fix! As Edward Moy (of Apple) wrote, you have to do the following: We recently discovered the DBD::mysql problem as well. The patch is to edit /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config.pm, replacing: ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc' with ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc' Do that, and DBD::Mysql (and anything else that trips over this bug) will work just fine. -- Chris Devers
Re: problem with installing DBD::mysql
On Wed, 16 Mar 2005, John Horner wrote: Call me petty, but this problem has been around for *years*, hasn't it? Well, since 15 Oct 2003, as noted in the URL that I forgot to paste last time: http://www.mail-archive.com/macosx%40perl.org/msg05736.html That's when Panther came out, not Jaguar. Apparently, for whatever reason, it was never considered necessary to patch it in a following OS upgrade, or even in the XCode update that came out a few months ago. I don't know why, but there it is. Panther was on the market longer than the previous OSX releases, but it's not *quite* such an old bug -- it only impacts 10.3. On the other hand, we still have Jaguar users today. Not many, but a few. We'll probably have people using Panther, and hitting this bug, for at least a couple more years... :-/ -- Chris Devers
Re: perl.h?
On Mon, 14 Mar 2005, Warren Pollans wrote: I just got an error - complaining about not being able to find perl.h. Does that come with the xcode tools? Or something else? Yes, I seem to remember that header files come with XCode. If you want to install any Perl modules with a compiled XS component, you need the XCode toolkit anyway, so you might as well install it if you haven't done so already. -- Chris Devers
Re: First CGI Setup
On Thu, 10 Mar 2005, Ted Zeng wrote: It looks like I will need mod_perl. mod_perl makes me nervous. Last time I touched it, I could not make it work on Windows. The worst experience I had with Apache on Windows. Now, I just realized that I might need it because Axkit depends on it. Randal said that it is installed in OS X. I hope this is the case. I will do some search on this. There's little to research. If you look in /etc/httpd/httpd.conf, you should see these lines, mixed in with the other LoadModule and AddModule statements: #LoadModule perl_modulelibexec/httpd/libperl.so #AddModule mod_perl.c Uncomment them and you now have a mod_perl enabled Apache: LoadModule perl_modulelibexec/httpd/libperl.so AddModule mod_perl.c The mod_perl on OSX is, for the most part, exactly the same as it is on other versions of Unix: it can be flaky fiddly, and there's a lot to learn, but getting up running with it on Unix (including OSX) is a *lot* less painful than it would be on the Windows version of Apache. Or at least, that has been my experience. -- Chris Devers
Growl, PerlObjCBridge, Glue, etc.
I just uploaded Mac::Growl to the CPAN. It is an interface to Growl.
http://growl.info/
I mention it not because you should use Growl -- though you should -- but
because it has some interesting and useful examples of how to use
PerlObjCBridge in it.
http://search.cpan.org/~cnandor/Mac-Growl/lib/Mac/Growl.pm
The module actually uses three methods: PerlObjCBridge, Mac::Glue, and
AppleScript. This way it works out of the box, pretty much anywhere. On
initialization it sees if PerlObjCBridge (Foundation) is available, and if
so, it uses that to send messages directly to the Growl framework.
If that's not available -- because you built your own perl or somesuch --
it tries Mac::Glue, and then falls back to AppleScript (trying one of three
AppleScript modules, before reverting to system('osascript', ...)).
Anyway, over on use.perl.org I found some info for loading other Frameworks
into Perl:
http://use.perl.org/~pemungkah/journal/23339
I used this to load the AppKit framework, which, along with the
CoreFoundation framework, I used to send data and images to Growl. I know
almost nothing about ObjC or Cocoa, but I got it to work, and figured it
might be of some interest.
(Also perhaps of interest: the Makefile.PL automatically creates a glue for
Growl, for Mac::Glue to use, so the user doesn't have to ... feel free to
take that or give tips to me on how it can be improved.)
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: What Perl editor do you recommend?
[mangled quotation style revised :-) c.d.] On Wed, 2 Mar 2005, Joseph Alotta wrote: On Mar 2, 2005, at 5:20 PM, Ted Zeng wrote: I have downloaded TextWrangler and used it for a short while. It satisfies all my need right now. In fact, I feel it is better than the shareware I used to use for editing Perl scripts on Windows. TextWrangler is free from Bare Bone Software, which also sells BBEdit. TextWrangler seems to be a very good editor, and if you grow out of it, BBEdit will be there waiting for you as a superset of TW. It's also worth taking a look at SubEthaEdit though, if only for the extremely clever useful collaborative editing feature that allows multiple SEE users to work on the same document at the same time. The people working on the document can discover each other automatically if you're on the same local network, or you can connect to remote users over the internet if you have their address. As an example, I've used SEE to edit a shared document from home and at work at the same time (with help from VNC) or asynchronously (to work on the file at work, then pick up where I was when I get home). This isn't a capbility I'm aware of in any other editor, on any platform, and it's pretty much the only thing that would ever make me want to switch away from usign Vim as my main text editor. If you're collaborating on documents with other OSX users, this can be a great way to assist that. At my job, we've got half a dozen OSX users that have switched away from BBEdit to SEE just so they can collaborate this way, and they've been really happy with for the past few months. It seems to me, that vi and vim are very similiar. I actually thought they were the same. What is the difference? Vi was a very early full-screen UNIX editor going back to the 70s or so. Vi today is basically the same program it wass 20 or more years ago. Vim is Vi IMproved, a completely new program that both implements all the functionality of classic Vi while extending it with lots of features that came along later with editors like Emacs: multiple levels of undo, command history in the ex subshell, etc. Plus, it includes an optional graphical mode that runs natively on X11, Windows, and OSX; it doesn't make Vim as simple to use as TextWrangler / BBEdit / SubEthaEdit / etc, but it's a lot more friendly than the original Vi ever was... -- Chris Devers
Re: What Perl editor do you recommend?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Peter N Lewis) wrote: Some friends have recommended vim and emacs to me. And one of the reasons is he can remotely edit a text file very easily. This has been mentioned a few times, but of course TextWrangler/BBEdit both support Edit via FTP/SFTP, so presuming you are SSHing to your target machine, then you can easily edit remote files with TextWrangler/BBEdit. For example, on the target machine while logged in via ssh, you can do this: ssh [EMAIL PROTECTED] bbedit sftp://[EMAIL PROTECTED]/perl/Peter/Tools.pm I should here plug cenotaph. It's something Matthias Neeracher wrote, and then I ported it to Mac OS X. It's a client-server. The server, cenotaph, runs on your local Mac, and the client, ceno, runs on the remote boxes you're using as your editor. So you type: ceno somefile on the remote box, and somefile pops up on your local box, in your editor. When you're done editing it, cenotaph sends it back through the open connection to the client, where it is then saved. Any editor works, in theory: cenotaph will execute the editor and wait for it to return, so it pretty much requires an editor that runs in your GUI. By default, it uses BBEdit (via '/usr/bin/bbedit -w'). It's a useful tool to have, especially when you can't get direct scp/sftp access to a machine (such as in my work environment, where I have to go through a gateway first to get to any of the other machines, so I either use a remote command line editor, or this). There's no security, because I've never needed it and no one else seems to be using this and therefore no one really cares, but in theory if someone knew your IP address and that you were running cenotaph, they could open any number of files to your editor. :-) Anyway, it's on SourceForge.net if you care. http://sf.net/projects/pudge/ -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: could not build a module
On Thu, 24 Feb 2005, David H. Adler wrote: Perhaps I'm mistaken, but wouldn't it be more accurate to say install the OS X development tools, rather than Xcode, per se? As of OSX 10.3, Xcode is the name for the whole suite, in addition to the specific XCode IDE. Maybe it was decided that the 10.0 - 10.2 era [Month] [Year] OSX Develeoper's Tools was a clumsy name that had to be retired, and that having the same name for two things was acceptably annoying. *shrug* -- Chris Devers
Re: set photo properties in iPhoto
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (_brian_d_foy) wrote: I think I'm missing something about setting properties though. I can read things fine, but I get an error when I try to set a property: 'Mac::AEObjDesc=HASH(0xb03f00)' parameter not available. Where's my error? my $photo = $album-obj( photo = 1 ); my $date = $photo-prop( date )-get; print( qq|date is $date\n| ); $photo-set( date = to = 2004-06-13 12:34:56 ); # $photo-prop( 'date' )-set( ... ) ? You are calling date as the direct object on set(). This really works out to: $iphoto-set($photo = date, to = ...); Your second guess would be correct, although I would do: my $date = $photo-prop( date ); printf( qq|date is %s\n|, $date-get ); $date-set( to = ... ); But there is a bigger problem. From `gluedoc iPhoto`, under Classes = photo: date (idat/utxt): The date of the photo. (read-only) In Script Editor, you will see this as: date Unicode text [r/o] -- The date of the photo. There ain't nothing Mac::Glue can do to fix that problem. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Heredoc
On Fri, 18 Feb 2005, Jeremy Mates wrote:
Warning! The qq[] syntax produces different output than the heredoc:
my $foo = EOD;
asdf
EOD
my $bar = qq[
asdf
];
print uh oh unless $foo eq $bar;
Right. The qq[] syntax above as I offered earlier, tacks on newlines.
These are identical:
$ cat ptest
#!/usr/bin/perl
my $foo = EOD;
asdf
EOD
my $bar = qq[asdf
];
print uh oh unless $foo eq $bar;
print qq{
\$foo:
[$foo]
\$bar:
[$bar]
};
$ perl ptest
$foo:
[asdf
]
$bar:
[asdf
]
$
That's just wacky that I had to force a newline on the qq form to get a
match; I don't see this as validating the heredoc approach at all.
I find the qq[] form so much more readable forgiving than heredocs
that I generally never even consider using them unless I'm maintaing
something that uses them heavily or are otherwise forced to use them.
They have so little to offer though that I avoid them otherwise...
But as I say, YMMV...
--
Chris Devers
Re: Can't get DBD::mysql installed
On Wed, 16 Feb 2005, Boysenberry Payne wrote: On Feb 15, 2005, at 1:09 PM, Chris Devers wrote: ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc' Thanks for the patch/fix. Do you think I should rebuild DBD::mysql? It certainly wouldn't hurt, and it would only take a few minutes. It's worth doing. -- Chris Devers
Re: Next Problem...
At 9:49 -0600 2005.02.15, Ken Williams wrote: Would be nice if the error was /Applications/AddressBook.app - no such file or directory then. You are most wise. :) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Technology Group [EMAIL PROTECTED] http://ostg.com/
Re: Question: glue for the Summarize service?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Kim Helliwell) wrote: Is there a way to call the Summarize service from a Perl script? It's in StandardAdditions, summarize. Just pass your text to it: my $finder = new Mac::Glue 'Finder'; # or any other scriptable app print $finder-summarize($mytext); -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Questions about Perl and Mac::Glue
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Kim Helliwell) wrote:
for $mbox ($account-obj('mailboxes')-get)
{
... do some stuff...
}
But what if I want a reference to a list of all the mailboxes? Should
I force a list context like this?
$mboxes = ($account-obj('mailboxes')-get);
If you want a persistent reference to all the mailboxes, that will change as
the mailboxes change, then you just want merely:
$account-obj('mailboxes')
And then call -get on it whenever you want the mailboxes.
But if you want a Perl reference to the list of all mailboxes, then you just
need to make one explicitly.
$mboxes = [ $account-obj('mailboxes')-get ];
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Installing Mac::Glue
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Kim Helliwell) wrote: I just tried to install Mac::Glue, and even though there were no error indications, /usr/bin/gluemac (among other things) did not get installed. The output claimed to be installing it, but it's not there... I suspect I needed to have run the install behind sudo. Probably. If that is the correct diagnosis, how can I recover? Running it now under sudo just results in the message that everything is up to date. How do I undo/uninstall the stuff so I can re-install it correctly? You appear to have fixed this (judging from your next message), but from what I gather, you probably installed using the CPAN shell. Yes, it won't install again if you already have it installed, unless you type force install Mac::Glue. Or you can type look Mac::Glue and then do the perl Makefile.PL ; make ; make test ; make install manually from the shell from there. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Next Problem...
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Kim Helliwell) wrote: When I type: kim% sudo gluemac /Applications/AddressBook.app I get: What is the glue name? [AddressBook]: ref is not a valid file specification at /Library/Perl/5.8.1/Mac/AETE/App.pm line 252, STDIN line 1. This didn't happen before. (that is, it worked on an older machine) I think you entered the filename incorrectly. There's a space: % sudo gluemac /Applications/Address\ Book.app -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Perl stopped working on Apache 1.3.3, but then starts?
On Mon, 7 Feb 2005, InnoTech Support wrote: I had a situation where I had to cycle power to my G5 Mac running Apache 1.3.3 OS X 10.3.7 today. After reboot, I found that Perl scripts no longer reliably run via the web. I can get pages to load a few times, but then I get the Internal error page, but do not see any errors in apache error log. I tested via Terminal calling a Perl script and it seemed to work fine. What shows up in the Apache logs when someone hits this page? Do successes errors look the same in the log? -- Chris Devers
RE: Perl stopped working on Apache 1.3.3, but then starts?
On Tue, 8 Feb 2005, InnoTech Support wrote: Did not see any errors in Apache error log, nor anything in web log. Today, all is well, seems to be working fine. Yesterday, we were pushing much more traffic than usual out. It appears as if Apache was too busy dealing with web requests, and could not process cgi requests until traffic subsided. Perhaps Perl/cgi requests are lower priority? Who knows? I think your best bet, if the problem appears to have vanished, is to look over the Apache logs for the time frame that the problem was happening to see if there is any record of what the problem may have been. You may or may not see any useful patterns, but it sounds like that's the only data you have to work with now. -- Chris Devers
TextWrangler
For those who haven't seen, TextWrangler 2.0 -- which is basically a slightly stripped-down version of BBEdit, without HTML tools and some other things -- is now available, and free. Free, as in beer. And it handles all the same Perl stuff as its bigger sibling: syntax coloring, running scripts, filters, debugging, viewing POD, etc. http://www.barebones.com/products/textwrangler/ I think the only thing it cannot do that BBEdit does -- from what I can tell -- is that it doesn't talk directly to Affrus (the perl debugger for Mac OS X), like BBEdit can. If you've always liked BBEdit for perl development, but didn't want to buy it, then now's your chance. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: installation weirdness with Mac::Glue
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Chris Devers) wrote: I thought I'd play around with Mac::Glue, so I fired up the CPAN shell to install it. The installation went, in part, like this: [snip] At this point, things seemed to go haywire. The perl process was taking up the bulk of CPU time, the virtual memory consumption for that process was well over a gigabyte and growing, the system was almost completely unresponsive, and it was staying that way for 20 minutes or more. I've never seen a CPAN installation do this sort of thing before. I've never seen a Mac::Glue installation do that before. So... in spite of some nasty looking errors, the installation made it to the tests, and they appear to have all passed cleanly. Is this trustworthy? No, because of this (which should cause the tests to fail, but does not, which I will fix in next release): t/gluePlease run gluedialect and gluescriptadds programs at /Users/cdevers/.cpan/build/Mac-Glue-1.22/blib/lib/Mac/Glue.pm line 1341, DATA line 1. Mac::Glue creates special glue files for the AppleScript core language/dialect, various scripting additions, programs, and so on. Without those, Mac::Glue can't do much, and while it looks like maybe you got the dialect file installed -- the most important one -- it needs the others too. You can try running those programs again, but I fear they would do the same thing if you don't change something. I wonder if maybe Joel has the right idea with the memory thing. If it continues to be a problem, I can try to hop on a dual G5 and try it out myself. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Mac::Glue and mod_perl
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Brian Dimeler)
wrote:
I'm trying to write a mod_perl script (for PerlRun) that will present an
online interface to my Mac OS X Address Book. Using the standard method
of connecting to the glue (new Mac::Glue 'Address Book') doesn't work;
the webserver complains about not being able to connect to a window
server. So, I'm using Remote Apple Events instead (yes, I remembered to
turn them on in System Preferences):
my $book = new Mac::Glue 'Address Book',
eppc = 'Address Book',
'mac8.local' # hosts both the webserver + addressbook
undef, undef, # uid pid omitted
'Mac8', 'mypass' # Mac8 is the Admin user owner of addressbook
This line apparently causes the server child process to exit:
[Fri Jan 14 11:02:40 2005] [notice] child pid 6070 exit signal Bus error
(10)
I just took an existing mod_perl script running on my PowerBook and added:
my $book = new Mac::Glue 'Address Book',
eppc = 'Address Book',
'bourque.local', undef, undef,
'pudge', 'pass';
print $book-prop('version')-get, \n\n;
$book-activate;
I went to the URL in my browser, and it worked. It printed 3.1.2 and then
brought Address Book to the front.
My wild offhand guess is that you have a different mod_perl than installed
perl: different version, or architecture, or something.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
installation weirdness with Mac::Glue
I thought I'd play around with Mac::Glue, so I fired up the CPAN shell to install it. The installation went, in part, like this: [...] Manifying blib/man3/Mac::AETE::Format::Glue.3pm Manifying blib/man3/Mac::AETE::Dialect.3pm Manifying blib/man3/Mac::AETE::Parser.3pm Manifying blib/man3/Mac::Glue.3pm Manifying blib/man3/Mac::AETE::App.3pm Created and installed Dialect glue for AppleScript.rsrc (AppleScript) At this point, things seemed to go haywire. The perl process was taking up the bulk of CPU time, the virtual memory consumption for that process was well over a gigabyte and growing, the system was almost completely unresponsive, and it was staying that way for 20 minutes or more. I've never seen a CPAN installation do this sort of thing before. Thinking something had gone off the rails, I did a `clean Mac::Glue`, then tried it again. The installation did the same thing at the same point, so I decided to just let it run while I watched television. The computer sat there making all kinds of painful noises for the next hour and a half before it settled down; when I came back to check, the following text was on the console: Manifying blib/man3/Mac::AETE::Format::Glue.3pm Manifying blib/man3/Mac::AETE::Dialect.3pm Manifying blib/man3/Mac::AETE::Parser.3pm Manifying blib/man3/Mac::Glue.3pm Manifying blib/man3/Mac::AETE::App.3pm Created and installed Dialect glue for AppleScript.rsrc (AppleScript) *** malloc: vm_allocate(size=268435456) failed (error code=3) *** malloc[8585]: error: Can't allocate region Out of memory! *** malloc: vm_allocate(size=268435456) failed (error code=3) *** malloc[8585]: error: Can't allocate region Out of memory! END failed--call queue aborted, DATA line 1. *** malloc: vm_allocate(size=268435456) failed (error code=3) *** malloc[10104]: error: Can't allocate region Out of memory! *** malloc: vm_allocate(size=268435456) failed (error code=3) *** malloc[10104]: error: Can't allocate region Out of memory! END failed--call queue aborted. /usr/bin/make -j3 -- 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/gluePlease run gluedialect and gluescriptadds programs at /Users/cdevers/.cpan/build/Mac-Glue-1.22/blib/lib/Mac/Glue.pm line 1341, DATA line 1. t/glueok t/pod.ok All tests successful. Files=2, Tests=11, 6 wallclock secs ( 1.11 cusr + 0.30 csys = 1.41 CPU) /usr/bin/make test -- OK Running make install Appending installation info to ///System/Library/Perl/5.8.1/darwin-thread-multi-2level/perllocal.pod Installing /Library/Perl/5.8.1/Mac/Glue.pm Installing /Library/Perl/5.8.1/Mac/Glue/Common.pm Installing /Library/Perl/5.8.1/Mac/Glue/glues/dialects/AppleScript Installing /Library/Perl/5.8.1/Mac/Glue/glues/dialects/AppleScript.pod Installing /man/man3/Mac::AETE::App.3pm Installing /man/man3/Mac::AETE::Dialect.3pm Installing /man/man3/Mac::AETE::Format::Glue.3pm Installing /man/man3/Mac::AETE::Parser.3pm Installing /man/man3/Mac::Glue.3pm Writing ///Library/Perl/5.8.1/darwin-thread-multi-2level/auto/Mac/Glue/.packlist /usr/bin/make install -j3 -- OK cpan So... in spite of some nasty looking errors, the installation made it to the tests, and they appear to have all passed cleanly. Is this trustworthy? This is a dual G5/1.8ghz running the stock version of Perl. In detail: % hostinfo Mach kernel version: Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Kernel configured for up to 2 processors. 2 processors are physically available. Processor type: ppc970 (PowerPC 970) Processors active: 0 1 Primary memory available: 1024.00 megabytes. Default processor set: 158 tasks, 316 threads, 2 processors Load average: 0.06, Mach factor: 1.93 % sw_vers ProductName:Mac OS X ProductVersion: 10.3.7 BuildVersion: 7S215 % uname -a Darwin macgarnicle 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc % perl -v | grep -i 'this is perl' This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level Any ideas? Are installations like this normal for Mac::Glue? -- Chris Devers
Re: catnip.local (redirect)
On Thu, 6 Jan 2005, Jeff Lowrey wrote: I might actually look at the apache configuration, and see if it's using ServerName=catnip.local, and fix that. This sounds like the right solution to me. From what I can tell, if the ServerName directive is undefined in the Apache configuration, then it will default to the host name, which the Mac is going to see as `hostname`.local. If she manually specifies -- ServerName catnip.company.com -- in /etc/httpd/httpd.conf, then restarts Apache with a -- $ sudo apachectl configtest sudo apachectl restart -- then everything should begin working properly. Mucking around with the hosts file is the wrong way to fix this. For one thing, Panther doesn't even necessarily pay attention to it (by default it ignores it and most other files in /etc, if I remember right), but more importantly you're fixing the symptom (redirecting the host name) rather than the real problem (apache should use a portable name). Fix the real problem and the symptom will go away. -- Chris Devers
Re: iTunes shell
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Cutter Brown) wrote: One of the biggest issues I'm having right now is querying the Library by the database_id: my $track = $remote-obj( tracks = whose(database_id = equals = $args), playlist = 1 ); This actions seems to take forever (30+seconds). Is there a better way to get the track from id? The problem is that iTunes is just very slow at whose searches. There may be another way, though I don't know how reliable it is, and it's more of a pain. Instead of getting the database ID, get the unique ID: my $id = $sometrack-get-getdata; Then: my $track = $remote-obj( track= obj_form(formUniqueID, typeLongInteger, $id), playlist = 1 ); That's very fast, assuming a. you can get the unique IDs, and b. they are reliably consistent for you. (This was somewhat documented in the Mac::Glue POD, using iPhoto as an example, for a different problem.) Good luck, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Trying to Install Bundle::DBD::mysql
On Mon, 20 Dec 2004, Sherm Pendley wrote: No, it doesn't matter what user you use to grant the privileges. If 'mysqluser' is your normal admin user, just log in to the mysql shell as that user: mysql -u mysqluser -p For that matter, you could use phpMyAdmin to grant the privileges too. The important part is that the user '[EMAIL PROTECTED]' needs full access to the database 'test' - how you grant it that access is incidental. To clarify, '[EMAIL PROTECTED]' is an account with the MySQL database. It has no relation at all to the system 'root' account on your computer. MySQL has its own set of accounts which generally have no connection to the ones on the system that the database server is running on. -- Chris Devers
