Re: [perl #131991] AutoReply: [REGEX] Longest Alternation followed by an Alternation fails

[Shy Guy via RT]

This is Rakudo version 2017.07-155-gc229022cb built on MoarVM version
2017.07-378-g5e94da03
implementing Perl 6.c.

Linux Kataomoi 4.13.0-rc6
CPU E3-1230 V2 @ 3.30GHz GenuineIntel GNU/Linux

Also tested on IRC with Moar and Star


On Tue, Aug 29, 2017 at 1:22 PM, perl6 via RT 
wrote:

> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "[REGEX] Longest Alternation followed by an Alternation fails",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [perl #131991].
>
> Please include the string:
>
>  [perl #131991]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
> Thank you,
> perl6-bugs-follo...@perl.org
>
> -
> *Description:*
> Longest alternation seems to only evaluate the first nested alternation of
> its right side arguments.
> That is, if the first regex of an alternation <||> following longest
> alternation <|>  fails, and the regex preceding the longest alternation
> succeeds, the longest alternation uses the preceding/ left side match
> rather than evaluating the rest of the right side alternation which could
> have a potentially longer match.
>
> *Example 1:*
> 'succeed'.match(/ suc | [ fail || succeed ]/).say;
>
> Returns:
> ｢suc｣
>
> Expected:
> ｢succeed｣
>
> *Example 2:*
> grammar TEST {
> regex NestedAlternation { fail || succeed }
> regex LongestAlternation { suc |  }
> regex TOP {  .* }
> }
> TEST.parse('succeed').say;
>
> Returns:
> ｢succeed｣
>  LongestAlternation => ｢suc｣
>
> Expected:
> ｢succeed｣
>  LongestAlternation => ｢succeed｣
>   NestedAlternation => ｢succeed｣
>
> Note if we remove the trailing '.*' in TOP, backtracking forces it to
> evaluate the NestedAlternation and return the expected result. However,
> backtracking back into the NestedAlternation should not be necessary.
>
> *Example 3:*
> grammar TEST {
> token NestedAlternation { fail || succeed }
> token LongestAlternation { suc |  }
> token TOP {  }
> }
> TEST.parse('succeed').say;
>
>
> Returns:
> Nil
>
> Expected:
> ｢succeed｣
>  LongestAlternation => ｢succeed｣
>   NestedAlternation => ｢succeed｣
>
>

[perl #131991] AutoReply: [REGEX] Longest Alternation followed by an Alternation fails

[Shy Guy via RT]

This is Rakudo version 2017.07-155-gc229022cb built on MoarVM version
2017.07-378-g5e94da03
implementing Perl 6.c.

Linux Kataomoi 4.13.0-rc6
CPU E3-1230 V2 @ 3.30GHz GenuineIntel GNU/Linux

Also tested on IRC with Moar and Star
This is not specific to right side nested alternations.

*Example 4:*
'succeed'.match(/ [fail || succeed] | suc /).say;
Result:
｢suc｣
Expected:
｢succeed｣

Re: [perl #131983] [BUG] mixin thread safety

[J . David Lowe via RT]

Agreed. In that case, the threads are just racing to observe a mutating value 
while it's in the "expected" state.

I will add my voice to the chorus calling for either making roles into 
closures, or producing a compile-time warning or error. It's tempting to use 
roles to "monkey patch", and would be good to be warned if it isn't a safe 
thing to do.

I'm fine with closing this as a duplicate.

> On Aug 29, 2017, at 7:32 AM, Sam S. via RT  
> wrote:
> 
> @David
> 
> I think this is not a thread safety issue, but rather a result of `role`s 
> (intentionally) not being closures.
> 
> I.e. a duplicate of this RT: This is a duplicate of 
> https://rt.perl.org/Ticket/Display.html?id=130965

[perl #131991] [REGEX] Longest Alternation followed by an Alternation fails

[via RT]

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


*Description:*
Longest alternation seems to only evaluate the first nested alternation of
its right side arguments.
That is, if the first regex of an alternation <||> following longest
alternation <|>  fails, and the regex preceding the longest alternation
succeeds, the longest alternation uses the preceding/ left side match
rather than evaluating the rest of the right side alternation which could
have a potentially longer match.

*Example 1:*
'succeed'.match(/ suc | [ fail || succeed ]/).say;

Returns:
｢suc｣

Expected:
｢succeed｣

*Example 2:*
grammar TEST {
regex NestedAlternation { fail || succeed }
regex LongestAlternation { suc |  }
regex TOP {  .* }
}
TEST.parse('succeed').say;

Returns:
｢succeed｣
 LongestAlternation => ｢suc｣

Expected:
｢succeed｣
 LongestAlternation => ｢succeed｣
  NestedAlternation => ｢succeed｣

Note if we remove the trailing '.*' in TOP, backtracking forces it to
evaluate the NestedAlternation and return the expected result. However,
backtracking back into the NestedAlternation should not be necessary.

*Example 3:*
grammar TEST {
token NestedAlternation { fail || succeed }
token LongestAlternation { suc |  }
token TOP {  }
}
TEST.parse('succeed').say;


Returns:
Nil

Expected:
｢succeed｣
 LongestAlternation => ｢succeed｣
  NestedAlternation => ｢succeed｣

Re: [perl #131983] [BUG] mixin thread safety

[J . David Lowe]

Agreed. In that case, the threads are just racing to observe a mutating value 
while it's in the "expected" state.

I will add my voice to the chorus calling for either making roles into 
closures, or producing a compile-time warning or error. It's tempting to use 
roles to "monkey patch", and would be good to be warned if it isn't a safe 
thing to do.

I'm fine with closing this as a duplicate.

> On Aug 29, 2017, at 7:32 AM, Sam S. via RT  
> wrote:
> 
> @David
> 
> I think this is not a thread safety issue, but rather a result of `role`s 
> (intentionally) not being closures.
> 
> I.e. a duplicate of this RT: This is a duplicate of 
> https://rt.perl.org/Ticket/Display.html?id=130965

[perl #131991] AutoReply: [REGEX] Longest Alternation followed by an Alternation fails

[Shy Guy]

This is Rakudo version 2017.07-155-gc229022cb built on MoarVM version
2017.07-378-g5e94da03
implementing Perl 6.c.

Linux Kataomoi 4.13.0-rc6
CPU E3-1230 V2 @ 3.30GHz GenuineIntel GNU/Linux

Also tested on IRC with Moar and Star
This is not specific to right side nested alternations.

*Example 4:*
'succeed'.match(/ [fail || succeed] | suc /).say;
Result:
｢suc｣
Expected:
｢succeed｣

Re: [perl #131991] AutoReply: [REGEX] Longest Alternation followed by an Alternation fails

[Shy Guy]

This is Rakudo version 2017.07-155-gc229022cb built on MoarVM version
2017.07-378-g5e94da03
implementing Perl 6.c.

Linux Kataomoi 4.13.0-rc6
CPU E3-1230 V2 @ 3.30GHz GenuineIntel GNU/Linux

Also tested on IRC with Moar and Star


On Tue, Aug 29, 2017 at 1:22 PM, perl6 via RT 
wrote:

> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "[REGEX] Longest Alternation followed by an Alternation fails",
> a summary of which appears below.
>
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [perl #131991].
>
> Please include the string:
>
>  [perl #131991]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
> Thank you,
> perl6-bugs-follo...@perl.org
>
> -
> *Description:*
> Longest alternation seems to only evaluate the first nested alternation of
> its right side arguments.
> That is, if the first regex of an alternation <||> following longest
> alternation <|>  fails, and the regex preceding the longest alternation
> succeeds, the longest alternation uses the preceding/ left side match
> rather than evaluating the rest of the right side alternation which could
> have a potentially longer match.
>
> *Example 1:*
> 'succeed'.match(/ suc | [ fail || succeed ]/).say;
>
> Returns:
> ｢suc｣
>
> Expected:
> ｢succeed｣
>
> *Example 2:*
> grammar TEST {
> regex NestedAlternation { fail || succeed }
> regex LongestAlternation { suc |  }
> regex TOP {  .* }
> }
> TEST.parse('succeed').say;
>
> Returns:
> ｢succeed｣
>  LongestAlternation => ｢suc｣
>
> Expected:
> ｢succeed｣
>  LongestAlternation => ｢succeed｣
>   NestedAlternation => ｢succeed｣
>
> Note if we remove the trailing '.*' in TOP, backtracking forces it to
> evaluate the NestedAlternation and return the expected result. However,
> backtracking back into the NestedAlternation should not be necessary.
>
> *Example 3:*
> grammar TEST {
> token NestedAlternation { fail || succeed }
> token LongestAlternation { suc |  }
> token TOP {  }
> }
> TEST.parse('succeed').say;
>
>
> Returns:
> Nil
>
> Expected:
> ｢succeed｣
>  LongestAlternation => ｢succeed｣
>   NestedAlternation => ｢succeed｣
>
>

[perl #131994] [REGRESSION] int32 goes crazy on -2147483648 (my int32 $x = -2147483648; say $x * 1.0)

[via RT]

# New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
# Please include the string:  [perl #131994]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131994 >


This one is really old.

Code:
my int32 $x = -2147483648;
my Int $z = $x;
say $z;
say $z * 1.0

Result (2014.01 … 2015.07.2):
-2147483648
-2147483648

Result (b3b4926cc0, 2015.09 … 2017.08, HEAD(e3af662)):
-2147483648
-18446744071562067968


All other values don't seem to cause problems. int64 seems to be OK too.

Bisected to 
https://github.com/rakudo/rakudo/commit/b3b4926cc06eb189e6a9be6d31353fe933f7fe03

[perl #129019] [BUG] Range.WHICH fails on many kinds of endpoints

[Brian S. Julin via RT]

On Sat, 20 Aug 2016 10:24:51 -0700, zef...@fysh.org wrote:
> > (:a..:b).WHICH
> Range|a True..b True
> > (List..Pair).WHICH
> Use of uninitialized value $!min of type List in string context.
> Methods .^name, .perl, .gist, or .say can be used to stringify it to
> something meaningful.  in block  at  line 1
> Use of uninitialized value $!max of type Pair in string context.
> Methods .^name, .perl, .gist, or .say can be used to stringify it to
> something meaningful.  in block  at  line 1
> Range|..
> 
> Even where it doesn't produce these warnings and an empty
> representation
> of an endpoint, this style of .WHICH is very poor and clash-prone.
> Range.WHICH should apply .WHICH to the endpoint objects.
> 
> -zefram

Unfortunately using the .WHICHs of the endpoints will not be sufficient.

For example "Foo^".."Bar" and "Foo"^.."Bar" would put out the same WHICH.
Since any Str can foil any attempt we make to simply bracket the result,
we have no choice than to either use an escape character quoteish
construct, or prepend a length:

Range|(8)|Str|Foo^..Str|Bar

...we could, however, decide whether or not to do so
by detecting anything in $!min which may jump the rails.

Same problem with Pair, BTW, which already .WHICHs its members:

$ perl6 -e '("Foo|Str|2" => "1").WHICH.say'
Pair|Str|Foo|Str|2|Str|1
$ perl6 -e '("Foo" => "2|Str|1").WHICH.say'
Pair|Str|Foo|Str|2|Str|1

...and given the use of WHICH in hashing, this is more consequential
than it may seem at first glance.

[perl #131991] [REGEX] Longest Alternation followed by an Alternation fails

[Larry Wall via RT]

Yes, as noted above, this is a dup of rejected ('better docs needed', really) 
ticket #130562.

[perl #131991] [REGEX] Longest Alternation followed by an Alternation fails

[Larry Wall via RT]

Yes, as noted above, this is a dup of rejected ('better docs needed', really) 
ticket #130562.

[perl #131991] [REGEX] Longest Alternation followed by an Alternation fails

[Ron Schmidt via RT]

Closing on request: https://irclog.perlgeek.de/perl6/2017-08-29#i_15087239

I have never closed anybody else's ticket before so let me know if I am doing 
anything wrong.

[perl #122004] Spooky capture with native int

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Well, it was clearly wrong to say that we don't care about it, sorry about
that. Maybe it's not the top priority thing (for example, there is a module to
do this: https://github.com/azawawi/perl6-memoize), but there are still plans
to get it done eventually.

I'll change the title a little bit so that it is easier to find this ticket.

On 2017-08-28 15:17:02, alex.jakime...@gmail.com wrote:
> We no longer seem to care about “is cached”, so… I don't think we
> should reject
> this (because it may be a nice test case once we start supporting
> cached
> trait), but at the same time this ticket is kinda useless.
>
> On 2014-06-01 03:12:32, elizabeth wrote:
> > On 01 Jun 2014, at 12:07, Elizabeth Mattijsen  wrote:
> > > On 01 Jun 2014, at 12:05, perl6 via RT  > > follo...@perl.org>
> > > wrote:
> > >> Greetings,
> > >>
> > >> This message has been automatically generated in response to the
> > >> creation of a trouble ticket regarding:
> > >> "Spooky capture with native int",
> > >> a summary of which appears below.
> > >>
> > >> There is no need to reply to this message right now. Your ticket
> > >> has been
> > >> assigned an ID of [perl #122004].
> > >>
> > >> Please include the string:
> > >>
> > >> [perl #122004]
> > >>
> > >> in the subject line of all future correspondence about this issue.
> > >> To do so,
> > >> you may reply to this message.
> > >>
> > >> Thank you,
> > >> perl6-bugs-follo...@perl.org
> > >>
> > >>
-
> > >> [07:39:51]  m: sub a(int $i) is cached { return unless $i;
> > >> a($i-1) }; say a(4);
> > >> [07:39:53] <+camelia> rakudo-moar ce6acf: OUTPUT«Cannot find
> > >> method 'gist': no method cache and no .^find_method␤ in method
> > >> gist
> > >> at src/gen/m-CORE.setting:7121␤ in block at src/gen/m-
> > >> CORE.setting:3357␤ in any enter at src/gen/m-Metamodel.nqp:3089␤
> > >> in method postcircumfix:<( )> at src/gen/m-C…»
> > >> [11:52:00]  Timbus: seems there is some confusion as to
> > >> what gets passed to the sub
> > >> [11:52:13]  is cached uses the gist of the signature to
> > >> creata a key
> > >> [11:52:22]  for caching the return value
> > >> [11:52:34]  m: sub a(int $i) is cached { return unless $i;
> > >> a(($i-1).Int) }; say a(4)
> > >> [11:52:35] <+camelia> rakudo-moar ce6acf: OUTPUT«(Any)␤»
> > >> [11:53:00]  either defining $i as an Int, or making sure
> > >> we pass an Int, is a workaround for now
> > >> [11:56:39]  yeah. just thought it was an odd one
> > >>
> > >> Feels like the Capture is not set up at all with a recursive call.
> > >> Any direct calls seem to work ok.
> > >
> > > As a further datapoint: it only happens on Moar and JVM, not on
> > > parrot.
> >
> > [12:09:15]  its an optimizer thing
> > [12:11:23]  Timbus: ah, indeed, with MVM_SPESH_DISABLE=1
> > no problems

[perl #131991] [REGEX] Longest Alternation followed by an Alternation fails

[Ron Schmidt via RT]

Looks to me like possible dup of RT 130562 
https://rt.perl.org/Ticket/Display.html?id=130562

See also doc issue: https://github.com/perl6/doc/issues/1141

[perl #130181] [BUG] .WHAT.:: leaks internal exception

[Brian S. Julin via RT]

On Sat, 26 Nov 2016 10:50:44 -0800, FROGGS.de wrote:
> say Int.new.WHAT.::
> 
> rakudo-moar 7c5ea3: OUTPUT«===SORRY!===␤MVMArray: Can't pop from an
> empty array␤»
> 
> IMO it should do the same as:
> m: say Int::
> rakudo-moar 7c5ea3: OUTPUT«Int␤»
> 
> 

fixed in rakudo 74ca5ce951, roast tests in 4ff4def2e4

[perl #131991] [REGEX] Longest Alternation followed by an Alternation fails

[Zoffix Znet via RT]

Adding more content from OP (seems there's some possible delay/issue with RT 
emails) per https://irclog.perlgeek.de/perl6/2017-08-29#i_15086833 



This is Rakudo version 2017.07-155-gc229022cb built on MoarVM version 
2017.07-378-g5e94da03
implementing Perl 6.c.

Linux Kataomoi 4.13.0-rc6
CPU E3-1230 V2 @ 3.30GHz GenuineIntel GNU/Linux
Also tested on IRC with Moar and Star

This is not specific to right side nested alternations.

Example 4:
'succeed'.match(/ [fail || succeed] | suc /).say;
Result:
｢suc｣
Expected:
｢succeed｣

[perl #131991] [REGEX] Longest Alternation followed by an Alternation fails

[Zoffix Znet via RT]

Adding more content from OP (seems there's some possible delay/issue with RT 
emails) per https://irclog.perlgeek.de/perl6/2017-08-29#i_15086833 



This is Rakudo version 2017.07-155-gc229022cb built on MoarVM version 
2017.07-378-g5e94da03
implementing Perl 6.c.

Linux Kataomoi 4.13.0-rc6
CPU E3-1230 V2 @ 3.30GHz GenuineIntel GNU/Linux
Also tested on IRC with Moar and Star

This is not specific to right side nested alternations.

Example 4:
'succeed'.match(/ [fail || succeed] | suc /).say;
Result:
｢suc｣
Expected:
｢succeed｣

Re: Floating point Num addition produces rationals?

[Timo Paulssen]

Here's a C program that simulates exactly how rakudo creates nums from
strings and shows the same problem:

https://gist.github.com/zoffixznet/46ae8dd7d85096d58dc557f60f82a179

Here's an IRC conversation with the author of the post you linked to
followed by investigation and discovery of this problem:

https://irclog.perlgeek.de/perl6/2017-07-13#i_14864050

Re: Floating point Num addition produces rationals?

[Timo Paulssen]

This is an insidious bug rooted in how we parse floating point numbers,
combined with a caching-related problem that causes the order of 0.1e0
vs 1e-1 to matter for all further outcomes.

I wasn't able to find a ticket for this in our bug tracker, but it most
definitely is something we will fix.

Floating point Num addition produces rationals?

[Andy Bach]

http://www.evanmiller.org/a-review-of-perl-6.html

has

Scientific notation (such as 1e-1 for 1×10-1) always produces a
floating-point Num in Perl 6. For reasons I don’t understand, however, they
sometimes seem to add up as rationals, rather than floating-point:

> 0.1e0 + 0.2e0 == 0.3e0
False
> 1e-1 + 2e-1 == 3e-1
True

Maybe someone can explain the discrepancy to me in a polite email. Anyway,
I wholeheartedly endorse Perl 6’s use of rational numbers for exact
arithmetic, and I think more languages could benefit from a similar
implementation. For reference, Julia and Haskell have built-in rationals,
constructed (respectively) with the // and % operators; most other
languages have them as a library, if at all, without support for literals.

Is this a surprise? Is there an explanation?
-- 

a

Andy Bach,
afb...@gmail.com
608 658-1890 cell
608 261-5738 wk

My work around for Net::SMTP crashing on SSL

[ToddAndMargo]

Problem:
https://github.com/retupmoca/P6-Net-SMTP/issues/17


Workaround:

curl smtps://smtp.zoho.com:465 -v --mail-from "xx...@zoho.com" 
--mail-rcpt "y...@zoho.com" --ssl -u 
xx...@zoho.com:zz -T "mail.txt" -k --anyauth



Curl can be called directly or through the curl module

[perl #131983] [BUG] mixin thread safety

[Sam S. via RT]

@David

I think this is not a thread safety issue, but rather a result of `role`s 
(intentionally) not being closures.

I.e. a duplicate of this RT: This is a duplicate of 
https://rt.perl.org/Ticket/Display.html?id=130965

[perl #131985] [BUG] curly-brace interpolation thread safety

[Sam S. via RT]

Possibly related to:

https://rt.perl.org/Ticket/Display.html?id=131871