Re: perlpodspec vs. Pod::Perldoc vs. Pod::Parser
On 9/14/05, Joshua Hoblitt [EMAIL PROTECTED] wrote: [...] I think that Pod::Parser is probably the one properly following the spec.. Can anyone help confirm or clarify what the correct behavior here is? That would be Sean Burke, maintainer of both perlpodspec and Pod::Parser.
[PATCH] Math::Complex and Math::Trig updates (Re: [perl #37117] Math::Complex atan2 bug)
The attached patch (#1) brings several pending updates to Math::Complex and Math::Trig. - Complex: fix for the [perl #31117]: atan2(0, i) now works, as do all the (computable) complex argument cases (I adopted the Mathematica definition) - Complex: fixes for certain bugs in the make() and emake() - Complex: support returning the kth root directly - Complex: support [2,-3pi/8] in emake() - Complex: support 'inf' for make()/emake() (the 9**9**9 trick) - Complex: document make()/emake() more visibly - Trig: add more great circle routines: great_circle_waypoint() and great_circle_destination() I also made the modules scratch-proof, err, 5.00504 and 5.6.2-resistant. Since the Complex+Trig have had some fixes/updates over the years, maybe also them should be spun off to CPAN so that users of older Perls can use the latest versions? The tiny patch (#2) documents the attested fact that atan2(0, 0) is not well-defined (i.e., or ie., or ie, the result depends on the underlying math libraries). Both patches should be maint-worthy. cxtr.pat.bz2 Description: Binary data atan2.pat.bz2 Description: Binary data
Re: perl5.004_05 compile problems
On Tue, 13 Sep 2005 21:21:23 -0700, Shaun Daredia [EMAIL PROTECTED] wrote: I am trying to compile perl5.004_05 under SLES9 SP2 and I am seeing the following message. make: *** No rule to make target `built-in', needed by `miniperlmain.o'. Stop. You are building a very old perl with a (very) new GNU gcc GNU gcc has changed some of the text it prints, and the build process of newer perls (5.6.2, 5.8.x, 5.9.x) can deal with that, but there has never been an update for 5.005.x If you *really* need a perl that old, you will have to apply this patch: --8--- Change 16449 by [EMAIL PROTECTED] on 2002/05/07 19:17:41 Subject: [ PATCH ] HP-UX 11.00 + 16446 + gcc-3.1/64 From: H.Merijn Brand [EMAIL PROTECTED] Date: Tue, 07 May 2002 19:41:03 +0200 Message-Id: [EMAIL PROTECTED] Affected files ... ... //depot/perl/makedepend.SH#30 edit Differences ... //depot/perl/makedepend.SH#30 (xtext) @@ -148,6 +148,7 @@ -e '1d' \ -e '/^#.*stdin/d' \ -e '/^#.*builtin/d' \ +-e '/^#.*built-in/d' \ -e '/^#.*command line/d' \ -e '/^#.*-/d' \ -e '/: file path prefix .* never used$/d' \ --8--- But there is no guarantee whatsoever that this will lead to success Here is the uname output. Linux gdead 2.6.5-7.191-smp #1 SMP Tue Jun 28 14:58:56 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11, AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
Re: [perl #37162] Perl -- Make test errors..
On Tue, 13 Sep 2005 11:56:12 -0700, Sharma, Rahul (via RT) [EMAIL PROTECTED] wrote: # New Ticket Created by Sharma, Rahul # Please include the string: [perl #37162] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37162 Hello, Can you please let m know if there is any known resolution for the below. I am using HP -UX supplied C compiler cc to compile perl. Make test gives t he below errors When I build the source, I get failures on Constant.t and Recurs.t lib/ExtUtils/t/Constant...Can't exec gmake: No such file or di rectory at ../lib/ExtUtils/t/Constant.t line 130. FAILED at test 3 Just to check if I'm right, is 'gmake' in your $PATH? If I look in the output below, I see make='make', and this test refers to gmake. On HP that makes quite a lot of difference. What you could do to start with is copy gmake to $HOME/bin/make and put $HOME/bin in front of your $PATH and start again lib/ExtUtils/t/recurs.# Failed test (../lib/ExtUtils/t/r ecurs.t at line 62) # got: '-1' # expected: '0' FAILED at test 6 -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, 5.9.2 on HP-UX 10.20, 11.00 11.11, AIX 4.3 5.2, SuSE 9.2 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
Re: [perl #37163] dprofpp array subscript error
[EMAIL PROTECTED] (via RT) wrote: The dprofpp that comes with perl 5.8.6 and 5.8.4 (haven't tried others) has a bug where a non-existent array element is assigned to which makes dprofpp die. I create a profile like this: dprofpp -Q -p program.pl and I get this tmon.out (gz): http://perlcode.org/dprofpp_bug/tmon.out.gz I try to profile it like this: dprofpp -I -g main::do_loop and receive this error: Modification of non-creatable array value attempted, subscript -1 at /usr/bin/dprofpp line 662, fh line 1100. This happens on FreeBSD and Mac OSX under the above Perl versions. This patch helps (I'm not sure if something is not being counted, however. It may be that the chunk of code that creates the array index below needs to be moved to before this section): Thanks, applied as change #25413 to bleadperl.
Perl 5 Porters list summariser
At various times a regular summary of the Perl 5 Porters mailing list has been published, providing informal reports on Perl 5 development activity to an audience far wider than the readership of this list. We've not had a regular summary for some time, because the various volunteers who used to write them no longer have time to donate to this task. So Rafael and I are asking if anyone would like to volunteer to perform this useful service. It would involve writing a summary of the important discussions and announcements on perl5-porters, and publishing it a regular basis, probably weekly or fortnightly. Historically the summary has been sent to the summary list http://lists.cpan.org/showlist.cgi?name=perl5-summary and published on a prominent Perl website, most recently use.perl.org. Given the fairly light traffic on the list these days I don't feel that the task is that onerous for someone already reading the list regularly. If anyone is interested in taking this on, could you reply to me privately, or join the channel #p5p on irc.perl.org and express your interest there. If more than one person is interested, we could run with alternating summarisers, as happens on the Perl 6 lists. Nicholas Clark
Smoke [5.9.3] 25409 FAIL(XF) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25409 fixit.xs4all.nl: Pentium II (i386/1 cpu) onbsd/os - 4.1 using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release) smoketime 3 hours 56 minutes (average 1 hour 58 minutes) Summary: FAIL(XF) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25409 Configuration (common) none --- - F F - - -Duse64bitint X O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio] -Duse64bitint ../t/op/int.t...FAILED 11 [perlio] -Duse64bitint ../t/op/int.t...FAILED 11 Inconsistent test results (between TEST and harness): ../lib/Net/hostent.tFAILED at test 4 [stdio] Inconsistent test results (between TEST and harness): ../lib/Net/hostent.tFAILED at test 4 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
Re: Transliteration operator(tr//)on EBCDIC platform
On Wed, 14 Sep 2005 16:50:26 +0530, Sastry [EMAIL PROTECTED] wrote
Hi Sadahiro
On 9/12/05, SADAHIRO Tomoyuki [EMAIL PROTECTED] wrote:
I attribute the failure in tr/\x{12c}-\x{130}/\xc0-\xc4/; to
such an ambiguity of \xc0-\xc4. In this expression the left part
\x{12c}-\x{130} parsed before coerces \xc0-\xc4 into Unicode,
and results in the failure.
So this is still a problem on EBCDIC! Is there a way to fix this?
#test case B # On ASCII platform, of course successful
$c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/\x{100}\x89-\x91/X/;
is($c, 8);
is($a, );
This test fails on EBCDIC. In S_scan_const(), there is a statement below.
/* Insert oct or hex escaped character.
* There will always enough room in sv since such
* escapes will be longer than any UTF-8 sequence
* they can end up as. */
/* We need to map to chars to ASCII before doing the tests
to cover EBCDIC
*/
if (!UNI_IS_INVARIANT(NATIVE_TO_UNI(uv))) {
if (!has_utf8 uv 255) {
on an ASCII , the first if condition is true as uv is 137 and it
falls in the variant range as uv \x7F whereas on EBCDIC the if
condition is false. Can you explain why this behaviour is?
see else for this if. This condition tests whether uv needs
multiple octets in UTF-8/UTF-EBCDIC or only needs a single octet.
\x89 in Latin-1 corresponds to a double-octet representation
in UTF-8, and true (that needs multiple octets) on ASCII platform.
\x89 in EBCDIC corresponds to a single-octet representation
in UTF-EBCDIC, and false on EBCDIC platform.
Where else runs, there is no difference between ASCII and UTF-8;
or between single-octet EBCDIC and UTF-EBCDIC.
Also I found that the characters are expanded during runtime in
S_do_trans_simple_utf8()
If I understand it correctly, expansion of character ranges isn't
performed in do_trans_simple_utf8(). It is performed in scan_const()
for non-Unicode and pmtrans() for Unicode.
Do you have any suggestion where the problem is?
(1) one way (I think worse)
Perl should treat the range in the native order (not in Unicode one)
through the parse time, the compile time, and the run time.
using uvchr_to_utf8() instead of uvuni_to_utf8(),
utf8n_to_uvchr() instead of utf8n_to_uvuni(),
in op.c#pmtrans and doop.c#do_trans_simple_utf8 etc.
But swash_fetch() also needs change (the current swash does not
know EBCDIC, only Unicode); changes of swash may lead to
corruption of lc(), uc(), regular expression \p{something} etc.
(2) another way (I think better)
No change of swash, pmtrans, do_trans_.
Then all character ranges within 0..255 (not only for non-Unicode
but also for Unicode) to be expanded in scan_const().
(and pmtrans() will expand only uv = 256).
I think this way requires only the change of toke.c#scan_const
and influences only tr///.
But the change will be quite big, since the current scan_const()
only expands non-Unicode and assumes a single octet encoding.
The range 0..255 in UTF-8/UTF-EBCDIC includes double-octet characters.
I'm not sure whether such a change should be enclosed
with #ifdef EBCDIC and #endif
Regards,
SADAHIRO Tomoyuki
Re: Transliteration operator(tr//)on EBCDIC platform
Hi Sadahiro
On 9/12/05, SADAHIRO Tomoyuki [EMAIL PROTECTED] wrote:
On Mon, 12 Sep 2005 16:12:45 +0530, Sastry [EMAIL PROTECTED] wrote
Hi Sadahiro
On 9/11/05, SADAHIRO Tomoyuki [EMAIL PROTECTED] wrote:
Do you think that perl-5.8.6 is not expanding the character ranges with
Unicode? If so how is this test case working?
($a = \x{12d}\x{12e}\x{12f}\x{130}) =~ tr/\x{12c}-\x{130}/Y/;
All the bytes are translated to Y
regards
-Sastry
Beyond 255 (\x{ff}), I think it will be correctly expanded.
\x{12c}-\x{130} is beyond 255, and thus no problem.
In the range of 0..255 (inclusive), I think generally no for EBCDIC.
(Why I don't say always no is that there are some cases where
a character range in EBCDIC coincides with that in Unicode:
for example 0-9 can be successfully expanded into 0123456789
in both encodings)
I attribute the failure in tr/\x{12c}-\x{130}/\xc0-\xc4/; to
such an ambiguity of \xc0-\xc4. In this expression the left part
\x{12c}-\x{130} parsed before coerces \xc0-\xc4 into Unicode,
and results in the failure.
So this is still a problem on EBCDIC! Is there a way to fix this?
In contrast, I attribute the success in tr/\xc0-\xc4/\x{12c}-\x{130}/;
to that \xc0-\xc4 is parsed before \x{12c}-\x{130}, and then
\xc0-\xc4 is expanded into \xc0\xc1\xc2\xc3\xc4 as EBCDIC
before the character list is coerced into Unicode.
Well, how about the tese case B? (It has \x{100} at first and
then both sides are coerced into Unicode.)
#test case A # now resolved
$c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/\x89-\x91/X/;
is($c, 8);
is($a, );
#test case B # On ASCII platform, of course successful
$c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/\x{100}\x89-\x91/X/;
is($c, 8);
is($a, );
This test fails on EBCDIC. In S_scan_const(), there is a statement below.
/* Insert oct or hex escaped character.
* There will always enough room in sv since such
* escapes will be longer than any UTF-8 sequence
* they can end up as. */
/* We need to map to chars to ASCII before doing the tests
to cover EBCDIC
*/
if (!UNI_IS_INVARIANT(NATIVE_TO_UNI(uv))) {
if (!has_utf8 uv 255) {
on an ASCII , the first if condition is true as uv is 137 and it
falls in the variant range as uv \x7F whereas on EBCDIC the if
condition is false. Can you explain why this behaviour is?
Also I found that the characters are expanded during runtime in
S_do_trans_simple_utf8()
Do you have any suggestion where the problem is?
I think the current perl on EBCDIC does not translate gap characters
for the test case B, which works like tr/\x{100}i-j/X/
and results in $c == 2, and $a eq X\x8a\x8b\x8c\x8d\x8f\x90X;
because i's next character is j in Unicode.
It expands the range but doesn't translate.
And then try this:
#test case C # On ASCII platform, of course successful
$c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/\x89-\x91\x{100}/X/;
is($c, 8);
is($a, );
This works fine
I think the test case C would success even on EBCDIC, because
the expansion from \x89-\x91 to \x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91
will be done before the parser finds \x{100}.
Regards,
SADAHIRO Tomoyuki
regards
Sastry
--
Re: [PATCH] Math::Complex and Math::Trig updates (Re: [perl #37117] Math::Complex atan2 bug)
Jarkko Hietaniemi wrote: The attached patch (#1) brings several pending updates to Math::Complex and Math::Trig. - Complex: fix for the [perl #31117]: atan2(0, i) now works, as do all the (computable) complex argument cases (I adopted the Mathematica definition) - Complex: fixes for certain bugs in the make() and emake() - Complex: support returning the kth root directly - Complex: support [2,-3pi/8] in emake() - Complex: support 'inf' for make()/emake() (the 9**9**9 trick) - Complex: document make()/emake() more visibly - Trig: add more great circle routines: great_circle_waypoint() and great_circle_destination() I also made the modules scratch-proof, err, 5.00504 and 5.6.2-resistant. Since the Complex+Trig have had some fixes/updates over the years, maybe also them should be spun off to CPAN so that users of older Perls can use the latest versions? The tiny patch (#2) documents the attested fact that atan2(0, 0) is not well-defined (i.e., or ie., or ie, the result depends on the underlying math libraries). Both patches should be maint-worthy. Both applied to blead as #25414, thanks. But may I suggest that next time, you run tests before sending them ? Just look again at your next_test() function for lib/Math/Complex.t (I didn't apply this part) and you'll see that you made a trivial mistake... :) -- Faithful to this feeble magic, he would invent, so that they might not happen, the most atrocious particulars. -- Borges
Re: File::Spec::VMS enhancements.
On Tue, Sep 13, 2005 at 09:53:15AM -0400, John E. Malmberg wrote: Ken Williams wrote: Extended characters in pathnames: The traditional VMS mode ... [0..9],[A..Z],[-$_] I'm admittedly a few decades past the peak of my expertise in VMS, but shouldn't the ; preceding a file's version number be listed in that set also? -Tim *--* | Tim Maher, PhD (206) 781-UNIX (866) DOC-PERL (866) DOC-UNIX | | tim(AT)Consultix-Inc.Com http://TeachMePerl.Com http://TeachMeUnix.Com | *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-* |Watch for my Fall, 2005 book: Minimal Perl for UNIX/Linux People| | See http://minimalperl.com for details, ordering, and email-list signup | *--*
RE: Encode on EBCDIC patch( Doesn't Work)
What does the verbose output from the encode.t look like once after your change to ext/Encode/Makefile.PL? Paul From: Sastry [mailto:[EMAIL PROTECTED] Hi I changed the ext/Encode/Makefile.PL with the def_t table to contain iso- 8859-16 as follows my %tables = ( def_t = ['ascii.ucm', '8859-1.ucm', '8859-16.ucm', 'null.ucm', 'ctrl.ucm', ] ); a) Now the encode(iso8859-16,euro); gives \x65\x75\x72\x6F which is as expected. can this be a solution to resolve the encode failure on EBCDIC? b) But the test case lib/DBM_Filter/t/encode.t fails as it expects the euro key. Do we need to modify the test case? regards Sastry On 9/13/05, Sastry [EMAIL PROTECTED] wrote: Hi Paul The other tests with DBM_Filter are working fine on EBCDIC platform. The only problem is with lib/DBM_Filter/t/encode.t and I guess Dan can address this! Dan! The workaround for encode() is not complete. Can you recheck it? -regards Sastry On 9/13/05, Paul Marquess [EMAIL PROTECTED] wrote: From: Sastry [mailto:[EMAIL PROTECTED] HI Paul On 9/13/05, Paul Marquess [EMAIL PROTECTED] wrote: From: Sastry [mailto:[EMAIL PROTECTED] Hi I agree with you Dan, I was referring to another test lib/DBM_Filter/t/encode.t where it encodes the k/v pairs using the code page iso-8859-16 and the normal DBM_Filter to store and verify the same. Other tests in DBM_Filter are working fine on EBCDIC platform. According to the output you posted yesterday there were two of the DBM_Filter test suites failing - utf8.t and encode.t. These are the only tests that touch encoding in the DBM_Filters I posted a summary of what the utf8 filter was doing because it is a simpler test, so it might be easier to figure out what is going wrong. The encode.t test changes the encoding from utf8 to iso-8859-16 mid test - in fact the euro symbol that you mention is the only thing written to the DBM file that should be encoded in iso-8859-16 - everything else should be in utf8. The 'euro' symbol is not encoded properly. Hence the failure. The rest of the test cases are fine. I confused. Do you mean that the other failures in the DBM_Filter test suite are to be expected on an EBCDIC platform? Paul ___ Does your mail provider give you FREE antivirus protection? Get Yahoo! Mail http://uk.mail.yahoo.com -- ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Storable 2.15 on OSX 10.4 with maintperl fails make test
t/weakWeak references are not implemented in the version of perl at t/weak.t line 28 BEGIN failed--compilation aborted at t/weak.t line 33. t/weakdubious Test returned status 255 (wstat 65280, 0xff00) Huh? Since when are Weak references not implemented in modern Perls? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: [PATCH] Math::Complex and Math::Trig updates (Re: [perl #37117] Math::Complex atan2 bug)
There is a small technical bug in sub great_circle_destination {...}.
An additional (optional) argument, RHO, must be passed to the
subroutine. Otherwise, the calculation will always be based on the
assumption that we are using a unit sphere. RHO will represent the
radius of the sphere. I have previously written a subroutine also named
great_circle_destination which may be of use to you :) The subroutine
assumes that the user is inputting coordinates in radians using the
following standards:
North Western Hemisphere = (
-pi = Longitude = 0,
0 = Latitude = pi/2
)
South Western Hemisphere = (
-pi = Longitude = 0,
-pi/2 = Latitude = 0
)
North Eastern Hemisphere = (
0 = Longitude = pi,
0 = Latitude = pi/2
)
South Eastern Hemisphere = (
0 = Longitude = pi,
-pi/2 = Latitude = 0
)
There is no need to subtract by pi/2 (pip2) in this case. The
destination is also required to be input in radians where:
North is 0;
South is -pi or pi;
East is pi/2;
West is -pi/2;
Here it is (tried and tested on GIS applications):
=cut
Example:
my ($dlat, $dlon) = great_circle_distance($lat, $lon, $distance,
$direction, 6378.1);
# 6378.1 is the radius of the earth in km. You could alternatively use
any
# other value for rho, for example, 3443.89849 which is the radius of
the
# earth in nautical miles;)
=cut
sub great_circle_destination {
my (
$lat0,
$lon0,
$distance,
$direction,
$rho
) = @_;
my (
$lat1,
$lon1
);
# lat2 = asin(sin(lat1)*cos(d) + cos(lat1)*sin(d)*cos(hdng))
# lon2 = lon1 + atan2(sin(hdng)*sin(d)*cos(lat1),
cos(d)-sin(lat1)*sin(lat2))
# Reference: http://www.movable-type.co.uk/scripts/LatLong.html
$rho = 1 unless defined($rho);
$distance = $distance/$rho;
$lat1 = asin(sin($lat0)*cos($distance) +
cos($lat0)*sin($distance)*cos($direction));
$lon1 = $lon0 + atan2(sin($direction)*sin($distance)*cos($lat0),
cos($distance)-sin($lat0)*sin($lat1));
return ($lat1, $lon1);
}
-Original Message-
From: Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 14, 2005 2:26 AM
To: Mueller, Steffen
Cc: perl5-porters@perl.org; Douba,Nadeem [CIS]
Subject: [PATCH] Math::Complex and Math::Trig updates (Re: [perl #37117]
Math::Complex atan2 bug)
The attached patch (#1) brings several pending updates to Math::Complex
and Math::Trig.
- Complex: fix for the [perl #31117]: atan2(0, i) now works,
as do all the (computable) complex argument cases (I adopted
the Mathematica definition)
- Complex: fixes for certain bugs in the make() and emake()
- Complex: support returning the kth root directly
- Complex: support [2,-3pi/8] in emake()
- Complex: support 'inf' for make()/emake() (the 9**9**9 trick)
- Complex: document make()/emake() more visibly
- Trig: add more great circle routines: great_circle_waypoint()
and great_circle_destination()
I also made the modules scratch-proof, err, 5.00504 and 5.6.2-resistant.
Since the Complex+Trig have had some fixes/updates over the years, maybe
also them should be spun off to CPAN so that users of older Perls can
use the latest versions?
The tiny patch (#2) documents the attested fact that atan2(0, 0) is not
well-defined (i.e., or ie., or ie, the result depends on the underlying
math libraries).
Both patches should be maint-worthy.
Re: Storable 2.15 on OSX 10.4 with maintperl fails make test
On Wed, Sep 14, 2005 at 10:07:42AM -0700, Randal L. Schwartz wrote: t/weakWeak references are not implemented in the version of perl at t/weak.t line 28 BEGIN failed--compilation aborted at t/weak.t line 33. t/weakdubious Test returned status 255 (wstat 65280, 0xff00) Huh? Since when are Weak references not implemented in modern Perls? I've seen this issue elsewhere but haven't caught whether the problem is with the default Perl installed on OS X 10.4, or if this is a freshly built maint. Which are you seeing this on? The actually cause of the problem lies in how Scalar::Utils is built. The implementation you have was built without compiling the XS portion of Scalar::Utils. If you do a fresh install of Scalar::Utils, the problems are fixed. Steve Peters [EMAIL PROTECTED]
Re: Storable 2.15 on OSX 10.4 with maintperl fails make test
Steve == Steve Peters [EMAIL PROTECTED] writes: Steve I've seen this issue elsewhere but haven't caught whether the problem is Steve with the default Perl installed on OS X 10.4, or if this is a freshly built Steve maint. Which are you seeing this on? Freshly built maintperl, MAIN24637 to be exact. Steve The actually cause of the problem lies in how Scalar::Utils is built. The Steve implementation you have was built without compiling the XS portion of Steve Scalar::Utils. If you do a fresh install of Scalar::Utils, the problems Steve are fixed. I have both Scalar/Util.pm and darwin/Scalar/Util.pm. The one in darwin looks very old. -r--r--r-- 1 merlyn wheel 7940 Sep 12 10:02 Scalar/Util.pm -r--r--r-- 1 merlyn wheel 8729 May 23 07:06 darwin/Scalar/Util.pm So is the build/install process broken? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [PATCH] Math::Complex and Math::Trig updates (Re: [perl #37117] Math::Complex atan2 bug)
Rafael Garcia-Suarez wrote: Jarkko Hietaniemi wrote: Both applied to blead as #25414, thanks. But may I suggest that next time, you run tests before sending them ? Just look again at your next_test() Ooops. In my defense I can say I did perl -wIlib lib/Math/Complex.t|grep not (and came up empty) but yeah, didn't run full test or use the harness... function for lib/Math/Complex.t (I didn't apply this part) and you'll see that you made a trivial mistake... :)
Re: [PATCH] Math::Complex and Math::Trig updates (Re: [perl #37117] Math::Complex atan2 bug)
There is a small technical bug in sub great_circle_destination {...}.
An additional (optional) argument, RHO, must be passed to the
subroutine. Otherwise, the calculation will always be based on the
I am confused. On a sphere the destination point d (radians)
one ends up after going from point a (radians) in direction b (radians)
for c (radians) doesn't depend on the rho (radius) ... that's the beauty
of radians, right? Or do you mean you want to specify the distance
to travel in some units other than radians?
assumption that we are using a unit sphere. RHO will represent the
radius of the sphere. I have previously written a subroutine also named
great_circle_destination which may be of use to you :) The subroutine
assumes that the user is inputting coordinates in radians using the
following standards:
We cannot change the default coordinate system of the great_circle_*
routines. For better or worse, the pi/2 or 90 deg needed twist has been
documented to work that way for quite some time now, we cannot change
this without breaking people's code. See also the discussion in the
documentation about the theta and phi: these is no one single correct
spherical coordinate system.
One possible way to incorporate your semantics would be to add
an export tag, e.g. :great_circle_latlon that would affect the
great circle formulas.
