[perl #131256] Re: Configure failure of Rakudo Star Release 2017.04 on ARM

[via RT]

# New Ticket Created by  Steve Mynott 
# Please include the string:  [perl #131256]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131256 >


With 2017.04 Rakudo Star you need to pass '--no-telemeh' to MoarVM
Configure.pl.  You then also have to Configure.pl nqp and finally
rakudo itself.



On 4 May 2017 at 15:41, Parrot Raiser <1parr...@gmail.com> wrote:
> Unfortunately, install processes is broken on ARM (R Pi). The
> configure process has a compile failure. I've attached the output to
> STDERR.
>
> The offending code appears to be identical to the 2012.01 version,
> which worked. Did someone change the compiler options?



-- 
4096R/EA75174B Steve Mynott 

[perl #131118] [RFC][@LARRY] Implement a way to propagate exceptions in Junctions

[Zoffix Znet via RT]

On Fri, 07 Apr 2017 10:08:54 -0700, comdog wrote:
> Consider this junction which you probably shouldn't make but you know
> will happen in the hands of users:
> 
> any( 5, 'flarg' ) == 5
> 
> Despite having an element that satisfies the condition, it blows up
> because one of them doesn't:
> 
> > any(5, "flarg") == 5
> Cannot convert string to number: base-10 number must begin with
> valid digits or '.' in '⏏flarg' (indicated by ⏏)
>   in block  at  line 1
> 
> But, it should't matter that what happens with any other parts of the
> junction if at least one of them satisfies the condition. You could,
> for instance, evaluate that differently so the new junction looks
> something like this:
> 
> any( True, Failure );
> 
> But, I don't think it should evaluate to another junction at all. The
> comparison operator should evaluate to a Boolean. That Failure will
> never matter because it's equivalent to False.


Thank you for the report. However, I'm going to reject the ticket.

As previous replies mentioned, there's no problem with Failures in a Junctions,
they work as any other value. The actual explosion in OP's code happens when 
one of the
Failures—created when 'flarg' was coerced to Numeric—is used as a value for
the purposes of evaluating the `==` op with it. That's when the Exception
gets thrown.

I'm unsure if one of the suggestions was to catch such exceptions and turn
them into Failures again... If it were, it's not a good idea, since Junctions
are not meant to be well-introspectable and just silencing exception like that
is bound to end in tears.

Some of the other suggestions were to make `try` Junctionable and stuff
a Junction into $! variable. If that's possible to do at all, IMO it should be
done as a trial in a module first, to evaluate usability and any issues
with the compatibility with core code.

Lastly, I added a 'Failures and Exceptions' section to Junction docs[^1] that
explains the issues raised in this ticket as well as shows some of possible
ways to attain the goals, if really necessary.

[1] https://github.com/perl6/doc/commit/7628708384bdc049d74c997fc2059cf57fcf5a57

[perl #131118] [RFC][@LARRY] Implement a way to propagate exceptions in Junctions

[Zoffix Znet via RT]

On Fri, 07 Apr 2017 10:08:54 -0700, comdog wrote:
> Consider this junction which you probably shouldn't make but you know
> will happen in the hands of users:
> 
> any( 5, 'flarg' ) == 5
> 
> Despite having an element that satisfies the condition, it blows up
> because one of them doesn't:
> 
> > any(5, "flarg") == 5
> Cannot convert string to number: base-10 number must begin with
> valid digits or '.' in '⏏flarg' (indicated by ⏏)
>   in block  at  line 1
> 
> But, it should't matter that what happens with any other parts of the
> junction if at least one of them satisfies the condition. You could,
> for instance, evaluate that differently so the new junction looks
> something like this:
> 
> any( True, Failure );
> 
> But, I don't think it should evaluate to another junction at all. The
> comparison operator should evaluate to a Boolean. That Failure will
> never matter because it's equivalent to False.


Thank you for the report. However, I'm going to reject the ticket.

As previous replies mentioned, there's no problem with Failures in a Junctions,
they work as any other value. The actual explosion in OP's code happens when 
one of the
Failures—created when 'flarg' was coerced to Numeric—is used as a value for
the purposes of evaluating the `==` op with it. That's when the Exception
gets thrown.

I'm unsure if one of the suggestions was to catch such exceptions and turn
them into Failures again... If it were, it's not a good idea, since Junctions
are not meant to be well-introspectable and just silencing exception like that
is bound to end in tears.

Some of the other suggestions were to make `try` Junctionable and stuff
a Junction into $! variable. If that's possible to do at all, IMO it should be
done as a trial in a module first, to evaluate usability and any issues
with the compatibility with core code.

Lastly, I added a 'Failures and Exceptions' section to Junction docs[^1] that
explains the issues raised in this ticket as well as shows some of possible
ways to attain the goals, if really necessary.

[1] https://github.com/perl6/doc/commit/7628708384bdc049d74c997fc2059cf57fcf5a57

[perl #131261] [@LARRY] phasers/loop controls in routines that accept Callables

[via RT]

# New Ticket Created by  Zoffix Znet 
# Please include the string:  [perl #131261]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131261 >


I came across an interesting doc Issue[^1] showcasing `next` working inside the 
Callable given to `Any.first`.

The reason it works is pure accident and other loop controls don't work, nor do 
the phasers.

`grep -FR 'Callable' src | wc -l` gives 128 matches, and I'd guess at least 
some of those are a similar
situation where loop controls/phasers either interfere with the internals in 
the method or are not handled.
For example, some phasers are currently not handled[^2] by .grep method.

So the question is, what do we do about these?

Implementing handlers for everything would be giant buggy mess and 
pessimization, often done to handle cases
no one really needs. Catching stuff in CONTROL just to throw is also messy and 
may interfere with stuff
that does want to propagate those exceptions further up the food chain.

Or lastly, and this is the option I favour, don't do anything. We implement 
handlers for controls/phasers
only where they make a lot of sense and document the places where they work. In 
all the other cases, were
a Callable is taken by routines, we simple declare that control 
exceptions/phasers are undefined behaviour
and should not be used. IMO the latter category includes the grep[^2] phasers 
as well; if someone really needs
to phaserize a grep callable, rewrite it as a for/gather/take thing.

[1] https://github.com/perl6/doc/issues/1290
[2] https://rt.perl.org/Ticket/Display.html?id=131060

[perl #128201] [BUG] [WEIRD] `.gist` hangs indefinitely on a lazy array passed to a slurpy paramater

[Zoffix Znet via RT]

On Fri, 20 May 2016 15:32:02 -0700, sml...@gmail.com wrote:
> The .gist call in the following code hangs indefinitely:
> 
> my @a = 1..Inf;  foo @a;  sub foo(*@_) { say @_.gist };
> 
> It shouldn't hang, because checking the argument for laziness returns
> True, and indexing it does not hang either:
> 
> my @a = 1..Inf;  foo @a;  sub foo(*@_) { say @_.is-lazy };  # True
> my @a = 1..Inf;  foo @a;  sub foo(*@_) { say @_[42] };  # 43
> 
> And now, this is where it gets really weird: When calling `.is-lazy`
> or `.[]` on the parameter *first*, then a *subsequent* .gist on it no
> longer hangs:
> 
> my @a = 1..Inf;  foo @a;  sub foo(*@_) { say @_.is-lazy; say @_.gist
> };  # True␤[...]
> my @a = 1..Inf;  foo @a;  sub foo(*@_) { say @_[1];  say @_.gist
> };  # 1␤[...]
> 
> For comparison, here are some variations which also do not hang:
> 
> my @a = 1..Inf;  say @a.gist;  # [...]
> 
> my @a = 1..Inf;  foo @a;  sub foo(@_) { say @_.gist };  # [...]
> 
> my @a = 1..Inf;  foo @a;  sub foo(*@_ is raw) { say @_.gist };  # (1 2
> 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
> 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
> 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
> 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97
> 98 99 100 ...)
> 
> 
> ---
> This is Rakudo version 2016.04-210-gc59e4dc built on MoarVM version
> 2016.05
> implementing Perl 6.c.


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/5e6b38789a
Test: https://github.com/perl6/roast/commit/5653ebb91b

[perl #128201] [BUG] [WEIRD] `.gist` hangs indefinitely on a lazy array passed to a slurpy paramater

[Zoffix Znet via RT]

On Fri, 20 May 2016 15:32:02 -0700, sml...@gmail.com wrote:
> The .gist call in the following code hangs indefinitely:
> 
> my @a = 1..Inf;  foo @a;  sub foo(*@_) { say @_.gist };
> 
> It shouldn't hang, because checking the argument for laziness returns
> True, and indexing it does not hang either:
> 
> my @a = 1..Inf;  foo @a;  sub foo(*@_) { say @_.is-lazy };  # True
> my @a = 1..Inf;  foo @a;  sub foo(*@_) { say @_[42] };  # 43
> 
> And now, this is where it gets really weird: When calling `.is-lazy`
> or `.[]` on the parameter *first*, then a *subsequent* .gist on it no
> longer hangs:
> 
> my @a = 1..Inf;  foo @a;  sub foo(*@_) { say @_.is-lazy; say @_.gist
> };  # True␤[...]
> my @a = 1..Inf;  foo @a;  sub foo(*@_) { say @_[1];  say @_.gist
> };  # 1␤[...]
> 
> For comparison, here are some variations which also do not hang:
> 
> my @a = 1..Inf;  say @a.gist;  # [...]
> 
> my @a = 1..Inf;  foo @a;  sub foo(@_) { say @_.gist };  # [...]
> 
> my @a = 1..Inf;  foo @a;  sub foo(*@_ is raw) { say @_.gist };  # (1 2
> 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
> 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
> 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
> 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97
> 98 99 100 ...)
> 
> 
> ---
> This is Rakudo version 2016.04-210-gc59e4dc built on MoarVM version
> 2016.05
> implementing Perl 6.c.


Thank you for the report. This is now fixed.

Fix:  https://github.com/rakudo/rakudo/commit/5e6b38789a
Test: https://github.com/perl6/roast/commit/5653ebb91b

[perl #131255] [STAR] Configure failure of Rakudo Star Release 2017.04 on ARM

[Zoffix Znet via RT]

On Fri, 05 May 2017 02:47:02 -0700, c...@zoffix.com wrote:
> On Thu, 04 May 2017 07:41:10 -0700, 1parr...@gmail.com wrote:
> > Unfortunately, install processes is broken on ARM (R Pi). The
> > configure process has a compile failure. I've attached the output to
> > STDERR.
> >
> > The offending code appears to be identical to the 2012.01 version,
> > which worked. Did someone change the compiler options?
> 
> Yeah, there were some issues this release cycle. I recall the release
> manager mentioning he'll look into the ARM thing today ( somewhere in
> https://irclog.perlgeek.de/perl6/2017-05-04#i_14532819 )


Oh, looks like there was a reply to this ticket but it ended up being another 
ticket: https://rt.perl.org/Ticket/Display.html?id=131256

[perl #131255] [STAR] Configure failure of Rakudo Star Release 2017.04 on ARM

[Zoffix Znet via RT]

On Fri, 05 May 2017 02:47:02 -0700, c...@zoffix.com wrote:
> On Thu, 04 May 2017 07:41:10 -0700, 1parr...@gmail.com wrote:
> > Unfortunately, install processes is broken on ARM (R Pi). The
> > configure process has a compile failure. I've attached the output to
> > STDERR.
> >
> > The offending code appears to be identical to the 2012.01 version,
> > which worked. Did someone change the compiler options?
> 
> Yeah, there were some issues this release cycle. I recall the release
> manager mentioning he'll look into the ARM thing today ( somewhere in
> https://irclog.perlgeek.de/perl6/2017-05-04#i_14532819 )


Oh, looks like there was a reply to this ticket but it ended up being another 
ticket: https://rt.perl.org/Ticket/Display.html?id=131256

[perl #131255] Configure failure of Rakudo Star Release 2017.04 on ARM

[Zoffix Znet via RT]

On Thu, 04 May 2017 07:41:10 -0700, 1parr...@gmail.com wrote:
> Unfortunately, install processes is broken on ARM (R Pi). The
> configure process has a compile failure. I've attached the output to
> STDERR.
> 
> The offending code appears to be identical to the 2012.01 version,
> which worked. Did someone change the compiler options?

Yeah, there were some issues this release cycle. I recall the release manager 
mentioning he'll look into the ARM thing today ( somewhere in 
https://irclog.perlgeek.de/perl6/2017-05-04#i_14532819 )