Re: [perl #60170] Segfault in verify_signature
On Monday 27 October 2008 09:14:32 Will Coleda wrote: > While trying to duplicate the tcl segfault in PIR, I was able to > generate PIR that reliably segfaulted; except it turned out it was > segfaulting a different way: > > .sub '__onload' :immediate > load_bytecode 'TGE.pbc' > push_eh class_loaded > $P1 = subclass [ 'TGE'; 'Grammar' ], ['what'] > pop_eh > class_loaded: > .end > > #0 0xb7e74958 in verify_signature (interp=0x804f040, ins=0x81ce4a8, > pc=0x81ce590) at compilers/imcc/pbc.c:1734 > #1 0xb7e752d2 in e_pbc_emit (interp=0x804f040, param_unused=0x0, > unit=0x81cdf08, ins=0x81ce4a8) at compilers/imcc/pbc.c:1998 > #2 0xb7e69726 in emit_flush (interp=0x804f040, param=0x0, unit=0x81cdf08) > at compilers/imcc/instructions.c:879 > ... > > This segfault doesn't is still present with -G This is the same issue as RT #6, and is also fixed in r32633. -- c
Re: [perl #60000] [BUG][IMCC] an :immediate sub cannot load_bytecode
On Sunday 19 October 2008 14:02:58 Klaas-Jan Stol wrote: > when running code as this: > .sub main :immediate > load_bytecode "foo.pir" > .end > > (assuming you have a file 'foo.pir'), IMCC can't handle this. > > This is because in pbc.c, a global structure called 'globals' is used to > allow the different functions to share access to some data (in particular, > the code segment stuff). It's actually IMCC_INFO(interp)->ghash. In particular, constant folding assigns register numbers to constant PMCs and STRINGs as addresses into the constant table. That's good. Those constants are still around for code loaded from :immediate subs. That's also good. The problem is that the SymReg structures which represent those constants keep their assigned register numbers. That's bad, because they only get added to the bytecode if they don't already have register numbers representing indices into the constant table. Thus, they don't get assigned. This is a problem when handling parameters or return values. The PCC section of IMCC creates a FixedIntegerArray to handle these arguments, and that's a constant PMC in the bytecode. If this doesn't get created somehow (in the case I just described), other parts of the PCC-handling code expect it's there and throw an assertion if it isn't. The right fix is to walk IMCC_INFO(interp)->ghash and reset the color of all constant SymRegs to -1 before running any pragma subs (e_pbc_end_sub() in compilers/imcc/pbc.c), but r32633 is a quicker workaround for now, to get this closed. I'll work on the prettier fix in the next couple of days, unless someone beats me to it. -- c
Re: [perl #43831] [CAGE] Document how we do function decoration
Andrew Whitworth via RT wrote: 1) Rename this ticket to something more descriptive 2) Rename seatbelts.pod to something more descriptive, like /docs/dev/C_Functions.pod or something. 3) Expand that documentation to include more cases (ARGIN, ARGMOD, ARGOUT, all the *_NULLOK variants of those, etc). Agreed. Once 2) and 3) are done, ticket can be closed. Allison
Re: [perl #53210] [TODO] change new_from_string to init_str
Andrew Whitworth via RT wrote: On Tue Apr 22 10:05:57 2008, [EMAIL PROTECTED] wrote: We've been kicking around the idea of removing new_from_string for a while, but the pushback is always that it's useful to be able to create a new PMC with some initialization data, without first creating a PMC initializer that has to be garbage collected. So, instead of removing it entirely, make it a standard initialization option, passing a string argument instead of a PMC argument. [...] Is this idea still being kicked around? What would all the new interfaces look like? This seems like the kind of update that could be tackled in the next month if we wanted something that was more internally consistent. - Would need a new vtable function 'init_str'. void init_str(STRING *initializer) Or alternatively, if we find we need to exactly duplicate the interface of 'new_from_string': void init_str(STRING *initializer, INTVAL flags) - The 'new' opcode would need two additional variants that take a STRING initializer instead of a PMC initializer: =item B(out PMC, in STR, in STR) =item B(out PMC, in PMC, in STR) - The 'pmc_new' function would need two new variants, in addition to 'pmc_new' (which calls VTABLE_init), 'pmc_new_init' (which takes an extra PMC argument and calls VTABLE_init_pmc), and 'pmc_new_noinit' (which doesn't call any vtable init), and the constant versions of each. pmc_new_init_str(PARROT_INTERP, INTVAL base_type, ARGIN(STRING *init)) Allison
Re: Are eqv and === junction aware?
Larry Wall wrote: > eqv and === autothread just like any other comparisons. If you really > want to compare the contents of two junctions, you have to use the > results of some magical .eigenmumble method to return the contents > as a non-junction. Possibly stringification will be sufficient, if > it canonicalizes the output order. Perhaps there should be a way of disabling the autothreading? Something similar to the way that Lisp can take a block of code and tag it as "do not execute at this time". The idea is that there may be some cases where one might want to look at a Junction as an object in and of itself, rather than as a superposition of other objects; and simply extracting its contents into a list or set won't always do, since it might be Junction-specific details at which you want to look. And as long as Junctions autothread by default, I don't see them losing any power. -- Jonathan "Dataweaver" Lang
Re: [perl #60044] [BUG?] rethrow just throwing?
Martin D Kealey wrote: What about keeping track of where the exception was originally created? If we have lazy exceptions, then knowing where the fault they represent was detected is probably more important than were (exactly) it was triggered. Or does this all amount to the same thing? Is an exception only "lazy" because there's an enclosing dynamic scope that catches it and transmogrifies it into an Uncaught Exception? Or if not, could we have both back-traces available? A "created_by" back-trace and a "thrown_by" back-trace? Theoretically, yes. But 99% of the time, the useful information is where the exception was thrown, so the extra effort of tracking both doesn't add enough value to be worth it. But, if someone did need to track both (perhaps for a research project), they could just subclass the Exception class and add a creation backtrace. Allison
Re: [perl #57438] [DEPRECATED] [PDD19] .pragma n_operators
Will Coleda via RT wrote: This appears to be the only .pragma; should we leave a placeholder or just remove .pragma entirely when we remove this particular one? Nuke it. Allison
Re: [perl #60510] Bad plan: t/spec/S29-conversions/ord_and_chr.rakudo
--- On Thu, 13/11/08, Mark J. Reed <[EMAIL PROTECTED]> wrote: > Failed Test Stat Wstat Total Fail > List of Failed > > t/spec/S12-class/declaration-order.t0 6 20 > ?? > 1490 subtests skipped. > > Failed 1/219 test scripts. 0/6484 subtests failed. > Files=219, Tests=6484, 1224 wallclock secs (661.02 cusr + > 28.94 csys = > 689.96 CPU) Aha! Mark, what version of Test::Harness are you running? This looks like 2.X version output and I'm running 3.15. There might be a bug in the newer version which is losing that information. My best friend from the US arrives in a few hours, though, so there's not likely to be much follow up from me. Sorry. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Collapsing Junction states?
Darren Duncan wrote: Larry Wall wrote: It seems simpler to say that one() produces bags rather than sets. If we don't make other modifications to the language then this would mean that a Junction is defined over a union type, "Set|Bag with additional behaviors", depending on what operator constructed it. Now maybe that's fine. Or alternately, why not just redefine a Junction for consistency to say it is a "Bag with additional behaviors" rather than a "Set with additional behaviors"? Would doing this break anything? Do any intended uses of a Junction specifically versus a plain Set|Bag involve asking how many instances of a value there are, or asking how many distinct values or value instances are in the Junction? Aside from the 3 answers: exactly none, exactly one, one or more? The meaning of any() and all() do not change if the collection is allowed to be a Bag instead of a Set. There are two reasonable meanings for one(), either duplicates collapse done to single members of the collection or duplicates cancel (or are ignored, same thing). The later interpretation would mean that one(1,2,3,3) is the same as one(1,2), but constants aren't the interesting case, one(@a) is. I suppose we could define a :uniq(true|false) adverb to modify the meaning of one() so we could have both interpretations. Mark Biggar
Re: Collapsing Junction states?
Larry Wall wrote: It seems simpler to say that one() produces bags rather than sets. If we don't make other modifications to the language then this would mean that a Junction is defined over a union type, "Set|Bag with additional behaviors", depending on what operator constructed it. Now maybe that's fine. Or alternately, why not just redefine a Junction for consistency to say it is a "Bag with additional behaviors" rather than a "Set with additional behaviors"? Would doing this break anything? Do any intended uses of a Junction specifically versus a plain Set|Bag involve asking how many instances of a value there are, or asking how many distinct values or value instances are in the Junction? Aside from the 3 answers: exactly none, exactly one, one or more? What I was originally going to suggest but Tsa suggested first: Keep the definition of a Junction as "Set with additional behaviors" but the one() constructor just excludes values that appear multiple times in its argument list. In other words, one() *is* the same as any() except for the added filter. -- Darren Duncan
Re: [perl #60312] [BUG] OpenBSD Smolder test failures
On Monday 03 November 2008 09:38:11 Andy Dougherty wrote: > > 3. 1 of the tests appears to fail depending on how the OS initial- > > cases 'Inf'. Again, could this be addressed in a hints file? > > This too is a long-standing problem: See [perl #19183]. It stalled > pending a decision on whether or not parrot should try to enforce a single > spelling of 'Inf' (and 'Nan', etc.) or whether the tests should patch over > the issue. What does Perl 5 do? Let's do that. (No one else has made a decision.) -- c
MAIN conflict in S06?
S06:2362 says: You can get the current routine name by calling C<&?ROUTINE.name>. (The outermost routine at a file-scoped compilation unit is always named C<&MAIN> in the file's package.) Is this the same MAIN that is described later in "Declaring a MAIN subroutine"? It seems like that section describes MAIN subroutines that are lexically nested within the mainline code of the outermost file-scoped compilation unit, and it seems a little confusing if both are called MAIN. I'm guessing that the statement at S06:2362 is an artifact of an earlier draft that didn't have the section on MAIN subroutines, but I'm wanting to verify that this is the case (or seek further clarification if it isn't). Thanks! Pm
Re: [perl #60510] Bad plan: t/spec/S29-conversions/ord_and_chr.rakudo
On Thu, Nov 13, 2008 at 06:03:09PM -0500, Mark J. Reed wrote: > Now this test passes (r32629), but the Perl 6 test suite is still failing. > Now, however, I can't tell which test fails. > > Seems like the summary report should at least include counts of passed vs > failed tests. I assume the result of "FAIL" means that at least one of the > 6,487 tests failed, but that's not very informative... but I can't even find > the code that generates this output to try and fix it: IIUC, the harness that rakudo is using is ultimately passing control to Parrot::Test::Harness, which in turn uses Test::Harness. I don't know much more about it beyond that -- we'd welcome any efforts to clean up the testing system. Since Test::Harness didn't really output the statistics I was looking for anyway[*], I wrote a simple tools/test_summary.pl script to run all of the tests and collect output in a form more useful to me -- perhaps that would work better for you. [*] At this stage of development, I'm more interested in how many tests we pass than how many we fail. Pm
Re: [perl #60510] Bad plan: t/spec/S29-conversions/ord_and_chr.rakudo
On Thu, Nov 13, 2008 at 06:03:09PM -0500, Mark J. Reed wrote: > > It would also help if the actual test output weren't overrun with "Use of > uninitialized value". Is that the result of bad tests or bad harness? In some cases it's bad tests -- i.e., tests that are using values of undef when they shouldn't In other cases it's failing tests -- the test fails in a way that causes an undef value to be used (generating the warning). An example of this would be when an incorrect result looks up a value in an array at a non-existent index position. We could potentially see about disabling the warnings, but I'd prefer to fix them in the tests when/where we can. Pm
Re: [perl #60510] Bad plan: t/spec/S29-conversions/ord_and_chr.rakudo
I retract the previous comment. It was based on the file sent by Ovid; when I run make spectest myself, I get more informative output. In my case, 2 of the declaration-order tests are what's failing: Failed Test Stat Wstat Total Fail List of Failed t/spec/S12-class/declaration-order.t0 6 20 ?? 1490 subtests skipped. Failed 1/219 test scripts. 0/6484 subtests failed. Files=219, Tests=6484, 1224 wallclock secs (661.02 cusr + 28.94 csys = 689.96 CPU) On Thu, Nov 13, 2008 at 6:03 PM, Mark J. Reed <[EMAIL PROTECTED]> wrote: > On Thu, Nov 13, 2008 at 5:31 PM, Ovid < > [EMAIL PROTECTED]> wrote: > >> Now this test passes (r32629), but the Perl 6 test suite is still failing. >> Now, however, I can't tell which test fails. > > > Seems like the summary report should at least include counts of passed vs > failed tests. I assume the result of "FAIL" means that at least one of the > 6,487 tests failed, but that's not very informative... but I can't even find > the code that generates this output to try and fix it: > > Test Summary Report > --- > Files=220, Tests=6487, 304 wallclock secs ( 1.65 usr 0.82 sys + 539.47 cusr > 22.60 csys = 564.54 CPU) > Result: FAIL > > It would also help if the actual test output weren't overrun with "Use of > uninitialized value". Is that the result of bad tests or bad harness? > > -- > Mark J. Reed <[EMAIL PROTECTED]> > > -- Mark J. Reed <[EMAIL PROTECTED]>
Re: [perl #60510] Bad plan: t/spec/S29-conversions/ord_and_chr.rakudo
On Thu, Nov 13, 2008 at 5:31 PM, Ovid <[EMAIL PROTECTED]>wrote: > Now this test passes (r32629), but the Perl 6 test suite is still failing. > Now, however, I can't tell which test fails. Seems like the summary report should at least include counts of passed vs failed tests. I assume the result of "FAIL" means that at least one of the 6,487 tests failed, but that's not very informative... but I can't even find the code that generates this output to try and fix it: Test Summary Report --- Files=220, Tests=6487, 304 wallclock secs ( 1.65 usr 0.82 sys + 539.47 cusr 22.60 csys = 564.54 CPU) Result: FAIL It would also help if the actual test output weren't overrun with "Use of uninitialized value". Is that the result of bad tests or bad harness? -- Mark J. Reed <[EMAIL PROTECTED]>
Re: [perl #60510] Bad plan: t/spec/S29-conversions/ord_and_chr.rakudo
--- On Thu, 13/11/08, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > Again, this is all with r32625, YMMV with other revisions > (and please > report whatever other clues you may find). Ah, sorry. I should have known better :) r32580 $ uname -a Darwin curtis-poes-computer-2.local 9.5.1 Darwin Kernel Version 9.5.1: Fri Sep 19 16:19:24 PDT 2008; root:xnu-1228.8.30~1/RELEASE_I386 i386 Now this test passes (r32629), but the Perl 6 test suite is still failing. Now, however, I can't tell which test fails. The output was confusing enough to me that I've copied it to a file and attached it (teeing the spectest rusults to a file was spectacularly disappointing. It doesn't play well with tee). Cheers, Ovid perl6 $ make spectest ../../parrot perl6.pbc --target=pir --output=Test.pir Test.pm cd t/spec && svn up US03-junctions/misc.t US03-operators/ternary.t Aintegration/real-strings.t Updated to revision 23000. perl t/harness --fudge --keep-exit-code --jobs --tests-from-file=t/spectest.data t/spec/S02-builtin_data_types/array_extending.t ok t/spec/S02-builtin_data_types/anon_block.rakudo ok ===( 45;6 0/? 1/45 0/? )===Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value t/spec/S02-builtin_data_types/array_ref.rakudo . ok ===( 90;7 1/97 0/? 0/? )===Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value t/spec/S02-builtin_data_types/array.rakudo . ok t/spec/S02-builtin_data_types/bool.t ... ok t/spec/S02-builtin_data_types/catch_type_cast_mismatch.rakudo .. ok t/spec/S02-builtin_data_types/assigning-refs.rakudo ok t/spec/S02-builtin_data_types/flattening.rakudo ok ===( 269;14 0/? 1/32 0/? )==Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value t/spec/S02-builtin_data_types/hash_ref.rakudo .. ok ===( 301;17 1/58 0/? 0/? )==Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value t/spec/S02-builtin_data_types/hash.rakudo .. ok t/spec/S02-builtin_data_types/multi_dimensional_array.rakudo ... ok t/spec/S02-builtin_data_types/nested_pairs.t ... ok t/spec/S02-builtin_data_types/nested_arrays.t .. ok t/spec/S02-builtin_data_types/mixed_multi_dimensional.rakudo ... ok ===( 495;24 0/? 0/? 1/8 )Use of uninitialized value t/spec/S02-builtin_data_types/subscripts_and_context.rakudo ok t/spec/S02-builtin_data_types/num.rakudo ... ok t/spec/S02-builtin_data_types/type.rakudo .. ok t/spec/S02-literals/array-interpolation.rakudo . ok ===( 590;29 1/79 0/? 0/? )==Undefined value shifted from empty range t/spec/S02-builtin_data_types/range.rakudo . ok t/spec/S02-literals/hash-interpolation.rakudo .. ok t/spec/S02-literals/hex_chars.t ok t/spec/S02-literals/char-by-number.rakudo .. ok t/spec/S02-literals/listquote-whitespace.rakudo ok t/spec/S02-literals/pair-boolean.t . ok ===( 741;36 0/? 1/14 0/? )==Use of uninitialized value Use of uninitialized value t/spec/S02-literals/listquote.rakudo ... ok t/spec/S02-literals/autoref.rakudo . ok t/spec/S02-literals/pairs.rakudo ... ok t/spec/S02-literals/string-interpolation.t . ok ===( 860;461/135 0/? 0/? )Use of uninitialized value t/spec/S02-literals/quoting.rakudo . ok t/spec/S02-magicals/dollar-underscore.t ok t/spec/S02-literals/underscores.t .. ok t/spec/S02-magicals/dollar_bang.rakudo . ok t/spec/S02-names_and_variables/varnames.t .. ok t/spec/S02-names_and_variables/fmt.rakudo ...
[perl #60482] Rakudo dies strangely on .trans calls to strings coming from PGE
On Wed Nov 12 08:07:43 2008, pmichaud wrote:
> On Tue, Nov 11, 2008 at 08:43:09AM -0800, Carl Mäsak wrote:
> > rakudo: for "foo\nbar\nbaz".split( /\n ** 2..*/ ) { say
> > .trans([ /\s+/ => " " ]) }
> > rakudo 32543: OUTPUT[too few arguments passed (2) - 3 params
> > expectedcurrent instr.: '_block25' pc -342568903 ((unknown
> > file):-1)]
> > HAH!
> > * masak files ticket
>
> The problem is that the strings returned in PGE's Match objects
> are Parrot String PMCs, and so the .trans method for String PMCs
> (src/pmc/string.pmc:867) ends up being used instead of the .trans
> method defined by Rakudo.
>
> This will all likely be fixed when we have HLL mapping in place,
> and when PGE is updated to understand HLL mapping. Until then, I
> think we're a little stuck on this one.
As a start towards fixing this, I've added a String.Scalar method that
will promote Parrot String PMCs into Rakudo Str objects whenever the
String PMC is asked for its scalar value (e.g., upon assignment).
So, while $/[0].trans(...) will still go to the wrong object, assigning
$/[0] to a scalar and then performing .trans(...) will get closer to
what you want.
Again, a lot of this gets solved by HLL mapping -- but even once we have
HLL mapping this can be a very useful backstop.
We also now have the .PARROT method, which can be used to find out
exactly what type of object Parrot thinks something is (as opposed to
how Rakudo sees it).
Pm
Re: [perl #57444] [PATCH] add the S29-trig tests to spectest regression
Patrick R. Michaud via RT wrote: > Can this ticket be closed? I'd say we stall it until the :trig tag export works for the trigonometric functions. Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: [perl #60506] Segmentation fault in t/pmc/pmc.t
On Thursday 13 November 2008 13:54:36 James Keenan via RT wrote: > At r32625, I am observing this on Darwin/PPC -- but it passes on > Linux/i386. Darwin below. Is the backtrace the same as the one Moritz posted? -- c
[perl #57444] [PATCH] add the S29-trig tests to spectest regression
Can this ticket be closed? Pm
Re: [perl #54000] [DEPRECATED] get_array, get_list, get_scalar methods
On Thu, Nov 13, 2008 at 07:40:52AM -0800, Will Coleda via RT wrote:
> > I probably just need to remove the methods from the code,
> > see what breaks, and fix what breaks. I'll try to do that this
> > weekend before the release. If it doesn't happen then, we can
> > do it immediately following the release.
>
> If you can provide a patch that does the removal, someone else can do
> the grunt work of making sure everything still works.
Attached.
Pm
Index: runtime/parrot/library/Parrot/Capture_PIR.pir
===
--- runtime/parrot/library/Parrot/Capture_PIR.pir (revision 32625)
+++ runtime/parrot/library/Parrot/Capture_PIR.pir (working copy)
@@ -39,17 +39,6 @@
.end
-# deprecated RT#54000
-.sub 'get_array' :method
-.tailcall self.'list'()
-.end
-
-# deprecated RT#54000
-.sub 'get_hash' :method
-.tailcall self.'hash'()
-.end
-
-
.sub 'unshift_pmc' :vtable :method
.param pmc val
$P0 = self.'list'()
Index: src/pmc/capture.pmc
===
--- src/pmc/capture.pmc (revision 32625)
+++ src/pmc/capture.pmc (working copy)
@@ -463,7 +463,7 @@
*/
-METHOD get_array() {
+METHOD list() {
PMC *capt_array;
PMC *capt = SELF;
/* XXX: This workaround is for when we get here as
@@ -481,7 +481,7 @@
RETURN(PMC *capt_array);
}
-METHOD get_hash() {
+METHOD hash() {
PMC *capt_hash;
PMC *capt = SELF;
/* XXX: This workaround is for when we get here as
Index: t/pmc/capture.t
===
--- t/pmc/capture.t (revision 32625)
+++ t/pmc/capture.t (working copy)
@@ -243,9 +243,9 @@
0 0
OUTPUT
-pir_output_is( $PRE . <<'CODE'. $POST, <<'OUTPUT', "get_hash, get_array" );
-$P0 = capt.'get_array'()
-$P1 = capt.'get_hash'()
+pir_output_is( $PRE . <<'CODE'. $POST, <<'OUTPUT', "hash, list" );
+$P0 = capt.'list'()
+$P1 = capt.'hash'()
$S0 = typeof $P0
$S1 = typeof $P1
@@ -297,7 +297,7 @@
2
OUTPUT
-pir_output_is( <<'CODE', <<'OUTPUT', 'get_array method delegation' );
+pir_output_is( <<'CODE', <<'OUTPUT', 'list method delegation' );
.sub main :main
$P0 = subclass 'Capture', 'Match'
addattribute $P0, '$.abc'
@@ -310,7 +310,7 @@
$P2 = new 'String'
setattribute $P1, '$.xyz', $P2
-$P2 = $P1.'get_array'()
+$P2 = $P1.'list'()
$P2 = 0
$I0 = elements $P2
print $I0
Re: [perl #60510] Bad plan: t/spec/S29-conversions/ord_and_chr.rakudo
On Wed, Nov 12, 2008 at 03:35:08PM -0800, [EMAIL PROTECTED] (via RT) wrote: > t/spec/S29-conversions/ord_and_chr.rakudo fails with: > > t/spec/S29-conversions/ord_and_chr.rakudo (Wstat: 10 Tests: 170 Failed: 0) > Parse errors: Bad plan. You planned 240 tests but ran 170. > > However, it runs to completion with: > > ./perl6 t/spec/S29-conversions/ord_and_chr.rakudo fails with: This appears to be one of our heisenbugs -- it occurs in some revisions but not in others. For example in r32625 I get a similar situation with t/spec/S03-operators/assign.t -- running it with "make t/spec/S03-operators/assign.t" produces a failure in tests 246-306, while running it directly from the command line works fine. In other revisions it seems to work properly. In contrast, for r32625 I don't see the ord_and_chr.t failure you have, although I have seen it in other revisions. So, when reporting these sorts of bugs it really helps to know what svn revision you're working from. In the assign.t case, it appears this may be related to the fact that the test harness sets the PERL6LIB environment variable: # works $ ./parrot perl6.pbc t/spec/S03-operators/assign.rakudo # fails $ PERL6LIB=$PWD/t/01-sanity ./parrot perl6.pbc t/spec/S03-operators/assign.rakudo 1..306 ok 1 - # SKIP List assignment ok 2 - # SKIP List assignment ok 3 - # SKIP List assignment [...] ok 242 - # SKIP unknown reasons ok 243 - # SKIP unknown reasons ok 244 - # SKIP unknown reasons ok 245 - # SKIP unknown reasons GC: error obj 0xb7790198 () has properties *** glibc detected *** ./parrot: corrupted double-linked list: 0x08d06200 *** === Backtrace: = /lib/tls/i686/cmov/libc.so.6[0xb76ae149] /lib/tls/i686/cmov/libc.so.6[0xb76afedd] /lib/tls/i686/cmov/libc.so.6(__libc_calloc+0xcf)[0xb76b19ff] /home/pmichaud/parrot/trunk/blib/lib/libparrot.so.0.8.0[0xb7b2e3e5] Again, this is all with r32625, YMMV with other revisions (and please report whatever other clues you may find). Thanks! Pm
[perl #60444] [PATCH] Improve junctions to store only unique eigenstates.
After getting confirmation from p6l... Applied in r32625, thanks! Pm
Re: Collapsing Junction states?
On Thu, Nov 13, 2008 at 09:40:19AM -0800, Larry Wall wrote: > On Thu, Nov 13, 2008 at 05:02:56PM +0100, TSa wrote: > > Patrick R. Michaud wrote: > >> I expect that $a will become one(True, False, True). $a doesn't > >> collapse to a non-Junction False until it is used in a boolean context. > > > > My proposal is a different unification behavior in one() junctions. > > > >> my $a = one(1,2,3) % 2 == 1; > >>--> my $a = one(1%2, 2%2, 3%2) == 1; > > --> my $a = one(1,0,1) == 1; > > --> my $a = one(0) == 1; > > --> my $a = one(0 == 1) > > --> my $a = one(False); I think your proposal (C drops duplicates) might have trouble with: my $a = (one(15, 25, 22, 21) % 10) % 2; Dropping duplicates, we get: --> my $a = one(15%10, 25%10, 22%10, 21%10) % 2; --> my $a = one(5, 5, 2, 1) % 2; --> my $a = one(2, 1) % 2; # omit duplicate 5 --> my $a = one(2%2, 2%1); --> my $a = one(0, 1); Preserving duplicates, we get: my $a = (one(15, 25, 22, 21) % 10) % 2; --> my $a = one(15%10, 25%10, 22%10, 21%10) % 2; --> my $a = one(5, 5, 2, 1) % 2; --> my $a = one(5%2, 5%2, 2%2, 1%2); --> my $a = one(1, 1, 0, 1); Note that ?$a would end up being True if we drop duplicates (top) but False if we preserve them (bottom). > It seems simpler to say that one() produces bags rather than sets. I agree, so Rakudo will go with that for now. Thanks! Pm
Re: Are eqv and === junction aware?
On Thu, Nov 13, 2008 at 05:37:21PM +0100, TSa wrote: > HaloO, > > reading the "Collapsing Junction states" thread I wondered > how eqv and === handle junctions. I would expect > >all(1,2) === all(1,2) > > to evaluate to True and not expand to > >1 === 1 && 1 === 2 && 2 === 1 && 2 === 2 > > which is False. OTOH, > >2 === any(1,2,3) > > should be False because 2.WHAT is Int and any(1,2,3).WHAT is > Junction. Or are my expectations wrong? eqv and === autothread just like any other comparisons. If you really want to compare the contents of two junctions, you have to use the results of some magical .eigenmumble method to return the contents as a non-junction. Possibly stringification will be sufficient, if it canonicalizes the output order. Larry
Re: Collapsing Junction states?
On Thu, Nov 13, 2008 at 05:02:56PM +0100, TSa wrote: > HaloO, > > Patrick R. Michaud wrote: >> I expect that $a will become one(True, False, True). $a doesn't >> collapse to a non-Junction False until it is used in a boolean context. > > My proposal is a different unification behavior in one() junctions. > >> my $a = one(1,2,3) % 2 == 1; >>--> my $a = one(1%2, 2%2, 3%2) == 1; > > --> my $a = one(1,0,1) == 1; > --> my $a = one(0) == 1; > >>--> my $a = one(1%2 == 1, 2%2 == 1, 3%2 == 1); > > --> my $a = one(0 == 1) > >>--> my $a = one( True, False, True ); > > --> my $a = one(False); > >> I agree that one() with collapsing values isn't dwimmy (or useful), >> which is part of the reason for my original message. > > I agree as well, but make a different proposal how to resolve it. > BTW, how does an empty junction work? That could happen not only > with one() but also through one(1,2,1,2) in my proposal. So one() > is just another way of writing False ;) It seems simpler to say that one() produces bags rather than sets. Larry
Re: More about arrayref/hashref in spectest suite
HaloO, Patrick R. Michaud wrote: By way of illustration, contrast the two assignments at the end of the following code: my @x = ; my @y; @y[1] = @x, 'c'; @y[1,2,3] = @x, 'c'; The second assignment would seem to clearly be a list assignment, leaving @y with (undef, 'a', 'b', 'c'). But is the first assignment parsed as an item assignment or a list assignment? If it is parsed as an item assignment, how does the parser recognize it as such? Couldn't the distinction be made in the type analysis phase? Something similar how it would be resolved at runtime if &postcircumfix:<[ ]>:(Int) and &postcircumfix:<[ ]>:(List of Int) returned different types. E.g. ArrayItem and ArraySlice. Then the assignment operator could distinguish the cases. With enough type information the compiler could do the same analysis. Without it the issue is left up to the runtime dispatcher. Both dispatch targets treat the rhs different, of course. The ArrayItem case builds an arrayref, the ArraySlice assigns the elements with flattened @x. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Are eqv and === junction aware?
HaloO, reading the "Collapsing Junction states" thread I wondered how eqv and === handle junctions. I would expect all(1,2) === all(1,2) to evaluate to True and not expand to 1 === 1 && 1 === 2 && 2 === 1 && 2 === 2 which is False. OTOH, 2 === any(1,2,3) should be False because 2.WHAT is Int and any(1,2,3).WHAT is Junction. Or are my expectations wrong? Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
[perl #57980] Fix bugs with nested ?? !!
On Wed Nov 12 23:00:38 2008, chrisdolan wrote: > Attached is a very simple patch that solves the problem, but I've only > tested lightly. I am truly impressed -- this particular approach to solving the problem never occurred to me. Patch applied (r32618), thanks! Pm
[perl #57980] Fix bugs with nested ?? !!
On Wed Nov 12 23:00:38 2008, chrisdolan wrote: > Attached is a very simple patch that solves the problem, but I've only > tested lightly. I am truly impressed -- this particular approach to solving the problem never occurred to me. Patch applied (r32618), thanks! Pm
Re: Collapsing Junction states?
HaloO, Patrick R. Michaud wrote: I expect that $a will become one(True, False, True). $a doesn't collapse to a non-Junction False until it is used in a boolean context. My proposal is a different unification behavior in one() junctions. my $a = one(1,2,3) % 2 == 1; --> my $a = one(1%2, 2%2, 3%2) == 1; --> my $a = one(1,0,1) == 1; --> my $a = one(0) == 1; --> my $a = one(1%2 == 1, 2%2 == 1, 3%2 == 1); --> my $a = one(0 == 1) --> my $a = one( True, False, True ); --> my $a = one(False); I agree that one() with collapsing values isn't dwimmy (or useful), which is part of the reason for my original message. I agree as well, but make a different proposal how to resolve it. BTW, how does an empty junction work? That could happen not only with one() but also through one(1,2,1,2) in my proposal. So one() is just another way of writing False ;) Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Collapsing Junction states?
HaloO, Leon Timmermans wrote: But of what use would one() if it were to use those semantics? It would be essentially the same as any(), and it would definitely not DWIM. So you want one(1,1,2,3) to compare equal to 2 or 3 and exclude 1 because it is in the junction twice. That could be accomplished by not putting it in at all, as well. So the unification step of a one() junction drops duplicates completely? I see your point because the uniqueness test all(@array) == one(@array) always returns true if the junctions are unified before the comparison takes place. So the only way out is to make the definition that a one() junction drops duplicates completely. My personal favorite use of one() junctions would be in types. A Dog^Cat is either a Dog or a Cat but never something that does a combined role. But we don't have that in the language. Instead we have Dog|Cat and the juxtaposition Dog Cat. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Collapsing Junction states?
On Thu, Nov 13, 2008 at 02:55:06PM +0100, Leon Timmermans wrote: > On Thu, Nov 13, 2008 at 2:24 PM, TSa <[EMAIL PROTECTED]> wrote: > > Pm wrote: > > > Presumably the values of a one() junction do not collapse in > > > this way, otherwise we could easily lose the fact that > > > a value occurs more than once: > > > > > > my $a = (one(1,2,3) % 2 == 1); > > > > Do I understand your question right, that you want the return > > of == to be false because there is a one(1,0,1) junction? I expect that $a will become one(True, False, True). $a doesn't collapse to a non-Junction False until it is used in a boolean context. my $a = one(1,2,3) % 2 == 1; --> my $a = one(1%2, 2%2, 3%2) == 1; --> my $a = one(1%2 == 1, 2%2 == 1, 3%2 == 1); --> my $a = one( True, False, True ); > > As Duncan points out junctions are immutable values and as such > > the % autothreads but the resulting values are assembled into > > a new junction according to the general rules, i.e. one(0,1). > > The number of elements in one(1,2,3) is not preserved. > > But of what use would one() if it were to use those semantics? It > would be essentially the same as any(), and it would definitely not > DWIM. I agree that one() with collapsing values isn't dwimmy (or useful), which is part of the reason for my original message. Pm
[perl #60506] Segmentation fault in t/pmc/pmc.t
# New Ticket Created by Moritz Lenz # Please include the string: [perl #60506] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=60506 > for a few days now t/pmc/pmc.t fails with a segfault in the third test: $ ./parrot t/pmc/pmc_3.pasm All names ok. Segmentation fault With this backtrace: (gdb) bt #0 0xb7c07069 in Parrot_cx_delete_task (interp=0x8e6a048, task=0x8eddfac) at src/scheduler.c:388 #1 0xb7d57e64 in Parrot_Timer_destroy (interp=0x8e6a048, pmc=0x8eddfac) at ./src/pmc/timer.pmc:191 #2 0xb7bb7be9 in Parrot_dod_free_pmc (interp=0x8e6a048, pool_unused=0x8e8abb0, p=0x8eddfac) at src/gc/dod.c:679 #3 0xb7bb7b1f in Parrot_dod_sweep (interp=0x8e6a048, pool=0x8e8abb0) at src/gc/dod.c:643 #4 0xb7bb83d9 in Parrot_dod_ms_run (interp=0x8e6a048, flags=4) at src/gc/dod.c:1122 #5 0xb7bb854a in Parrot_do_dod_run (interp=0x8e6a048, flags=4) at src/gc/dod.c:1189 #6 0xb7bc3cf6 in Parrot_really_destroy (interp=0x8e6a048, exit_code_unused=0, arg_unused=0x0) at src/inter_create.c:344 #7 0xb7baf82c in Parrot_exit (interp=0x8e6a048, status=0) at src/exit.c:89 #8 0x08048949 in main (argc=1, argv=0xbfcc5738) at src/main.c:66 (this is with r32577 on a 32 bit i386 linux) chromatic already investigated a bit: http://irclog.perlgeek.de/parrot/2008-11-07#i_675133 but so far no fix. Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
[svn:parrot-pdd] r32615 - trunk/docs/pdds
Author: coke
Date: Thu Nov 13 07:24:58 2008
New Revision: 32615
Modified:
trunk/docs/pdds/pdd19_pir.pod
Log:
RT #45859; remove last docu-reference.
Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod (original)
+++ trunk/docs/pdds/pdd19_pir.pod Thu Nov 13 07:24:58 2008
@@ -822,10 +822,6 @@
function call. I can denote a global subroutine, a local I or
a I.
-{{ DEPRECATION NOTE: bare word method names (e.g. C where
-C is not a local variable name) are deprecated. Use a quoted string
-instead. See #45859. }}
-
=item .return ([ [: ...], ...])
Return from the current subroutine with zero or more values.
[perl #60512] [PATCH] rewrite of names.t to PIR
# New Ticket Created by Bruce Stockwell
# Please include the string: [perl #60512]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60512 >
This is a rewrite of t/names.t from a perl test to a PIR test
names.t | 63 +--
1 file changed, 33 insertions(+), 30 deletions(-)
--
V/r
Bruce
Index: t/oo/names.t
===
--- t/oo/names.t (revision 32578)
+++ t/oo/names.t (working copy)
@@ -1,13 +1,7 @@
-#!perl
+#! parrot
# Copyright (C) 2007, The Perl Foundation.
# $Id$
-use strict;
-use warnings;
-use lib qw( . lib ../lib ../../lib );
-use Test::More;
-use Parrot::Test tests => 1;
-
=head1 NAME
t/oo/names.t - Test OO name-related items
@@ -22,33 +16,42 @@
=cut
-pir_output_is(
-<<'CODE', <<'OUT', 'Create HLL class same-named as Parrot class', todo => 'RT #43419' );
-.HLL "perl6", ""
+.HLL "perl6", ""
-.namespace []
+.namespace []
-.sub main :main
-# works
-$P0 = new 'Class'
-$P0.'name'('AnObject')
-$S0 = $P0
-say $S0
+.sub main :main
+.include 'include/test_more.pir'
-# fails
-$P0 = new 'Class'
-$P0.'name'('Object')
-$S0 = $P0
-say $S0
-.end
-CODE
-perl6;AnObject
-perl6;Object
-OUT
+plan(2)
+hll_object_different_than_parrot_name()
+hll_object_same_as_parrot_name()
+.end
+
+.sub hll_object_different_than_parrot_name
+# works
+$P0 = new 'Class'
+$P0.'name'('AnObject')
+$S0 = $P0
+is ($S0, 'AnObject','HLL obj w/ name different than parrot obj created')
+.end
+
+.sub hll_object_same_as_parrot_name
+# fails
+$P0 = new 'Class'
+push_eh OK_1
+$P0.'name'('Object')
+pop_eh
+$S0 = $P0
+ok (0, 'HLL obj created w/ same name as parrot obj')
+.return()
+OK_1:
+ok (1, 'HLL obj w/ same name as parrot obj not created')
+.end
+
# Local Variables:
-# mode: cperl
-# cperl-indent-level: 4
+# mode: pir
# fill-column: 100
# End:
-# vim: expandtab shiftwidth=4:
+# vim: expandtab shiftwidth=4 ft=pir:
[perl #60510] Bad plan: t/spec/S29-conversions/ord_and_chr.rakudo
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #60510]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60510 >
t/spec/S29-conversions/ord_and_chr.rakudo fails with:
t/spec/S29-conversions/ord_and_chr.rakudo (Wstat: 10 Tests: 170 Failed: 0)
Parse errors: Bad plan. You planned 240 tests but ran 170.
However, it runs to completion with:
./perl6 t/spec/S29-conversions/ord_and_chr.rakudo fails with:
The problem is that, when running it as a test, it appears to hang between
these two for loops, and then exits:
for @maps -> $char, $code {
my $descr = "\\{$code}{$code >= 32 ?? " == '{$char}'" !! ""}";
is ord($char), $code, "ord() works for $descr";
is chr($code), $char, "chr() works for $descr";
}
for 0..31 -> $code {
my $char = chr($code);
is ord($char), $code, "ord(chr($code)) is $code";
}
In testing, I put "say 1" between the two loops and the test ran to completion.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
[perl #57980] Fix bugs with nested ?? !!
Attached is a very simple patch that solves the problem, but I've only tested lightly. ternary.patch Description: Binary data
Re: Collapsing Junction states?
HaloO, Leon Timmermans wrote: Still that doesn't solve the problem of his code example. If my understanding of the synopses is correct, operations on junctions generate a new junction, so `one(1,2,3) % 2 == 1` will collapse to one(1 % 2 == 1, 2 % 2 == 1, 3 % 2 == 1), which is one(true, false, true). If it collapses, it will be one(true, false), and thus true, but if it doesn't collapse it will be false. Hmm? The auto-threading is one operator at a time not the '% 2 == 1' as a whole. The intermediate junctions are assembled according to the general rule that duplicates are removed. Thus the steps here are 1) one(1,2,3) % 2 --> one(1,0,1) --> one(1,0) 2) one(1,0) == 1 --> True The comparison collapses the junction. Boolean context collapses junctions as well because you can think of it as comparison to True. That is, there is an overload &infix:<==>(Junction,Num-->Bool) that is not auto-threaded. BTW, would it be useful to have auto-threading for Set as well? That is, Junction inherits it from Set. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Collapsing Junction states?
On Thu, Nov 13, 2008 at 2:24 PM, TSa <[EMAIL PROTECTED]> wrote: > Do I understand your question right, that you want the return > of == to be false because there is a one(1,0,1) junction? As > Duncan points out junctions are immutable values and as such > the % autothreads but the resulting values are assembled into > a new junction according to the general rules, i.e. one(0,1). > The number of elements in one(1,2,3) is not preserved. > But of what use would one() if it were to use those semantics? It would be essentially the same as any(), and it would definitely not DWIM. Regards,
Re: Collapsing Junction states?
HaloO, Patrick R. Michaud wrote: Presumably the values of a one() junction do not collapse in this way, otherwise we could easily lose the fact that a value occurs more than once: my $a = (one(1,2,3) % 2 == 1); Do I understand your question right, that you want the return of == to be false because there is a one(1,0,1) junction? As Duncan points out junctions are immutable values and as such the % autothreads but the resulting values are assembled into a new junction according to the general rules, i.e. one(0,1). The number of elements in one(1,2,3) is not preserved. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Collapsing Junction states?
> According to Synopsis 2, under "Immutable types", a Junction is a "Set with > additional behaviors". This implies to me a Junction consists just of > distinct unordered values. A Junction is not a Bag and it doesn't matter > that we lose the fact that a value occurred more than once in the arguments > of the Junction constructor. Whether values are considered identical or not > and get eliminated depends on what their .WHERE returns. Whether a Perl 6 > implementation internally reduces the constructor value list doesn't matter > as long as the semantics of using the Junction are as if it had; so eg that > reduction could be done lazily, just when the Junction is first used. -- > Still that doesn't solve the problem of his code example. If my understanding of the synopses is correct, operations on junctions generate a new junction, so `one(1,2,3) % 2 == 1` will collapse to one(1 % 2 == 1, 2 % 2 == 1, 3 % 2 == 1), which is one(true, false, true). If it collapses, it will be one(true, false), and thus true, but if it doesn't collapse it will be false. Either I'm missing something, or the behavior of `one' needs to be specified more thoroughly. I think I agree with Patrick that collapse needs to be delayed there. Regards, Leon
Re: Collapsing Junction states?
Patrick R. Michaud wrote: Are duplicate values in any/all/none junctions expected to "collapse" such that each value becomes unique? For example, should any(1,2,2,1,2,3,2) internally reduce to the equivalent of any(1, 2, 3)? Or is this something that is left to individual implementations to decide? Presumably the values of a one() junction do not collapse in this way, otherwise we could easily lose the fact that a value occurs more than once: my $a = (one(1,2,3) % 2 == 1); Comments and/or pointers to relevant specifications that I've missed are welcomed. According to Synopsis 2, under "Immutable types", a Junction is a "Set with additional behaviors". This implies to me a Junction consists just of distinct unordered values. A Junction is not a Bag and it doesn't matter that we lose the fact that a value occurred more than once in the arguments of the Junction constructor. Whether values are considered identical or not and get eliminated depends on what their .WHERE returns. Whether a Perl 6 implementation internally reduces the constructor value list doesn't matter as long as the semantics of using the Junction are as if it had; so eg that reduction could be done lazily, just when the Junction is first used. -- Darren Duncan
Collapsing Junction states?
Are duplicate values in any/all/none junctions expected to "collapse" such that each value becomes unique? For example, should any(1,2,2,1,2,3,2) internally reduce to the equivalent of any(1, 2, 3)? Or is this something that is left to individual implementations to decide? Presumably the values of a one() junction do not collapse in this way, otherwise we could easily lose the fact that a value occurs more than once: my $a = (one(1,2,3) % 2 == 1); Comments and/or pointers to relevant specifications that I've missed are welcomed. Thanks! Pm
[perl #60456] Str ~~ Grammar do not return Match object, but return strange hash
This issue should now be fixed in r32597 so that PGE::Match objects correctly return an ObjectRef and assigns properly into scalar types. Also, in order to help diagnose such issues in the future, I've added a .PARROT method to rakudo that can be used to better diagnose what is happening internally when difficulties arise. This should be a more reliable indicator than trying to use .WHAT, which often hides such differences. For example $ ./parrot perl6.pbc > my $a = 'foo' ~~ /./; say $a.WHAT; say $a.PARROT; Match ObjectRef->PGE;Match > my $a = 'foo' ~~ /./; say (~$a).WHAT; say (~$a).PARROT; Str String Here we can see that even though .WHAT returns the expected Perl 6 protoobject, .PARROT shows us what is really happening beneath the surface. I expect that most of the remaining discrepancies will resolve themselves when we get HLL mapping in place. Resolving ticket, thanks! Pm
