Re: [perl #47397] t/op/arithmetics.t hangs
On 13/11/2007, Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Mon, Nov 12, 2007 at 12:33:41PM -0800, Andy Dougherty wrote: > > > It may well be there's an issue with gcc's optimizer, since the problem > > goes away without optimization, but I think it's also fair to say that > > the definition of FLOAT_IS_ZERO in include/parrot/misc.h is > > perhaps not optimal here. I'd prefer the simpler definition: > > > > #define FLOAT_IS_ZER0(f) ((f) == 0.0) > > > > but I didn't get anywhere last time I proposed that. I don't know > > what else to do. > > I suggested > > f >= 0.0 && f <= 0.0 > > which I believe is identical, even in the face of NaNs, but should also shut > up the whining, er, warning, about comparison. > > Because I would be so bold as to say that the constant zero would be > exempted from any useful warning about floating point equality check. The floating point comparison warning isn't switched on (in gcc) anymore. If it's on somewhere else, then I'd like to know so that we can switch off the warning on that compiler. Paul
Re: [perl #47349] [BUG] 'make' failure on Darwin
On Nov 13, 2007, at 9:06 PM, James Keenan via RT wrote: On Sun Nov 11 22:29:21 2007, ptc wrote: My next guess now is that the -std=c89 gcc compiler option doesn't play nicely with your system headers. I've removed the compiler flag in r22809, see how you go. Paul It did. Now Darwin is back to failing just one non-coding-standards test: t/examples/shootout.t (what else?). Perhaps we could get Apple to give a microgrant to the Perl Foundation so that someone could be commissioned to fix this persistent test failure! Will close ticket. kid51 The shootout's tend to use not use the standard runcore(it's too slow), so the shootouts test other runcores or combinations of runcores. Call it a bug or feature, whichever.
[perl #47421] Illegal instruction when "Invoking Parrot to generate runtime/parrot/include/config.fpmc"
# New Ticket Created by "B. Estrade" # Please include the string: [perl #47421] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=47421 > --- osname= freebsd osvers= 6.2-stable arch= sparc64-freebsd cc= cc --- Flags: category=install severity=high ack=no --- Parrot 0.4.17r22818 freebsd 6.2-sparc64 gcc 4.3 I have the output of the build up to this point as well as the core file - just let me know where to send it/upload it. ### perl tools/build/parrot_config_c.pl --mini > \ src/null_config.c src/null_config.c gcc43 -o miniparrot src/main.o \ -Wl,-R/usr/home/estrabd/estrabd-at-gmail-dot-com/parrot/blib/lib -L/usr/home/estrabd/estrabd-at-gmail-dot-com/parrot/blib/lib -lparrot -lm -lcrypt -lutil -pthread -lgmp -lreadline -Wl,-E -L/usr/local/lib src/null_config.o Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your fingers ./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc Illegal instruction (core dumped) gmake: *** [runtime/parrot/include/config.fpmc] Error 132 --- Summary of my parrot 0.4.17 (r22819) configuration: configdate='Wed Nov 14 02:09:42 2007 GMT' Platform: osname=freebsd, archname=sparc64-freebsd jitcapable=0, jitarchname=nojit, jitosname=freebsd, jitcpuarch=sparc64 execcapable=0 perl=perl Compiler: cc='gcc43', ccflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.8/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -pipe -Wdeclaration-after-statement -I/usr/local/include -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT ', Linker and Libraries: ld='gcc43', ldflags=' -Wl,-E -L/usr/local/lib', cc_ldflags='', libs='-lm -lcrypt -lutil -pthread -lgmp -lreadline' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -L/usr/local/lib', load_ext='.so', ld_load_flags='-shared -L/usr/local/lib' Types: iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8, ptrsize=8, ptr_alignment=1 byteorder=87654321, nv=double, numvalsize=8, doublesize=8 --- Environment: HOME =/home/estrabd LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH =/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/estrabd/bin SHELL =/bin/sh
Re: [svn:parrot] r22824 - trunk/lib/Parrot/Configure
On 14/11/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: chromatic > Date: Tue Nov 13 17:42:13 2007 > New Revision: 22824 > > Modified: >trunk/lib/Parrot/Configure/Step.pm > > Log: > [configure] Don't use the libs in the configuration object when linking C > files > in the configuration tests. For some reason, they're wrong (why does it think > I have GDBM installed? I don't have GDBM installed, and it's already done a > probe to find GDBM!). > > This may not be the rightest solution, but in lieu of figuring out how to get > the correct configuration object here, one which knows which libraries are > actually necessary and installed, I can live with this. > > Now all tests pass by default on x86 GNU/Linux. Unfortunately, this breaks Configure on Windows. We need to find a cleaner solution to this problem. I'm going to revert this change in order to get Windows back working again. Paul
Re: [perl #47397] t/op/arithmetics.t hangs
On Tue, 13 Nov 2007, Nicholas Clark via RT wrote: > On Mon, Nov 12, 2007 at 12:33:41PM -0800, Andy Dougherty wrote: > > > It may well be there's an issue with gcc's optimizer, since the problem > > goes away without optimization, but I think it's also fair to say that > > the definition of FLOAT_IS_ZERO in include/parrot/misc.h is > > perhaps not optimal here. I'd prefer the simpler definition: > > > > #define FLOAT_IS_ZER0(f) ((f) == 0.0) > > > > but I didn't get anywhere last time I proposed that. I don't know > > what else to do. > > I suggested > > f >= 0.0 && f <= 0.0 > > which I believe is identical, even in the face of NaNs, but should also shut > up the whining, er, warning, about comparison. You're probably right. However, given that gcc currently throws over a thousand warnings it's hard to get worried about about another one or two. > Because I would be so bold as to say that the constant zero would be > exempted from any useful warning about floating point equality check. Yes, it's amazing how gcc seems to have hundreds of flags that are almost, but not quite, entirely unlike the ones you actually want. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #47397] t/op/arithmetics.t hangs
On Wed, Nov 14, 2007 at 09:20:40AM -0500, Andy Dougherty wrote: > On Tue, 13 Nov 2007, Nicholas Clark via RT wrote: > > On Mon, Nov 12, 2007 at 12:33:41PM -0800, Andy Dougherty wrote: > > > It may well be there's an issue with gcc's optimizer, since the problem > > > goes away without optimization, but I think it's also fair to say that > > > the definition of FLOAT_IS_ZERO in include/parrot/misc.h is > > > perhaps not optimal here. I'd prefer the simpler definition: > > > > > > #define FLOAT_IS_ZER0(f) ((f) == 0.0) > > > > > > but I didn't get anywhere last time I proposed that. I don't know > > > what else to do. > > > > I suggested > > > > f >= 0.0 && f <= 0.0 > > > > which I believe is identical, even in the face of NaNs, but should also shut > > up the whining, er, warning, about comparison. Yes, as long as whatever expressions we use for "f" don't have any side effects (but you both already know this :-). > You're probably right. However, given that gcc currently throws over a > thousand warnings it's hard to get worried about about another one or two. IIRC, part of the reason we went to some effort to shut up the floating point comparison warnings from gcc was because there were significantly more than one or two of them. :-) But like Andy I've always been strongly in favor of the ((f) == 0.0) approach and simply turning off the float_equals warnings in gcc. > > Because I would be so bold as to say that the constant zero would be > > exempted from any useful warning about floating point equality check. > > Yes, it's amazing how gcc seems to have hundreds of flags that are almost, > but not quite, entirely unlike the ones you actually want. Well said. Pm
[perl #47421] Illegal instruction when "Invoking Parrot to generate runtime/parrot/include/config.fpmc"
Stuff it into a plain-text file and re-post with the file as an attachment. I recommend naming the attachment '*.txt' to avoid mime-type problems.
[perl #47421] Illegal instruction when "Invoking Parrot to generate runtime/parrot/include/config.fpmc"
On Tue Nov 13 19:01:07 2007, [EMAIL PROTECTED] wrote: > --- > osname= freebsd > osvers= 6.2-stable > arch= sparc64-freebsd > cc= cc > --- > Flags: > category=install > severity=high > ack=no > --- > Parrot 0.4.17r22818 > freebsd 6.2-sparc64 gcc 4.3 Also, you might want to search this group's archives to see if similar results have been filed about this combination of OS and architecture. (I take it this is not the Dragonfly machine about which you reported yesterday.)
Re: [perl #47397] t/op/arithmetics.t hangs
On 14/11/2007, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Wed, Nov 14, 2007 at 09:20:40AM -0500, Andy Dougherty wrote: > > On Tue, 13 Nov 2007, Nicholas Clark via RT wrote: > > > On Mon, Nov 12, 2007 at 12:33:41PM -0800, Andy Dougherty wrote: > > > > It may well be there's an issue with gcc's optimizer, since the problem > > > > goes away without optimization, but I think it's also fair to say that > > > > the definition of FLOAT_IS_ZERO in include/parrot/misc.h is > > > > perhaps not optimal here. I'd prefer the simpler definition: > > > > > > > > #define FLOAT_IS_ZER0(f) ((f) == 0.0) > > > > > > > > but I didn't get anywhere last time I proposed that. I don't know > > > > what else to do. > > > > > > I suggested > > > > > > f >= 0.0 && f <= 0.0 > > > > > > which I believe is identical, even in the face of NaNs, but should also > > > shut > > > up the whining, er, warning, about comparison. > > Yes, as long as whatever expressions we use for "f" don't have any > side effects (but you both already know this :-). > > > You're probably right. However, given that gcc currently throws over a > > thousand warnings it's hard to get worried about about another one or two. > > IIRC, part of the reason we went to some effort to shut up the > floating point comparison warnings from gcc was because there > were significantly more than one or two of them. :-) > > But like Andy I've always been strongly in favor of the ((f) == 0.0) > approach and simply turning off the float_equals warnings in gcc. The float_equals warnings in gcc *are* off. So why is this warning a problem (maybe I've missed something)? I also don't see over 1000 warnings with gcc (I've got gcc 3.4.5 on Gentoo Linux x86); I have in the order of 100 atm. If we *are* seeing over 1000 warnings with gcc, then either we should turn the warnings level down a bit, or the warnings should be fixed (like some warnings about required non-null arguments I know). Paul
Re: [perl #47397] t/op/arithmetics.t hangs
>> the definition of FLOAT_IS_ZERO in include/parrot/misc.h is Could this be relevant to RT45209 (a -0.0 being taken as true, rather than false?). I tried to track down the problem, but got lost in the woods. Somebody more familiar with the logic might recognise it. -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: [perl #47391] t/configure/1*.t tests incorrectly rely on init::defaults
On Tue, 13 Nov 2007, James Keenan via RT wrote: > Could you supply the output of perl -V for the system where you are > encountering these problems? This was a perl compiled with Sun's cc. $ perl5.8 -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris uname='sunos XX 5.8 XX sun4u sparc sunw,ultra-5_10 ' config_args='-Doptimize=-fast -xdepend -Dprefix=/opt/perl -Dcc=cc -de' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fast -xdepend', cppflags='-I/usr/local/include' ccversion='WorkShop Compilers 4.2 30 Oct 1996 C 4.2', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib ' libpth=/usr/lib /usr/ccs/lib /opt/SUNWspro/SC4.2/lib /usr/local/lib libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-KPIC', lddlflags='-G -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO Built under solaris Compiled at Feb 2 2006 08:42:07 @INC: /opt/perl/lib/5.8.8/sun4-solaris /opt/perl/lib/5.8.8 /opt/perl/lib/site_perl/5.8.8/sun4-solaris /opt/perl/lib/site_perl/5.8.8 /opt/perl/lib/site_perl/5.8.7/sun4-solaris /opt/perl/lib/site_perl/5.8.7 /opt/perl/lib/site_perl/5.8.6/sun4-solaris /opt/perl/lib/site_perl/5.8.6 /opt/perl/lib/site_perl/5.8.5/sun4-solaris /opt/perl/lib/site_perl/5.8.5 /opt/perl/lib/site_perl/5.8.4/sun4-solaris /opt/perl/lib/site_perl/5.8.4 /opt/perl/lib/site_perl/5.8.3/sun4-solaris /opt/perl/lib/site_perl/5.8.3 /opt/perl/lib/site_perl/5.8.2/sun4-solaris /opt/perl/lib/site_perl/5.8.2 /opt/perl/lib/site_perl . I was trying to build parrot with gcc. $ cat myconfig Summary of my parrot 0.4.17 (r0) configuration: configdate='Wed Nov 14 14:44:25 2007 GMT' Platform: osname=solaris, archname=sun4-solaris jitcapable=0, jitarchname=nojit, jitosname=solaris, jitcpuarch=sun4 execcapable=0 perl=perl5.8 Compiler: cc='gcc', ccflags='-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -DDISABLE_GC_DEBUG=1 -DNDEBUG -O4 -fstrict-aliasing -funroll-loops -mno-unaligned-doubles -Wcast-align', Linker and Libraries: ld='gcc', ldflags=' -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib ', cc_ldflags='', libs='-lsocket -lnsl -ldl -lm -lpthread -lrt' Dynamic Linking: share_ext='.so', ld_share_flags='-G -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib', load_ext='.so', ld_load_flags='-G -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=4 byteorder=4321, nv=double, numvalsize=8, doublesize=8 > Also it would be good to have the output of prove -v for each of the > failing t/configure/*.t tests. I've attached them, though they actually aren't very informative by themselves. However, I have already diagnosed the problem in my previous messages -- the values getting loaded by init::defaults are not suitable for compilation. While running parrot's Configure.pl, I fixed them, but the correct values I gave to Configure.pl are being ignored. You can easily recreate this situation for yourself. Build and install a private copy of perl. Then hand-edit Config.pm and Config_heavy.pl in your new perl's architecture-dependent library. Change some entries to invalid ones. For example, you might change 'cc' to 'qcc' to mimic a case where you have different compiler installed than the system vendor used. Or you might change the libs directive to include -lbogus, simulating the case where the vendor had a partic
parentheses and context (was Re: state and START)
On Sat, Sep 08, 2007 at 01:48:39PM +0100, Nicholas Clark wrote: > Have I got this correct? > > state @a = foo(); # Implicit START block around call and initialisation > state (@a) = foo(); # Implicit START block around call and > initialisation > (state @a) = foo(); # foo() called every time, assignment every time Um. That seemed to scare everyone away. If it's rephrased like this: my @a = foo(); # What context is foo called in? my (@a) = foo();# What context is foo called in? Is it the same? (my @a) = foo();# What context is foo called in? Is it the same? Are the three calls in the same context? Or two (or even three) different contexts? Nicholas Clark
[perl #47453] make test errors (likely test harness related)
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #47453] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=47453 > Last week I had to reinstall the OS on my desktop, and after installing Test::TAP::HTMLMatrix (for 'make smoke') I now get a lot of errors during 'make test' that look like: [...] t/library/getopt_obj...ok t/library/iter.Option -I not known parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-D [FLAGS]][-O [level]] [-o FILE] t/library/iter. Dubious, test returned 1 (wstat 256, 0x100) No subtests run t/library/md5..ok t/library/mime_base64..Option -I not known parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-D [FLAGS]][-O [level]] [-o FILE] t/library/mime_base64.. Dubious, test returned 1 (wstat 256, 0x100) No subtests run t/library/parrotlibok t/library/pcre.ok t/library/pg...Option -I not known parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-D [FLAGS]][-O [level]] [-o FILE] t/library/pg... Dubious, test returned 1 (wstat 256, 0x100) No subtests run t/library/protoobject..ok [...] The test summary report then has a fairly long list of test failures, making it difficult to see if we've in fact passed all of the tests. I suspect the issue has to do with one of the packages installed as dependencies for Test::TAP::HTMLMatrix, but I'm not exactly sure which package introduced the problem. Somewhat surprisingly, 'make smoke' works just fine [1] -- it's only 'make test' that has the problems. Thus, I'm filing this ticket in hopes that someone else can quickly look at this and come up with a fix or workaround. Otherwise I'll have to start uninstalling CPAN modules until 'make test' starts doing something reasonable for me again. :-) Thanks! Pm 1. http://xrl.us/bar28 (Link to smoke.parrotcode.org)
Could you forward this into the perl6 internals list (fwd)
I'm forwarding a message I got about the f == 0.0 warnings. -- Andy Dougherty [EMAIL PROTECTED] -- Forwarded message -- Date: Wed, 14 Nov 2007 10:38:10 -0500 From: Jeffrey Kegler <[EMAIL PROTECTED]> To: Andy Dougherty <[EMAIL PROTECTED]> Subject: Could you forward this into the perl6 internals list Resent-Date: Wed, 14 Nov 2007 10:38:35 -0500 Resent-From: <[EMAIL PROTECTED]> I've been following the floating point issue for some time, but am not on the perl6 internals list, and didn't want to join to make a single comment. Could I ask you to forward this into the list? Bottom line: the floating point equality warning is the expression of a philosophy of math issue, and you may not be following the philosophy. That's cool. But it's not viable IMHO to not adhere to the philosophy, but try to keep the warning. The philosophy of math issue is that if you are taking floats as approximations of reals, equality does not usually mean anything useful. It almost never means what the programmer is trying to express via equality. Floating point zero (0.00) means zero plus or minus an error, just as with any other floating point number. Zero is not special in any sense. Are all your "special case" floating zeroes safe from being mistaken for certain very small but non-zero numbers in all implementations? However, we are hackers, not philosophers of mathematics (actually I'm both, but I'm talking now as a hacker). Floats on computers are what we hackers use them for, and if we find it useful to special case the bit pattern corresponding to zero, we can do it. We should, however, turn off the warning. I hesitated to come in, because I'm not aware of the context. You may, for example, be trying to mix code that carefully adheres to the floating-point-equals-Platonic-idea-of-real-numbers philosophy, with code written on a it-works-so-what's-the-beef philosophy, in which case I can see why the problem keeps coming up. Primary suggestion: You might consider simply turning off the warning in preference to heroic efforts to shut it up for cases which are actually no safer than any others. Other suggestions: If code rewrites are feasible, an additional boolean is not (certainly in the context of C code) all that expensive these days, and is a philosophically "right" answer. A more hackerly solution is to identify a range which won't be the result of normal computation and test for that. (If the value can never be less than zero let (f < 0.00) be the special case. Sorry to interrupt your work, but I've followed your list and seen this come up several times and I hoped this might help, thanks for your work, jeffrey kegler > > On Mon, Nov 12, 2007 at 12:33:41PM -0800, Andy Dougherty wrote: > > > > > It may well be there's an issue with gcc's optimizer, since the > problem > > > goes away without optimization, but I think it's also fair to > say that > > > the definition of FLOAT_IS_ZERO in include/parrot/misc.h is > > > perhaps not optimal here. I'd prefer the simpler definition: > > > > > > #define FLOAT_IS_ZER0(f) ((f) == 0.0) > > > > > > but I didn't get anywhere last time I proposed that. I don't know > > > what else to do. > > > > I suggested > > > > f >= 0.0 && f <= 0.0 > > > > which I believe is identical, even in the face of NaNs, but > should also shut > > up the whining, er, warning, about comparison. > > You're probably right. However, given that gcc currently throws over a > thousand warnings it's hard to get worried about about another one > or two. > > > Because I would be so bold as to say that the constant zero would be > > exempted from any useful warning about floating point equality > check. > > Yes, it's amazing how gcc seems to have hundreds of flags that are > almost, > but not quite, entirely unlike the ones you actually want. > > -- > Andy Dougherty [EMAIL PROTECTED] >
Re: [perl #47391] t/configure/1*.t tests incorrectly rely on init::defaults
On Nov 14, 2007, at 5:37 PM, Andy Dougherty via RT wrote: On Tue, 13 Nov 2007, James Keenan via RT wrote: Could you supply the output of perl -V for the system where you are encountering these problems? This was a perl compiled with Sun's cc. $ perl5.8 -V Thanks. I think this may prove useful. kid51
Re: [perl #36255] [TODO] Exceptional Documentation
On Nov 13, 2007, at 3:58 PM, Klaas-Jan Stol via RT wrote: Can this ticket closed, having an exceptions PDD no longer in draft status? http://www.parrotcode.org/docs/pdd/pdd23_exceptions.html kjs I think so, yes. -- Will "Coke" Coleda [EMAIL PROTECTED]
Re: [perl #47453] make test errors (likely test harness related)
On Wed, 14 Nov 2007, Patrick R . Michaud wrote: > # New Ticket Created by Patrick R. Michaud > # Please include the string: [perl #47453] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=47453 > > > > Last week I had to reinstall the OS on my desktop, and after > installing Test::TAP::HTMLMatrix (for 'make smoke') I now get > a lot of errors during 'make test' that look like: > > [...] > t/library/getopt_obj...ok > t/library/iter.Option -I not known > parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-D [FLAGS]][-O [level]] [-o FILE] > > t/library/iter. Dubious, test returned 1 > (wstat 256, 0x100) > No subtests run > t/library/md5..ok > t/library/mime_base64..Option -I not known > parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-D [FLAGS]][-O [level]] [-o FILE] > > t/library/mime_base64.. Dubious, test returned 1 > (wstat 256, 0x100) > No subtests run > t/library/parrotlibok > t/library/pcre.ok > t/library/pg...Option -I not known > parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-D [FLAGS]][-O [level]] [-o FILE] > > t/library/pg... Dubious, test returned 1 > (wstat 256, 0x100) > No subtests run > t/library/protoobject..ok > [...] That's a Test::Harness 3 change. It doesn't understand the #!./parrot lines at the top of some of the tests. -- Andy Dougherty [EMAIL PROTECTED]
Re: Could you forward this into the perl6 internals list (fwd)
At 14:35 -0500 11/14/07, Andy Dougherty wrote: SNIP >Bottom line: the floating point equality warning is the expression of >a philosophy of math issue, and you may not be following the >philosophy. That's cool. But it's not viable IMHO to not adhere to >the philosophy, but try to keep the warning. > >The philosophy of math issue is that if you are taking floats as >approximations of reals, equality does not usually mean anything >useful. It almost never means what the programmer is trying to >express via equality. Floating point zero (0.00) means zero plus or >minus an error, just as with any other floating point number. Zero >is not special in any sense. Are all your "special case" floating >zeroes safe from being mistaken for certain very small but non-zero >numbers in all implementations? SNIP >Sorry to interrupt your work, but I've followed your list and seen >this come up several times and I hoped this might help, SNIP >thanks for your work, Many thanks are due and I do appreciate what's going on. What is really needed is a new "float" which might be named "measurement". Measurements contain a value, a unit from the SI list, and an estimate of error. They are a class that would fit easily into the O-O world that exists today. It might well include complex values and vectors. Asking if two measurements are equal would be meaningful because each value, as calculated from other measurements, would come with its own estimate of error. Ditto for an "is it zero" question. But.. . . perl is a practical extraction and report generator - I think. Yes. I use perl 5 to do engineering and it's a decent replacement for FORTRAN. But it's reason de etre is to make text manipulation easy and I use it for that too. I look forward to a perl 6 that provides a way to create a universal module that implements a class measurement with all of the bells and whistles I would like - units and error estimates. I would also like to see real vector operations that do dot and cross products. But it's more important that the text processing and basic - extendable - package be implemented right soon now. I can wait for, and possibly contribute to, engineering additions that will provide what I want. Let's get perl 6 out into the world and add the mathematical niceties later. Just be sure it's possible to do that. -- Applescript syntax is like English spelling: Roughly, though not thoroughly, thought through.
Re: [perl #47453] make test errors (likely test harness related)
On Thu, 15 Nov 2007, Andy Armstrong wrote: > On 14 Nov 2007, at 23:11, Andy Dougherty wrote: > > That's a Test::Harness 3 change. It doesn't understand the > > #!./parrot > > lines at the top of some of the tests. > > > It's actually Perl that handles the ./parrot shebang. Test::Harness just asks > Perl to run the test. > > It looks as if ./parrot doesn't like the -I switches. But that's odd because > Test::Harness 2.64 passed them too. Oh, there may well be something far more subtle going on underneath, but I observed this when I tried T::H 2.99_02 about two months ago (and I reported it at the time) and it went away when I uninstalled T::H 2.99_02. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #47453] make test errors (likely test harness related)
On 14 Nov 2007, at 23:11, Andy Dougherty wrote:
That's a Test::Harness 3 change. It doesn't understand the
#!./parrot
lines at the top of some of the tests.
It's actually Perl that handles the ./parrot shebang. Test::Harness
just asks Perl to run the test.
It looks as if ./parrot doesn't like the -I switches. But that's odd
because Test::Harness 2.64 passed them too.
I've just done a little experiment. Here's my test:
[02:16] andy $ cat parrot.t
#!./parrot
... does nothing ...
Here's my (rather minimal) Parrot implementation:
[02:16] andy $ cat ./parrot
#!/alt/local/bin/perl
warn "# ", join(' ', @ARGV), "\n";
print "1..1\nok 1\n";
Here's what it says with Test::Harness 2.64:
[02:16] andy $ perl -Ireference/Test-Harness-2.64/lib reference/Test-
Harness-2.64/bin/prove -vb parrot.t
parrot# -Iblib/arch -Iblib/lib parrot.t
1..1
ok 1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00
CPU)
And here with Test::Harness 3.01:
[02:16] andy $ prove -vb parrot.t
parrot..
1..1
ok 1
# -I/Users/andy/Works/Perl/TAPx-Parser/tapx/trunk/blib/lib -I/Users/
andy/Works/Perl/TAPx-Parser/tapx/trunk/blib/arch parrot.t
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU)
Result: PASS
The only difference seems to be that T::H 3.01 makes the paths absolute.
If I get time tomorrow I'll install parrot on this machine and try it
for real.
--
Andy Armstrong, Hexten
Re: [perl #47453] make test errors (likely test harness related)
On 15 Nov 2007, at 02:43, Andrew Dougherty wrote: It looks as if ./parrot doesn't like the -I switches. But that's odd because Test::Harness 2.64 passed them too. Oh, there may well be something far more subtle going on underneath, but I observed this when I tried T::H 2.99_02 about two months ago (and I reported it at the time) and it went away when I uninstalled T::H 2.99_02. That's a pretty compelling smoking gun :) I'm checking out parrot now... -- Andy Armstrong, Hexten
Re: [perl #47397] t/op/arithmetics.t hangs
On Wed, 14 Nov 2007, Paul Cochrane wrote: > The float_equals warnings in gcc *are* off. So why is this warning a > problem (maybe I've missed something)? They used to be on. I don't know when they were turned off. The workaround in was put in place to try to silence the warnings. When the warning was removed, the workaround was not. >I also don't see over 1000 > warnings with gcc (I've got gcc 3.4.5 on Gentoo Linux x86); I have in > the order of 100 atm. If we *are* seeing over 1000 warnings with gcc, > then either we should turn the warnings level down a bit, or the > warnings should be fixed (like some warnings about required non-null > arguments I know). Here are the warnings I got on my latest run, along with the number of times each one appeared: (this was with gcc-4.1.0 on Solaris/SPARC) 689 visibility attribute not supported in this configuration; ignored 130 cast increases required alignment of target type 66 switch missing default case 65 dereferencing type-punned pointer will break strict-aliasing rules 56 null argument where non-null required (argument 2) 5 dereferencing type-punned pointer might break strict-aliasing rules 3 return makes pointer from integer without a cast 2 variable 'buffer' might be clobbered by 'longjmp' or 'vfork' 2 request for implicit conversion from 'void *' to 'caddr_t' not permitted in C++ 2 cast discards qualifiers from pointer target type 2 'type' may be used uninitialized in this function 1 value computed is not used 1 unused parameter 'obj_file' 1 request for implicit conversion from 'void *' to 'char *' not permitted in C++ 1 null argument where non-null required (argument 1) 1 nested extern declaration of 'localtime_r' 1 nested extern declaration of 'gmtime_r' 1 nested extern declaration of 'asctime_r' 1 implicit declaration of function 'localtime_r' 1 implicit declaration of function 'gmtime_r' 1 implicit declaration of function 'asctime_r' 1 comparison between signed and unsigned 1 comparison between pointer and integer 1 cast from function call of type 'INTVAL' to non-matching type 'void *' 1 assignment from incompatible pointer type 1 array subscript has type 'char' 1 'type_name' is used uninitialized in this function 1 'old_value' may be used uninitialized in this function 1 'old_blocks' declared 'static' but never defined 1 'is_ins_save' defined but not used 1 'curlog' may be used uninitialized in this function 1 "__STDC_VERSION__" is not defined -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #47397] t/op/arithmetics.t hangs
On Monday 12 November 2007 16:49:18 chromatic wrote:
> > After poking around quite a bit, the following patch fixes it:
> >
> > --- parrot-current/src/ops/experimental.ops Wed Oct 17 19:15:15 2007
> > +++ parrot-andy/src/ops/experimental.opsMon Nov 12 15:13:43 2007
> > @@ -91,7 +91,7 @@
> >FLOATVAL temp2 = fabs($2);
> >FLOATVAL temp3 = fabs($3);
> >
> > - while (!FLOAT_IS_ZERO(temp3)) {
> > + while (temp3 != 0.0) {
> > q = floor((FLOATVAL)temp2/temp3);
> > c = temp2 - temp3*q;
> > temp2 = temp3;
> >
> > It may well be there's an issue with gcc's optimizer, since the problem
> > goes away without optimization, but I think it's also fair to say that
> > the definition of FLOAT_IS_ZERO in include/parrot/misc.h is
> > perhaps not optimal here. I'd prefer the simpler definition:
> >
> > #define FLOAT_IS_ZER0(f) ((f) == 0.0)
> >
> > but I didn't get anywhere last time I proposed that. I don't know
> > what else to do.
Applied as r22820, thanks!
-- c
