Re: Cron Progress Bar in OSX
At 12:16 am +0100 14/10/03, Alan Fry wrote: The script runs fine from the Terminal with the command 'perl' however. What am I missing? Read my message of Thu, 9 Oct 2003 12:40:33 +0100
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 I'm not sure. You might try putting the exact Terminal command inside of the do shell script command, like this: do shell script perl /Users/alanfry/Desktop/backatcha.pl or you might make the file /Users/alanfry/Desktop/backatcha.pl executable like this: chmod u+x /Users/alanfry/Desktop/backatcha.pl -- Thanks, James Reynolds University of Utah Student Computing Labs [EMAIL PROTECTED] 801-585-9811
An example (of Weird math)
# An example that tells it all: # 1 + 1/20 = 1.05= 1.00 0011 : bit52 = 0, bit53 = 1 # 1 + 1/40 = 1.025 = 1.000 0011: bit52 = 0, bit53 = 0 # 1 + 1/80 = 1.0125 = 1. 0011 : bit52 = 1, bit53 = 0 # 1 + 1/160 = 1.00625 = 1.0 0011 : bit52 = 1, bit53 = 1 # where # 1.00 0011 means # 1.11001100110011001100110011001100110011... base 2, # and similarly for the other binary representations. # Also bit52 and bit53 are the 52nd and 53rd bits after the point. # The results: printf %.1f\n, 1.05; # produces 1.1 printf %.2f\n, 1.025;# produces 1.02 printf %.3f\n, 1.0125; # produces 1.012 printf %.4f\n, 1.00625; # produces 1.0063 # This is 52-bit precision with rounding arithmetic. Sprintf rounds a # number up or down according as the 53rd bit in the binary # representation of the number is set or not. (The 52nd bit would be # the indicator with 52-bit precision and truncating arithmetic.) -- *---* mailto:[EMAIL PROTECTED] | Victor Thane Norton, Jr. | Mathematician and Motorcyclist | phone: 419-353-3399 *---* http://vic.norton.name
Problems installing libwww-perl-5.69 on OSX
Hi, I'm trying to install libwww-perl-5.69 on my OSX machine to run under Perl 5.8.0. The build appears to have gone okay but when I run 'make test' I get the following output: /usr/bin/perl t/TEST 0 base/common-req...ok base/cookies..ok base/date.ok base/headers-auth.ok base/headers-etag.ok base/headers-util.ok base/headers..ok base/http.ok base/listing..ok base/mediatypes...ok base/message..ok base/negotiateok base/response.ok base/status...ok base/ua...ok html/form.ok robot/rules-dbm...ok robot/rules...ok robot/ua-get..NOK 7HTTP Server terminated robot/ua-get..FAILED tests 1-3, 5, 7 Failed 5/7 tests, 28.57% okay robot/ua..NOK 7HTTP Server terminated robot/ua..FAILED tests 1-3, 5, 7 Failed 5/7 tests, 28.57% okay local/autoload-getok local/autoloadok local/get.ok local/http-getNOK 8Can't call method is_redirect on an undefined value at local/http-get.t line 214, DAEMON line 1. HTTP Server terminated local/http-getdubious Test returned status 22 (wstat 5632, 0x1600) DIED. FAILED tests 1-19 Failed 19/19 tests, 0.00% okay local/httpNOK 8Can't call method is_redirect on an undefined value at local/http.t line 188, DAEMON line 1. HTTP Server terminated local/httpdubious Test returned status 22 (wstat 5632, 0x1600) DIED. FAILED tests 1-18 Failed 18/18 tests, 0.00% okay local/protosubok Failed Test Stat Wstat Total Fail Failed List of Failed --- local/http-get.t 22 563219 19 100.00% 1-19 local/http.t 22 563218 18 100.00% 1-18 robot/ua-get.t 75 71.43% 1-3 5 7 robot/ua.t 75 71.43% 1-3 5 7 Failed 4/26 test scripts, 84.62% okay. 47/343 subtests failed, 86.30% okay. make: *** [test] Error 2 The errors seem to refer to this line in ./t/local/http-get.t and ./t/local http.t although I don't understand it enough to work out what the problem is. print ok 8\n; print not unless $res-previous-is_redirect and $res-previous-code == 301; Can anyone suggest why things are going wrong and how I can fix it please? Thanks, Mike
RE: Weird math...
I'm of the opinion that, as rounding is generally only for the purpose of *displaying* a result, that the rounding operation should be delayed until the last possible moment. Thus, in general, it's better to do all the adding and other stuff and then round just prior to printing. Look at it this way: rounding throws away information, specifically that embodied in the digits that get rounded off. Computers can generally handle all that information. It's only when they need to show it to *people* that they need to dumb it down ;) Chuck -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2003 2:56 PM To: Bill Stephenson Cc: mac osx list Subject: 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 Tue, 14 Oct 2003, Malloch, Charles B wrote: I'm of the opinion that, as rounding is generally only for the purpose of *displaying* a result, that the rounding operation should be delayed until the last possible moment. Thus, in general, it's better to do all the adding and other stuff and then round just prior to printing. Look at it this way: rounding throws away information, specifically that embodied in the digits that get rounded off. Computers can generally handle all that information. It's only when they need to show it to *people* that they need to dumb it down ;) Well, in this case you get the rounding for every number and every math operation, just not the one you think you're going to get. Just as decimal math can't accurately represent 1/3, binary floating point numbers can't accurately represent 1/10. (Which can be something of an issue, as you might expect) Every decimal constant your program uses with a fractional part that can't be composed of the sums of powers of two (1/2, 1/4, 1/8, 1/16, and so on) will be represented by something that's close, but not quite right. Usually, though *not* always, the errors cancel, or at least stay within reasonable levels of tolerance, but that's not universal, and it can lead to some counter-intuitive and, with numbers that are a result of a large series of math operations, occasionally very wrong answers. What you get is usually good enough, and most (though, sadly, not all) people who will be affected by the error introduced with the inexact representation are in a position to compensate for it, but it still catches people by surprise. As an example, if your doctoral dissertation is based on the results of a lot of numerical analysis, it would be a darned good idea to keep in mind the effects of binary representation on constant terms and the errors that propagate from there. (In addition to whatever error margins you have on the original data, of course) You'd also be very ill-advised to do much financial math with floats--as you can see it takes very few operations to see penny-level errors. Multiply that by a couple of hundred thousand (or million) calculations for your average bank and, well, that's a lot of potential cash. I'd also *really* prefer you not do payroll calculations (at least not on *my* paycheck :) with floating point math. Fixed-point math (generally with 4 decimal places and an implied decimal point on a 32 or 64 bit integer) is more appropriate in those cases. Not that there's anything wrong with floats--they're just fine at what they do. They just don't quite do what people think they do, which is where the problems creep in. Dan -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2003 2:56 PM To: Bill Stephenson Cc: mac osx list Subject: 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: Cron Progress Bar in OSX
Riccardo Perotti wrote: DropScript Don't have an url, but I'm sure you can find it in Version Tracker. Or from my earlier post ;) http://www.mit.edu/people/wsanchez/software/ Pete
Re: Cron Progress Bar in OSX
At 00:16 +0100 10/14/03, Alan Fry wrote: do shell script /Users/alanfry/Desktop/backatcha.pl results in the error: ...backatcha.pl:perl:bad interpreter:Permission denied do shell script is misnamed as are a lot of other commands in AppleScript. What it really means is Tell the OS to execute something that has been flagged as executable by setting the x bit in its permissions for the user who is making the request. It doesn't matter whether the file pointed to is a shell script or not though AppleScript does invoke the bash shell to manage the execution and can accept bash commands directly. Compiled C code and perl scripts with a #! line are equally executable but you must set that x bit. The failure you report is that you didn't have execute permission. Terminal is the easy way. The command is chmod 777 path_to_file which actually opens it up completely to anyone. The rightmost bit in each octal digit is the x bit for user, group, and world. man chmod for more. It would be nice if Finder allowed access to the x bit but it doesn't. It would be nice if Finder would execute a double-clicked file with the x bit set but. . . Steve? Is it possible to write an AppleScript to do that? -- -- There are 10 kinds of people: those who understand binary, and those who don't --
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 Yippee! I have got this to work, and now, with a few minor variations have a nice little applet on which you can drop a 'pod' file and get a 'pdf' version in return. I am most grateful for all the very helpful contributions from so many folk in the last day or so. Many thanks, Alan
Re: Cron Progress Bar in OSX
Tue, 14 Oct 2003 08:38:22 +0100 John Delacour wrote: At 12:16 am +0100 14/10/03, Alan Fry wrote: 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? You have two choices: do shell script perl quoted form of pathname or, if the permissions are set to executable and the script has the shebang (chmod pathname +x), do shell script ./Users/alanfry/Desktop/backatcha.pl for example /tmp/test.pl reads #!/usr/bin/perl print hello\n do shell script ./tmp/test.pl -- hello Running a 'chmod' fixes the problem and both methods above now work. However I don't seem to need the dot before the path (?) in the case where the file is 'executable'. Many thanks, Alan
Re: Cron Progress Bar in OSX
At 10:05 pm +0100 14/10/03, Alan Fry wrote: Running a 'chmod' fixes the problem and both methods above now work. However I don't seem to need the dot before the path (?) in the case where the file is 'executable'. You will if its not in your PATH. Compare these three scripts. Since tmp.pl is not in your path, you will get an error with the third: do shell script cd /tmp; perl -e ' $f=qq~tmp.pl~; open F, qq~$f~ ; print F qq~#!/usr/bin/perl\\nprint qq(hello\\n)~ ' ; chmod +x tmp.pl ; ./tmp.pl do shell script cd /tmp; perl -e ' $f=qq~tmp.pl~; open F, qq~$f~ ; print F qq~#!/usr/bin/perl\\nprint qq(hello\\n)~ ' ; chmod +x tmp.pl ; perl tmp.pl do shell script cd /tmp; perl -e ' $f=qq~tmp.pl~; open F, qq~$f~ ; print F qq~#!/usr/bin/perl\\nprint qq(hello\\n)~ ' ; chmod +x tmp.pl ; tmp.pl
Re: Weird math...
Fixed-point math (generally with 4 decimal places and an implied decimal point on a 32 or 64 bit integer) is more appropriate in those cases. Math::BigFloat, perhaps?
