Re: [MacPerl] Perl Shared Library (was Re: [MacPerl] ports and builds)

["William H. Asquith" <asquith@macconnect.com>]

Wow this is a long topic (over a week now).

I agree with David.  The Python Tk port for MacOS looks really good.  I is
fun to play with, but Python simply does not allow power and flexability of
Perl, nor does it have the extensive user base, TPJ, and numerous books on
the subject.  How about a MacPerl Tk port?  The multiplatform perspective is
extremely important in my office.  I want to put a new G3 or G4 on my office
desk this year (seeded with my own money as we're not a Mac shop--just so I
can thumb the NT crowd and have the coolest looking desktop ever.)  If I can
do daily work and development on Mac and then run on an NT or Solaris 2.6
that is a huge win for me and Apple.  Because of OS-X in the future, is this
a reason that someone hasn't ported Tk to MacPerl--the demand will just dry
up next year?

I have tried out the Wish Tcl/Tk route as suggested by many of you last
month, but just doesn't quite cut the cake.  Thanks for all your help
though.  I'm now trying install Tk on MachTen 4.1.1, but having some
trouble, which is for another newgroup.

-wha

William H. Asquith, Hydrologist/Civil Engineer
U.S. Geological Survey
http://www.usgs.gov/

----------
>From: David Steffen <steffen@biomedcomp.com>
>To: mac-perl@iis.ee.ethz.ch
>Subject: Re: [MacPerl] Perl Shared Library (was Re: [MacPerl] ports and
builds)
>Date: Sun, Jan 24, 1999, 9:40 AM
>

> Thanks to all of you for your thoughts!  Given that MacPerl has a future
> well past the introduction of OS X,  I'd like to respond to the invaluable
> Chris Nandor:
>
>>I think that the fact that a MacPerl standalone app is
>>source-readable makes it unsuited to shrinkwrapped applications anyway,
>>since piracy is a no-brainer.  But for the same type of application, sure.
>>While MacPerl is not ready for writing a BBEdit clone now, it may be in a
>>few years.  I took "target" not as where MacPerl currently is, but where it
>>is headed.  And in the future, for writing a full-fledged large
>>application, I say, "why not?".
>
> Well, let me interpret "why not" in terms of what is not now in MacPerl
> that would need to be added before this could come to pass (IMVHO):
>
> 1) Distribution.  Both current alternatives of requiring a separate install
> of MacPerl and the current Standalone application have problems which would
> significantly reduce the attractiveness of BBEdit in MacPerl.  This really
> brings us back to the original topic of this thread.  I have seen proposals
> but no consensus on this point.
>
> 2) Portability.  (This is unfair, because BBEdit AFAIK is a Mac only
> product, but in my domain of biomedical software, this would be an issue.)
> Most of the developers in this area write for Unix, and users are split
> about 50:50 between MacOS and Windows.  My very preliminary experiments
> suggest to me that Python has solved this fairly well by supporting Tk on
> Mac (and reportedly on Windows).    In my community, I think the ability to
> write one program that would run with little or no modification under Unix,
> MacOS, and Windows would be a major win.
>
> 3) Ability to run multiple programs.  This brings me to a question: the
> Perl5.005-based MacPerl which will support multiple threading:  will this
> allow one script to spawn multiple threads, and/or one interpreter to run
> multiple scripts?  The latter is what is required to solve this problem,
> and incidentally the CGI problem as well.
>
> THANKS!
>
> -David-
>
> David Steffen, Ph.D.
> President, Biomedical Computing, Inc. <http://www.biomedcomp.com/>
> Phone: (713) 610-9770 FAX: (713) 610-9769 E-mail: steffen@biomedcomp.com
>
>
>
> ***** Want to unsubscribe from this list?
> ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch
> 

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch