Re: [MacPerl] What's Latest MacPerl

[Richard Gordon <maccgi@bellsouth.net>]

At 08:28 -0400 07/20/1999, Chris Nandor wrote:
> >I've forgotten why, but it seems like I  used to use a clumsy resedit
> >hack to run multiple copies of the same app as separate processes
> >even under System 7.
>
>Just make physical copies of the app, and run them.

I think that what I was doing before involved using multiple copies 
of FoxPro on a single machine and they had to be renamed & given 
bogus creator codes in order to keep AppleScript from getting 
confused about which copy was supposed to be doing what. Eventually, 
it seems like this system was retired and a single server copy was 
used by multiple AppleScript clients on the network, but program 
linking had to be enabled and the application itself had to be 
locked. I wonder if the MacPerl interpreter would tolerate something 
like that?

>
> >Would this kind of thing make it possible (if
> >not especially practical) to run concurrent scripts that had hacked
> >creator codes to reference correspondingly hacked copies of MacPerl
> >(MacPerl, MacPerl1, MacPerl2, etc.)?
>
>I run multiple versions of MacPerl all the time.  This is not a very robust
>solution, however.

I suppose that you could also just save different scripts as runtime 
files and then call them from a master script as needed? In other 
words, if you had a lot of text files on a server and wanted to use 
MacPerl to back them up every night (which it's pretty good for, BTW) 
while concurrently scanning the server for some other maintenance 
reason like generating a report of files created during that day, you 
could get both running at once from within another script?

>If you are really interested in this kind of thing, macperl-porters
>discusses it every once in awhile.  Last month I posted a note about a
>discussion I had with Dick Hardt, where he described the plans for an
>in-process fork() in Win32 perl.  Basically, if you have threads and
>multiplicity, you should be able to use their work to get an in-process
>fork().  MacPerl already has multiplicty, and has had it for some time
>(this is what allows you to keep the same MacPerl program running and
>executing multiple Perl programs without restarting the app).  So when
>GUSI2 is done, and MacPerl is updated to the latest perl (merging the
>sources with perl proper), MacPerl could get threads, and a fork() for not
>much extra work on our (erm, Matthias') part.  At least, that is the hope.
>
>The kicker here is that this work for the in-process fork() is being funded
>by Microsoft.  :D

I was just curious. Will Matthias' library be used to essentially 
bypass the Mac thread manager then or is it still dependent on it? As 
far as MS goes, if their efforts inadvertently spill over and produce 
something unexpectedly useful to anyone other than Chairman Bill, 
that's great.


Richard Gordon
--------------------
Gordon Consulting & Design
Database Design/Scripting Languages
mailto:richard@richardgordon.net
http://www.richardgordon.net
770.971.6887 (voice)
770.216.1829 (fax)

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