Re: Installable packages
On Friday, September 6, 2002, at 11:54 PM, ellem wrote: > On Thursday, September 5, 2002, at 10:12 , Ken Williams wrote: > > Snip > >> * Installer for 5.6.1 >> * Installer for 5.6.0 >> * Installer for 5.8.0 > > Snip > > Maybe a _really_ useful thing would be" > > * Installer for Apple's Perl > > So we can all get back to square one > > (Seriously, as long as you're doing it.) That's exactly what the 5.6.0 installation is. I just extracted it from the Apple Installer CDs. -Ken
Slow file upload in 10.2
After updating to Mac OS 10.2, I've noticed that my perl file uploads (using HTTP::Request::Common) have slowed down by a lot. Using tcpdump, I see that there is a long delay before the first packet is sent. Playing around with file sizes, I found a very strong file-size dependence: File Size Time till first packet 15M 4 sec 17M 76 sec 19M 180 sec 24M 555 sec This is the test code: #!/usr/bin/perl use HTTP::Request::Common; use LWP::UserAgent; my $ua = LWP::UserAgent->new(); $ua->timeout(60*10); $response = $ua->request(POST 'http://my_url_', Content_type => 'form-data', Content => [ upload_file => ['my_big_file...'] ]. ); print $response->content; That 24M file, which used to take a minute or two, now takes over nine minutes before the upload even starts. I just tried updating my perl installation to 5.8.0, but that didn't help. At this point, I don't know if this is a perl problem or not. -- gc
Re: DropScript recursive processing
At 12:05 pm +1000 6/9/02, Shannon Murdoch wrote:
>Thanks for the help so far guys, I've got a much better picture of what's
>going on now!
>
>Does the @ARGV array contain the full paths to the file, or just their names
>(ie, do the files HAVE to be in the same directory as the dropscript?)
The full paths. To verify this, make a droplet using this script and
drop a few files on it. A file will open listing the pathnames of
the files.
#!/usr/bin/perl
$report = 'report.txt' ;
open REPORT, ">$report" ;
for (@ARGV) {
print REPORT "$_\n";
}
`open $report` ; # shell command
This script will do more, but only drop small things...
#!/usr/bin/perl
$report = 'report.txt' ;
open REPORT, ">$report" ;
for (<>) {print REPORT "$_\n";}
`open $report` ;
JD
Re: installing a module
On Friday, September 6, 2002, at 12:08 PM, [EMAIL PROTECTED] wrote: > i am new to mac's X and its perl. I have a few modules from cpan i have > to install, but the good old perl Makefile.PL make make test make > install > won't work, is this thure ? This should work. However, if you have CPAN modules with XS in them -- that have C code -- then you'll need to install the Mac OS X developer tools. You can get these for a free registration at http://developer.apple.com/. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
installing a module
Hi List, i am new to mac's X and its perl. I have a few modules from cpan i have to install, but the good old perl Makefile.PL make make test make install won't work, is this thure ? how to get modules work/compaile on a mac ? thanx kris
Re: Perl compiling and caching
At 7:33 AM -0500 9/6/02, Puneet Kishor wrote: >a basic question for which I could not determine a definitive answer... > >I understand that Perl compiles the scripts and then runs them. Does >it also cache the compiled versions? Nope. It's compile-and-go, fresh each time. Generally speaking compilation time's not that significant relative to runtime. Perl 6 will have an optional separate compilation phase, but it's rather a ways off. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Installable packages
On Fri, 6 Sep 2002, Ken Williams wrote: > I notice that there's an application > /Developer/Applications/PackageMaker.app that can create > installable OS X packages. If people would find it useful, I > could make a couple of packages for installing perl and put them > in my CPAN directory (and probably the ports/ directory too?). > The following things could be useful: > > * Installer for 5.6.1 > * Installer for 5.6.0 > * Installer for 5.8.0 Where does it put Perl? IMNSHO, replacing the System perl is not a good idea. Why? Because it is Apple's perl; any internal tool will depend on the built-in perl. Only Apple should update the system perl, because only Apple can test to see that nothing is broken, or fix what does break. So, a second copy of Perl gets installed, your copy, with its own @INC directories, etc. You can update it as often and as quickly as you want. If you need your perl, you put the right #!/path/to/my/perl at the beginning of whatever script you are writing. Ideally, Apple would, like Sun in Solaris 8, make /usr/bin/perl just a symlink to their internal perl. The system scripts would all call the actual binary in /usr/perl5/bin, and we could redirect the symlink in /usr/bin to our second copy of perl, wherever it may be. For BSD to ditch Perl just to avoid these problems, to me, is silly. I think somebody just wanted to brush up on their shell scripting, and prove a point. -- MattLangford
Re: Installable packages
On 6/9/02 03:12, "Ken Williams" <[EMAIL PROTECTED]> wrote: > Would there need to be separate versions of these for > pre-Jaguarian and post-Jaguarian systems? I wouldn't think so... 10.1.x and 10.2 use different versions of the Developer Tools is the only thing I can think of. I can check my Project Builder digests for any compatibility differences if you like (there are a few I know of for sure but that is in compiling carbon/cocoa apps with the respective versions). Regards, Phil.
Perl compiling and caching
a basic question for which I could not determine a definitive answer... I understand that Perl compiles the scripts and then runs them. Does it also cache the compiled versions? Perhaps comparing timedate stamps? If so, where is this cache of compiled scripts stored? Is there a way to modify properties of this cache, like say increase its size, or force flush it, etc.? I am not using mod_perl... I understand mod_perl does caching, which, if one doesn't understand well, can lead to strange looking behavior. No, my above questions relate to just stock 5.6.1 either from the terminal or as a cgi via the browser. many tia, pk/
Re: Installable packages
On Friday, September 6, 2002, at 12:06 AM, Scott R. Godin wrote: > On Thu, 05 Sep 2002 22:26:39 -0400, Puneet Kishor wrote: > >> yes Please! I know I would love a installer for 561. I went through a >> great amount of heart-burn upgrading my stock 560 to 561 and have >> everything running. Except, tomorrow I'm gonna get my copy of Jagwyre >> and that will put the kibosh on everything. I will definitely want to >> get back up to 561 (not 580 yet as no use for it... probably wait until >> 581 comes out). > > Insofar as I am aware, 5.8.0 is literally THE most-tested release of > perl > TO DATE. Why wait for a 5.8.1 that may never come (or may take months)? > > Have there been any 5.8.0 horror-stories ? Anyone got URL's ? > no, no horror stories that I know of... just that there is a module I depend on that is built using swig, and methinks swig doesn't yet work well with 5.8.0. Once that module works well with 5.8.0 I will upgrade too... until then I will continue with 5.6.1. My needs are not too exotic, and most things I have dreamed of till now have been happily fulfilled with 5.6.1. Thanks, pk/
Re: DropScript recursive processing
Thanks for the help so far guys, I've got a much better picture of what's
going on now!
Does the @ARGV array contain the full paths to the file, or just their names
(ie, do the files HAVE to be in the same directory as the dropscript?)
Cheers,
-Shannon
On 6/9/02 12:51 AM, in article p05200809b99d1b83553c@[158.152.20.126], "John
Delacour" <[EMAIL PROTECTED]> wrote:
> Suppose you have a perl script "test.pl" as below saved with UNIX
> line endings in your user directory, and in the same directory you
> have three text files "a.txt", "b.txt", "c.txt" ...
>
> #!/usr/bin/perl
> foreach $file (@ARGV){
> open FILE, $file;
> print ;
> }
