Re: [MacPerl] MacPerl and OS X (yet again :-)

[Joel Rees <joel_rees@sannet.ne.jp>]

>>1) What is the newline character under OS X?
>
>Same as regular Unix, LF (\012, \x0A).
>
>While under Mac OS, I copied text files from my Mac OS startup disk to my
>Mac OS X disk, drag and drop.  Then I needed to run `perl -pi.bak -e
>'s/\015/\012/g' *.PL` to fix them.  I don't know of a "solution" to this
>problem.  It might be nice to have a special drag modifier key that would
>convert text files appropriately (as well as a special argument to cp).

Adding options to cp is probably not a good idea. Better to write your 
own cp with newline filtering options. Or, better still, just save the 
one-liner Chris mentions here as a script (say, newlnfilter) and pipe I/O 
that needs to be filtered through your brand-new filter:

     % cat source.pl | newlnfilter > target.pl

Which points out the killer problem (killer solution waiting to be found) 
hidden behind the excitement about scripting. With true scripting, 
program options don't have to be added. The desired effects can be 
achieved by external filter programs. Non-algebraically minded users tend 
to blur the distinction between option and filter, but that's no big 
deal. (Well, maybe it's a pride issue for some engineers and 
theoreticians like myself about ten years ago.)

We have not yet found a general way to shove filters into the input and 
output streams in GUI environments. This problem seems like a corollary 
to the problem of a general method for passing parameters to programs in 
GUI, which has still not been solved. (There are some context-specific 
solutions to both problems.)

While we are hunting for the solution, we just remember that newlines are 
less a system feature than an application feature in a system context. 
But I'm preaching to the choir.

>Also note: perl 5.6 comes with Mac OS X Beta, but there is no perldoc,
>pod2man, etc.  Of course, there are no compilers or other build tools,
>either (yet; I understand they will be made available).

I wonder why. I see lots of pods and manpages about perl. The source code 
should be easy enough to compile. License issues? 

>>2) I deleted a rambling discourse on this; so to say it briefly,

(So now we can all ramble with you. Thanks.)

>>anyone who has run Perl under Windows knows why MacPerl is so
>>wonderful.  Developing short little scripts in the simple integrated
>>MacPerl environment is quick, easy, and intuitive.  Droplets fit
>>nicely into both the Perl and Macintosh paradigms.  Unless MacOS X
>>eliminates drag and drop, point and click as the primary interface, I
>>see just as much a need for the MacPerl application under OS X as
>>under OS 1-9 (sez he who still has a copy of OS 1).  It seems to me
>>this is entirely separate from the whole issue of porting the
>>interpreter per se; the application consists of the basic interpreter
>>plus a simple, intuitive development environment plus the droplet
>>code.  OS X may change how best to port the interpreter, but it seems
>>to me that the development environment and the droplet code are as
>>useful as ever.  Am I missing something?
>
>Well, I see little or no need for the MacPerl application.  As for
>droplets, well, they would be pretty simple to create in Mac OS X.  Now,
>here is the bad news: I made a perl script executable (chmod a+x), but it
>appears as a text file.  This is Bad.  However, I imagine it would be
>mostly trivial to create an executable wrapper for the script, just like
>the current droplet code, which would send the script and the dropped
>contents to /usr/bin/perl instead of MacPerl.

Ahh! I see you have run into one of the walls between UNIX and Mac. While 
you would not want chmod to mess with the actual contents of the file, 
you might hope that the system commands for UNIX would influence the Mac 
side's interpretation of a file. But this would basically require the Mac 
OS version of chmod to build the underlying package structure around the 
file being converted to executable, move the file down in the directory 
structure, and generate an alias in the file's original position.

If I say it this way, do we all see why we might prefer a new tool to 
build a package around the script file, maybe even have the tool 
optionally chmod the file for us, if it doesn't complicate the tool too 
much? This tool does exist, I think. Look it up under the key word 
"package".

>>3) Is it anticipated that all web serving and CGI programming will be
>>done in an essentially Unix environment?  Will the need for "save as
>>CGI script" have past?
>
>I imagine so.

I tend to think we will still want the "save as CGI" option, but what it 
does will be rather different.

>>4) Will the AppleEvents interapplication interface be entirely
>>replaced by a Unix stdin/stdout interface?
>
>No.  Take Internet Explorer, for example.  It is a Carbon or Cocoa app
>(which is it, and how does one tell?  I dunno), yet it has no STDIN/STDOUT.
>I should be able to talk to it with Apple events (though I haven't yet
>tried, or figured out how :-).

Until we learn how to mix events and text in a pipe, we will continue to 
need AppleEvents.

>5) Is this the right place for MacOS X/MacPerl questions?  If not, where?

I myself would vote against a new forum, at least for now. There are 
newsgroups and lists that you might want to get on. Some of them require 
you to at join the developers association (on-line only is free) and sign 
the non-disclosure agreement. Woops, that's backwards. I mean, sign the 
NDA and join the ADC.


Joel Rees
---------------------------
joel_rees@sannet.ne.jp
http://www.page.sannet.ne.jp/joel_rees


# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org