Re: BBEdit
At 15:27 -0700 2001.04.23, John W Baxter wrote: When a rational person can make that recommendation, then one is just accommodating people who elect not to move up or can't afford to by continuing MacPerl. That's a decision for later this year, I think...post 5.6.1-based MacPerl (if Chris and the gang want to keep going that long). At the VERY least, I want to get out a modern MacPerl and set it up so that someone else can more easily carry the mantle, if I do decide to move on. I anticipate a MacPerl 5.6.1, and a MacPerl 5.8.0. I've already built MacPerl for 5.7.1 several times. For the most part, it is just drop in the perl source, be it 5.6.1, or 5.7.1, and compile. So in the future, anyone can build MacPerl for themselves, with whatever version is current. The big work right now is porting to GUSI 2 and working out a lot of kinks in the system. But the core of perl 5.6 and 5.7/8 are so close, it is going to be mostly quite easy to move forward. The big questions would be additional features, like a better built-in editor, or threading/forking, etc. So to sum up: I am going to stay with Mac OS for the forseeable future. I will do my darndest to release MacPerl 5.6.x and MacPerl 5.8.x, as applicable. After that, we are past the forseeable future, but nevertheless, if I am not still working on it, it should be relatively simple for someone else to build new versions. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Fwd: perl 5.7.1+ fine(ish) on mac os x (please fwd)
Date: Wed, 25 Apr 2001 10:34:42 -0500 From: Jarkko Hietaniemi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: perl 5.7.1+ fine(ish) on mac os x (please fwd) Sender: [EMAIL PROTECTED] Public service announcement: the development branch of Perl now builds [1] out of the box in Mac OS X, with just Configure -de. I integrated the various needed changes and Paul Schinder tested them for me, kudos to Paul who never sleeps (he simply can't, given how much he tests stuff). [1] Note that I said fine(ish) and builds, the three test failures (pragma/warnings, lib/sigaction, lib/posix) are still there. P.S. Anyone on Rhapsody wanting to test a developer snapshot? ftp:[EMAIL PROTECTED] (I already sent this to [EMAIL PROTECTED] but since I'm not a subscriber something seems to have silently eaten that message. Besides, that message had wrong URL for the snapshot.) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Fwd: perl 5.7.1+ fine(ish) on mac os x (please fwd)
At 10:07 + 2001.04.26, [EMAIL PROTECTED] wrote: On Wed, 25 Apr 2001, Chris Nandor wrote: Public service announcement: the development branch of Perl now builds [1] out of the box in Mac OS X, with just Configure -de. Erm, except doing -de with a development edition doesn't work because it realises it is a development edition and the default answer to using a development edition is no. Add -Dusedevel to the command line. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Fwd: perl@10517
Hi, everybody! Jarkko humbly requests that people test the latest snapshot of perl 5.7 on Mac OS X. -- Chris Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm list-help: mailto:[EMAIL PROTECTED] list-unsubscribe: mailto:[EMAIL PROTECTED] list-post: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Date: Mon, 11 Jun 2001 11:20:24 -0500 From: Jarkko Hietaniemi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: perl@10517 Mail-Followup-To: Jarkko Hietaniemi [EMAIL PROTECTED], [EMAIL PROTECTED] X-Spam-Rating: onion.valueclick.com 1.6.2 0/1000/N http:[EMAIL PROTECTED] http:[EMAIL PROTECTED] ftp:[EMAIL PROTECTED] http:[EMAIL PROTECTED] http:[EMAIL PROTECTED] ftp:[EMAIL PROTECTED] The VMS de-PerlIO patch is not in since I'm still hoping NI-S can find a better way. Changes since the last: [ 10516] By: jhi on 2001/06/11 14:46:33 Log: Add the modfl_pow32_bug (anti)definition also to VOS headers. Branch: perl ! vos/config.alpha.h vos/config.ga.h [ 10515] By: jhi on 2001/06/11 14:39:05 Log: VOS updates from Paul Green for @10476. Branch: perl ! README.vos vos/Changes vos/build.cm vos/compile_perl.cm ! vos/config.alpha.def vos/config.alpha.h vos/config.ga.def ! vos/config.ga.h vos/configure_perl.cm [ 10514] By: jhi on 2001/06/11 12:58:43 Log: Subject: [PATCH] Not many people know this ... From: Mike Guy [EMAIL PROTECTED] Date: Mon, 11 Jun 2001 14:55:15 +0100 Message-Id: [EMAIL PROTECTED] Branch: perl ! pod/perldebug.pod [ 10513] By: jhi on 2001/06/11 12:30:06 Log: Add final commas to lists as suggested by Philip Newton. Branch: perl ! lib/ExtUtils/Constant.pm t/lib/extutils.t [ 10512] By: jhi on 2001/06/11 12:28:49 Log: Subject: [MacPerl-Porters] [PATCH] Mac OS Compatability for bleadperl Date: Sun, 10 Jun 2001 23:35:38 -0400 From: Chris Nandor [EMAIL PROTECTED] Message-Id: p05100306b749ec0eaade@[10.0.1.177] Branch: perl ! lib/DirHandle.pm lib/File/Basename.pm lib/diagnostics.pm ! perl.c t/base/term.t t/comp/cpp.t t/comp/multiline.t ! t/comp/script.t t/lib/anydbm.t t/lib/autoloader.t ! t/lib/dirhand.t t/lib/selfloader.t t/op/anonsub.t ! t/op/closure.t t/op/defins.t t/op/exec.t t/op/goto.t ! t/op/pack.t t/op/regexp.t t/op/regexp_noamp.t t/op/split.t ! t/op/write.t t/pragma/strict.t [ 10511] By: jhi on 2001/06/11 12:13:31 Log: Subject: [RESEND] [PATCH] Mac OS lib patches for bleadperl From: Chris Nandor [EMAIL PROTECTED] Date: Mon, 11 Jun 2001 08:24:28 -0400 Message-Id: p05100303b74a66faf625@[10.0.1.177] Branch: perl ! ext/IO/lib/IO/Dir.pm lib/File/Copy.pm t/lib/filecopy.t ! t/lib/io_dir.t [ 10510] By: jhi on 2001/06/11 12:03:16 Log: One more run_byacc (a hand-tweaked version had slipped in). Branch: perl ! perly.c vms/perly_c.vms [ 10509] By: nick on 2001/06/11 07:49:15 Log: Integrate mainline Branch: perlio ! Makefile.SH embed.h embed.pl global.sym ! lib/ExtUtils/Constant.pm lib/ExtUtils/Manifest.pm objXSUB.h ! perl.h perlapi.c perlapi.h perly.c perly.fixer perly.h perly.y ! perly_c.diff pod/perl572delta.pod pod/perlapi.pod proto.h sv.c ! t/lib/extutils.t util.c vms/perly_c.vms vms/perly_h.vms [ 10508] By: jhi on 2001/06/10 22:38:05 Log: Subject: [PATCH] ExtUtils::Manifest not -w clean From: Mike Guy [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] Branch: perl ! lib/ExtUtils/Manifest.pm [ 10507] By: jhi on 2001/06/10 22:37:16
Re: Accented characters in scripts (and whereis iconv.h?)
At 09:33 -0400 2001.07.23, Steve Torrence wrote: I would just like to know what is the most common way of handling this. It's hard to believe the Perl script authors working on scripts for languages that contain these extended characters are going through a lot of trouble putting the accented characters in their scripts. It seems that a tool like bbedit would be able to take a script that was written using the extended characters and convert the text to something compatible with perl. I am not sure what you are asking. Most people don't use non-ASCII characters. When they do, they usually use Latin-1 or Unicode. If you use MacRoman or Windows character sets instead, then you need to convert. So what is it you want to handle? If it is BBEdit or Terminal showing the right characters, then you need to either do a Latin1-MacRoman character map, or you need to change the behavior of the programs to show the characters in the character set you want (in BBEdit or Terminal, this might be as simple as changing the font; I use ProFont, and it has a companion ProFontIsoLatin1). I know that the few scripts I have found don't use either of the 2 coding methods Will mentioned. They seem to substitute one extended character for another which Perl seems to convert to the correct character when sending the html to the browser. Again, perl does not convert any characters. It just sends a byte of data. How that byte is rendered is not determined by perl, it is determined by the rendering process (BBEdit, Terminal, Internet Explorer, etc.). For example, if I send the byte 0xC4, Terminal (using MacRoman) will show (that italicized lower-case f used often for folders). But Internet Explorer (using the default of Latin-1) will show Ä (capital A with an umlaut). perl doesn't care. It is just data to perl (unless you are in a regex, or using isprint(), etc.). perl does no conversion or translation. It just sends a single byte that is rendered by the displaying process in different ways. So you need to know not how perl will print the data, but how a particular process will render it. If you are printing data in Latin-1, then you need to make sure the rendering process displays it in Latin-1. For most applications (web, etc.), this is the default, and therefore not a problem. You might want to therefore adjust the behavior of your apps to use Latin-1 instead of MacRoman. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: State of OS X Perl?
In article f04320401b7927838ceb7@[192.168.0.2], [EMAIL PROTECTED] (Gero Herrmann) wrote: I hope using the same name as the MacPerl.pm module in the MacPerl distribution is acceptable, or is it? I thought about including MacPerl::SetFileInfo and MacPerl::GetFileInfo but am not sure how file paths should be handled. Perhaps the best way to handle it would be to, at some point, merge the two files. Bottom line: please do not put it on CPAN with that name until we figure something out. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Script menu in 10.1
In article 4685534.1001435141@[10.0.0.3], [EMAIL PROTECTED] (Ken Williams) wrote: Holy crap, is that cool! John Gruber [EMAIL PROTECTED] wrote: http://www.apple.com/applescript/macosx/script_menu/ It's a system-wide script menu for 10.1 that runs AppleScript, Perl, and Shell scripts. Hmm... I've been using something like that in Mac OS 8/9 for years, OSA Menu. The only problem was that I need to wrap a Perl script in a compiled AppleScript (or other OSA Script), but I wrote a MacPerl droplet with Mac::OSA::Simple to do that, so no worries. I'll probably install Mac OS X 10.1 anyway. ;-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Script menu in 10.1
In article 25932486.1001528307@[10.0.0.2], [EMAIL PROTECTED] (Ken Williams) wrote: Allow me to elaborate. =) Ah, ignore me. I was just taking the opportunity to note that we have something similar in Mac OS 9, and that I don't want to use Mac OS X. ;) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Converting a Unix path into a Mac path
In article 2001102423-r01010800-e58cfee9-0921-0108@localhost, [EMAIL PROTECTED] (John Gruber) wrote: Is there an easy, reliable method to turn a Unix-style path into a Mac HFS-style path? For example, turning /Users/gruber/Documents/foo into Boot:Users:gruber:Documents:foo where Boot is the name of my startup disk. (Why? Because I want to write a script that executes an AppleScript using Mac OS X's osascript tool. I need to convert the file arguments into HFS-style paths, because osascript doesn't take command line arguments and AppleScript doesn't understand Unix-style paths.) I know this is old, but I don't get in here much. :-) There's a module on CPAN called Mac::FileSpec::Unixish which may be able to help you; Sean Burke wrote it, and it converts Unix paths to Mac paths. You would need to manually prepend the volume name, in this example, of course. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Perl and AppleScript Studio
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Michael Stearne) wrote: That's really cool. I'm a lot better with Perl. But I guess you don't get any of the application tie ins like you do with AppleScript. Sure you can. Someone just needs to port the Mac:: modules, and then you'll have Mac::Glue, which can do nearly everything anything AppleScript can do (as far as controlling and talking to applications), using the same vocabulary (but with a Perl syntax). use Mac::Glue; $itunes = new Mac::Glue 'iTunes'; $itunes-play; Mac::Glue works from MacPerl under Classic to control Mac OS X apps too, somewhat (I've not tested it extensively, and at least on problem involves the droplet to create the glue for an application doesn't yet understand Mac OS X apps). In the case of iTunes, I created the glue using the Classic version of iTunes, and used it as above to control the Mac OS X version of iTunes, running MacPerl from Classic. And like I said, if the Mac:: modules (AppleEvents, Events, etc.) are ever ported to Mac OS X, you'll be able to do the same under perl for Mac OS X. I don't know when that will happen. One thing is nearly certain: it will happen before I make the switch to Mac OS X as my main box. :-) But that might not be for quite some time. Mac OS 9 is quite comfortable, and Mac OS X is not, for now. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: MacOSX::File uploaded to CPAN
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Dan Kogai) wrote: My name is Dan Kogai and this is my first time to drop a message here -- maybe with a good reason. I just uploaded a module called MacOSX::File, which allows you to write programs like the ones on /Developer/Tools. You can now copy() with resource fork and finder info, gets and sets finder flags, etc. Hope you guys like it. Any comments are welcome. Hi Dan. Two comments: 1. Did you ask [EMAIL PROTECTED] about the namespace? I am not sure MacOSX is a good top-level namespace. 2. Did you look at the modules in MacPerl that do the same thing, with an eye toward compatability of interfaces? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Namespace [Was: Re: MacOSX::File]
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Dan Kogai) wrote: Anyway, since then my policy to upload a module is as follow; 0) Make sure it does not exist yet. 1) Upload and see what happens. Well, I am a member of the [EMAIL PROTECTED] cabal; the general practice is that if something is OK, we don't necessarily respond. If no one responds after a week or so, you're probably fine. But that doesn't mean you shouldn't ask first. I don't necessarily think that your name is wrong, but I do think you should post to [EMAIL PROTECTED] first for such things as new top-level namespaces. Maybe Mac::X would be better, I dunno. That's why it is discussed first. :) So far so good. But of course, I am open to opinions. If enough number of you (well, even I am not sure how many would be enough. Say if my mailbox gets flooded with complaints) don't like it I am happy to change that. As for the toplevel 'MacOSX', I first considered 'Darwin' but Dawin's own /bin/cp and /bin/mv ignore Resource fork. Then I considered 'Carbon' but What actually my module does is to bridge both worlds. So I picked MacOSX, the name that contains both worlds. My problem is that I think this module should have the same interface as Mac::Files and should be called Mac::Files and then programmers on both platforms can use Mac::Files and just have it work. Well, OK, maybe not. But I do want *A* module called Mac::Files on Mac OS X that has the same interface as Mac::Files on Mac OS, though, and what I don't want is for there to be confusion in the long run as to what these modules should and shouldn't do ... What I really should do is just port the Mac:: modules, but I don't have the time to do that work. :/ -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Namespace [Was: Re: MacOSX::File]
At 17:40 +0900 2002.01.14, Dan Kogai wrote: Okay, I will. I heareby request namespace MacOSX for the use by modules that are platform-specific to MacOS X. As for the namespace Mac::X, I object because this is confusing with X window. Yes, I agree it is confusing. I am not crazy about MacOSX, but can think of nothing better, so I am not objecting. My problem is that I think this module should have the same interface as Mac::Files and should be called Mac::Files and then programmers on both platforms can use Mac::Files and just have it work. Mine does not have the same interface. That's why I picked the different name space to begin with. After XS (therefore C compiler) is imperative for make install MacOSX::File (though binary distribution is considered when it gets stable) something you can't expect of MacOS 9 and below. What can be expected of Mac OS (9) isn't relevant, since binary distributions are possible (and the norm). We have binary distributions of all the Mac modules, plus many other modules; certainly a binary distribution of this module for Mac OS 9 would be possible, if it were written to be compatible (or were patched as such). So it makes me wonder again if MacOSX is the right place for it, if indeed it can work on both platforms. Oh, that reminds me. Is there a canonical way to upload BINARY version of the module? I can make it so that Makefile.PL works like an installer rather than Makefile generator but is it the way? Well, there is a canonical way on Mac OS, but I don't know about Mac OS X. You can grab one of the distributions from my user directory (CNANDOR) and examine it; essentially, I put the binary files in their place (macbinarizing them), and then there is special code in ExtUtils::Mac / CPAN / Mac::BuildTools to handle them. It wouldn't be as complex for Mac OS X to handle it, if for no other reason but that you wouldn't need MacBinary for anything. Well, OK, maybe not. But I do want *A* module called Mac::Files on Mac OS X that has the same interface as Mac::Files on Mac OS, though, and what I don't want is for there to be confusion in the long run as to what these modules should and shouldn't do ... It would be nice, too but that requires more than my share of work. Resorting to reinventing a wheel is a pain enough. But the issue is that there *will be* Mac::Files on Mac OS X eventually. So with your module, there will be two sets of modules that do the same thing, one of which is incompatible with Mac OS (perhaps). This isn't necessarily a bad thing, but I would like to see something like this module just be a stopgap measure until the full toolbox set is available via the Mac:: modules, because I would rather people use modules compatible for both OSes when possible, for maximum portability. What I really should do is just port the Mac:: modules, but I don't have the time to do that work. :/ Yes, that's always the problem. As for MacOSX::File, I was too lazy to use Finder to backup a hundred of thousand of files (vanilla MacOS X with Developer Kit well exceeds 100,000 files). I was too impatient to wait for someone come of a module like this. And I was too hubristic to wait for the verdict of [EMAIL PROTECTED] What other virtues do I need :) I am not denying the need for the module, and I am not saying the module as it exists is wrong in any way. But the issue of duplicated functionality and compatability (as well as the issues of what File::Copy etc. should do) need to be addressed, so that we all know what direction things are headed, and so that interested parties have a chance to weigh in. Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Namespace [Was: Re: MacOSX::File]
At 11:44 -0500 2002.01.14, John Gruber wrote: Chris Nandor [EMAIL PROTECTED] wrote on 1/14/02 at 9:27a: Yes, I agree it is confusing. I am not crazy about MacOSX, but can think of nothing better, so I am not objecting. I have a feeling that MacOSX is not future-proofed. What happens if the next major revision to the OS is _not_ named Mac OS X 11, but instead Mac OS XI, or (preferably) Mac OS 11? Yeah, another good point. Hrm. Although, the way Apple is doing it now, the OS is named Mac OS X and its version is 10.1.2, so the complete name is Mac OS X 10.1.2; similarly, it is Mac OS 9.2.1. So if they continued with that, it would be Mac OS X 11.0. However, there is no way of knowing what Apple will do in this regard; I don't think consistency is necessarily going to be the standard by which future rules apply. I wonder if maybe Mac:: is a better namespace, and then say in the docs which versions of Mac are supported? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Namespace [Was: Re: MacOSX::File]
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Brian McNett) wrote: On Monday, January 14, 2002, at 09:42 AM, Chris Nandor wrote: I wonder if maybe we should have Carbon:: or Cocoa:: namespaces? Even Mac::Carbon:: or Mac::Cocoa:: or Mac::Aqua:: etc. This would be Mac::Carbon::Something in that case ... I haven't weighed in on this issue (or much of anything of late) but this would seem to be the most reasonable solution. This would give us Mac:: as the classic MacOS namespace, Mac::Carbon:: as the transitional API (with CarbonLib on MacOS 9 and earlier systems), and Mac::Cocoa as the namespace for MacOS X (and later) modules. Although I would still push for similar interfaces across similar modules (and there will be some duplicate functionality regardless of what else happens). Note that the Classic Mac toolbox *is* almost entirely Carbon, however. There's been some thought that the port of the Mac:: toolbox to Carbon could be in Mac::Carbon::, with the same interface, though I am not sure it's necessary. At this point, I figure the Mac:: toolbox modules should stay where they are, in lieu of companions in Mac::Carbon::, although additional Carbon modules could go there. Or something. I dunno, I am still trying to figure it out myself. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Line endings (was: Help with Perl on MacOSX)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Frank Nospam) wrote: For the record, does anyone here know why the two Steves picked CR instead of LF back when they started this little company we hate to love? Is there a practical advantage? Similarly, : vs / as separator, the 1901 datestamp, etc. Is the Steve way actually better than the pre-existing Unix way, or were they being difficult just to think different? You say that as though Unix were some sort of standard ... the problem was that there wasn't really an established standard. As to the 1904 datestamp, that was to accomodate the fact that time_t in Mac OS is unsigned ... which in some ways makes more sense than a signed time_t. Why have a negative time_t to go before 1970 when you can just start at 0 further back? Again, there was no standard at the time. Same thing with /. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Please
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ken McGlothlen) wrote: John Gruber [EMAIL PROTECTED] writes: | Just curious: Why? Well, I don't know about the other guy, but I miss having droplets, plus all the MacOS glue that makes working with creators and types easier. The modules are getting there, but I haven't heard of any way to make a Perl droplet yet. Droplets can be done in other ways. And the modules, while nice to have, don't rely on having a Carbon MacPerl, it relies on Carbonized modules. Stay tuned. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Please DON'T
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Gregory Cranz) wrote: Please, pretty please, carbonize MacPerl. IMHO, MacPerl was a stopgap that kept the Mac in the game until we've got OS/X i.e. Un*x to work with. Do you mean the purpose of the existence of MacPerl, or the purpose it is maintained, or the purpose you use it? Maybe MacPerl was a stopgap for you, but it was not designed as such, and is not maintained as such. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: MacPerl Capabilities on OS X (was Please Don't)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: In the interest of stopping what looks to be a potential flame war: I don't think there's any flamewar brewing. Perhaps I was a bit too curt -- it was a long week -- but I just wanted to emphasize that MacPerl is a first-class Perl implementation on a viable platform. In fact, it is easier, IMO, to build perl 5.6.1[*] on Mac OS than it is on Mac OS X. :-) MacPerl is not dead yet, and neither is Mac OS. For those who prefer Mac OS X, that's great, but I don't want anyone who might want to use Mac OS and MacPerl to think that MacPerl is not still going to be around or that it is merely a stopgap. If you want to use it, it will be here, and it will work well, and don't let anyone tell you anything different. That's my message. :-) [ObPlug: MacPerl 5.6.1b3 is out, and b4 is going to be ready within a week or three, as hopefully the final beta before the release.] As a long-time Unix (Solaris) SysAdmin and a Macintosh Bigot, I developed apps in both the *nix Perl and MacPerl. I really liked many of the capabilities of MacPerl (the open box, the droplets, the syntax checking from the editor) I also missed the fact that the Perl 5 capabilites were missing and that modules that required C compiles were not easy to implement. I don't know what you mean by the Perl 5 capabilities were missing. Maybe you were using MacPerl 4.x? MacPerl 5 has been out for many years now. But yes, XS modules have always been difficult, though the most popular ones have been readily available for a few years now, as has a tutorial on how to build them yourself using freely available tools. Still, a high bar for most people, but that can't be helped. :) I have long wished that the best of both worlds were available, and I hope that someone or some group can make it happen. We should have an plain vanilla perl implementation for the command line, and we should have extensions that would include an IDE and the ability to make simple clickable apps and droplets. Correct me if I am wrong, but it seems like you are suggesting that an IDE and the ability to make droplets etc. are somehow different from a 'plain vanilla perl implementation.' I don't know what that means. An IDE and droplet can simply communicate with the command line perl. They don't need to be separate things. [*] Well, the latest maint-5.6 source from the perl repository, which is more like perl 5.6.1 + patches. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: MacPerl Capabilities on OS X (was Please Don't)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: The version of MacPerl lagged behind the current release of Perl - I was constantly porting stuff and finding out that modules like HTML::Table wouldn't work because it required capabilities not in the MacPerl release. To someone who was not constantly trying to develop Solaris and Mac Apps in parallel might not have been so frustrated. As soon as MacOS X 10 was released, I went to using the unix version because of this frustration - but I really missed the Mac goodies, especially when developing for Mac end users, most of whom are graphics artists in my shop, and not at all interested in the Terminal app, and aren't interested in anything but Macish apps. Well, then have no fear: if you still want it, MacPerl 5.6.1 is approaching release status. The next beta -- probably this week -- will have all known major bugs fixed. Although, perl on Mac OS X will someday (hopefully sooner rather than later) have access to the Mac:: modules (if in a different form), which will, hopefully, make MacPerl on Mac OS X obsolete. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Applescript call from Perl
In article p05101401b888f79cab91@[203.47.34.3],
[EMAIL PROTECTED] (Peter N Lewis) wrote:
At 21:13 -0500 7/2/02, Brad Rice wrote:
How do you call Applescript from Perl? I want to make a CGI that
runs an applescript.
In MacPerl, use:
MacPerl'DoAppleScript(END_SCRIPT);
tell application Finder
move alias $folder to trash
end tell
END_SCRIPT
I believe MacPerl can also do raw AppleEvents.
Yeah. MacPerl also has Mac::Glue, a sorta AppleScript in Perl
framework:
use Mac::Glue;
my $finder = new Mac::Glue 'Finder';
$finder-move( $finder-obj(alias = $folder),
to = $finder-prop('Trash')
);
Or one of my favorites: :)
$interarchy-edit( path = $rpath, host = $host, user = $user );
$bbedit-compare( $bbedit-obj(window = 1), $lpath );
When we get Carbon running on Mac OS X, I'll be porting Mac::Glue, too.
In Mac OS X Perl, use /usr/local/bin/osascript, man osascript for
info on how to use it and send the data to it from the Perl script.
Is there any other ways?
There's a MacPerl module for Mac OS X with a similar interface to the
MacPerl module in MacPerl, whish uses osascript.
http://news2.ils.uec.ac.jp/~herr/
http://news2.ils.uec.ac.jp/~herr/OSXMacPerl-0.1.gz
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Announce: osx-client mailing list
In article p05100310b8a15746ce7d@[61.115.108.82], [EMAIL PROTECTED] wrote: Due to the lack of such a mailing list dealing with OSX client only problems I went ahead and set one up - send an email to [EMAIL PROTECTED] with subscribe osx-client on a line of it's own in the message body. What are OSX client only problems? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Announce: osx-client mailing list
In article p05100305b8a4fd27ef3c@[61.115.111.63], [EMAIL PROTECTED] wrote: This is just off the top of my head mind, I'm sure if you give me time to think I could come up with a couple of others. No, that's fine, I just didn't know what you meant by the phrase. Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Carbon patches for Mac::(Types,Memory,Resources)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Michael Blakeley) wrote: It's probably time that SourceForge had a Carbon Perl Modules project, feeding into CPAN. Yep! One already exists. http://sf.net/projects/mac-carbon/ But I'm a relative novice at XS, and even more ignorant of Carbon, so I'm hoping that some more capable developers will have time and interest, too. Are the MacPerl developers still uninterested, as http://macperl.sf.net/ suggests? Why do you say we are uninterested? The page clearly says the opposite! Read again: # It would be nice to, at some point, have the Toolbox modules # (Mac::Windows, Mac::Events) Carbonized so the same GUI-based MacPerl # programs would run on both platforms. This may happen in the future. The fact is that we are very interested, and have already begun the process. The short story is that Matthias Neeracher has begun planning the Mac::Carbon module. The plan is to port the existing Mac:: toolbox modules to use the new module, so they are primarily pure-perl frontends to the new module. I don't know if he's got any code started yet, though I've stated that, as time permits, I want to start working on it when MacPerl is released (any day now). I know a lot of people want it, and I do too, so I want to get it going ASAP. So all that said, I've not done any work on patches to the existing Mac:: modules for Carbon compatibility, since it looks like we're going a different way, as described above. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
YAPC
I'll be giving a talk entitled Mac::Perl at YAPC, June 26-28, in St. Louis. The talk will discuss the present and future of the state of perl on Mac OS and Mac OS X. If you wish to have anything in particular discussed, please let me know. I am currently planning on an overview of 5.6/5.8 on Mac OS, and on Mac OS X, and the state of various tools and modules for accessing the Mac OS API on both platforms. I'll be preparing my slides over the next two weeks. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: FYI: Successful Install of Perl 5.8.0 RC 1 + Apache 2.0.36 + ModPerl-2.0 on OSX 10.1.4
In article p05111a37b9248135ce12@[203.47.34.3], [EMAIL PROTECTED] (Peter N Lewis) wrote: At 18:57 -0400 5/6/02, Rick Frankel wrote: so, adding: .PHONY: install at the top of the (gnu)makefile will force the install target to execute. Presumably that would be a NOP on any other makefile anyway (unless someone ever went make .PHONY which is probably a reasonable acceptable risk ;-). .PHONY is not just a GNU make thing anyway; I know dmake uses it (we use it in the MacPerl Makefile, which uses dmake), so that makes it even less likely. There are also multiple .PHONY declarations in perl's Makefile.SH already, including one for the install target, so I imagine it is used on other *make, too. From my generated Makefile on Linux: .PHONY: install install-strip install-all install-verbose install-silent \ no-install install.perl install.man install.html So I dunno what the deal is ... maybe the problem is that .PHONY is a no-op on Mac OS X's make? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
YAPC talk
Just a reminder for anyone who will be there, I'll be giving a Mac::Perl talk at YAPC. Covered will be an overview of the state of perl on Mac OS and Mac OS X; different methods for controlling your Mac OS X environment from perl (including AppleScript, Carbon, Cocoa); MacPerl's place in Mac OS X; and an announcement about MacPerl on Mac OS X that you may not want to miss. Slides will be posted after the talk. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
mac-toolbox
There is a [EMAIL PROTECTED] mailing list. I started it some time ago, for discussion of issues relating to accessing the Mac toolbox(es) from perl. The rationale of a separate list is twofold: * Discussions of the Mac toolbox are not necessarily specific to Mac OS, or Mac OS X * Keep the clutter down in the main macosx list This would effectively kill off the macperl-toolbox list. So, is there any interest in it? If the consensus is no, we want to keep it to the main macosx list, that's fine by me. Thoughts? Apologies if something like this has been discussed before; I've been effectively offline much of this year, being busy with other things. (FWIW, I bring this up now because I am finishing up version 0.01 of Mac::Carbon, which is a port of the MacPerl Mac:: modules to Mac OS X ... more to come later.) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: mac-toolbox
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Jefferson R. Lowrey) wrote: Actually, I wonder where the break-even point is for maintaining a separate 'MacPerl on OS 9/Classic is. At some point in the very near future, if it hasn't happened already, the majority of Macintosh users will be running OS X. MacPerl will still be relevant, as people will be using it from Classic. But it won't be a common experience. MacPerl may die someday, but I won't be the one to send it to its grave. :) Generally the subscribers to the macosx list seem less bothered by off topic posts than the subscribers to the macperl list seem. But that may also change as more of the macperl subscribers move to macosx (or add macosx to their subscriptions). Yes, I will recommend people come to the macosx@ list for most discussions about Mac::Carbon if this is what is decided. As long as people here don't care so much when the MacPerl users invade, that's fine with me. I'll probably just say that people should discuss development and such issues on macosx@, and be free to discuss using it on either macosx@ or macperl@. I suppose this will mean some duplication of effort in answering questions, but I suppose that's better than using a list that most people won't subscribe to. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Mac::Carbon 0.01 Released
Urk, one of the tests (Types/t/Types.t) fails when running under a user that has no Desktop folder (e.g., root). FindFolder(kOnSystemDisk, kDesktopFolderType) is unhappy. Either edit it to another constant that will work (such as kApplicationsFolderType), or run the test with your normal user account. Or, if the only tests that fail are Types/t/Types.t, tests 3-4, then just force install. Oh, and I should have warned one more thing about the test suite ... it plays with your system volume. It can be loud for a few seconds, and quiet for a few more. :) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: BBEdit 7.0
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Adrian Howard) wrote: And CVS support too! Excellent! The CVS support is very cool, too. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: BBEdit 7.0
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (John Siracusa) wrote: On 11/13/02 11:46 AM, Adrian Howard wrote: And CVS support too! Excellent! Hrm, not so excellent for me so far...it just hangs with the connecting dialog box and then fails. CVS works fine from the command line. Maybe BBEdit isn't picking up my CVS environment variables? I thought there'd be someplace to set them in the BBEdit prefs, but I haven't found it yet... The only problem I had like that was when I tried to use CVS with a checkout that had Mac newlines. Oopsie. :) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Sherlock SDK released
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (David Wheeler) wrote: On Wednesday, November 13, 2002, at 09:21 AM, Nathan Torkington wrote: Released today, the Sherlock 3 Software Development Kit, opening Sherlock to 3rd party channel development: http://developer.apple.com/macosx/sherlock/ It's about time! Damn. Once someone writes a search.cpan.org plugin, I might actually have to start using Sherlock... Bah. Use Watson instead. :) Seriously, Watson is faster and has mostly better tools (although that may change now ...). -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
EyeTV + Carbon
Just today, I found my first real need for Mac::Carbon in my daily work,
since I started the port.
I have a review of EyeTV (http://www.elgato.com/eyetv/) on Slashdot
today; while writing it, I was bemoaning the fact that it is hard to
find which EyeTV files are which, as the filenames don't give any clue.
Noting that the files in question are plist files, I set about to
writing a solution this morning, to finish it in time for the review. :-)
The finished product is at http://dev.macperl.org/files/scripts/eyetv
... but the part where Carbon helped me is below. The path to the EyeTV
folder is stored as alias data in the EyeTV prefs, and it needed to be
turned into a path so I could open the directory and look at the files.
So Mac::Files::FindFolder() finds the preferences directory, Mac::Memory
puts the alias data into a memory handle, and Mac::Files::ResolveAlias()
turns it into a path. M, Carbon-licious. Enjoy!
use Mac::Files;
use Mac::Memory;
# ...
if (!$eyetvdir) {
# find proper file from preferences, it's a Base64'd alias,
# so get the data, stick it in a handle, and resolve it
my $prefs = catfile(
FindFolder(kOnSystemDisk, kPreferencesFolderType),
'com.elgato.eyetv.plist'
);
# opens the plist file, gets the data, parses with Mac::PropertyList
my $data = get_plist($prefs);
my $handle = new Handle $data-{value}{'archive folder'}{value};
$eyetvdir = catdir(scalar ResolveAlias($handle), 'EyeTV Archive');
}
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Sherlock SDK released
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Pete Prodoehl) wrote: There is a Mycroft http://mycroft.mozdev.org/ plugin for CPAN I believe... Which should be compatible with Sherlock. That's the old Sherlock. Sherlock 3, new with Jaguar, is completely different. The other ones were just little text files which described how to send and process search forms. Sherlock 3 is web services and JavaScript, and designing a UI rather than just a few text parameters. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: BBEdit 7.0 - Not Impressed
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (_brian_d_foy) wrote: i'll have to see about this CVS tool thing. i'm dubious. It really rocks. It's fairly simple, but it works great. I really only want to do a few things with CVS in my text editor: commit and diff. And both are now a simple key-command away; commit brings up a message window to type in, and diff brings up a list of revisions to diff against (and, of course, takes you to the great BBEdit differences windows to view the diff). I use it for a few other little things, like revision history and checking the status, but the ability to do commit and diff is huge for me. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
RunAppleScript vs. DoAppleScript
Mac::Carbon includes MacPerl.pm, which has some of the same functions as the MacPerl version: primarily convenience functions like SetFileInfo, GetFileInfo, and DoAppleScript. There's a Mac::AppleScript module that has a RunAppleScript, which is mostly like DoAppleScript; the only real difference is in the error value in $@. RunAppleScript outputs errOSAScriptError for every failed compilation (which is a bit unuseful, but I figure it could be changed ... Dan?). DoAppleScript puts the text of the error in there. $ perl -MMacPerl=:all -le 'DoAppleScript (asd); print $@' The variable asd is not defined $ perl -MMac::AppleScript=:all -le 'RunAppleScript(asd); print $@' -1753 $ macerror -1753 Mac OS error -1753: (errOSAScriptError) Anyway, before people started asking, that's the only real difference, that I can see. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: RunAppleScript vs. DoAppleScript
In article a05200f00b9f976d5acfe@[63.120.19.221],
[EMAIL PROTECTED] (Dan Sugalski) wrote:
Apparently there's a bug in Mac::AppleScript that needs fixing. OTOH,
if there's nothing that Mac::AppleScript does that Mac::Carbon
doesn't, then I'm all for tossing its guts and turning it into a
simple wrapper for Mac::Carbon. No point in duplicating the code if
there's no win.
I had thought of that, but I wasn't really sure what your plans were,
and didn't want to speak out of turn. If there is a need or desire for
both, fine; if not, then it makes sense to have only one. I'd not have
even bothered with DoAppleScript, except that it was a part of a module
I needed to port anyway (for SetFileInfo, GetFileInfo, Volumes,
MakePath, and MakeFSSpec), and I wanted to have a single codebase of
that module for MacPerl and Mac::Carbon.
So yeah, a simple wrapper would work:
use MacPerl 'DoAppleScript'; # no need to slurp in all of Mac::Carbon
*RunAppleScript = *DoAppleScript{CODE};
The only caveat is that right now Mac::Carbon is still in development
... and I am not entirely sure if there isn't any other significant
difference between the two functions.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: BBEdit 7.0 - Not Impressed
In article p0530090cb9f97023425e@[192.168.1.104], [EMAIL PROTECTED] (Kee Hinckley) wrote: At 11:29 PM -0500 11/13/02, Chris Nandor wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (_brian_d_foy) wrote: i'll have to see about this CVS tool thing. i'm dubious. It really rocks. It's fairly simple, but it works great. I really only want to do a few things with CVS in my text editor: commit and diff. Local CVS-only, or remote via ssh (with passcode prompting)? It just uses the command line cvs tool, I think. I use it with remote CVS. Mine doesn't prompt for the password, since I have ssh-agent set up, but yeah. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: searching cpan with Chimera (was Re: Sherlock SDK released)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (David Wheeler) wrote: In the location bar. If I understood Ken's post, that's what Omniweb does, and IIRC, Mozilla can do this, too. Yes, I do it in Mozilla. I make a bookmark for the CPAN with this URL: http://search.cpan.org/search?query=%smode=all I then enter cpan in the keyword field for that bookmark's Properties window, and then I can type: cpan Mac::Carbon in the location field. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: locale in carbon emacs (was: OS X Installed numbers (was: mac-toolbox))
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Heather Madrone) wrote: At 09:45 PM 11/14/2002 -0500, Kee Hinckley wrote: Two possibilities. 1. You're used to some version of make which does cpan installs? sudo perl -MCPAN -e shell install xxx I'm used to ActivePerl's ppm, which looks and feels a lot like ftp. No need to make anything. Unix-style makefiles are not common on Windows these days. In fairness, this is because Windows developers/users essentially gave up trying to get stuff to build, and instead distribute prebuilt binaries. We've not yet gotten to that point on Mac OS X, because for the most part, as long as you have the most recent developer tools, it Just Works. More to the point though, if you haven't installed the developer package, you don't have a make at all--that may be your problem. Which developer package would that be? The Developer Tools CD. It comes with standalone copies of Mac OS X, as well as most pro line computers (including the PowerBook). If you don't have it, check /Applications/Installers/. Also, look to http://connect.apple.com/ and get a free ADC account, so you can download all the latest Developer Tools disk images when they are released. I understand part of your frustration, but as far as development goes (sorry, not much that I know of that can be done about network disks not cleanly unmounting; I have similar problems that I learn to deal with in various ways ... sometimes force-relaunching the Finder helps, sometimes not), if you stick with it, I think you'll find it in the end to be more rewarding than Microsoft (unless you really like the GUI development tools that are more scarce on Mac OS X). Good luck, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Darwin darwin or darwin6.0
In article p05100307b9fad2141fb6@[192.168.1.14], [EMAIL PROTECTED] (Doug McNutt) wrote: What is the official name of the operating system under MacOS neXt? darwin. Where does perl get it? Lowercase uname, same as most (but not all) OSes. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Darwin darwin or darwin6.0
In article p05100300b9fc502960d7@[192.168.1.14], [EMAIL PROTECTED] (Doug McNutt) wrote: We are getting somewhere here. I think I have to add code to support MacPerl and perl running under Windoze or DOS. Perhaps Parrot/Perl6 will fix it all up. There's nothing really to fix up. It is what it is; $^O values are arbitrary. There's a default way of getting it, but no standard to abide by. Under perl, you just need to know to use $^O, and what the values are (most of which are listed in perlport.pod). What you basically need to do is figure out how to identify a particular OS in whatever environment you are in. Under most Unixes, you can use uname. Over on the MacPerl list the suggestion is to use Gestalt but I'll bet one can't do that until after the OS is determined somehow. I don't recall that. Someone asked how to get the OS version, which under Mac OS can be done with Gestalt. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: NetInfo (was: migration successful)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Gary Blackburn) wrote: In Mac OS X 10.1.x and earlier, the system was configure to consult the Netinfo database for all directory information...However, in Mac OS X 10.2 (Jaguar), NetInfo functions more as a legacy protocol. Instead of being a major player in the directory services world, NetInfo's role has been reduced to that of the local directory database for machines that are not participating in a network-wide directory, such as Active Directory or OpenLDAP. NetInfo is still present on Mac OS X systems, but you can perform most configuration tasks by editing the standard Unix flat files. Can't speak to how popular or well-regarded NetInfo is, but there you go... the book is a Recommended Title from the Apple Developer Connection, so I'm assuming the authors are speaking the truth... I wouldn't. It sounds like speculation to me. Yes, they have moved to flat files as the defaults for some things, but that doesn't indicate that NetInfo is going away. Note that your Mac OS X user name is not in /etc/passwd in *any* version of Mac OS X, including 10.2. There has been no indication I am aware of that this is changing any time soon. My guess is that wanting to edit /etc/hosts was so common that they simply changed the lookupd order to accomodate the preferences of the greatest number of people (many of us changed the lookupd order on our own in previous versions of Mac OS X), and that this is not a reflection on NetInfo in general. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: unix or mac-style text files?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Wiggins D'Anconia) wrote: There is some discussion of this issue in the docs, check out: perldoc perlport Note that perlport does not discuss this issue -- executing a non-native text file with perl -- at all, really. I guess the real question I have is does Perl on OS X qualify as MacPerl or Unix perl ... I defer to the mac os x experts, but would guess Unix perl. MacPerl is perl for Mac OS. Mac OS X is not Mac OS; they are two different operating systems. perl for Mac OS (MacPerl) uses Mac newlines, perl for Mac OS X (Unix perl) uses Unix newline. But back to the point: there's been some discussion in this threa on workarounds, but my personal feeling is that this is a bug, or at best a broken feature, in perl. Some time ago, the capability was added to perl to recognize and filter CRLF files to work on Unix and LF to work on Windows (grep for PERL_STRICT_CR in toke.c). However, this functionality was not extended to CR files, as it should have been, IMO. OK, so I am a little bitter about it. The last discussion about how to deal with this was on p5p in July: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-07/msg00871.html The bottom line was that it'd be nice to have a PerlIO filter for perl 5.8.x, so that MacPerl can execute Unix and Windows text files, and Mac OS X perl can execute Mac OS text files, etc. Patches are surely welcome! :-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: unix or mac-style text files?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Dan Kogai) wrote: On Monday, Nov 25, 2002, at 01:05 Asia/Tokyo, Chris Nandor wrote: The bottom line was that it'd be nice to have a PerlIO filter for perl 5.8.x, so that MacPerl can execute Unix and Windows text files, and Mac OS X perl can execute Mac OS text files, etc. Patches are surely welcome! :-) One good question may be how to handle newlines in heretext, the only part that really matters because that's the only exception to the fact that newlines are nothing but whitespace from perl compiler's point of view -- oops, shebang is another. When you feed MacPerl *.pl to MacOS X, should linefeeds in heretext emit \015 or \012? I am talking here about taking (for example) a perl program with Mac OS newlines, and making it run under Unix perl. In order for that to happen, you need to translate all the CRs to LFs. That would include the CRs in the heretext, as well as in every literal string. I am not sure which is lazier to simply apply # Any - Unix perl -i.bak -ple 's/\015\012|\015|012/\012/g' *.pl # Any - Mac perl -i.bak -ple 's/\015\012|\015|012/\015/g' *.pl or teach camel the same trick One of the main points of this is that some people will want the same files to be used in more than one context, such as sharing code between Windows and Unix perl over NFS, or sharing code between perl on Mac OS X and MacPerl under Mac OS or Classic. Right now, the only solution is to make copies, as you suggest. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: unix or mac-style text files?
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Slaven Rezic) wrote:
Could this be made even more generic, but translating to \n instead of \012?
Or use source filters:
package Filter::Any2Unix;
Any2Native?
use Filter::Util::Call;
sub import {
if ($^O ne 'MacOS') {
#?
filter_add(sub {
my($status) = filter_read();
if ($status 0) {
s/\015\012|\015|\012/\012/g;
/\n/g ?
}
}
);
}
#?
}
and then call the script with
perl -MFilter::Any2Unix script.pl
or embed use Filter::Any2Unix into the script.
That shouldn't work. By the time you get to it in the script, if you have a
#! line, then the entire script is one long comment, and the use() line
won't ever be executed.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: unix or mac-style text files?
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Heather Madrone) wrote:
At 11:05 AM 11/24/2002 -0500, Chris Nandor wrote:
But back to the point: there's been some discussion in this threa on
workarounds, but my personal feeling is that this is a bug, or at best a
broken feature, in perl. Some time ago, the capability was added to perl to
recognize and filter CRLF files to work on Unix and LF to work on Windows
(grep for PERL_STRICT_CR in toke.c). However, this functionality was not
extended to CR files, as it should have been, IMO.
I think you're right. It's easier to move back and forth from
Windows to Solaris than it is to move from one side of the Mac
house to the other. This is undoubtedly broken, not just in
perl, but on the Macintosh in general.
Well, I'd say it is only broken in perl because there is some support for
it, but it is limited only to certain platforms. Otherwise I'd call it a
woefully missing feature.
I don't think it is, in the general case, broken on the Mac, however. They
can't just abandon CR, and they shouldn't have stuck with CR instead of
moving to LF. And CR itself wasn't broken to begin with. They really
didn't have many options; that is to say, the brokenness we encounter
because of the CR/LF differences are not indicative of a brokenness in the
OS, but just unfortunate confluence of events.
Personally, I think that Apple would be wise to move to the Unix
standard for text files. It would take several releases of
confusion to do it, but that would be better than carrying
forward this schizophrenia to future OS generations.
It has moved to the Unix standard. Many apps, however, have not entirely
made the adjustment.
While they're at it, they might drop file resource forks.
Again, they essentially have. They are still supported because, as with the
CR issue, they cannot just abandon them. But most apps do not have them;
instead, the resource data is in separate files inside the packages. I
don't imagine support for resource forks will be dropped any time soon, but
resource forks aren't really used by new apps.
[pudge@bourque]$ perl -MFile::Find -MMac::Files -e 'find(sub{my $f =
$File::Find::name; return if ! -f || -l; my $catf = FSpGetCatInfo($_);
printf %s : %d\n, $f, $catf-ioFlRLgLen if $catf-ioFlRLgLen}, shift)'
/Applications/
The above one-liner prints out the size of the resource fork in every file
under /Applications/ (ioFlRLgLen is the logical length of the resource fork,
while ioFlLgLen is the logical end of the data fork; the -s file test
operator and other file utilities, in perl and in Unix, only display the
data fork size, so it should always be the case that -s $f ==
$catf-ioFlLgLen).
Out of all my apps in there, I got hits in maybe a dozen or so, and the only
*Apple* apps were iMovie and DVD Player. It's fairly clear that resource
forks are being used less, and I imagine Apple is discouraging their use,
since they are no longer needed.
If Apple doesn't want to give up its own peculiar file formats,
then they ought to fix their Unix so it handles Macintosh files
sensibly.
Apple assumes -- for right or wrong -- that people who use the Unix side of
things will be able to figure out how to deal with the resource forks, the
newlines, etc. (with tools such as CpMac, ditto) Let's face it: the Unix
user side of things is relatively minor in priority to most other things in
the OS. And really, it should be that way: it is used relatively little and
its users are smart enough to figure out workarounds. Life sucks sometimes.
;-)
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Understanding $Config{startperl} in MacPerl
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Ken Williams) wrote:
I see that in MacPerl (not perl for OS X), $Config{startperl} is set to
Perl -Sx \{0}\ {\Parameters\}; Exit {Status}\n#!perl
in Config.pm . I'm not sure what that extra stuff is before the
shebang, but when I run a script that contains that (using
MacPerl 5.6.1), I just get a perl syntax error. When I remove
it, all is well.
Can anyone enlighten about what that first line is for?
As noted, it is essentially like the shebang line in Unix, but for MPW.
You can have it ignored from the command line with perl's -x command-line
switch.
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: CPAN messages
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Phil Dobbin) wrote: I'm getting a simple error message every time I install via CPAN: Scanning cache /Users/phil/.cpan/build for sizes Deleting from cache: /Users/phil/.cpan/build/perl-5.6.1 (31.40.0 MB) Can't make directory /Users/phil/.cpan/build/perl-5.6.1 read+writeable: Operation not permitted at /System/Library/Perl/CPAN.pm line 910 This is a leftover from when I upgraded 5.6.0 - 5.6.1 (and is obviously still left in the build directory) on 10.1.5. Is it just a case of making the directory 0755 and deleting or is there something else to take into account (I've studied CPAN.pm 910 and can't quite make it out)? All other modules are deleted after installation automatically (CPAN 1.63) so any advice welcome :-) You should be safe to delete anything in the build directory. I'd just rm -rf .cpan/build/*. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Process table information
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ken Williams) wrote: I was thinking about working on Proc::ProcessTable to get support for OS X. But after a little effort, it occurred to me that I have no clue how to access process table information. Anyone know this kind of thing, or could tell me what docs to look at? Mac::Processes can give you much of the information you could want. It provides a PSN instead of a PID, but I could add GetProcessPID() and GetProcessForPID() to Mac::Processes, which maps between the two. Take a look at the module and see if there's anything else there you need that it doesn't provide. :-) Let me know, or file a report on SourceForge.net. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Process table information
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Chris Nandor) wrote: Mac::Processes can give you much of the information you could want. It provides a PSN instead of a PID, but I could add GetProcessPID() and GetProcessForPID() to Mac::Processes, which maps between the two. Take a look at the module and see if there's anything else there you need that it doesn't provide. :-) Let me know, or file a report on SourceForge.net. I don't know how much use Mac::Processes will be to you for this, but I went ahead and added the two functions for the next release. I know I've wanted the functionality before. $ perl -MMac::Processes -e '$psn = GetCurrentProcess(); printf %d == %d, %08X == %08X\n, GetProcessPID($psn), $$, $psn, GetProcessForPID($$)' 1862 == 1862, 015A0001 == 015A0001 -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Process table information
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Jerry Levan) wrote: Regrettably sysctl does not give access to table info in the kernel. Source code and commentary: http://developer.apple.com/qa/qa2001/qa1123.html You can get a list of all BSD processes, which includes daemon processes, using the BSD sysctl routine. Code for doing this is shown in Listing 1. When using this code you should note the following. * The returned kinfo_proc structures contain a huge amount of information about the process, including the process ID (in kp_proc.p_pid) and the process name (in kp_proc.p_comm). * As far as BSD is concerned all Classic applications run within a single process. * You do not need any special privileges to make this sysctl; any user can get a list of all processes on the system. * The UNIX Programming FAQ lists a number of alternative ways to do this. Of these, the only approach that works on Mac OS X is exec'ing the ps command line tool. exec'ing ps will require parsing the tool's output and will not use system resources as efficiently as Listing 1. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: unix or mac-style text files?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ken Williams) wrote: I don't think it's really a good idea to translate newlines in string literals (let's lump heretext in with string literals, since that's how they function). That stuff is part of the data of a program, not part of the instruction set. So by doing one mass CR-LF conversion blindly, you'd get the program to run, but it would run differently given the exact same data input. I don't think that's desirable. I disagree. We've been doing this for years on Mac OS without problem. Whenever I unpack a tarball or fetch a file via FTP or HTTP, my programs are doing mass/blind newline conversions on text files. It's long been accepted as the Right Thing, and it only rarely causes problems. And on the contrary, it would cause major problems to do it the other way, not only in terms of effort (Yes, you downloaded the file via FTP as text, and it converted the newlines from Unix to Mac, but you need to go back and convert the newlines in string literals back into Unix newlines), but also in the simple fact that it would rarely be what we want. When you do a here doc, 99.99% of the time you want native newlines in there. The basic tenet is that if you embed an actual newline anywhere at all in your code, it is a logical newline, no matter where it is or what it is doing, and it should be converted to the native format of whatever the target platform is. If you want a literal \012, then you should encode it as \012 or \0xA or \cJ. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
open() a resource fork
Does anyone know how to open a resource fork, with open(), sysopen(), POSIX::open(), etc.? On Mac OS, I would use O_RSRC, but that is apparently not available in Mac OS X's fcntl.h. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: open() a resource fork
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sherm Pendley) wrote: On Thursday, December 5, 2002, at 12:38 PM, Chris Nandor wrote: Does anyone know how to open a resource fork, with open(), sysopen(), POSIX::open(), etc.? On Mac OS, I would use O_RSRC, but that is apparently not available in Mac OS X's fcntl.h. open(filename/rsrc); I tried that. Didn't work. open($rf, filename/rsrc) or die $!; Oh, I see. I need to first create the file, THEN I can open the rsrc fork. D'oh. open($df, filename) or die $!; open($rf, filename/rsrc) or die $!; There we go. Much better than using ResMerger. Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: open() a resource fork
At 13:21 -0500 2002.12.05, Sherm Pendley wrote: On Thursday, December 5, 2002, at 12:38 PM, Chris Nandor wrote: Does anyone know how to open a resource fork, with open(), sysopen(), POSIX::open(), etc.? On Mac OS, I would use O_RSRC, but that is apparently not available in Mac OS X's fcntl.h. open(filename/rsrc); I tried that. Didn't work. open($rf, filename/rsrc) or die $!; Oh, I see. I need to first create the file, THEN I can open the rsrc fork. open($df, filename) or die $!; open($rf, filename/rsrc) or die $!; There we go. Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Apple Perl directory layout
In article a05200f00ba1b3fdd51a7@[63.120.19.221],
[EMAIL PROTECTED] (Dan Sugalski) wrote:
At 1:42 AM -0500 12/10/02, Sherm Pendley wrote:
What's more, unless 100% pure Perl modules were stored in a
version-agnostic location, they would then need to be reinstalled as
well, whereas under the current layout, they can continue to be used
as-is.
FWIW, they generally are.
I don't believe this is true. Usually they are installed in an
*architecture*-agnostic location.
[pudge@yaz pudge]$ perl -e 'printf %s, %vd\n, $^O, $^V'
linux, 5.8.0
[pudge@yaz pudge]$ pmpath MP3::Info
/usr/local/lib/perl5/site_perl/5.6.1/MP3/Info.pm
Then when you configure perl, you can choose to add older version
directories:
[pudge@yaz pudge]$ perl -MConfig -le 'print $Config{inc_version_list}'
5.6.1 5.6.0 5.005
But this won't use the architecture-specific extensions under
site_perl/$version/$arch, only the pure-perl ones found in
site_perl/$version.
[pudge@yaz pudge]$ perl -le 'print join \n, @INC'
/usr/local/lib/perl5/5.8.0/i686-linux
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i686-linux
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl/5.6.0
/usr/local/lib/perl5/site_perl/5.005
/usr/local/lib/perl5/site_perl
.
So I still have access to my old pure perl modules with perl 5.8.0, and my
old versions of perl still have access to their architecture-specific
extensions, and I need to install new versions of those for perl 5.8.0. The
only problem I encounter here is if an old version of perl needs a new
version of a module (architecture-specific or not) that has already been
installed for perl 5.8.0; I need to install it back for each old version
that needs it. But since I rarely use the old versions, this is not a
significant problem.
Everyone's entitiled to their opinion, especially when something is so tied
to personal preference as this is. But the default system as shown above
works well for me, and I find no significant maintenance issues as outlined
by Sherm.
However, I do find little fault with how Apple handles it, as I just prefer
to install my own perl. This is what I've learned to do on Debian Linux
too, as installing your own perl over the system perl can cause havoc with
apt-get etc. There are certainly ways around it, but it's easier just to
install into /usr/local/.
I think the biggest problem with how Apple does it is that it is
nonstandard. Every other platform does it with versions, that I am aware of
(well, except for maybe MacPerl g).
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: closing and opening a browser
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Phil Dobbin) wrote: On 11/12/02 14:06, Chris Nandor [EMAIL PROTECTED] wrote: Mac::Carbon 0.02 is available on the CPAN, and on http://sf.net/projects/macperl/ (where there is also a binary installer, for those of you who have trouble building it, such as those on 10.1.x systems). This is excellent news as I was having a torrid time trying to build Mac::Carbon on 10.1.5/5.6.1. Oh, I should note this will only work with perl 5.6, and installs into /Library/Perl/. It should be fine with 5.6.1, since they are binary compatible, though you might need to move the extensions if you have a different location. It probably won't work with 5.8.0. In the end, if this is still necessary (hopefully not), we can get a more intelligent installer, with selectable location, with binaries for 5.8.0 too, etc. For now it should suffice for most needs. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Test Mac::Carbon build for me?
http://dev.macperl.org/tmp/Mac-Carbon-0.02_01.tar.gz If you have the time, please try this build out, compiling and testing. It's been tested with perl 5.6.0 and gcc2/gcc3 on Mac OS X 10.2, but I imagine it should work with any combination of perl 5.6.0/5.6.1/5.8.0, gcc2/gcc3, and Mac OS X 10.1/10.2. Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Test Mac::Carbon build for me?
At 10:35 +1100 2002.12.13, Ken Williams wrote: Chris, do you know where 'keyReplyPortAttr' is defined? Hm. That's in AEMach.h. This is the workaround I was using to get AESend to work at all on Mac OS X. If that won't work, I wonder if even precompiled binaries will work. To see if it will, use the 0.02 binaries you have installed and try this one-liner: % perl -MMac::AppleEvents -e '$e = AEBuildAppleEvent(qw(misc actv sign MACS -1 0), ); AESend($e, kAEWaitReply); AEDisposeDesc($e)' It should activate the Finder, then the script should exit. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Test Mac::Carbon build for me?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Enrique Terrazas) wrote: I tried installing using cpan (Jaguar 10.2.2, perl 5.8.0) and ran into the following problem: CPAN.pm: Going to build C/CN/CNANDOR/Mac-Carbon-0.02.tar.gz The original message mentioned the version on the web site, which isn't on the CPAN. http://dev.macperl.org/tmp/Mac-Carbon-0.02_01.tar.gz The errors you got were expected with the version you used. Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Test Mac::Carbon build for me?
At 13:57 +1100 2002.12.13, Ken Williams wrote: 0.02 binaries? Where are those available? I only have the 0.01 binaries installed for Mac::Carbon, and it looks like Mac::AppleEvents isn't part of that. Ah. I mentioned them in another post, I think. They are on SourceForge.net (http://sf.net/projects/macperl/). -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Test Mac::Carbon build for me?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ken Williams) wrote: I've been working on the ExtUtils::ParseXS module, which is designed to render this approach obsolete. It's on CPAN right now, maybe it could be used here instead of custom/version-specific xsubpps? The goal is to have One True Version of xsubpp, as a module instead of a script, which works on any [reasonable] platform version of perl. I've started with the xsubpp in bleadperl, and it seems to backport fine to 5.6.0 from my testing so far. That sound interesting, but I haven't the time or energy to put into this at the moment. :) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Test Mac::Carbon build for me?
In article p05200f0dba2013320b77@[192.168.0.2], [EMAIL PROTECTED] (Emmanuel. M. Decarie) wrote: Mac-Carbon-0.02 01 doesn't compile on my machine. I get this error: /usr/include/gcc/darwin/2.95.2/g++/../stdbool.h:10: warning: empty declaration AppleEvents.xs: In function `XS Mac AppleEvents AESend': AppleEvents.xs:624: `keyReplyPortAttr' undeclared (first use in this function) AppleEvents.xs:624: (Each undeclared identifier is reported only once AppleEvents.xs:624: for each function it appears in.) make[1]: *** [AppleEvents.o] Error 1 make: *** [subdirs] Error 2 Could you search your system headers for keyReplyPortAttr? If you can't find it, try (in Carbon.h, or AppleEvents.xs): #define keyReplyPortAttr 'repp' See if that works. Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Test Mac::Carbon build for me?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (David H. Adler) wrote: Test results for os 10.2.2, perl 5.6.0: t/Carbon...## Component Manager: attempting to find symbols in a component alias of type (imdc/MP42/MSFT) ok I am not entirely sure what it is, but some component you are loading is printing this information out, probably to STDERR. I don't know that there's anything I can do about it from Mac::Carbon, and it doesn't affect the tests. MacPerl/t/MacPerl..## Component Manager: attempting to find symbols in a component alias of type (imdc/MP42/MSFT) Use of uninitialized value in pattern match (m//) at blib/lib/MacPerl.pm line 144. Use of uninitialized value in substitution (s///) at blib/lib/MacPerl.pm line 145. Use of uninitialized value in substitution (s///) at blib/lib/MacPerl.pm line 146. # Failed test (MacPerl/t/MacPerl.t at line 88) # got: undef # expected: '3' Hm. I thought maybe this was a problem in 10.1.x, but apparently not, since you're using 10.2.2. Did you run the test from Terminal.app on the local machine? Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Upgrade Mac::Carbon problems
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Jon Boehm) wrote: I had a problem upgrading to Mac::Carbon-0.02 tonight. A) CPAN would not build and install b) AND THE BIGGEST PROBLEM After installing the binary from the MacPerl web I got the following error. dyld: perl Undefined symbols: _Perl_sv_2pv _perl_get_sv Trace/BPT trap It looks like you are using perl 5.8.0. I didn't note in the README that it was for perl 5.6 (the two are not binary compatible). It shouldn't matter in the future, because there's no problem anymore building with perl 5.8.0. See the previous post about 0.02_01, or wait a day or so for 0.03 to be released. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Test Mac::Carbon build for me?
In article p05200f0bba23a385de61@[192.168.0.2], [EMAIL PROTECTED] (Emmanuel. M. Decarie) wrote: À (At) 18:07 -0500 14/12/02, Chris Nandor écrivait (wrote) : Could you search your system headers for keyReplyPortAttr? Hmm, not sure what you are saying here. I just know basic C and I'm not familiar with the Carbon framework. Where are my system headers? I tried that though: % grep -r keyReplyPortAttr /System/Library/Frameworks/* But it take forever to run. If you give me more details, I'll try again. Yes, it could take forever. :-) I am not sure how to better narrow it down, though. Maybe use find(1) to look for *.h files. If you can't find it, try (in Carbon.h, or AppleEvents.xs): #define keyReplyPortAttr 'repp' Ok, in Carbon.h, in the beginning of the file: #ifndef MAC CARBON H #define MAC CARBON H #define keyReplyPortAttr 'repp' See if that works. Well it pass most of the tests (btw, these tests are very funny) Good, and :). t/Carbon..._ComponentCacheableInitialize t/Carbon...ok As noted in a previous post, some Components when initialized or used or something decide to emit text to STDERR (hopefully, it's STDERR, not STDOUT!). I consider this behavior broken on behalf of the component, though I suppose I could be wrong. But you should see this any time you run anything on the command line that loads in components, such as osascript(1). So basically, I don't know I can do anything to quiet that _ComponentCacheableInitialize. MacPerl/t/MacPerl..ok 3/13 ComponentCacheableInitialize Argument 10.1.2 isn't numeric in numeric ge (=) at Fixed for 0.03. MacPerl/t/MacPerl.t line 40. MacPerl/t/MacPerl..ok 10/13# Failed test (MacPerl/t/MacPerl.t at line 88) # got: '2' # expected: '3' MacPerl/t/MacPerl..ok 12/13# Looks like you failed 1 tests of 13. MacPerl/t/MacPerl..dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 11 Failed 1/13 tests, 92.31% okay Weird. Are you sure you clicked Cancel? Processes/t/Processes..ok 2/6 skipped: No parent Odd. You ran this on the local machine from Terminal.app? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: The Inside Macintosh warning still valid for Mac::Carbon?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ken Williams) wrote: In the documentation for modules like Mac::Resources and Mac::Memory, there's always a warning that says I need to look at Inside Macintosh, and reminds me that this has been a Warning. Is the material from IM now part of the documentation in /Developer/Documentation/ ? If so, it would be nice if it were pointed out, as I'm not exactly sure where to look for the docs on a lot of this stuff. It's still valid. I suppose one could append and/or the Carbon documentation and headers. Inside Macintosh is not included in the /Developer/ docs that I know about, but it is far more complete than the Carbon docs, in terms of explaining and covering each function, constant, etc. OTOH, the Carbon docs (and, more importantly, the headers, which are much better than the docs in /Developer/) say what changes / additions / removals have been made to the existing API. Also, it looks like the '=include *.xs' directives didn't get processed for the binary installer of Mac::Carbon 0.02, so some of the docs are missing there too. That's fixed in 0.02_01. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Apple Perl directory layout
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Sherm Pendley) wrote: You were right. The CamelBones framework is linked against libperl, and I've received numerous reports that CB apps continue to work untouched after an upgrade to 5.6.1, which is binary-compatible. An excellent reason to tell people to put perl in /usr/local/ (or similar)! -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Mac::Carbon 0.03 Released
Mac::Carbon 0.03 is on the CPAN (er, on its way there, anyway) and SourceForge.net. http://sf.net/projects/macperl/ http://www.cpan.org/authors/id/C/CN/CNANDOR/ It fixes the bugs with AEDesc, POD, xsubpp, building on Mac OS X 10.1/gcc2/etc. A binary distribution for perl 5.6 is available from SourceForge.net. Thanks to all who have helped, and please submit bugs to SourceForge.net if you have any to report. This is the last release for a little while; I am going to focus on fixing some of the outstanding bugs listed in the documentation. Patches welcome. Enjoy! -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: The dyld dance
At 23:03 -0500 2002.12.25, Sherm Pendley wrote: Oh, and by the way - Merry Christmas everyone. :-) Merry Christmas! -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Fixing font spacing in Terminal.app
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ken Williams) wrote: I suppose it depends on the size of your windows - mine are usually 120 x 40. The annoying extra pixel is probably a rounding error spread over the width of the window, so the exact number will probably vary. I use 120 x 40 too, and had the same problem, also with Monaco 9. Great minds think alike. :-) The funny thing is that I never did find a value (though I played with the plist values) that looked right, so I just learned to live with it, and now it is right, but looks WEIRD! So you broke my Terminal by making it look right, and you can't break Mac::Carbon on Mac OS X 10.1.5 anymore. What good ARE you, anyway? ;-) Thanks, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Fixing font spacing in Terminal.app
In article p05200f01ba40d474013f@[192.168.123.100], [EMAIL PROTECTED] (Heather Madrone) wrote: OTOH, I stuck Perl 5.8 in /usr/local, and I've had no difficulty with it whatsoever. Yay! -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: dumb 802.11g question
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Drieux) wrote: since apple has announced it's new 802.11g initiative with it's 17 laptop - does this mean that they will not be working on any of the 802.11a options of going into the 5Ghz range so as to avoid the 2.4gHz spread spectrum first generation phones Steve Jobs essentially ridiculed 802.11a in his talk, because it is not compatible with 802.11b, so I highly doubt Apple has any plans to do 802.11a. I like the idea of 54Mbps, but if I can't use it in conjunction with my telephone Then you get a new telephone! ;-) I've never had any problems with my AirPort or my 2.4 GHz phone, but as always, YMMV. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: perl-5.8.0 and Fink
In article p05200011ba422983e2ec@[128.84.209.12], [EMAIL PROTECTED] (Ray Zimmerman) wrote: Nevermind ... looks like the answer is in the archives at ... http:[EMAIL PROTECTED]/msg02447.html Where can a find a searchable version of the archives? I use Google. For example: http://www.google.com/search?q=site%3Aarchive.develooper.com+dyld+symbols -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: dmg of perl 5.8.0 on Mac OS X
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Nathan Torkington) wrote: Please download and test the perl 5.8.0 distribution available from: http://nathan.torkington.com/tmp/perl5.8.0gnat1.dmg It installs Perl, Berkeley DB 4.1.25, DB_File 1.42 and Time::HiRes 1.42 into /usr/local/perl5-8. You'll need to add /usr/local/perl5-8/bin to your path, probably in your .cshrc. Be warned: it's a 12M download. With the help of Fink, I managed to totally trash my system. I reinstalled yesterday, and went through the hassle of building Perl 5.8.0 all over again. I figured I'd save other folks that hassle. Now, who is going to do a dmg of Apache / mod_perl / libapreq? :-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Mac OS X client and #perl
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Ask Bjoern Hansen) wrote: [EMAIL PROTECTED] (Brad Hughes) writes: Semi-off topic... What IRC client are people here using, and which IRC servers do perl folk inhabit? sirc - http://www.iagora.com/~espel/sirc/sirc.html (and rhizomatic; now also on irc.perl.org) I use ircle. Also rhizo. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: a folder of file system questions
In article p05200f3cba67470bba32@[192.168.254.205], [EMAIL PROTECTED] (Rich Morin) wrote: Actually, it may well be a moot point. Not that many files are sparse, so the number of bytes is a reasonable indication of the number of blocks. It's just that I'd rather have the individual block count for each fork. BTW, I'd be happy to see a bit more information about ..namedfork. Google only found a few references, including Inside Mac OS X: Performance, which says: Although Apple recommends moving resources into data files in the application package Resources directory, it is possible to access the resource fork of a file on an HFS Plus volume by adding the suffix:/..namedfork/rsrc to the end of the file pathname. Because this doesn't work on other file systems, notably UFS, and because it requires you to parse the resource fork structure directly, this technique is not recommended. Nat notes in reply to me, in message http:[EMAIL PROTECTED]/msg04257.html : From /usr/include/sys/paths.h: * Provides support for system wide forks */ #define _PATH_FORKSPECIFIER/..namedfork/ #define _PATH_DATANAME data #define _PATH_RSRCNAME rsrc #define _PATH_RSRCFORKSPEC /..namedfork/rsrc Not much else to it, really. My interest is that I'd like to think about storing metadata with files. I think I need to take a closer look at the relevant modules. I knew Chris had been porting some of Matthias's MacPerl libraries over to OSX; looks like I may get a chance to use some of them... Just be sure to read the README and POD in Carbon.pm for some background and other implementation info, as well as bugs etc. It's not exactly the same. In re: what Apple said about resources in data forks, I just got a bug report the other day about the fact that right now Mac::Resources can't handle resources in a data fork; while this isn't technically a bug (I think ...), it is something I wished it could do already, just in testing, so I want to come back to that at some point. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Installing Slash (dyld errors)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Christian Schneider) wrote: I am trying to install Slash on Mac OS X with Perl 5.8.0. I can configure, make, install everything without problems and Apache/mod_perl seems to work fine. I cannot, however, use the Slash installation. To be precise, I cannot use Slash::Apache::User. With DYLD_PRINT_LIBRARIES turned on, I get the following output from Perl: Slash::Apache::User requires some of the mod_perl symbols, and can only run under mod_perl. This is normally not a problem, except when you go to rebuild the module, at which point Apache::ExtUtils tries to eval the module, and perl segfaults. On other platforms, it fails and puts the error in $@. I patched Apache::ExtUtils locally to not do the eval; I am not sure what the Right Thing to do is. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Fink sets PERL5LIB
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Nathan Torkington) wrote: If you use Fink to install something that has a Perl module component, Fink's /sw/bin/init.csh will set the PERL5LIB environment variable when you next log in. This screws with @INC if you have your own Perl installed--you'll see Dylib messages everything you try to do something that involves a Perl module with an XS component. The easiest fix is to specifically unset PERL5LIB in your .cshrc after the sourcing: source /sw/bin/init.csh unsetenv PERL5LIB This is probably what messed with my head last week. Yes, I've been doing this in my .bash_profile since I installed perl 5.8.0. Not a great solution, but no big deal (once you realize the problem and how to fix it :-). -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: dmg of perl 5.8.0 on Mac OS X
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Nathan Torkington) wrote:
I'm not entirely sure. I think that a previous 5.8 install overwrote
some of the 5.5 library (doing a 'configure.gnu --prefix=/blah' still
made 5.8 install crap into /Library).
hints/darwin.sh overrides the defaults. I want everything in /usr/local/,
though, so this is what I do to mine, for Mac OS X:
[pudge@bourque hints]$ diff -u darwin.sh.orig darwin.sh
--- darwin.sh.orig Thu Jul 18 01:42:44 2002
+++ darwin.sh Wed Feb 19 19:53:46 2003
@@ -7,31 +7,7 @@
# Paths
##
-# BSD paths
-case $prefix in
-'')
- # Default install; use non-system directories
- prefix='/usr/local'; # Built-in perl uses /usr
- siteprefix='/usr/local';
- vendorprefix='/usr/local'; usevendorprefix='define';
-
- # Where to put modules.
- privlib='/Library/Perl'; # Built-in perl uses /System/Library/Perl
- sitelib='/Library/Perl';
- vendorlib='/Network/Library/Perl';
- ;;
-'/usr')
- # We are building/replacing the built-in perl
- siteprefix='/usr/local';
- vendorprefix='/usr/local'; usevendorprefix='define';
-
- # Where to put modules.
- privlib='/System/Library/Perl';
- sitelib='/Library/Perl';
- vendorlib='/Network/Library/Perl';
- ;;
-esac
-
+prefix='/usr/local';
# 4BSD uses ${prefix}/share/man, not ${prefix}/man.
man1dir=${prefix}/share/man/man1;
man3dir=${prefix}/share/man/man3;
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: dmg of perl 5.8.0 on Mac OS X
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Puneet Kishor) wrote: fwiw, I am using 10.2.3... I don't have wget. I could be wrong, but I remember something to the effect that wget is not only deprecated in favor of curl but also abolished. As usaul, I culd be wrong. wget was removed from Mac OS X, but it, itself, is not deprecated or abolished, and you can install it via fink. I believe the issue is primarily of Apple wanting to use non-GPL equivalents when possible; but OTOH, I think curl is a little nicer to use, so it might merely be that. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Rendezvous in Perl
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Nathan Torkington) wrote: My friend Rael was wondering where the Perl implementation of Rendezvous (zeroconf) is. How do I register my service? How do I browse for local machines and services? Download Rendzevous source from Apple's Public Source site. Run SWIG on it. Enjoy. ;-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Rendezvous in Perl
At 17:11 -0700 2003.02.24, Nathan Torkington wrote: Chris Nandor writes: Download Rendzevous source from Apple's Public Source site. Run SWIG on it. Enjoy. ;-) That isn't very portable beyond OS X :-) No, Apple's zeroconf implementation there is open source and builds on several different platforms. http://developer.apple.com/darwin/projects/rendezvous/ Rendezous.tar.gz has source for Mac OS X, Mac OS, Windows, Solaris, Linux, Open BSD. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
New Mac::Carbon Release, Tests Needed
Now that I have my new system of managing my software in place (using URL:http://rt.cpan.org/ for bugs, URL:http://projects.pudge.net/ for central location of links, URL:http://sf.net/projects/pudge/ for CVS and file downloads, and URL:http://search.cpan.org/~petdance/release to simplify the distribution process), I am moving forward again with development. Mac::Carbon and MP3::Info have had long-awaited releases (Mac::Carbon includes some bugfixes, a lot more constants for Mac::Files, some additions to Mac::Speech from Peter N Lewis, and the fix for AppleEvents' Makefile.PL for the Dec Dev Tools). So now I am just about ready to release the first port of Mac::OSA::Simple to Mac OS X (as soon as I finish up the tests for it). The changes were minor: a newline issue (OSA scripts are returned by the decompile API with CRs for newlines!) and an issue to work around an open bug in Mac::Carbon (the file routines fail for nonexistent files). When that is released, I'll do some work on porting Mac::AppleEvents::Simple. Mac::Carbon could really use some more tests, especially for Mac::Files. Volunteers? :-) Other modules needing tests are Mac::MoreFiles and Mac::Resources. Mac::Sound, Mac::Processes, and Mac::Components have some tests, but could use more. Coordinate with me if you are interested. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Mac::OSA::Simple 1.03 Released
Mac::OSA::Simple is now updated to work with Mac OS X, using Mac::Carbon.
It has some minor fixes that also apply to MacPerl.
Mac::OSA::Simple provides simple access to Mac::OSA. At its most basic
level, it provides an applescript(SCRIPT) function for compiling and
executing an AppleScript, and returning the result, just like
MacPerl::DoAppleScript(SCRIPT).
But OSA is not just AppleScript; there is also the osa_script(COMP, SCRIPT)
function for executing arbitrary OSA scripts, such as with the OSAShell
component and the JavaScript component.
$x = osa_sscript('Shll', 'ls');
$y = `ls`;
# $x eq $y;
OK, maybe that is not extraordinarily useful, but it's just an example. :-)
Also, Mac::OSA::Simple allows compiling of a script into a Perl object,
which can then be executed, saved, and decompiled, with
compile_applescript() and compile_osa_script().
$script = compile_applescript('tell app Finder to activate');
$script-save(annoyingscript);
print $script-source, \n;
$script-execute, sleep 2 while 1; # ha ha ha
And you can load scripts, either from the filesystem, or from an script in
memory:
$script2 = load_osa_script(annoyingscript);
$script3 = load_osa_script($script2-compiled);
This works with any compiled AppleScript/OSA script, not just those created
by Mac::OSA::Simple.
Example of when to use Mac::OSA::Simple instead of DoAppleScript():
# slow
MacPerl::DoAppleScript('tell app iTunes to pause');
# fast
$pause_script = load_osa_script($pause_path);
$pause_script-execute;
Coming next is a port of Mac::AppleEvents::Simple to Mac OS X.
Also note the new address of my Perl modules:
http://projects.pudge.net/
And I am still entertaining volunteer efforts for tests for Mac::Carbon.
:) Contact me if you want to help.
Enjoy,
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: A Wheeler by anyother name...
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Randal L. Schwartz) wrote: I'm also offended that you cc'ed my private email to the list when my reply to you was private. Technically, that's a copyright violation, and I could take you to court over that. It technically isn't, as it is clearly fair use; and you could sue, but you'd likely lose. You don't make fun of a man's name. Period. That is your opinion, it is not a rule, and stating it as a rule doesn't make it one. Your Jedi mind tricks won't work on us, no matter how much you use the Schwartz. Oops. :) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
DynaLoader and prebinding
So I have this problem: Mac::Carbon takes a long time to load. $ time perl -Iblib/arch -Iblib/lib -MMac::Carbon -e1 real0m2.923s user0m2.570s sys 0m0.160s Profiling the run showed that over 80% of that time is taken by dyld, so I wondered if prebinding could solve the problem. However, perl uses .bundle files for DynaLoader, and .bundle files cannot be prebound. Drat. But .dylib files can be prebound, and I was able to modify DynaLoader.xs to load in either .bundle or .dylib files, and to compile my extensions as .dylib files. Woop. But I am having problems with the prebinding. I first had to rebuild libperl.dylib with prebinding, and that worked fine (just added -prebind). Woop woop. I added -prebind to my extension, and it complained that you can't use -undefined suppress with -prebind. Remove -undefined suppress, and got warnings about undefined symbols. Go figure. So I added -L/path/to/perl -lperl, and did it again, and I got complaints about conflicting symbols. ld: warning prebinding disabled because of symbols overridden in dependent dynamic shared libraries: /usr/lib/libSystem.dylib(crypt.So) definition of _crypt /usr/lib/libcrypto.0.9.dylib(fcrypt.o) definition of _crypt Drat drat. Anyway, I know there are perhaps better places to ask about dylib and prebinding, but I just wonder if anyone else has run into these issues with perl, before I move on. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Perl grep from AppleScript
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Christopher Stone) wrote: I used to use the RegEx osax for a huge number of tasks, but it hasn't been ported to X nor will it ever be. So, that being the case I have to break down and learn Perl... :) This rank newbie needs a template for using perl grep from AppleScript. FWIW: you use grep in perl to loop over the elements of a list, performing some action (usually matching) against each one, and returning the ones that match. So you probably don't mean grep here. What I want to do is provide input from an AppleScript variable; grab the pattern I want with perl; and output to an AppleScript variable. do shell script perl -e '$x = shift; $x =~ /(.pat.)/; print $1' spatter spatt Hope that helps, -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacPerl] Re: problem with Japanese text
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Robin) wrote: MacPerl per se historically has not been aware of locale outside of ascii defined ones (not sure about the latest version). Which is why of course there is MacJPerl. http://world.std.com/~habilis/macjperl Is there a reason for MacJPerl when MacPerl 5.8.x is released? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacPerl] Re: problem with Japanese text
At 13:52 +0900 2003.03.27, Dan Kogai wrote: I wonder how many of you have ever tried 5.8 features such as Encode and PerlIO in MacPerl (besides make test, of course). I don't even lauch Classic these days... Give me some examples to run and I can give it a shot. :) My greatest reason to run Classic is for Mac::Glue programs. I have everything I need for Mac::Glue ported, though, so I expect that to change soon after I get back from vacation (I'll get to work on Mac::Glue after a new release of Mac::Carbon, plus Mac::Apps::Launch and Mac::AppleEvents::Simple, and probably a Bundle::Mac::Carbon ...). But I still plan on releasing MacPerl 5.8.x, which is mostly all there and working now (I did a test build of the latest code a week or so ago). -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Another shell/GUI cooperation script
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Ken Williams) wrote:
Chris, would it be fun/possible to convert all that applescript to perl?
Yep. Note that currently you cannot tell an object in Mac::Glue, but no
big deal; that is just syntactic sugar. You'll see that apart from that, it
is basically a line-by-line translation of syntax, using the same words but
in Perl.
use Mac::Glue ':all';
my $mail = new Mac::Glue 'Mail';
my $msg = $mail-make( new = 'outgoing message' );
$mail-set( $mail-prop( visible = $msg ), to = gTrue() );
my $last_char = $mail-obj( character = gLast(), of = content = $msg );
$mail-make(
new = 'attachment',
at = location( after = $last_char ),
with_properties = {
file_name = /etc/motd
}
);
$mail-activate;
The most difficult thing is to know what it means, for example, to tell
newMessage to set visible to true. In this case, it means the same as set
visible of newMessage to true, where visible is a property, so we
prop(visible = $msg), to = gTrue(). Yay fun.
See similar fun with the location insertion record for after last character
of content of message (the extra of in the perl is because content is a
property and not an object ... at some point I want to get rid of that extra
verbiage, which should be possible).
See the Mac::Glue POD for more details.
Of course, this currently works only in MacPerl (but the script above does,
in fact, work from MacPerl in Classic to control Mail.app). But as noted
before, I am working to finish porting it all to work under Mac OS X, and
most of the pieces are in place, I just need to find the time to finish it
all up. Before summer. :)
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacOS X] consider useshrplib='false' by default
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Dan Kogai) wrote: That's a great work but with all due respect I do not think making XS prebindable a good idea. Correct me if I am wrong but my understanding on prebinding is that it is a technique that makes dynamic libraries behave like static ones by predetermining ALL ADDRESSES IN NEED A PRIORI. Yes, I am not convinced prebinding is the best thing for XS. However, there may be other benefits to using -dynamiclib, and someone may have a good reason to use prebinding in the future, so I figure ... might as well include the option in DynaLoader, if it doesn't hurt anything, since DynaLoader is core and it is hard to add it later. :-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Mac::Carbon 0.50 Released
Some new features of general interest: * Ability to open resource files in data forks with FSOpenResourceFile() * Ability to find paths to applications based on bundle ID, creator type, or app name with LSFindApplicationForInfo() * Addition of Mac::InternetConfig, to look up and set IC information, Get URLs (e.g., GetURL($url) will open the URL in your app of choice), etc. Some important bugfixes are included as well, including the ability of FSp* routines to accept pathnames for files that don't exist. A full test suite for Mac::Files was added as well (with more extensions to go). I'll be posting some journal entries about this release of Mac::Carbon at http://use.perl.org/~pudge/journal this week, time permitting. The ports of Mac::Apps::Launch, Mac::AppleEvents::Simple, and -- yes! -- Mac::Glue are basically done, with this release of Mac::Carbon, and are being prepared for release. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: copy files with everything?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Berndt Wischnewski) wrote: simple question, how can I copy file type, creator and icon along with a file. #!/usr/bin/perl use File::Copy; copy(/private/var/root/Desktop/xxx/test1.doc, /private/var/root/Desktop/yyy/test2.doc); copies just the file, but the resulting test2.doc has lost the icon, file type and creator. I think there must be a way, which I simply dont now. File::Copy uses FSpFileCopy() for Mac OS: Mac::MoreFiles::FSpFileCopy($from, $dir, $toname, 1); Works on Mac OS X too; just install Mac::Carbon. use Mac::MoreFiles; FSpFileCopy(/private/var/root/Desktop/xxx/test1.doc, /private/var/root/Desktop/yyy/, test2.doc, 1); -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: [MacOS X] consider useshrplib='false' by default
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Dan Kogai) wrote:
As you see ${ldflags} is injected into $lddlflags but in case of
-prebind we need to avoid that. $ldflags is for perl linking while
$lddlflags is for XS. Since -prebind and -bundle are mutually
exclusive, we do not want -prebind in $lddlflags (though CC on darwin
is smart enough to ignore -prebind when -bundle, it still issues
warnings and I don't want to see that warning for each XS gets built).
Another question is whether to use something other than bundle for XS, to
allow prebinding. I have a patch to dl_dyld.xs that seems to work; it
allows both bundle and dyld (thanks to some pointers from wsanchez).
--- dl_dyld.xs.orig Wed Jun 4 06:57:32 2003
+++ dl_dyld.xs.new Wed Jun 4 06:57:21 2003
@@ -109,14 +109,22 @@
NSModule handle = NULL;
dyld_result = NSCreateObjectFileImageFromFile(path, ofile);
-if (dyld_result != NSObjectFileImageSuccess)
- TranslateError(path, OFImage, dyld_result);
-else
+if (dyld_result == NSObjectFileImageSuccess)
{
// NSLinkModule will cause the run to abort on any link error's
// not very friendly but the error recovery functionality is limited.
handle = NSLinkModule(ofile, path, TRUE);
NSDestroyObjectFileImage(ofile);
+}
+else if ((dyld_result == NSObjectFileImageFormat ||
+ dyld_result == NSObjectFileImageInappropriateFile)
+ NSAddLibrary(path) == TRUE)
+{
+ handle = (NSModule)(void *)-1;
+}
+else
+{
+ TranslateError(path, OFImage, dyld_result);
}
return handle;
Then, instead of using -bundle, I used -dynamiclib. However, when I tried
to add -prebind I got a bunch of errors, and then I ran out of time to mess
with it. :-) But perhaps worth:
1. doublechecking my work :)
2. including it in perl's DynaLoader as an option for XS developers, even if
-bundle is still the default
--
Chris Nandor [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Perl for Panther
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Edward Moy) wrote: Yes, I'd have to agree with Rich that Apple would be hesitant about a Panther server farm with unrestricted access. But if a reasonably secure proposal can be made, I can try to sell it to the higher ups. Would not Darwin 7 be suitable for most of the related purposes? -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: DropScript confusion about cwd
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Chip Howland) wrote: At 1:10 AM +0900 7/11/03, Robin wrote: But if I have to have a double clickable perl script I prefer using the '.command' technique because I really believe Apple should just go ahead and use Perl as the scripting language and put AppleScript to bed along with OS9 Well, that's flat-out ridiculous. Perl is HARD compared to Applescript. That is a matter of opinion. Here's an Applescript tutorial: Open the Script Editor Type display dialog Hello, world. Run the script and here's a Perl tutorial: [snip way too many lines of tutorial, apparently intended to make perl look a lot harder than it is] Here is what, perhaps, you meant: Open BBEdit Type print Hello, world. Run the script HAND. HTH. Now that you've mastered Perl and Applescript, it should be trivial to use either language to create a script that extracts information from a FileMaker database and places it into a QuarkXPress template, then imports images into the document from a remote server, applies the appropriate style sheets to the text, prints the document on a color printer, exports the document as a PDF, saves the text as an HTML file, then opens the HTML file in BBEdit. Yes, quite. A snippet: use Mac::Glue; my $fm = new Mac::Glue 'FileMaker Pro'; $fm-obj(file = $file)-open; # get fields my @fields = $fm-prop(name = fields = database = 1)-get; # get records where second cell isn't empty my @data = $fm-obj(records = whose(NOT = [cell = 2, equals = '']), database = 1 )-get; etc. Or did you intend to mean that manipulating data in AppleScript was hard? If you find this difficult to accomplish in Perl I don't. :-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: DropScript confusion about cwd
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Chip Howland) wrote: At 10:29 AM -0700 7/11/03, Chris Nandor wrote: and here's a Perl tutorial: [snip way too many lines of tutorial, apparently intended to make perl look a lot harder than it is] Here is what, perhaps, you meant: Open BBEdit Type print Hello, world. Run the script Yes, that's one way to run a Perl script, but Apple doesn't bundle BBEdit with OS X. I wasn't trying to make Perl look harder than it is. I was illustrating the baseline of knowledge you need to get started. Oh, come now. Even if you wanted to do the bundled with Mac OS X thing, it could have been as simple as: Open Terminal Type perl -e 'print Hello, world.\n' Hit enter You did not go through how to save scripts in Script Editor, which was part of what you did for the Perl example. You did not discuss differences between compiled scripts, applications, and source text. etc. I think you might be a special case. Not everyone has written Mac::Glue or maintained MacPerl. If you are claiming that you can do everything with Perl and Mac::Glue that you can with Applescript, then I won't dispute you. But don't pretend it's just as easy for a novice. As long as you don't pretend that AppleScript is easy for a novice, I won't pretend that Perl is. I am an expert of sorts, and I find AppleScript very difficult to use. YMMV, of course. I do concede -- for the record! -- that AppleScript is easier to figure out than Mac::Glue, for finding out what works and what doesn't. I even use Script Editor when I am figuring out what to use in Mac::Glue, sometimes, if I get stuck. But AppleScript is MUCH more difficult -- for me -- in pretty much *everything else*. And since once I know how to do something controlling an app in AppleScript, it is pretty simple to convert to Mac::Glue (while the opposite is not true: knowing how to do something handling data or flow control etc. in Perl provides no instruction for AppleScript), it makes a lot of sense to use Mac::Glue, if you know Perl. Yes, there is a learning curve, but what gets me is when people assert that AppleScript is easy for some reason. I just don't see it. And if you already know AppleScript well, the learning curve for Mac::Glue is tiny (mostly a matter of modifying syntax). OK, I admit, I've gone off on a tangent from the original yes Perl can do that onto Mac::Glue r00lZ!, but I just released it for Mac OS X recently and I haven't talked about it much on this list since then. :-) I wish I had cross-posted my original reply to MACSCPT so we could have a proper flamewar. Oh yeah, that's a GREAT idea. ;-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
