[perl #64262] the CATCH block catching its own exception recursively forever
# New Ticket Created by Ilya Belikin
# Please include the string: [perl #64262]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=64262 >
Hi there,
example:
try{
foo;
CATCH { die 1 }
}
S04, L800:
A C block sees the lexical scope in which it was defined, but
its caller is the dynamic location that threw the exception. That is,
the stack is not unwound until some exception handler chooses to
unwind it by "handling" the exception in question. So logically,
if the C block throws its own exception, you would expect the
C block to catch its own exception recursively forever. However,
a C must not behave that way, so we say that a C block
never attempts to handle any exception thrown within its own dynamic scope.
(Otherwise the C in the previous paragraph would never work.)
Ilya
Re: [perl #62974] Signed-zero tests failing on Windows XP
> > Can you give us any update on these tests on the same platform? > All seems to be well here, too. (At svn 37803.) C:\parrot>prove t\op\arithmetics.t t\op\arithmeticsok All tests successful. Files=1, Tests=23, 4 wallclock secs ( 0.08 usr + 0.01 sys = 0.09 CPU) Result: PASS C:\parrot>prove t\pmc\complex.t t\pmc\complexok All tests successful. Files=1, Tests=467, 1 wallclock secs ( 0.25 usr + 0.00 sys = 0.25 CPU) Result: PASS C:\parrot>prove t\pmc\float.t t\pmc\floatok All tests successful. Files=1, Tests=61, 8 wallclock secs ( 0.09 usr + 0.00 sys = 0.09 CPU) Result: PASS -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
[perl #64246] [PATCH] Add a Perl 6 version of chr, ord and chars to the setting
# New Ticket Created by Cory Spencer # Please include the string: [perl #64246] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=64246 > The following patch adds inline PIR versions of chr, ord and chars to Any.pm in the setting. 0001-Added-Perl-6-versions-of-chr-ord-and-chars-to-Any.patch Description: Binary data
Re: [perl #62974] Signed-zero tests failing on Windows XP
On Sat, Mar 28, 2009 at 1:15 PM, wrote: >> >> Can you give us any update on these tests on the same platform? >> > > All seems to be well here, too. (At svn 37803.) > > C:\parrot>prove t\op\arithmetics.t > t\op\arithmeticsok > All tests successful. > Files=1, Tests=23, 4 wallclock secs ( 0.08 usr + 0.01 sys = 0.09 CPU) > Result: PASS > > C:\parrot>prove t\pmc\complex.t > t\pmc\complexok > All tests successful. > Files=1, Tests=467, 1 wallclock secs ( 0.25 usr + 0.00 sys = 0.25 CPU) > Result: PASS > > C:\parrot>prove t\pmc\float.t > t\pmc\floatok > All tests successful. > Files=1, Tests=61, 8 wallclock secs ( 0.09 usr + 0.00 sys = 0.09 CPU) > Result: PASS > I would just make sure that the tests aren't passing because they are currently skipped or todo'd. =-) -- Will "Coke" Coleda
Re: [perl #62528] Match.keys method returns nothing.
Since afaict this is not specced, I'll hand that over to p6l.
Eric Hodges (via RT) wrote:
> use v6;
>
> rule test {test};
>
> "test" ~~ //;
> say '$/.keys => ', $/.keys.perl;
> say '%($/).keys => ', %($/).keys.perl;
>
> # outputs
> # $/.keys => []
> # %($/).keys => ["test"]
>
>
> Same could be said for .values and .kv
>
> It would be very DWIM for it to act like a hash in these cases by default.
Actually I think it would DWIM more in the general case if Match.keys
(and .kv, .pairs, .values etc) would give a list of the array and hash
part, so $/.keys would be @($/).keys, %($/).keys.
Your suggestion would be just a degenerate case of that.
Any thoughts on that?
Cheers,
Moritz
Re: On Junctions
Jon Lang wrote:
> I stand corrected. That said: with the eigenstates method now
> private, it is now quite difficult to get a list of the eigenstates of
> the above expression.
I thought about that a bit, and I think eigenstates are not hard to
extract (which somehow makes the privateness of .eigstates a bit
absurd), simply by autothreading:
sub e(Object $j) {
my @states;
-> Any $x { @states.push($x) }.($j);
return @states;
}
Cheers,
Moritz
Re: On Sets (Was: Re: On Junctions)
On Sat, Mar 28, 2009 at 10:39:01AM -0300, Daniel Ruoso wrote: > That happens because $pa and $pb are a singular value, and that's how > junctions work... The blackjack program is an example for sets, not > junctions. > > Now, what are junctions good for? They're good for situation where it's > collapsed nearby, which means, it is used in boolean context soon > enough. Or where you know it's not going to cause the confusion as in > the above code snippet. Unfortunately, it is extremely common to follow up a boolean "is this true" with either "if so, how" and/or "if not, why not". A boolean test is almost always the first step toward dealing with the consequences, and that almost always requires knowing not only what the result of the boolean test were, but which factors caused it to have that result. The canonical example of quantum computing is using it to factor huge numbers to break an encryption system. There you divide the huge number by the superposition of all of the possible factors, and then take the eigenstate of the factors that divide evenly to eliminate all of the huge pile of potential factors that did not divide evenly. Without being able to take the eigenstate, the boolean answer "yes, any(1..n-1) divides n" is of very little value.
Re: Junction Algebra
Richard Hainsworth conjectured:
> 1) Is the following true for an any junction?
> any( ... , any('foo','bar')) === any(...,'foo','bar')
>
> If yes, then
> if an 'any' junction is contained in an outer 'any', the inner 'any' can be
> factored out?
Yes. More precisely, an 'any' that is directly nested inside another
'any' can be flattened.
By "directly", I mean with no intervening levels of non-'any'
junctions. That is, not like: any(...,all(...,any('foo', 'bar')))
> 2) Also, is the following true for nested 'all' junctions? viz.
> all(... , all('foo', 'bar')) === all(...,'foo','bar')
Yes, with a similiar "directly" caveat, as above.
> 3) Conjecture: The following is true of all junction types, eg.,
> junc(..., junc(...)) === junc(..., ...)
No. As Patrick so ably pointed out, this is not true for 'one' nor for 'none'
Damian
Re: On Sets (Was: Re: On Junctions)
On Sun, Mar 29, 2009 at 1:18 PM, John Macdonald wrote:
> On Sat, Mar 28, 2009 at 10:39:01AM -0300, Daniel Ruoso wrote:
>> That happens because $pa and $pb are a singular value, and that's how
>> junctions work... The blackjack program is an example for sets, not
>> junctions.
>>
>> Now, what are junctions good for? They're good for situation where it's
>> collapsed nearby, which means, it is used in boolean context soon
>> enough. Or where you know it's not going to cause the confusion as in
>> the above code snippet.
>
> Unfortunately, it is extremely common to follow up a boolean "is this
> true" with either "if so, how" and/or "if not, why not". A boolean test
> is almost always the first step toward dealing with the consequences,
> and that almost always requires knowing not only what the result of the
> boolean test were, but which factors caused it to have that result.
True point. Along these lines, I'd like to see at least one
"threshing function" that separates a junction's eigenstates that
passed a boolean test from those that didn't. I can see several
possible semantics for such:
1. It returns a list of the eigenstates that passed the test.
2. It returns a junction composed of only those parts of the
junction which passed the test.
3. It returns a two-item list: the wheat and the chaff. The form
that the items take would conform to one of the first two options.
The "G[op]" proposal could be thought of as one approach to the first
option. Note also that this option can be turned into a generic "list
all of the eigenstates" function by choosing a "test" that every
possible eigenstate is guaranteed to pass; as such, it would be a very
small step from this sort of threshing function to a public
.eigenstates method - e.g., "$j.eigenstates :where { ... }" (to add
optional threshing capabilities to a "list of eigenstates" function)
or "* G~~ $j" (to use a thresher to retrieve all of the eigenstates).
The "infix: (junction, Code --> junction)" proposal that I made
earlier is an example of the second option. This option has the
advantage that it preserves as much of the junction's internal
structure (e.g., composite junctions) as possible, in case said
structure may prove useful later on. (I'm a big fan of not throwing
anything away until you're sure that you don't need it anymore.) The
downside is that if you want a list of the eigenstates that passed the
test, this is only an intermediate step to getting it: you still have
to figure out how to extract a list of eigenstates from the threshed
junction.
The third "option" has the benefit of letting you handle "if so" & "if
not" without having to thresh twice, once for the wheat and again for
the chaff. OTOH, it's bound to be more complicated to work with, and
is overkill if you only care about one of the outcomes. I have no
syntax proposals at this time.
Note further that these aren't necessarily mutually exclusive options:
TIMTOWTDI. I prefer the ones that use some form of "where"; but
that's just because those approaches feel intuitive to me.
> The canonical example of quantum computing is using it to factor huge
> numbers to break an encryption system. There you divide the huge number
> by the superposition of all of the possible factors, and then take the
> eigenstate of the factors that divide evenly to eliminate all of the
> huge pile of potential factors that did not divide evenly. Without
> being able to take the eigenstate, the boolean answer "yes, any(1..n-1)
> divides n" is of very little value.
Right. Something like:
any(2 ..^ $n).eigenstates :where($n mod $_ == 0)
or:
( any(2 ..^ $n) where { $n mod $_ == 0 } ).eigenstates
...might be ways to get a list of the factors of $n. (I'm not sure
how this would be done with junctions and the proposed grep
metaoperator - although I _can_ see how to do it with _just_ the
metaoperator, or with just a grep method. But that's list
manipulation, not junctive processing.) Of course, evaluating this
code could be a massive headache without a quantum processor.
I'm sure that one _could_ come up with a Set-based approach to doing
this; it might even be fairly easy to do. But again, TIMTOWTDI. Perl
has never been about trying to come up with an "ideal" approach and
then forcing everyone to use it - that would be LISP, among others.
Telling people that they must use Sets instead of junctions in cases
such as this runs counter to the spirit of Perl.
--
Jonathan "Dataweaver" Lang
Re: [perl #62528] Match.keys method returns nothing.
Moritz Lenz wrote:
> Since afaict this is not specced, I'll hand that over to p6l.
>
> Eric Hodges (via RT) wrote:
>> use v6;
>>
>> rule test {test};
>>
>> "test" ~~ //;
>> say '$/.keys => ', $/.keys.perl;
>> say '%($/).keys => ', %($/).keys.perl;
>>
>> # outputs
>> # $/.keys => []
>> # %($/).keys => ["test"]
>>
>>
>> Same could be said for .values and .kv
>>
>> It would be very DWIM for it to act like a hash in these cases by default.
>
> Actually I think it would DWIM more in the general case if Match.keys
> (and .kv, .pairs, .values etc) would give a list of the array and hash
> part, so $/.keys would be @($/).keys, %($/).keys.
> Your suggestion would be just a degenerate case of that.
>
> Any thoughts on that?
Take it one step more general: IIRC, Match returns a Capture of the
matches found. What happens if you apply .keys, .values, etc.
directly to a Capture object? I'm thinking that it should return a
multidimensional array: e.g., "(@$capture; %$capture).«keys".
--
Jonathan "Dataweaver" Lang
[perl #64268] Rakudo can`t parse .=sort: {...}
# New Ticket Created by Ilya Belikin
# Please include the string: [perl #64268]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=64268 >
Hi there,
rakudo> my @a = 1,3,2; say @a.sort: {1}
132 # :)
rakudo> my @a = 1,3,2; say @a.=sort: {1}
Statement not terminated properly at line 1, near ": {1}\n" # :(
rakudo> my @a = 1,3,2; say @a.=sort;
123 # :)
ihrd: std: my @a = 1,2,3; @a.=sort: {1}
p6eval: std 26019: OUTPUT«ok 00:02 37m»
Ilya
[perl #64276] [TODO] implement embedded comments
# New Ticket Created by Moritz Lenz # Please include the string: [perl #64276] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=64276 > 20:55 < frioux> rakudo: say #[ foo ] "test"; 20:55 < p6eval> rakudo 370dd7: OUTPUT«say requires an argument at line 1, near " #[ foo ] "current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)» Now we've got a ticket for that ;-)
[perl #64270] Cannot call private &!a variables in a class in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #64270]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=64270 >
rakudo: class A { has &!a = { say "OH HAI" }; method foo {
&!a() } };A.new.foo
rakudo 7af829: OUTPUT«No such attribute '!a' [...]
* masak submits rakudobug
The error message is contradictory, since there obviously is an
attribute '!a'. Using a dot when calling -- &!a.() -- produces the
same result.
Re: On Junctions
What I see here is that there is a tendency to want to think about,
and operate on, the eigenstates as a Set, but this seems to destroy
the "single value" impersonation of the Junction.
Further, if one ever calls .!eigenstates() on a Junction, then you
have really bollox'd your code up, as then this code fails if the
value you thought was a Junction happens to be, actually, just a
single value! (Unless .!eigenstates() is defined on Object, and
returns a Set of self...)
I think what is needed is a "single value" threshing function, which
can be applied to, well, single values. Such a function would take a
value and a predicate, and if the predicate applied to the value is
true, returns the value, else it returns... nothing. If such a
function were applied to a Junction, then the result would be a
Junction of just those those eigenstates that "passed" this function.
The "nothings" would not end up contributing to the Junction.
Now, I'm not sure I know how to return "nothing" in Perl6, but I'll
guess that undef can serve the purpose, since I can't think of a
useful use of undef as part of a Junction.
sub suchthat(Any $v, &predicate) { predicate($v) ?? $v !! undef }
So now:
$a = 1|2|3|4|5
say suchthat($a, odd)
>>> 1|3|5
$b = 1&2&3&4&5
say suchthat($a, odd)
>>> 1&3&5
And in the poker example:
@p = 1|11, 2, 1|11;
@d = 1|11, 3, 1|11;
$pv = suchthat([+] @p, {$_ <= 21})
$dv = suchthat([+] @d, {$_ <= 21})
if $pv and (!$dv or $pv > $dv) { say 'p wins!' };
- MtnViewMark
Mark Lentczner
http://www.ozonehouse.com/mark/
m...@glyphic.com
