MacPerl-Digest V1 #10

[owner-macperl-digest@macperl.org (MacPerl-Digest)]

MacPerl-Digest         Friday, March 12 1999         Volume 01 : Number 010



[MacPerl] AppleScript front end to MacPerl
Re: [MacPerl] Elementary question (I think)
Re: [MacPerl] XML

----------------------------------------------------------------------

Date: Fri, 12 Mar 1999 07:59:24 +0000
From: "Jay Bedsole" <rwdd30@email.sps.mot.com>
Subject: [MacPerl] AppleScript front end to MacPerl

I'm not sure how many people might be interested in this, but
here goes... A friend of mine recently installed MacPerl and
was complaining about the lack of a CLI... I explained the way
I handle user interfaces in MacPerl, but he was relatively
unimpressed... then I remembered an AppleScript snippet that
Chris Nandor posted a few months back and thought, "Hey, maybe
I could modify that to make a semi-useful front end to MacPerl."

So, since I knew basically nil about AppleScript, I dived right
in! This is my first attempt at AppleScript and it turned out
to be a bit more complex than I planned... What resulted is an
AppleScript application I call cli4mp.

What it does, in a nutshell is:

  (1) The user drops a perl script on the cli4mp icon.
  (2) cli4mp puts up a dialog prompting for the command
      line arguments.
  (3) cli4mp tells MacPerl to execute the dropped perl
      script passing the command line as arguments.
  (4) MacPerl does whatever your script tells it to with
      the ARGV list.

However, it's not quite that simplistic. First, cli4mp passes
most characters to MacPerl indiscriminately, but there are a
few exceptions.

  (1) Space characters are the argument delimiters and are not
      passed unless quoted.
  (2) The backslash (\) is the quote character and forces the
      next immediate character to be inserted into an argument.
  (3) There are two special characters that behave sort of as
      directives.

          (a) The Option-f character (which prints as a script-
              like f) tells cli4mp to request a file from the
              user with a StandardFile dialog.
              If the Option-f is followed immediately by an
              asterisk (*), cli4mp will ask for multiple files.
              This is my least favorite part of the user interface,
              but I couldn't figure out how to manage it
              differently...

          (b) The Option-d character (which prints as a delta)
              tells cli4mp to request a folder from the user with
              a StandardFile dialog.
              If the Option-d is followed immediately by an
              asterisk (*), cli4mp will ask for multiple folders.

These directives simply cause the files and folders that are
selected to be inserted into the ARGV list as paths... just as
if you had typed them. Because of the way I've implemented the
directives, you cannot enter arguments that consist only of
Option-f, Option-d, Option-f followed by an asterisk, or
Option-d followed by an asterisk. However these characters and
character pairs can occur in any other context... You can even
select files whose names are the same as the four un-enter-able
arguments by using the file/folder selection directives... Hope
that wasn't too confusing.

To demonstrate/test cli4mp, I used the following simple (2 line)
perl script as a target:

#!perl
foreach my $arg (@ARGV) { print "arg: $arg\n"; }


When I drag this perl script onto cli4mp, I get a dialog box
prompting for the arguments. With the following input typed into
the dialog box:

  -sw \one MyDisk:Documents:Dummy\ File \\two /abc/xyz/ \\\

I get the following output from MacPerl:

    arg: -sw
    arg: one
    arg: MyDisk:Documents:Dummy File
    arg: \two
    arg: /abc/xyz/
    arg: \

Unfortunately, the Option-f and Option-d characters don't go
through email very smoothly, so I'll ask you to use your
imagination for this next example. Pretend that the 'f' is
the Option-f and 'd' is the Option-d; then for the following
command line:

  one f two d three f* hot d* cold new\ f

I get the following output:

    arg: one
    arg: MyDisk:Documents:File1
    arg: two
    arg: MyDisk:Documents:Dir1
    arg: three
    arg: MyDisk:Documents:File2
    arg: MyDisk:Documents:Dir1:File3
    arg: hot
    arg: MyDisk:Documents:Dir2
    arg: MyDisk:Documents:Dir2:Dir3
    arg: MyDisk:Documents:Dir2:Dir3:Dir4
    arg: cold
    arg: new f
             |
             +-- Where the f is really Option-f...

All of the paths were selected via StandardFile dialogs.

Important Note:
In the loops where you can select multiple files or folders,
each path item is selected individually with it's own
instantiation of a StandardFile dialog. Hitting the "Cancel"
button ends the loop with the previously selected path item.
I know this kinda sucks, but what else can I do?


What's it good for? Well, aside from letting me get my feet wet
with a little AppleScripting, I admit it's uses may be limited.
I think it might be useful for beginning MacPerlers who may be
used to CLI interfaces to perl on other platforms. It should let
them run their scripts unmodified in many cases. It could also
be useful for scripts that take arguments other than file and
directory paths (such as switches, regular expressions, key
words, etc.).

What's missing, that you would find in other CLIs? Globbing and
other CLI substitutions, for one thing. I didn't find a simple
way to do this in the 3 or 4 hours that I spent on this, and
really... ya' gotta draw the line somewhere! Maybe in a later
revision, if someone points me in the right direction. There are
probably other common CLI features that are missing, and I'm
just too backwards to know about 'em...

Well, that's about it except for the code itself... and here's
where I had a dilemma. It contains characters that aren't in the
7-bit ASCII character set and thus the code can't be posted as
plain text and get mailed reliably (as I mentioned earlier). I
thought about tacking it on the end of this message as a mime
attachment, but then thought better of it. I don't currently have
a web site that can be accessed from the real world... Also, this
message was already starting to border on the ridiculously long...
So, I thought I'd ask how best to distribute. Should I:

  (1) Send it to interested parties upon request?
  (2) Post it to the list as a mime attachment?
  (3) Send it to someone who wants to post it on a web site?
  (4) Some other infinitely more brilliant idea?
  (5) Shove it where the sun don't shine...
      'cause, buddy, no one really cares?

Sorry for the length of this message.

cheers,
jay

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

------------------------------

Date: Fri, 12 Mar 1999 09:09:30 +0000
From: Chris Sansom <chris@highway57.co.uk>
Subject: Re: [MacPerl] Elementary question (I think)

Hi all

...and boy, was I right to 'think' that! Duh! Here I've been merrily coding
away doing some - though I say it myself - quite sophisticated stuff - and
I'd never taken in that @stuff is the number of elements in the array while
$#stuff is the index of the last element!

Many thanks to all those who have pointed this out and put me on the road
to enlightenment - especially Chris Nandor, Bart Lateur Ronald, J. Kimball
and Dave Lorand... and no, I'm not using tied array... and no, I haven't
changed $[... so I could use '$i < @stuff' in place of my '$i <= $#stuff'
or even the 'for my $i (0 .. $#stuff)' construct with impunity.

Many thanks again, everyone!

 Cheers ... Chris
 ======================================================================
 Chris Sansom    -    Highway 57   -   Designs for the World Wide Web |
 chris@highway57.co.uk                     http://www.highway57.co.uk |
 ======================================================================



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

------------------------------

Date: Fri, 12 Mar 1999 06:47:12 -0400 (AST)
From: Arved Sandstrom <Arved_37@chebucto.ns.ca>
Subject: Re: [MacPerl] XML

On Thu, 11 Mar 1999, w e b s l a v e wrote:

> Hello, I've been off the list for a while, can someone clue me into
> where MacPerl is with regards XML? (and the XML Parser and Expat?)

There was a recent posting related to this. To summarize, however,
XML-Parser-2.20 is built as a binary and available from
<http://pudge.net/mmp>.

All other XML modules I have tested, which is basically the complete set,
work fine. This includes XML::DOM, XML::XQL, XML::Dumper, XML::Generator,
XML::Grove and CGI::XMLForm.

There are two caveats for MacPerl use - one is MacOS specific and one is
more general.

(1) MacOS specific: methods such as toString() for DOM, or str() in
XML::XQL::Debug, return (correctly) strings containing \xA characters for
line-ends. There is  decent chance that XML::Parser behaviour will be
modified to permit such methods to return \n instead, but this will have
to wait for 2.21 at the earliest. As a result, when you pull a string out
and want to print it, or compare it to original (Mac) content, translate
\xA to \n.

(2) RAM: this is a major consideration probably on all OS's, and quite
possibly a factor for other implementations of XML API's. DOM is the big
offender here. As soon as you start using XML::DOM and/or XML::XQL,
consider giving MacPerl 15-20 MB minimum.

An app I'm working on produced an XML index of the most recent 160
MkLinux-Setup mailing list digests (*index*, mind you, not the digests
themselves), which ran to 500kB of disk space using MacOS Extended FS.
MacPerl used the better part (~90%) of 30 megs of RAM to produce an
XML::DOM object out of this. This is an example.

There are obvious ways out of this, which are good XML practise anyhow.
Examine the structure of your document collection, and use indexes, and if
necessary, indexes of indexes. Make heavy use of general entity refs, and
parse XML documents on demand. Ballpark the largest XML filesize that your
system can comfortably handle as a  DOM object, and split files up as
required. Etc etc etc. A lot of this is not just Perl - if you were using
TclDOM or Java DOM implementations, you would still be facing the same
issues.

Hope this helps. I just signed on to CPAN testers last night, so I will be
uploading a batch of test reports once very week or 2 weeks. I hope to
have a formal set of test reports for the XML modules in the first batch.
NOTE: all the XML modules work fine - frequently their *tests* don't. :-)

Arved Sandstrom



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

------------------------------

End of MacPerl-Digest V1 #10
****************************


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