[perl #40801] [TODO] Rename enter_nci_method to something better
# New Ticket Created by Matt Diephouse # Please include the string: [perl #40801] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40801 enter_nci_method is poorly named. It sounds like it's entering the method to execute it. What it's actually doing is entering the method into a symbol table somewhere. That makes reading the source difficult when you're not familiar with the function. It should be renamed to something less confusing. Perhaps add_nci_method? -- Matt Diephouse
[perl #40803] [BUG] 'make' fails on Darwin at -lgmp
# New Ticket Created by James Keenan # Please include the string: [perl #40803] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40803 This transaction appears to have no content parrot.make.output Description: Binary data myconfig Description: Binary data
Re: [perl #40793] AutoReply: [PATCH] outdated wiki irc links in docs/gettingstarted.pod
D'oh. Newbie move. === CREDITS == --- CREDITS (revision 331) +++ CREDITS (local) @@ -411,6 +411,10 @@ N: Richard Tibbetts D: Divide by zero exceptions in some PMCs +N: Rick Scott +D: Documentation patch +E: [EMAIL PROTECTED] + N: Ritz Daniel N: Robert Spier === docs/gettingstarted.pod == --- docs/gettingstarted.pod (revision 331) +++ docs/gettingstarted.pod (local) @@ -226,13 +226,12 @@ The mailing list is the main resource for Parrot development. However, there is an IRC channel which you may find useful if your problem is better solved -with real-time discussion. To find this channel, visit the channel #parrot in -the following IRC servers (either one will do): +with real-time discussion. Visit the channel #parrot on the IRC +server Lirc.perl.org. Alternative IRC servers are +Lirc.rhizomatic.net and Lirc.pobox.com. -Lirc.rhizomatic.net or Lirc.pobox.com - =head2 I've developed a patch. What should I do with it? There's a lot of traffic that goes through the mailing list, and it's quite @@ -277,23 +276,22 @@ =over 4 -=item * Experimental Parrot Wiki +=item * Parrot Wiki -Located at: +Lhttp://rakudo.org/parrot/ -Lhttp://www.vendian.org/parrot/wiki/ - -A collection of various other pieces of useful Parrot information and -documentation that have yet to make it into the SVN repository. Includes a -comprehensive guide to getting started with Parrot development (called, -unsurprisingly, 'Getting Started with Parrot Development'). - =back =head1 VERSION =over 4 +=item Revision 0.2 - 10 November 2006 + +Remove link to old wiki page (dead since 2004). + +Add irc.perl.org IRC server. + =item Revision 0.1 - 27 July 2002 Written to prepare for the fallout from TPC 6.
Re: [perl #40803] [BUG] 'make' fails on Darwin at -lgmp
I believe that the attachment containing your make output was truncated. Can you try again or just inline the make error(s)? Thanks, -J -- On Fri, Nov 10, 2006 at 06:10:42PM -0800, James Keenan wrote: # New Ticket Created by James Keenan # Please include the string: [perl #40803] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40803 This transaction appears to have no content pgpfRoTBB2miJ.pgp Description: PGP signature
Re: [perl #40803] [BUG] 'make' fails on Darwin at -lgmp
On Nov 11, 2006, at 5:56 AM, Joshua Hoblitt via RT wrote: I believe that the attachment containing your make output was truncated. Can you try again or just inline the make error(s)? See below. It should be noted that I upgraded to GMP 4.2.1. before trying to build Parrot (or, more precisely, after the first attempt at building Parrot failed). This is not the first time I've had problems with GMP; see http://perlmonks.org/?node_id=543267. ## OUTPUT OF 'make' ### Compiling with: xx.c cc -I./include -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe -fno-common -Wno-long-double -g -W -Wall -Wstrict-prototypes - Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual -Wwrite- strings -Waggregate-return -Winline -Wno-unused -Wsign-compare - falign-functions=16 -Wformat-nonliteral -Wformat-security -Wpacked - Wdisabled-optimization -Wno-shadow -DHAS_JIT -DPPC - DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c perl -MExtUtils::Command -e mkpath blib/lib c++ -dynamiclib -undefined suppress -L/usr/local/lib -L/Users/jimk/ work/parrot/blib/lib -flat_namespace -o blib/lib/libparrot. 0.4.6.dylib -install_name /usr/local/lib/libparrot.dylib \ src/ops/core_ops.o src/ops/core_ops_switch.o src/asmfun.o src/ ops/core_ops_cg.o src/ops/core_ops_cgp.o src/exec.o src/exec_cpu.o src/exec_save.o src/charset.o src/encoding.o src/exceptions.o src/ global_setup.o src/interpreter.o src/inter_call.o src/inter_cb.o src/ inter_create.o src/inter_misc.o src/inter_run.o src/register.o src/ memory.o src/objects.o src/packfile.o src/stacks.o src/stack_common.o src/string.o src/string_primitives.o src/sub.o src/runops_cores.o src/ trace.o src/pmc.o src/pmc_freeze.o src/key.o src/hash.o src/ core_pmcs.o src/platform.o src/jit.o src/jit_cpu.o src/jit_debug.o src/jit_debug_xcoff.o src/intlist.o src/list.o src/library.o src/ global.o src/embed.o src/warnings.o src/packout.o src/byteorder.o src/ debug.o src/smallobject.o src/headers.o src/hll.o src/dod.o src/ gc_ims.o src/gc_gms.o src/exit.o src/misc.o src/spf_render.o src/ spf_vtable.o src/datatypes.o src/fingerprint.o src/nci.o src/ cpu_dep.o src/tsq.o src/longopt.o src/events.o src/thread.o src/ dynext.o src/utils.o src/vtables.o src/pic.o src/pic_jit.o src/mmd.o src/builtin.o src/extend.o src/extend_vtable.o src/revision.o src/ packfile/pf_items.o src/stm/backend.o src/stm/waitlist.o src/ resources.o src/charset/ascii.o src/charset/binary.o src/charset/ iso-8859-1.o src/charset/tables.o src/charset/unicode.o src/io/io.o src/io/io_buf.o src/io/io_layers.o src/io/io_unix.o src/io/io_utf8.o src/io/io_mmap.o src/io/io_win32.o src/io/io_stdio.o src/io/ io_string.o src/io/io_passdown.o src/pmc/default.o src/pmc/null.o src/ pmc/env.o src/pmc/key.o src/pmc/random.o src/pmc/unmanagedstruct.o src/pmc/managedstruct.o src/pmc/delegate.o src/pmc/csub.o src/pmc/ compiler.o src/pmc/exception.o src/pmc/version.o src/pmc/ vtablecache.o src/pmc/parrotio.o src/pmc/parrotlibrary.o src/pmc/ parrotinterpreter.o src/pmc/parrotthread.o src/pmc/lexpad.o src/pmc/ timer.o src/pmc/pointer.o src/pmc/sub.o src/pmc/closure.o src/pmc/ continuation.o src/pmc/retcontinuation.o src/pmc/exception_handler.o src/pmc/coroutine.o src/pmc/eval.o src/pmc/nci.o src/pmc/float.o src/ pmc/integer.o src/pmc/bigint.o src/pmc/complex.o src/pmc/string.o src/ pmc/boolean.o src/pmc/ref.o src/pmc/sharedref.o src/pmc/array.o src/ pmc/fixedintegerarray.o src/pmc/intlist.o src/pmc/iterator.o src/pmc/ sarray.o src/pmc/fixedstringarray.o src/pmc/multiarray.o src/pmc/ hash.o src/pmc/orderedhash.o src/pmc/tqueue.o src/pmc/parrotclass.o src/pmc/parrotobject.o src/pmc/os.o src/pmc/file.o src/pmc/ addrregistry.o src/pmc/bound_nci.o src/pmc/capture.o src/pmc/ deleg_pmc.o src/pmc/enumerate.o src/pmc/fixedbooleanarray.o src/pmc/ fixedfloatarray.o src/pmc/fixedpmcarray.o src/pmc/lexinfo.o src/pmc/ multisub.o src/pmc/namespace.o src/pmc/pair.o src/pmc/ parrotrunningthread.o src/pmc/resizablebooleanarray.o src/pmc/ resizablefloatarray.o src/pmc/resizableintegerarray.o src/pmc/ resizablepmcarray.o src/pmc/resizablestringarray.o src/pmc/scalar.o src/pmc/slice.o src/pmc/stmlog.o src/pmc/stmref.o src/pmc/stmvar.o src/pmc/super.o src/pmc/undef.o src/encodings/fixed_8.o src/encodings/ ucs2.o src/encodings/utf16.o src/encodings/utf8.o compilers/imcc/ imcparser.o compilers/imcc/imclexer.o compilers/imcc/imc.o compilers/ imcc/symreg.o compilers/imcc/instructions.o compilers/imcc/cfg.o compilers/imcc/reg_alloc.o compilers/imcc/sets.o compilers/imcc/ debug.o compilers/imcc/optimizer.o compilers/imcc/pbc.o compilers/ imcc/parser_util.o compilers/imcc/pcc.o compilers/ast/astparser.o compilers/ast/astlexer.o compilers/ast/ast_main.o compilers/ast/ node.o -lm -lgmp ## END OUTPUT OF 'make' ## ## OUTPUT OF 'myconfig' CREATED BY ./Configure.pl ## Summary of my parrot 0.4.6 (r15342) configuration: configdate='Fri Nov 10
Re: [perl #40803] [BUG] 'make' fails on Darwin at -lgmp
On Nov 11, 2006, at 5:56 AM, Joshua Hoblitt via RT wrote: I believe that the attachment containing your make output was truncated. Can you try again or just inline the make error(s)? See below. It should be noted that I upgraded to GMP 4.2.1. before trying to build Parrot (or, more precisely, after the first attempt at building Parrot failed). This is not the first time I've had problems with GMP; see http://perlmonks.org/?node_id=543267. ## OUTPUT OF 'make' ### Compiling with: xx.c cc -I./include -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe -fno-common -Wno-long-double -g -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual -Wwrite-strings -Waggregate-return -Winline -Wno-unused -Wsign-compare -falign-functions=16 -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -Wno-shadow -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c perl -MExtUtils::Command -e mkpath blib/lib c++ -dynamiclib -undefined suppress -L/usr/local/lib -L/Users/jimk/work/parrot/blib/lib -flat_namespace -o blib/lib/libparrot.0.4.6.dylib -install_name /usr/local/lib/libparrot.dylib \ src/ops/core_ops.o src/ops/core_ops_switch.o src/asmfun.o src/ops/core_ops_cg.o src/ops/core_ops_cgp.o src/exec.o src/exec_cpu.o src/exec_save.o src/charset.o src/encoding.o src/exceptions.o src/global_setup.o src/interpreter.o src/inter_call.o src/inter_cb.o src/inter_create.o src/inter_misc.o src/inter_run.o src/register.o src/memory.o src/objects.o src/packfile.o src/stacks.o src/stack_common.o src/string.o src/string_primitives.o src/sub.o src/runops_cores.o src/trace.o src/pmc.o src/pmc_freeze.o src/key.o src/hash.o src/core_pmcs.o src/platform.o src/jit.o src/jit_cpu.o src/jit_debug.o src/jit_debug_xcoff.o src/intlist.o src/list.o src/library.o src/global.o src/embed.o src/warnings.o src/packout.o src/byteorder.o src/debug.o src/smallobject.o src/headers.o src/hll.o src/dod.o src/gc_ims.o src/gc_gms.o src/exit.o src/misc.o src/spf_render.o src/spf_vtable.o src/datatypes.o src/fingerprint.o src/nci.o src/cpu_dep.o src/tsq.o src/longopt.o src/events.o src/thread.o src/dynext.o src/utils.o src/vtables.o src/pic.o src/pic_jit.o src/mmd.o src/builtin.o src/extend.o src/extend_vtable.o src/revision.o src/packfile/pf_items.o src/stm/backend.o src/stm/waitlist.o src/resources.o src/charset/ascii.o src/charset/binary.o src/charset/iso-8859-1.o src/charset/tables.o src/charset/unicode.o src/io/io.o src/io/io_buf.o src/io/io_layers.o src/io/io_unix.o src/io/io_utf8.o src/io/io_mmap.o src/io/io_win32.o src/io/io_stdio.o src/io/io_string.o src/io/io_passdown.o src/pmc/default.o src/pmc/null.o src/pmc/env.o src/pmc/key.o src/pmc/random.o src/pmc/unmanagedstruct.o src/pmc/managedstruct.o src/pmc/delegate.o src/pmc/csub.o src/pmc/compiler.o src/pmc/exception.o src/pmc/version.o src/pmc/vtablecache.o src/pmc/parrotio.o src/pmc/parrotlibrary.o src/pmc/parrotinterpreter.o src/pmc/parrotthread.o src/pmc/lexpad.o src/pmc/timer.o src/pmc/pointer.o src/pmc/sub.o src/pmc/closure.o src/pmc/continuation.o src/pmc/retcontinuation.o src/pmc/exception_handler.o src/pmc/coroutine.o src/pmc/eval.o src/pmc/nci.o src/pmc/float.o src/pmc/integer.o src/pmc/bigint.o src/pmc/complex.o src/pmc/string.o src/pmc/boolean.o src/pmc/ref.o src/pmc/sharedref.o src/pmc/array.o src/pmc/fixedintegerarray.o src/pmc/intlist.o src/pmc/iterator.o src/pmc/sarray.o src/pmc/fixedstringarray.o src/pmc/multiarray.o src/pmc/hash.o src/pmc/orderedhash.o src/pmc/tqueue.o src/pmc/parrotclass.o src/pmc/parrotobject.o src/pmc/os.o src/pmc/file.o src/pmc/addrregistry.o src/pmc/bound_nci.o src/pmc/capture.o src/pmc/deleg_pmc.o src/pmc/enumerate.o src/pmc/fixedbooleanarray.o src/pmc/fixedfloatarray.o src/pmc/fixedpmcarray.o src/pmc/lexinfo.o src/pmc/multisub.o src/pmc/namespace.o src/pmc/pair.o src/pmc/parrotrunningthread.o src/pmc/resizablebooleanarray.o src/pmc/resizablefloatarray.o src/pmc/resizableintegerarray.o src/pmc/resizablepmcarray.o src/pmc/resizablestringarray.o src/pmc/scalar.o src/pmc/slice.o src/pmc/stmlog.o src/pmc/stmref.o src/pmc/stmvar.o src/pmc/super.o src/pmc/undef.o src/encodings/fixed_8.o src/encodings/ucs2.o src/encodings/utf16.o src/encodings/utf8.o compilers/imcc/imcparser.o compilers/imcc/imclexer.o compilers/imcc/imc.o compilers/imcc/symreg.o compilers/imcc/instructions.o compilers/imcc/cfg.o compilers/imcc/reg_alloc.o compilers/imcc/sets.o compilers/imcc/debug.o compilers/imcc/optimizer.o compilers/imcc/pbc.o compilers/imcc/parser_util.o compilers/imcc/pcc.o compilers/ast/astparser.o compilers/ast/astlexer.o compilers/ast/ast_main.o compilers/ast/node.o -lm -lgmp ## END OUTPUT OF 'make' ## ## OUTPUT OF 'myconfig' CREATED BY ./Configure.pl ## Summary of my parrot 0.4.6 (r15342) configuration: configdate='Fri Nov 10 18:24:21 2006' Platform: osname=darwin, archname=darwin-2level
Re: r15330 - in trunk: . compilers/imcc docs docs/pdds include/parrot src
On Fri, Nov 10, 2006 at 10:51:14PM -0500, Bob Rogers wrote: From: [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 11:12:21 -0800 (PST) Author: chip Date: Fri Nov 10 11:12:20 2006 New Revision: 15330 . . . Log: Remove the :maybe_flat feature, which was intended to help Perl 6, but they never used it. Substantially improve editorial quality of pdd03 (++particle). This seems to make t/op/calling.t test #15 fail (titled maybe flatten + slurpy param); the passed arrays are not flattened. Is it OK to just flush it? I've now done so, thanks. -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #34549] atan2() isn't IEEE compliant on OpenBSD/*BSD/Cygwin/Solaris
On Sat, Nov 11, 2006 at 04:02:21AM -0800, Joshua Hoblitt via RT wrote: Is this issue considered resolved for BSD and/or has acceptable test coverage? I believe that things were alright for both OpenBSD and NetBSD. Solaris is still an issue. t/op/trans.t passes when run like perl t/harness t/op/trans.t but fails miserably when run like perl t/harness -v t/op/trans.t Steve Peters [EMAIL PROTECTED] On Tue Mar 21 17:46:51 2006, jisom wrote: It seems I'm mistaking problems. OpenBSD does do atan2 correctly. But, OpenBSD doesn't like printing -0.0. It'll print it as positive. I'm not sure how to get it to print -0 instead of +0. On Mar 21, 2006, at 5:58 PM, Joshua Hoblitt wrote: Steve, What version of OpenBSD were you running (perhaps something old or direct from CVS)? -J -- On Tue, Mar 21, 2006 at 03:13:18PM -0800, Joshua Isom via RT wrote: On OpenBSD 3.8 x86, I still get the failures with -0.0/0.0. Check the smokes... On Mar 21, 2006, at 3:01 PM, Joshua Hoblitt wrote: On Tue, Mar 21, 2006 at 06:42:42AM -0800, Steve Peters via RT wrote: [jhoblitt - Sun Jan 01 18:49:23 2006]: I've commited a possible fix for openbsd, cygwin, solaris as changesets r10839 r10843. I basically applied what Steve Peters proposed but with the changes in math.c instead of creating init.c (as agreed to on #parrot). This doesn't appear to have done anything for gcc/solaris... can someone test openbsd and cygwin? These changes fixed OpenBSD and were used with NetBSD to allow it to pass all of its tests. That leaves the issue open for Solaris and Cygwin. Fantastic. Thanks for the update. Can someone test this on Cygwin? -J --
Re: [perl #40803] [BUG] 'make' fails on Darwin at -lgmp
On Saturday 11 November 2006 05:37, James E Keenan wrote: For what it's worth, Jerry and James and I tracked this down to some weird options coming from the Perl 5 compile-time configuration (Config.pm). ## OUTPUT OF 'myconfig' CREATED BY ./Configure.pl ## Summary of my parrot 0.4.6 (r15342) configuration: configdate='Fri Nov 10 18:24:21 2006' Platform: osname=darwin, archname=darwin-2level jitcapable=1, jitarchname=ppc-darwin, jitosname=DARWIN, jitcpuarch=ppc execcapable=1 perl=perl Compiler: cc='cc', ccflags='-fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe -fno-common -Wno-long-double ', Linker and Libraries: ld='c++', There's one weirdness. The output here doesn't show the value of lddl_flags (or something like that), which contains the invalid option '-bundle'. -- c
[perl #40817] [TODO] track generated files during the configure/make process
# New Ticket Created by Jerry Gay # Please include the string: [perl #40817] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40817 arguably the best way to track which files are generated during parrot's configure/build process is to append each file to a list when it is created. so, we need some makefile hackery in order to do this during build-time, and some config hackery to do it during configure-time. this would replace the MANIFEST.generated file which is created ex post facto with a file that is created at build-time. ~jerry
[perl #40819] [TODO] Remove Duplication in t/codingstd/*.t Files
# New Ticket Created by chromatic # Please include the string: [perl #40819] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40819 There's some duplication in the coding standards tests, specifically the source_files() subroutine. This should move into a single place to update. -- c
[perl #40822] Pg NCI Test Makes Unportable Connection
# New Ticket Created by chromatic
# Please include the string: [perl #40822]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40822
t/library/pg.t fails pretty miserably on this line:
con = cl.'connectdb'('') # assume table = user is present
I have PostgreSQL installed, but this assumption doesn't work for me. I've
checked in a skip for the remaining tests in this case, as there's no point
in running them. (They cause NCI assertion failures, as the NULL connection
isn't what NCI expects to pass to the Pg functions.)
This test needs another approach to run on multiple platforms successfully.
Setting an environment variable for user name and password might work better.
-- c
generic ordinal-relevant operators
Hello, Considering this context of comparison operators: Generic Num Str --- =:= # equality (container) !=:= # negated equality (container) === # equality (value, eternal semantics) !=== # negated equality (value, eternal semantics) eqv ==eq# equality (value, snapshot semantics) !eqv !== !eq # negated equality (value, snapshot semantics) !=ne# traditional shortcuts for previous lt# less than gt# greater than =le# less than or equal to =ge# greater than or equal to cmp = leg # lt = -1, eq = 0, gt = +1 ~~# smart match (see smartmatch) !~~ # negated smart match It stands out that there seems to be no generic ordinal-relevant operators specifically for less-than, greater-than, etc, while there are such that cast their arguments as Num or Str. While one can still emulate such operators on generic types using cmp (whose existence I am very glad for), I would like to propose that explicit less-than, greater-than etc exist partly for reasons of parity, so for example, one can take for example 2 Date-representing types and ask simply if one is earlier than the other, etc, and do this within the native type. For simplicity, these operators would just work using snapshot semantics as, AFAIK, cmp and the Num and Str specific operators do. Barring any better suggestions for names of such operators, I suggest we could follow a precedent laid down by eqv and name them: ltv, gtv, lev, gev (and also nev if that is useful); and we have visual consistency in that way. On a tangential matter, I believe there should also be generic 'min' and 'max' type operators for all ordinal types, which would be useful in list summarizing activities; they would return the value from a list that would sort first or last. I don't see the reduce meta-operator as being applicable to this, since reducing using less-than eg, will return a boolean result. Unlike, say, 'avg' or 'sum', 'min' and 'max' are conceptually generic to all ordinal types. So, is this workable? -- Darren Duncan
[perl #40823] Win32 vs. the world - length for sprintf('%e') - what's right?
# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #40823]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40823
Please somebody figure out what Perl does on Win32 for testing sprintf,
because the Perl sprintf test suite seems to think that the right value
for sprintf('%e',1) is 1e+00, but Win32 seems to return 1e+000 (note
the extra digit in the exponent). Is this true? If so, is it a bug? In
any case, how does the Perl test suite not fail on Win32?
--
Chip Salzenberg [EMAIL PROTECTED]
[perl #40824] loadlib opcode causes problems with exceptions
# New Ticket Created by Matt Diephouse # Please include the string: [perl #40824] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40824 If a loadlib fails, it doesn't throw a catchable exception. The t/ library/pg.t test was changed because it was failing on platforms where pg wasn't available. In particular, this assertion was getting tripped on: src/inter_call.c:122: failed assertion `PObj_is_PMC_TEST(sig_pmc) sig_pmc-vtable-base_type == enum_class_FixedIntegerArray' Abort trap The fix was this patch: === t/library/pg.t == --- t/library/pg.t (revision 23578) +++ t/library/pg.t (local) @@ -32,6 +32,10 @@ test = new 'Test::Builder' test.'plan'(N_TESTS) push_eh no_pg + + # TODO: fix when exception handling works again +loadlib $P0, 'libpq' +unless $P0 goto no_pg load_bytecode 'postgres.pir' clear_eh test.'ok'(1, 'load_bytecode') -- Matt Diephouse
Re: generic ordinal-relevant operators
Darren Duncan wrote:
Considering this context of comparison operators:
Generic Num Str
---
=:= # equality (container)
!=:= # negated equality (container)
=== # equality (value, eternal semantics)
!=== # negated equality (value, eternal semantics)
eqv ==eq# equality (value, snapshot semantics)
!eqv !== !eq # negated equality (value, snapshot semantics)
!=ne# traditional shortcuts for previous
Remind me again why it's a good idea to have distinct eqv, ==, and eq
operators, and for == to represent the numeric equivalence test
instead of an argument-based equivalence test?
Personally, I'd rather replace ('eqv', '==', 'eq') with either ('==',
'+==', '~==') or just '=='. In the latter case, the current '==' and
'eq' semantics could be preserved by applying the unary '+' or '~'
operators to both operands: as I understand it, $a == $b is
semantically indistinguishable from +$a eqv +$b.
In terms of ordinal types, '', '', '=', and '=' would be the
generic ordinal comparators, and you'd do the same sort of implicit
or explicit type coercion that's done with '=='. Mind you, if you go
with the ('==', '+==', '~==') set of equivalence operators, '+' and
'+' would now mean numerically greater than and numerically less
than, respectively, and the shift-right and shift-left operators
would have to be relabelled (e.g., to '+' and '+').
Likewise, ('cmp', '=', 'leg') would become ('=', '+=', '~='),
or just '='.
(Technically, the existence of '+==' and '~==' would imply the
existence of '?==' for completeness sake; but I can't think of any
reasonable case where '?==' would be used.)
While one can still emulate such operators on generic types using cmp
(whose existence I am very glad for), I would like to propose that
explicit less-than, greater-than etc exist partly for reasons of
parity, so for example, one can take for example 2 Date-representing
types and ask simply if one is earlier than the other, etc, and do
this within the native type.
Agreed. If we assume that the semantics of '==' are non-negotiable, then:
Barring any better suggestions for names of such operators, I suggest
we could follow a precedent laid down by eqv and name them: ltv, gtv,
lev, gev (and also nev if that is useful); and we have visual
consistency in that way.
My problem with these is the alphabet soup mentality that they entail:
'eq' meaning string-based equivalence makes _some_ sense because
'eq' is composed of letters and strings are composed of letters; but
even here, there's cognitive dissonance as my brain sees things like
'=' vs. 'leg' and has to reconcile them as being essentially the
same thing. Extending this to generic ordinal comparisons aggravates
the problem without even the tenuous use letters to compare letters
reasoning to back it up. If you're going to use letter-based
operators, follow the precedence set by 'cmp' (which abbreviates
'compare'): use something like 'before' and 'after' for the generic
versions of '' and ''. Better, ditch the letter soup entirely: in
reverse analogy to my original suggestion, use a '*' leading character
to denote the generic comparators: '*', '*', '*=', and '*='.
On a tangential matter, I believe there should also be generic 'min'
and 'max' type operators for all ordinal types, which would be useful
in list summarizing activities; they would return the value from a
list that would sort first or last.
Agreed.
I don't see the reduce
meta-operator as being applicable to this, since reducing using
less-than eg, will return a boolean result.
And rightfully so: '[] $a, $b, $c, ...' is asking are these
arguments in a strictly decreasing order? which is a perfectly valid
question to ask.
Unlike, say, 'avg' or
'sum', 'min' and 'max' are conceptually generic to all ordinal types.
And they're more readable (and probably faster) than 'sort(...)[0]'
and 'sort(...)[-1]', which would accomplish the same thing.
In effect, we're talking about an Ordinal role, which would package
together the generic ordinal comparators ('*', '*', '*=', '*=',
and 'cmp'), along with 'sort', 'min', and 'max'.
Tangentially related, I'd like to suggest that the negation
meta-operator be generalized from comparison operators to any binary
operator that returns a boolean value (or possibly even to any
operator that returns a boolean value, so that '!?$x' would mean
coerce to boolean, then negate its value).
--
Jonathan Dataweaver Lang
[perl #40824] loadlib opcode causes problems with exceptions
From: Matt Diephouse (via RT) [EMAIL PROTECTED] Date: Sat, 11 Nov 2006 16:46:20 -0800 If a loadlib fails, it doesn't throw a catchable exception. The t/ library/pg.t test was changed because it was failing on platforms where pg wasn't available. In particular, this assertion was getting tripped on: src/inter_call.c:122: failed assertion `PObj_is_PMC_TEST(sig_pmc) sig_pmc-vtable-base_type == enum_class_FixedIntegerArray' Abort trap I don't think it's loadlib itself; I believe the library :init code is trying to throw an error. If that is the case, then it's a continuation barrier problem. Before the error, do you see this oops message? [EMAIL PROTECTED] ./parrot t/library/pg.t 1..43 [oops; continuation 0x81e4d64 of type 25 is trying to jump from runloop 9 to runloop 1] not ok 1 #skip skipped not ok 2 #skip skipped not ok 3 #skip skipped not ok 4 #skip skipped not ok 5 #skip skipped . . . The :init code in runtime/parrot/library/postgres.pir is running in a separate runloop, so when it throws an error, the error doesn't actually get to the handler, and the loadlib op appears to complete normally. I don't recall seeing this failed assertion before, though. Probably we should turn this oops into an internal_exception, since memory might be getting corrupted subsequently. The fix was this patch . . . Looks good to me. I see chromatic has already committed this as r15413. -- Bob Rogers http://rgrjr.dyndns.org/
[perl #40826] Mac OS X and Dylib Funcs
# New Ticket Created by chromatic # Please include the string: [perl #40826] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40826 Hi there, config/gen/platform/darwin/dl.c contains some portability wrappers around NS* functions to handle dlopen(), dlfunc(), dlerror(), and related functions. They're important for Mac OS X 10.2 and earlier. Mac OS X 10.3 deprecated these functions in favor of the normal lovable functions themselves. They work better in at least one interesting way (when you pass NULL to dlopen(), you get back a handle to the current program). I've removed the single test that apparently relies on this, so it's not a big deal. However, it is a portability question; the Darwin hinter should probably pick up the correct dl.c file depending on the version of the OS. -- c
[perl #40827] [BUG] testing alarm with exception handlers causes runloops to play leapfrog
# New Ticket Created by Jerry Gay # Please include the string: [perl #40827] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40827 the code below is broken while testing alarm with exception handlers. i wish i could debug it, but it hurts my brain. maybe somebody smart (bob?) about exception handlers can have a look and tell me what's what. ~jerry OUTPUT: parrot t-alarm.pir 1..3 [oops; continuation 005B6B08 of type 25 is trying to jump from runloop 10 to run loop 1] ok 1 not ok 2 1 current instr.: 'alarm_handler' pc 128 (t-alarm.pir:69) called from Sub 'alarm_is' pc 78 (t-alarm.pir:40) called from Sub 'main' pc 53 (t-alarm.pir:16) CODE: #!./parrot ## load the dynamic opcode library that contains 'alarm' .loadlib 'myops_ops' .sub 'main' :main load_bytecode 'Test/More.pir' .local pmcplan plan = get_global ['Test::More'], 'plan' plan(3) 'alarm_is'( 3.0, 3.0, 1, 1, 'alarm: set: 3.0; check: 3.0; true' ) 'alarm_is'( 3.0, 4.0, 1, 2, 'alarm: set: 3.0; check: 4.0; true' ) 'alarm_is'( 3.0, 2.0, 0, 3, 'alarm: set: 3.0; check: 2.0; false' ) .end .sub 'alarm_is' .param numset ## this value is used to set the alarm .param numcheck## this is how long the test waits .param intexpected .param inttestnum .param string desc :optional .param inthas_desc :opt_flag .local pmcis is = get_global ['Test::More'], 'is' .local num time_start time_start = time .local numtime_check .local intresult .const .Sub alarm_handler = 'alarm_handler' alarm set, alarm_handler push_eh test loop: time_check = time time_check -= time_start if time_check = set goto end_loop sleep 1 goto loop end_loop: $P0 = new .Exception $P0[0] = 0 throw $P0 test: .local pmc exception .local int result get_results '0,0', exception, result eq result, expected, ok nok: print 'not ' ok: print 'ok ' print testnum print \n .end .sub 'alarm_handler' $P0 = new .Exception $P0[0] = 1 throw $P0 .end
Re: [perl #40824] loadlib opcode causes problems with exceptions
On Saturday 11 November 2006 19:01, Bob Rogers wrote: I don't think it's loadlib itself; I believe the library :init code is trying to throw an error. If that is the case, then it's a continuation barrier problem. Before the error, do you see this oops message? Yes, and agreed. Matt and I discussed that just after he sent the message. I don't recall seeing this failed assertion before, though. Probably we should turn this oops into an internal_exception, since memory might be getting corrupted subsequently. The fix was this patch . . . Looks good to me. I see chromatic has already committed this as r15413. It just gets the test to pass; there are still outstanding questions with regard to exceptions and continuations and the C barrier. -- c
Re: generic ordinal-relevant operators
At 5:24 PM -0800 11/11/06, Jonathan Lang wrote:
Remind me again why it's a good idea to have distinct eqv, ==, and eq
operators, and for == to represent the numeric equivalence test
instead of an argument-based equivalence test?
Personally, I'd rather replace ('eqv', '==', 'eq') with either ('==',
'+==', '~==') or just '=='. In the latter case, the current '==' and
'eq' semantics could be preserved by applying the unary '+' or '~'
operators to both operands: as I understand it, $a == $b is
semantically indistinguishable from +$a eqv +$b.
In terms of ordinal types, '', '', '=', and '=' would be the
generic ordinal comparators, and you'd do the same sort of implicit
or explicit type coercion that's done with '=='. Mind you, if you go
with the ('==', '+==', '~==') set of equivalence operators, '+' and
'+' would now mean numerically greater than and numerically less
than, respectively, and the shift-right and shift-left operators
would have to be relabelled (e.g., to '+' and '+').
Likewise, ('cmp', '=', 'leg') would become ('=', '+=', '~='),
or just '='.
snip
Better, ditch the letter soup entirely: in
reverse analogy to my original suggestion, use a '*' leading character
to denote the generic comparators: '*', '*', '*=', and '*='.
I like that proposal a lot, in principle, as it gives us a lot more
flexability and visual consistency. I hope that @Larry can get
behind something like it.
One detail to work out is whether we use * etc or etc for the
generic. Either option has its advantages or disadvantages.
(Whatever's chosen and any renaming fall-out from that, I don't think
a main operator can contain a or like your bit-shift examples
since those could be confused with hyper-operators.)
(Technically, the existence of '+==' and '~==' would imply the
existence of '?==' for completeness sake; but I can't think of any
reasonable case where '?==' would be used.)
I don't see that it would be a bad thing. Even if little used, it
does make conceptual sense. ?== checks if both arguments are the
same truth-wise, and !?== checks if they are different. Assuming we
defined for repeatable ordering purposes that False True (which is
consistent with any common string or numifications of booleans), then
? et al produce predictable results.
If we assume that the semantics of '==' are non-negotiable, then:
Barring any better suggestions for names of such operators, I suggest
we could follow a precedent laid down by eqv and name them: ltv, gtv,
lev, gev (and also nev if that is useful); and we have visual
consistency in that way.
My problem with these is the alphabet soup mentality that they entail:
'eq' meaning string-based equivalence makes _some_ sense because
'eq' is composed of letters and strings are composed of letters; but
even here, there's cognitive dissonance as my brain sees things like
'=' vs. 'leg' and has to reconcile them as being essentially the
same thing. Extending this to generic ordinal comparisons aggravates
the problem without even the tenuous use letters to compare letters
reasoning to back it up. If you're going to use letter-based
operators, follow the precedence set by 'cmp' (which abbreviates
'compare'): use something like 'before' and 'after' for the generic
versions of '' and ''.
I agree. And in fact, once we have a third column of order-determing
operators rather than just Num + Str, the arrangement of some
alphabetic and some not comes to look positively ugly. So better to
make them all alpha or all non, and it would seem non is better. So
== and and so on for all comparing operators. (And as an aside, we
get rid of !ne.)
In effect, we're talking about an Ordinal role, which would package
together the generic ordinal comparators ('*', '*', '*=', '*=',
and 'cmp'), along with 'sort', 'min', and 'max'.
Yes. And I was thinking about an Ordinal role before too.
Logically, some types are ordinal (eg, numbers (except complex?),
strings, dates), or could be assigned a canonical ordinal form (eg,
booleans, bits) and some are simply not ordinal (probably eg, a
polygon or a collection type).
So, while it could make sense to have an Ordinal role, which types
individually can .does(), and only those have , , =, =, =, min,
max, sort, etc, there is the question about how to handle types that
don't .does() Ordinal in some generic situations. Either they fail,
or there is some sort of fallback provided by Object, such as they
end up sorting on their memory addresses; but in the latter case, we
don't need an Ordinal role because every type will be doing it in
some fashion or other due to Object's defaults.
Tangentially related, I'd like to suggest that the negation
meta-operator be generalized from comparison operators to any binary
operator that returns a boolean value (or possibly even to any
operator that returns a boolean value, so that '!?$x' would mean
coerce to boolean, then negate its value).
If I'm not mistaken, the
[perl #40827] [BUG] testing alarm with exception handlers causes runloops to play leapfrog
From: Jerry Gay (via RT) [EMAIL PROTECTED] Date: Sat, 11 Nov 2006 19:15:52 -0800 the code below is broken while testing alarm with exception handlers. i wish i could debug it, but it hurts my brain. maybe somebody smart (bob?) about exception handlers can have a look and tell me what's what. ~jerry Thanks for the plug, but this is my first look at events, where I'm definitely *not* smart. However, I do see that do_event in src/events.c is indeed calling an inferior runloop to run the event sub. And that means that throwing an exception from the alarm sub just won't work. But should we expect it work? In general, timer code can't assume that the right handler will get control. You may have bound a handler that you expect will catch the error, but what if some other module you are using happens to bind an overly-general handler at just the wrong moment? It just doesn't seem robust. Of course, this doesn't really apply to your test script. And exceptions in timer events really ought to work in any case. But the right way to fix it involves turning a nontrivial amount of src/events.c code inside out, and I don't yet have a good way to do that. Thanks for pointing this out, though; I will factor this case into my thinking on this problem. -- Bob Rogers http://rgrjr.dyndns.org/ P.S. For the record, it would not be hard to teach Continuation:invoke to cross runloop barriers for exception handling (among others), since such continuations can only go down the stack. But I've been resisting the temptation, since we'd still need to do the same code rewriting to support upward continuations, including coroutines. Inferior runloops are evil.
Re: generic ordinal-relevant operators
Darren Duncan wrote:
Jonathan Lang wrote:
In terms of ordinal types, '', '', '=', and '=' would be the
generic ordinal comparators, and you'd do the same sort of implicit
or explicit type coercion that's done with '=='. Mind you, if you go
with the ('==', '+==', '~==') set of equivalence operators, '+' and
'+' would now mean numerically greater than and numerically less
than, respectively, and the shift-right and shift-left operators
would have to be relabelled (e.g., to '+' and '+').
-snip-
Better, ditch the letter soup entirely: in
reverse analogy to my original suggestion, use a '*' leading character
to denote the generic comparators: '*', '*', '*=', and '*='.
I like that proposal a lot, in principle, as it gives us a lot more
flexability and visual consistency. I hope that @Larry can get
behind something like it.
Note that this is two competing suggestions: one where '==' means
'generic equivalence', '+==' means 'numeric equivalence', and '*=='
means 'string equivalence'; and another where '*==' means 'generic
equivalence', '==' means 'numeric equivalence', and 'eq' means 'string
equivalence' (with '', '', etc. following suit). The goal of the
second proposal is to leave existing operator names unchanged, while
the goal of the first proposal is to provide a consistent and
intuitive naming convention.
One detail to work out is whether we use * etc or etc for the
generic. Either option has its advantages or disadvantages.
(Whatever's chosen and any renaming fall-out from that, I don't think
a main operator can contain a or like your bit-shift examples
since those could be confused with hyper-operators.)
Yes and no; binary hyper-operators require double arrows on both
sides, so it's possible that the parser _could_ distinguish
double-angle bit-shift operators from hyper-operators. Still, for the
sake of clarity, I could see basing bit-shifting off of thin-tailed
arrowheads: '+-' and '+-'. Note that this isn't a problem with the
'*' model: '*' would be a generic less-than; '' would be a numeric
less-than; 'lt' would be a stringified less than; '+' would be a
numeric bit-shift; and '~' would be a string-based bit-shift. No
ambiguity.
(Technically, the existence of '+==' and '~==' would imply the
existence of '?==' for completeness sake; but I can't think of any
reasonable case where '?==' would be used.)
I don't see that it would be a bad thing. Even if little used, it
does make conceptual sense. ?== checks if both arguments are the
same truth-wise, and !?== checks if they are different. Assuming we
defined for repeatable ordering purposes that False True (which is
consistent with any common string or numifications of booleans), then
? et al produce predictable results.
True enough. It's not _much_ of a mark in favor of the 'consistent
and intuitive naming convention' proposal; but it's a mark in its
favor nonetheless.
And in fact, once we have a third column of order-determing
operators rather than just Num + Str, the arrangement of some
alphabetic and some not comes to look positively ugly. So better to
make them all alpha or all non, and it would seem non is better. So
== and and so on for all comparing operators. (And as an aside, we
get rid of !ne.)
Another mark in its favor... :)
The two biggest marks against it are what it does to the bit-shift
operators (which isn't much of an issue IMHO; they're already changed
from perl5) and the drastic change from perl5-style thinking, where
numeric comparisons are effectively the default (which could very well
be a show-stopper).
In effect, we're talking about an Ordinal role, which would package
together the generic ordinal comparators ('*', '*', '*=', '*=',
and 'cmp'), along with 'sort', 'min', and 'max'.
Yes. And I was thinking about an Ordinal role before too.
Logically, some types are ordinal (eg, numbers (except complex?),
strings, dates), or could be assigned a canonical ordinal form (eg,
booleans, bits) and some are simply not ordinal (probably eg, a
polygon or a collection type).
Complex numbers can be ordered, but only if you're willing to accept
that multiplication by a complex number will mess with that order in a
not-always-intuitive way (as opposed to non-zero real numbers, where
the order will always be either preserved exactly or completely
reversed). I've seen the arguments against the validity of ordering
complex numbers, and I don't find them very persuasive. That said,
even if complex numbers aren't ordinal, they _can_ be assigned a
canonical ordinal form. Perhaps a better name for the role might be
something along the lines of Sortable...
And yes, there _are_ cases where assigning a canonical ordering to a
type is counterintuitive at best.
So, while it could make sense to have an Ordinal role, which types
individually can .does(), and only those have , , =, =, =, min,
max, sort, etc, there is the question about how to handle types that
don't .does() Ordinal in some generic
Re: generic ordinal-relevant operators
At 10:30 PM -0800 11/11/06, Jonathan Lang wrote: Note that this is two competing suggestions: one where '==' means 'generic equivalence', '+==' means 'numeric equivalence', and '*==' means 'string equivalence'; and another where '*==' means 'generic equivalence', '==' means 'numeric equivalence', and 'eq' means 'string equivalence' (with '', '', etc. following suit). The goal of the second proposal is to leave existing operator names unchangåed, while the goal of the first proposal is to provide a consistent and intuitive naming convention. snip For the record, my preference is to have the generics be the shortest, [==,!==,=,,,=,=], and use [+,~] prefixes for Num or Str casting versions. And lengthen the bit-shift operators to use thin-tailed arrowheads as you suggested. If this practice is followed, then we get these benefits: 1. Better self-documenting of code. 2. Better visual consistency of comparison operators - easier to learn. 3. Fewer base operators and/or fewer alternate shorthands - simplicity. 4. Eliminate the alphabet soup and related ugliness. 5. Better huffman coding because most people will want to sort their values by their native types; people normally want to sort Str as Str and Num as Num, and plain == etc will do that. I don't see any use of weak types as reducing the benefits either. 6. In my mind, bit shifting is a less commonly coded activity, so making those ops a bit longer shouldn't hurt anything. -- Darren Duncan
