Re: Cron Progress Bar in OSX
James Reynolds wrote Thu, 9 Oct 2003 08:38:24 -0600: I have been writing an extremely lightweight Cocoa utility (10 lines of code about) that displays a dialog box with a barber pole and some message. It isn't quite done yet (I don't like the way it looks). It is intended to be launched by a perl script. I would be very interested in giving that a try on a 'test-bed' basis if that appeals to you. Alan
Re: Cron Progress Bar in OSX
Doug McNutt wrote Thu, 9 Oct 2003 05:40:58 -0600: At 10:46 +0100 10/9/03, Alan Fry wrote: I have a MacPerl script I am trying to transfer from OS9 to OSX. There are two problems: cron cron needs to point, with a full path, to an executable, That is, something with the x permission bit set. That can be /usr/bin/perl with arguments pointing to a perl script as text or it can be to the script itself if it begins with a #!/usr/bin/perl line and has been made executable with a chmod. Remember that your .login and other initializations, $PATH in particular, will not be set up for you by cron. cron can open an AppleScript APPL (man open) but if all it is used for is to start up MacPerl you won't need it. Except for GUI things that involve Finder like drag and drop you'll be better off replicating the AppleScript tasks in a shell script. Osascript is available for simple AppleScript-like things from a shell. Many thanks Doug for your comments, which I have carefully filed against the day I shall understand what you're saying. My personal problem is total ignorance of Unix and all its manifold works. I have a learning curve to negotiate, to say the least. At the moment I am merely chipping away like Fred Flintstone at a paleolithic Terminal window, getting nowhere fast. What I miss most is the MacPerl droplet, on which you could drop a file, extract the path (into ARGV) and do something with the file. For instance I have a droplet to decode Base64 -- drop and bingo there is the decoded file. And similarly with more complicated issues like translating a 'pod' file to 'pdf'. Is there anyway one can get back to this functionality in MacOS X? Experiments with AppleScript have not been rewarding. Sure, you can write an applet which will extract the full path name from a file dropped on it. But the path is the old Mac-style colon separated directory path. What can you do with that? Even assuming you could translate the Mac-style path to a Unix-style path (in AppleScript!), how can you pass the path to a Perl script? I have tried telling application Terminal to do a perl script pushing a valid path into @ARGV and then to run a second perl script to see what is in the ARGV list. The answer is always nothing. So I am stuck -- wondering if things might perhaps be more cheerful with WinPerl? Can anybody cheer me up? Alan
Re: Cron Progress Bar in OSX
At 12:03 +0100 10/13/03, Alan Fry wrote: What I miss most is the MacPerl droplet, on which you could drop a file, extract the path (into ARGV) and do something with the file. For instance I have a droplet to decode Base64 -- drop and bingo there is the decoded file. I do use AppleScript for that kind of thing. I'll try to find some samples for you. In the meantime check this out. It is a droplet to replace line ends in dropped files but ignore that and have a look at the source. ftp://ftp.macnauchtan.com/Software/LineEnds/ ftp://ftp.macnauchtan.com/Software/LineEnds/FixEndsFolder.sit (52 kB) It's not perl but it does show a way to make AS droplets pass filenames and arguments to executable shell tools. You should also learn about POSIX path of and quoted form of commands in AS. And similarly with more complicated issues like translating a 'pod' file to 'pdf'. Wasn't that corncob great? I changed the creator code of all .pm's to match, but all that is repaired in OS neXt.. Can anybody cheer me up? -- Applescript syntax is like English spelling: Roughly, but not thoroughly, thought through.
Re: Cron Progress Bar in OSX
One of my personal favorites is to use a here document to supply the code
for an applescript via osascript. i.e.
---
#!/bin/perl -w
use strict;
use IPC::Open3;
my $script = 'APPLESCRIPT';
tell application Finder
display dialog Hello World
end tell
APPLESCRIPT
# using a here document can mess with the debugger line numbering,
# so include a line comment for it
#line 15
local *script_to;
local *script_from;
local *script_error;
my $pid = open3(*script_to, *script_from, *script_error,
/usr/bin/osascript) or die Couldn't open osascript;
print script_to $script;
close script_to;
while (script_from)
{
print result: $_\n;
}
close script_from;
while (script_error)
{
print error: $_\n;
}
close script_error;
--
On 10/13/03 6:58 AM, Doug McNutt [EMAIL PROTECTED] wrote:
I do use AppleScript for that kind of thing. I'll try to find some samples for
you.
Re: Cron Progress Bar in OSX
FWIW, you can pop up progress bars from perl, though it does require turning the perl program into a Cocoa app with Sherm's CamelBones framework. (I think the Mac::Carbon module(s?) may do this as well, but you may or may not still have to turn the program into an application) You can fire full-scale .apps off via cron--just dig through the bundle and find the real executable, and use its full pathname. (No relative paths, and no invocations via PATH env vars. Cocoa does *not* like that) For example, to fire off emacs which is living in /Applications you'd just invoke /Applications/Emacs.app/Contents/MacOS/Emacs. You can even pass in parameters, which'll show in @ARGV for perl programs. I suppose it'd be possible to build a progress app that took test-style output (you know, the 18 tests, ok 1, ok 2 stuff) from the child process and did the progress bar while the child did its thing and spat its status info to its stdout... Dan
Re: Cron Progress Bar in OSX
Doug McNutt wrote Thu, 9 Oct 2003 05:40:58 -0600: At 10:46 +0100 10/9/03, Alan Fry wrote: I have a MacPerl script I am trying to transfer from OS9 to OSX. There are two problems: cron cron needs to point, with a full path, to an executable, That is, something with the x permission bit set. That can be /usr/bin/perl with arguments pointing to a perl script as text or it can be to the script itself if it begins with a #!/usr/bin/perl line and has been made executable with a chmod. Remember that your .login and other initializations, $PATH in particular, will not be set up for you by cron. cron can open an AppleScript APPL (man open) but if all it is used for is to start up MacPerl you won't need it. Except for GUI things that involve Finder like drag and drop you'll be better off replicating the AppleScript tasks in a shell script. Osascript is available for simple AppleScript-like things from a shell. Many thanks Doug for your comments, which I have carefully filed against the day I shall understand what you're saying. My personal problem is total ignorance of Unix and all its manifold works. I have a learning curve to negotiate, to say the least. At the moment I am merely chipping away like Fred Flintstone at a paleolithic Terminal window, getting nowhere fast. What I miss most is the MacPerl droplet, on which you could drop a file, extract the path (into ARGV) and do something with the file. For instance I have a droplet to decode Base64 -- drop and bingo there is the decoded file. And similarly with more complicated issues like translating a 'pod' file to 'pdf'. Is there anyway one can get back to this functionality in MacOS X? Experiments with AppleScript have not been rewarding. Sure, you can write an applet which will extract the full path name from a file dropped on it. But the path is the old Mac-style colon separated directory path. What can you do with that? Even assuming you could translate the Mac-style path to a Unix-style path (in AppleScript!), how can you pass the path to a Perl script? I have tried telling application Terminal to do a perl script pushing a valid path into @ARGV and then to run a second perl script to see what is in the ARGV list. The answer is always nothing. This is one way to do it: on open these_items repeat with this_item in these_items set the_path to POSIX path of this_item set result to do shell script /Users/james/backatcha.pl \ the_path \ display dialog result end repeat end open Save as an application. And /Users/james/backatcha.pl is: #!/usr/bin/perl print I got: $ARGV[0]; -- Thanks, James Reynolds University of Utah Student Computing Labs [EMAIL PROTECTED] 801-585-9811
Re: Cron Progress Bar in OSX
At 9:00 am -0600 13/10/03, James Reynolds wrote: This is one way to do it: on open these_items repeat with this_item in these_items set the_path to POSIX path of this_item set result to do shell script /Users/james/backatcha.pl \ the_path \ This will break if there happens to be a in the pathname. 'quoted form of' POSIX path of... takes care of all that. What is needed is perl some.pl f1 f2 f3 f4 so only one Apple event is needed; the file list can be build as a string and passed with a single do shell script call. JD
Re: Cron Progress Bar in OSX
FWIW, you can pop up progress bars from perl, though it does require turning the perl program into a Cocoa app with Sherm's CamelBones framework. (I think the Mac::Carbon module(s?) may do this as well, but you may or may not still have to turn the program into an application) You can fire full-scale .apps off via cron--just dig through the bundle and find the real executable, and use its full pathname. (No relative paths, and no invocations via PATH env vars. Cocoa does *not* like that) For example, to fire off emacs which is living in /Applications you'd just invoke /Applications/Emacs.app/Contents/MacOS/Emacs. You can even pass in parameters, which'll show in @ARGV for perl programs. I suppose it'd be possible to build a progress app that took test-style output (you know, the 18 tests, ok 1, ok 2 stuff) from the child process and did the progress bar while the child did its thing and spat its status info to its stdout... Dan http://www.ihook.org I'm working on a similar app but is less functional so that it launches faster. -- Thanks, James Reynolds University of Utah Student Computing Labs [EMAIL PROTECTED] 801-585-9811
Re: Cron Progress Bar in OSX
On 10/13/2003 06:03 AM, Alan Fry [EMAIL PROTECTED] wrote: Doug McNutt wrote Thu, 9 Oct 2003 05:40:58 -0600: What I miss most is the MacPerl droplet, on which you could drop a file, extract the path (into ARGV) and do something with the file. For instance I have a droplet to decode Base64 -- drop and bingo there is the decoded file. And similarly with more complicated issues like translating a 'pod' file to 'pdf'. Is there anyway one can get back to this functionality in MacOS X? ... Can anybody cheer me up? Alan DropScript Don't have an url, but I'm sure you can find it in Version Tracker. Cheer Up! Riccardo -- mailto:perotti(at)pobox.com http://www.riccardoperotti.com
Weird math...
I've got a script that takes numbers similar to those below and then rounds them and adds them together using code similar to what is below. #!/usr/bin/perl -w use strict; my $item_1 = 1.655; my $item_2 = 1.755; my $rnd_1 = (sprintf qq~%.2f~, $item_1); my $rnd_2 = (sprintf qq~%.2f~, $item_2); print $rnd_1, $rnd_2; The code above prints this result (system 10.1.5, perl 5.6.0): 1.66, 1.75 But shouldn't it be: 1.66, 1.76 or: 1.65, 1.75 I'm no math wizard, so if someone could please take the time and tell what I'm missing here I would very much appreciate it! -- Bill Stephenson www.PerlHelp.com 1-417-546-5593
Re: Weird math...
On Mon, 13 Oct 2003, Bill Stephenson wrote: I've got a script that takes numbers similar to those below and then rounds them and adds them together using code similar to what is below. [snip] The code above prints this result (system 10.1.5, perl 5.6.0): 1.66, 1.75 But shouldn't it be: 1.66, 1.76 or: 1.65, 1.75 I'm no math wizard, so if someone could please take the time and tell what I'm missing here I would very much appreciate it! Welcome to the wonderful world of inexact representations. You're getting bitten by some fundamental issues with floating point representations of numbers. Floating point fractions are base 2, so they can't properly represent anything that's not base 2. (And, since our decimal fractions are base 10, that can be a lot of 'em) There's more explanation in the perl faq, along with some workarounds. Dan
Re: Weird math...
on 10/13/03 1:56 PM, Dan Sugalski at [EMAIL PROTECTED] wrote: Welcome to the wonderful world of inexact representations. snip Thank you!! I'll read up on this today, and hopefully the workarounds will suffice for my customers. -- Bill Stephenson www.PerlHelp.com 1-417-546-5593
Re: Weird math...
At 03:24 PM 10/13/2003, Bill Stephenson wrote: on 10/13/03 1:56 PM, Dan Sugalski at [EMAIL PROTECTED] wrote: Welcome to the wonderful world of inexact representations. snip Thank you!! I'll read up on this today, and hopefully the workarounds will suffice for my customers. Have you seen this paper? David Goldberg, What Every Computer Scientist Should Know About Floating-Point Arithmetic ACM Computing Surveys, Vol 23, No 1, March 1991. Available (among other places) at: http://docs.sun.com/source/806-3568/ncg_goldberg.html Also, there's Guy Steele, Jr. Jon White, How to Print Floating-Point Numbers Accurately, Conference on Programming Language Design and Implementation, Proceedings of the ACM SIGPLAN 1990 conference on Programming language design and implementation. http://www.acm.org/pubs/citations/proceedings/pldi/93542/p112-steele/ (I don't know if it's available free anywhere. Sorry.) That's my 2.001 cents. --Shawn
Re: Cron Progress Bar in OSX
At 9:00 am -0600 13/10/03, James Reynolds wrote:
This is one way to do it:
on open these_items
repeat with this_item in these_items
set the_path to POSIX path of this_item
set result to do shell script
/Users/james/backatcha.pl \ the_path \
This will break if there happens to be a in the pathname. 'quoted
form of' POSIX path of... takes care of all that.
What is needed is perl some.pl f1 f2 f3 f4 so only one Apple event
is needed; the file list can be build as a string and passed with a
single do shell script call.
JD
How about:
on open these_items
set args to
repeat with this_item in these_items
set args to args quoted form of POSIX path of this_item
end repeat
set result to do shell script /Users/james/backatcha.pl args
display dialog result
end open
Save as an application.
And /Users/james/backatcha.pl is:
#!/usr/bin/perl
foreach $i (@ARGV) {
print I got: $i\n;
}
--
Thanks,
James Reynolds
University of Utah
Student Computing Labs
[EMAIL PROTECTED]
801-585-9811
Re: Cron Progress Bar in OSX
At 9:00 am -0600 13/10/03, James Reynolds wrote: This is one way to do it: on open these_items repeat with this_item in these_items set the_path to POSIX path of this_item set result to do shell script /Users/james/backatcha.pl \ the_path \ display dialog result end repeat end open Save as an application. And /Users/james/backatcha.pl is: #!/usr/bin/perl print I got: $ARGV[0]; Thank you very much for that suggestion -- it is just the sort of thing I was hoping for. But I have a bug somewhere -- just a simple AS do shell script /Users/alanfry/Desktop/backatcha.pl results in the error: ...backatcha.pl:perl:bad interpreter:Permission denied The script runs fine from the Terminal with the command 'perl' however. What am I missing? Alan
Re: Weird math... (once more)
Here is a little Perl routine that shows exactly what is going on.
#!/usr/bin/perl -w
$bigtwo = 2**32;
while ($a = DATA) {
$b = (sprintf %.0f, $a * $bigtwo)/$bigtwo;
$up_or_down = $b = $a ? round up : round down;
print $a $up_or_down\n;
}
__END__
1.655
1.755
The output of this script is
1.655 round up
1.755 round down
===
Here is what is going on.
The 32-bit floating point number $b closest to $a = 1.655 is greater
than 1.655. This number $b is the computer representation of 1.655;
consequently the instruction
sprintf %.2f, $a;
rounds $b up to 1.66.
On the other hand, 32-bit floating point number $b closest to $a =
1.755 is less than 1.755. This number $b is the computer
representation of 1.755; consequently the instruction
sprintf .2f, $a;
rounds $b down to 1.75.
Regards,
Vic
At 1:49 PM -0500 10/13/03, Bill Stephenson wrote:
I've got a script that takes numbers similar to those below and then rounds
them and adds them together using code similar to what is below.
#!/usr/bin/perl -w
use strict;
my $item_1 = 1.655;
my $item_2 = 1.755;
my $rnd_1 = (sprintf qq~%.2f~, $item_1);
my $rnd_2 = (sprintf qq~%.2f~, $item_2);
print $rnd_1, $rnd_2;
The code above prints this result (system 10.1.5, perl 5.6.0):
1.66, 1.75
But shouldn't it be:
1.66, 1.76
or:
1.65, 1.75
I'm no math wizard, so if someone could please take the time and tell what
I'm missing here I would very much appreciate it!
--
Bill Stephenson
www.PerlHelp.com
1-417-546-5593
--
*---* mailto:[EMAIL PROTECTED]
| Victor Thane Norton, Jr.
| Mathematician and Motorcyclist
| phone: 419-353-3399
*---* http://vic.norton.name
Re: Weird math...
on 10/13/03 3:07 PM, John Delacour at [EMAIL PROTECTED] wrote:
Don't ask me why but this does solve your problem (which happens also
in 5.8.0):
@ls = qw(1.655 1.755) ;
for (@ls) {
$_ += 0.01;
printf %.2f$/ , $_;
}
JD
Thanks JD! That seems to work pretty good. I still don't quite get what's
going on here so I'll do some further testing to see If I can catch any more
odd (imho) behavior. For grins, run the included code and check the
different results for each sub routine.
--
Bill Stephenson
www.PerlHelp.com
1-417-546-5593
start code
#!/usr/bin/perl -w
use strict;
my @stuff = qw 1.055
1.155
1.255
1.355
1.455
1.555
1.655
1.755
1.855
1.955
1.1055;
round1;
round2;
round3;
sub round1 {
print === round1 \n;
foreach my $num1 (@stuff) {
print $num1 rounded to - ;
my $result1 = $num1;
$result1 = ($result1*100);
$result1=(int $result1 + ( $result1 0 ? 0.5 : -0.5 ))/100;
$result1 = (sprintf qq~%.2f~, $result1);
print $result1\n;
}
}
sub round2 {
print === round2 \n;
foreach my $num2 (@stuff) {
print $num2 rounded to - ;
my $result2 = $num2;
$result2 = ($result2 + .1);
$result2 = (sprintf qq~%.2f~, $result2);
print $result2\n;
}
}
sub round3 {
print === round3 \n;
foreach my $num3 (@stuff) {
print $num3 rounded to - ;
my $result3 = $num3;
$result3 = ($result3 + 0.0001);
$result3 = (sprintf qq~%.2f~, $result3);
print $result3\n;
}
}
# end code #
Re: Weird math... (once more)
You are wrong about the 64 bit part, Edward, no matter what the Perl books say.
The precision, eps, of a machine is the smallest positive number such that
1 + eps 1 in machine arithmetic. For example, if
1.01 1 but 1.001 = 1 (binary),
then the precision of the machine is 0.01 = 2**6, and the machine
can be said to have 6 bit precision.
By this definition the precision of Perl (on Mac OS X) is 2**52. The
following script shows this quite clearly.
$n = 0;
while( 1 + 2**(-$n) 1 ) { $n++ }
$n = $n-1;
print precision = 2**$n\n;
Probably Perl's precision is best put at 48 bits (12 hex). In the
case of rounding 1.655 and 1.755, this is the last point at which the
former rounds down and the latter rounds up. This can be seen with
the script
$twopower = 48;
$bigtwo = 2**$twopower;
print two power = $twopower\n;
while ($a = DATA) {
chomp $a;
$b = (sprintf %.0f, $a * $bigtwo)/$bigtwo;
$up_or_down = $b = $a ? round up : round down;
print $a $up_or_down\n;
}
print ---\n;
__END__
1.655
1.755
When $twopower 48 both numbers always round up. And they round
every which way for 32 $twopower 48.
The pair of numbers, 1.655 and 1.755, illustrate machine pathology
marvelously. Thank you Bill Stevenson!
Regards,
Vic
At 6:29 PM -0700 10/13/03, Edward Moy wrote:
Yes, Vic is correct (except Perl uses double precision, which is 64 bits).
--
*---* mailto:[EMAIL PROTECTED]
| Mathematicians are like Frenchmen: whatever you say to them
| they translate into their own language, and at once it is
| something entirely different.
|- Johann Wolfgang von Goethe, Maxims and Reflections
*---* http://vic.norton.name
Re: Weird math... (once more)
On Mon, 13 Oct 2003, Vic Norton wrote: You are wrong about the 64 bit part, Edward, no matter what the Perl books say. Never tell an Apple employee they are wrong, especially on a statement of machine or software capability. Unless you are sure. And even then, double check two or three times. In this case, you were right, and he was right, but you were wrong to call him wrong. :) By this definition the precision of Perl (on Mac OS X) is 2**52. The following script shows this quite clearly. IEEE standard double-precision floating point specifies 52 bits of fraction, 11 bits of exponent, and a sign bit: first link in Google for IEEE floating point 64 bit: http://www.psc.edu/general/software/packages/ieee/ieee.html IOW, Perl uses 64 bit doubles, which have 52 bits of precision and 11 bits of range. At 6:29 PM -0700 10/13/03, Edward Moy wrote: Yes, Vic is correct (except Perl uses double precision, which is 64 bits). -- MattLangford
