Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
Am 08.06.2017 um 01:11 schrieb Zoffix Znet via RT: Quoting Joachim Durchholz : Actually I'd like to *remove* a special case: That ² is to be interpreted as 2 But it's NOT a special case. You can use any character with No property as a numeric literal. That's. The. Entire. Rule that governs the behaviour under examination in this ticket. That cannot be correct. There's that other rule that turns superscripts into exponents. There's quite a bunch of these chars: https://gist.github.com/Whateverable/d94b6a42532a4c1262df794d9be799f3 Yeah I know. Unicode has been around with me for several years now. ² confuses me, does that even make sense? It's the same as the stated rule above: "Any `No` char can be used as a numeric literal" Then this: ²³ confuses me as well. m: dd [.unival, .uniprop] with '²' rakudo-moar 0a1008: OUTPUT: «[2, "No"]» As you can see above, ² is indeed a `No` char, and it's Unicode numeric value is 2, which is the numeral you get. That's pretty much what I've been expecting. What I don't know is how Rakudo distinguishes ² (superscript/exponent) from 2 (never assumed to be an exponent). Ideally it would be some Unicode property, but I do not happen to know whether Unicode already offers a property for that. What happens actually is that in ³², the ³ is taken as a base and the ² as an exponent (that's why we're getting ³² == 9. If the superscripts were handled just like normal literal digits, the result should be 32. No, the description above is incorrect and conflates `Nd` Unicode characters that can be used as **digits** with `No` chars that can be used as **numerals**. They can't be used as individual **digits**. And since Perl 6's expects a term here to be followed by an op, there's no ambiguity about what `²` in `³²` is supposed to be interpreted as. It's an operator, so we have a `No` numeral followed by an operator; or 3 raised to the power of 2. Since we're talking about what Perl *should* do, which means "programmer expectations", the details of how the parsing is done do not matter *that* much. Unless, of course, Perl6 is intended to be a language where parser details are supposed to be part of common knowledge (I do not think that that's a good idea but I won't pretend I know better than Perl6 experts about what's the proper gestalt of the language, so I'll simply agree to disagree and move on). *If* Perl6 is interpreting superscripts specially (and it already does) That statement is incorrect. It doesn't. It turns ² into an exponent in some contexts, and into a bare number in others. That's pretty special when compared how it interprets 2. since bare exponents do not make any sense They do. In that context they're a term and you can use ANY `No` character as a numeral. I gather that. It's still unexpected as hell. And since nobody is going to use that, reviewers on the hunt for security holes won't have practical experience when they see ³² in a context that turns ³ into a 3 and ² into an exponent. E.g. what's 2.³²? Is that 2.0**32, or is it 2.3²? No matter what the correct answer is, there's no real experience to go by (because People Don't Do This), so 50% of reviewers will get it wrong. That's why you don't do "clever tricks" anymore. I.e. no specialcasing at all beyond what's already there. There's no special casing. There's just one rule: "you can use `No` characters as numerals". Simple. Elegant. Easy to remember. Except 90% of programmers won't be able to tell a No from an Nd when they see them in code.
[perl #128875] [BUG] ignoremark + ignorecase ignores everything but first letter
On Mon, 08 Aug 2016 17:34:57 -0700, timo wrote: > to be more precise, the way we code-gen "literal" qregex nodes with > subtype "ignoremark+ignorecase" will only ever check the ordbaseat of > the first character in the literal against the haystack. > This has been fixed as of https://github.com/perl6/nqp/commit/18e40936a on nqp, and the regex nodes cleaned up. With the new nqp::indexicim and eqaticim ops in MoarVM we should have greater maintainability of that code and less difference between the different types of regex, mostly using the same code now. The rakudo version where I bumped nqp is 2017.05-381-g1ac7996a4 Tests: I have added tests to roast here, https://github.com/perl6/roast/commit/0a80d0d2e84c824d0d5cfde1bbf40440ba0732d8
[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
Quoting Joachim Durchholz : > Actually I'd like to *remove* a special case: That ² is to be interpreted as 2 But it's NOT a special case. You can use any character with No property as a numeric literal. That's. The. Entire. Rule that governs the behaviour under examination in this ticket. No special cases. No "unless followed by a superscript char". Just: "Any `No` char is good" There's quite a bunch of these chars: https://gist.github.com/Whateverable/d94b6a42532a4c1262df794d9be799f3 So just as you can write: m: say ⅓² rakudo-moar 0a1008: OUTPUT: «0.11» You can write: m: say ²² rakudo-moar 0a1008: OUTPUT: «4» In BOTH of these cases a No numeral is used with a ² "postfix n" operator. Entirely identical. No special casing. > But before deciding how to deal with them: What are the > supposed/expected meaning of the following constructs? > 3² > x² > ² > 3² should be 3 squared, i.e. 9 Indeed that is it. Same as in regular mathematics. The 3 raised to power 2: m: say 3² rakudo-moar 0a1008: OUTPUT: «9» > x² to be x squared, i.e. an expression Indeed that is it. Same as in regular mathematics. `x` raised to power 2: m: my \x = 42; say x² rakudo-moar 0a1008: OUTPUT: «1764» > ² confuses me, does that even make sense? It's the same as the stated rule above: "Any `No` char can be used as a numeric literal" m: dd [.unival, .uniprop] with '²' rakudo-moar 0a1008: OUTPUT: «[2, "No"]» As you can see above, ² is indeed a `No` char, and it's Unicode numeric value is 2, which is the numeral you get. > What happens actually is that in ³², the ³ is taken as a base and the > ² as an exponent (that's why we're getting ³² == 9. > If the superscripts were handled just like normal literal digits, the > result should be 32. No, the description above is incorrect and conflates `Nd` Unicode characters that can be used as **digits** with `No` chars that can be used as **numerals**. They can't be used as individual **digits**. And since Perl 6's expects a term here to be followed by an op, there's no ambiguity about what `²` in `³²` is supposed to be interpreted as. It's an operator, so we have a `No` numeral followed by an operator; or 3 raised to the power of 2. > *If* Perl6 is interpreting superscripts specially (and it already > does) That statement is incorrect. It doesn't. >, *then* I expect it to recognize a bare ² as an exponent That's incorrect, because it expects a term in that position, not an operator. > since bare exponents do not make any sense They do. In that context they're a term and you can use ANY `No` character as a numeral. > I.e. no specialcasing at all beyond what's already there. There's no special casing. There's just one rule: "you can use `No` characters as numerals". Simple. Elegant. Easy to remember.
[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
Quoting Joachim Durchholz : > Actually I'd like to *remove* a special case: That ² is to be interpreted as 2 But it's NOT a special case. You can use any character with No property as a numeric literal. That's. The. Entire. Rule that governs the behaviour under examination in this ticket. No special cases. No "unless followed by a superscript char". Just: "Any `No` char is good" There's quite a bunch of these chars: https://gist.github.com/Whateverable/d94b6a42532a4c1262df794d9be799f3 So just as you can write: m: say ⅓² rakudo-moar 0a1008: OUTPUT: «0.11» You can write: m: say ²² rakudo-moar 0a1008: OUTPUT: «4» In BOTH of these cases a No numeral is used with a ² "postfix n" operator. Entirely identical. No special casing. > But before deciding how to deal with them: What are the > supposed/expected meaning of the following constructs? > 3² > x² > ² > 3² should be 3 squared, i.e. 9 Indeed that is it. Same as in regular mathematics. The 3 raised to power 2: m: say 3² rakudo-moar 0a1008: OUTPUT: «9» > x² to be x squared, i.e. an expression Indeed that is it. Same as in regular mathematics. `x` raised to power 2: m: my \x = 42; say x² rakudo-moar 0a1008: OUTPUT: «1764» > ² confuses me, does that even make sense? It's the same as the stated rule above: "Any `No` char can be used as a numeric literal" m: dd [.unival, .uniprop] with '²' rakudo-moar 0a1008: OUTPUT: «[2, "No"]» As you can see above, ² is indeed a `No` char, and it's Unicode numeric value is 2, which is the numeral you get. > What happens actually is that in ³², the ³ is taken as a base and the > ² as an exponent (that's why we're getting ³² == 9. > If the superscripts were handled just like normal literal digits, the > result should be 32. No, the description above is incorrect and conflates `Nd` Unicode characters that can be used as **digits** with `No` chars that can be used as **numerals**. They can't be used as individual **digits**. And since Perl 6's expects a term here to be followed by an op, there's no ambiguity about what `²` in `³²` is supposed to be interpreted as. It's an operator, so we have a `No` numeral followed by an operator; or 3 raised to the power of 2. > *If* Perl6 is interpreting superscripts specially (and it already > does) That statement is incorrect. It doesn't. >, *then* I expect it to recognize a bare ² as an exponent That's incorrect, because it expects a term in that position, not an operator. > since bare exponents do not make any sense They do. In that context they're a term and you can use ANY `No` character as a numeral. > I.e. no specialcasing at all beyond what's already there. There's no special casing. There's just one rule: "you can use `No` characters as numerals". Simple. Elegant. Easy to remember.
Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
Am 07.06.2017 um 23:09 schrieb Zoffix Znet via RT: What baffles me is we have several people calling for the ban on The Superscripts yet, no one appears appear to have any issues with ⅟², 𑁓², ౸², ㆒², 𐌣², and 𑁒² which are also perfectly valid sequences. I would have issues with these if I had known about them. But before deciding how to deal with them: What are the supposed/expected meaning of the following constructs? 3² x² ² As the naive that I am, I'd expect these things to happen: 3² should be 3 squared, i.e. 9 x² to be x squared, i.e. an expression ² confuses me, does that even make sense? Replying to your other message: My entire point is the reason these sequence parse is due to well defined behaviour that a No character can be used as a literal numeral. What happens actually is that in ³², the ³ is taken as a base and the ² as an exponent (that's why we're getting ³² == 9. If the superscripts were handled just like normal literal digits, the result should be 32. What's undefined is why you, and Alex-Daniel you're seconding, hereare choosing to ban superscripts. Actually no. Well, at least for what I'd like to see, I'm not sure what Aleks-Daniel wanted. Anyway: Now given that the ² in ³² is already considered to be an exponent, I'd expect ³² to be the moral equivalent of **32. Which might or might not be a syntax error, depending on whether we have a numeric expression before it or not. If it's aesthetics alone,then there are plenty of other characters that foot the bill. Well, for me it's not aesthetics, it's expectations. *If* Perl6 is interpreting superscripts specially (and it already does), *then* I expect it to recognize a bare ² as an exponent, and since bare exponents do not make any sense, I'd expect it to throw an error. I.e. no specialcasing at all beyond what's already there. Actually I'd like to *remove* a special case: That ² is to be interpreted as 2 if it is not in a context that allows **2.
[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
On Wed, 07 Jun 2017 14:09:25 -0700, j...@durchholz.org wrote: > There's also the issue that undefined behaviour tends to become exploitable > as part of a security hole. > So I'm seconding Alekx-Daniel on this. It's not undefined. My entire point is the reason these sequence parse is due to well defined behaviour that a No character can be used as a literal numeral. It's just so happens superscripts are No numerals, which is why they're allowed to be used as the leading numeral. What's undefined is why you, and Alex-Daniel you're seconding, here are choosing to ban superscripts. If it's aesthetics alone, then there are plenty of other characters that foot the bill. Will you be special casing them as well? Will we create a Yucky Character Unicode Committee to police unsightly combinations? That's what's undefined here.
[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
On Wed, 07 Jun 2017 14:09:25 -0700, j...@durchholz.org wrote: > There's also the issue that undefined behaviour tends to become exploitable > as part of a security hole. > So I'm seconding Alekx-Daniel on this. It's not undefined. My entire point is the reason these sequence parse is due to well defined behaviour that a No character can be used as a literal numeral. It's just so happens superscripts are No numerals, which is why they're allowed to be used as the leading numeral. What's undefined is why you, and Alex-Daniel you're seconding, here are choosing to ban superscripts. If it's aesthetics alone, then there are plenty of other characters that foot the bill. Will you be special casing them as well? Will we create a Yucky Character Unicode Committee to police unsightly combinations? That's what's undefined here.
[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
On Wed, 07 Jun 2017 08:48:20 -0700, alex.jakime...@gmail.com wrote: > We had a bunch of segfaults Segfaults are program memory access errors. Here, we're talking about well-defined behaviour that you wish to make more complex on entirely arbitrary whim by special-casing the compiler, documentation, tests, and any program that relies on this well-defined behaviour. What baffles me is we have several people calling for the ban on The Superscripts yet, no one appears appear to have any issues with ⅟², 𑁓², ౸², ㆒², 𐌣², and 𑁒² which are also perfectly valid sequences. I'll tell you why, because no one typed that crap up on IRC and then said it looks weird to them. It's the sole reason this ticket exists and there's isn't a single real program in the world where making superscripts special-cased and erroring out on them would've done any good. The price of your proposal is unwanted complexity and IMO your justification for introducing it is entirely insufficient, poorly-defined, and arbitrary. The purpose of errors is to help people, not to make the language more complex.
[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
On Wed, 07 Jun 2017 08:48:20 -0700, alex.jakime...@gmail.com wrote: > We had a bunch of segfaults Segfaults are program memory access errors. Here, we're talking about well-defined behaviour that you wish to make more complex on entirely arbitrary whim by special-casing the compiler, documentation, tests, and any program that relies on this well-defined behaviour. What baffles me is we have several people calling for the ban on The Superscripts yet, no one appears appear to have any issues with ⅟², 𑁓², ౸², ㆒², 𐌣², and 𑁒² which are also perfectly valid sequences. I'll tell you why, because no one typed that crap up on IRC and then said it looks weird to them. It's the sole reason this ticket exists and there's isn't a single real program in the world where making superscripts special-cased and erroring out on them would've done any good. The price of your proposal is unwanted complexity and IMO your justification for introducing it is entirely insufficient, poorly-defined, and arbitrary. The purpose of errors is to help people, not to make the language more complex.
Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
On 6/7/17, Joachim Durchholz wrote: > There's also the issue that undefined behaviour tends to become > exploitable as part of a security hole. > Or, even worse, depended on for some perverse result.
Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
There's also the issue that undefined behaviour tends to become exploitable as part of a security hole. So I'm seconding Alekx-Daniel on this. Am 07.06.2017 um 17:48 schrieb Aleks-Daniel Jakimenko-Aleksejev via RT: (for example, because this kind of stuff makes the language look fragile). Let's resolve the issue by adding an error message and not by closing our eyes on this. On 2017-06-05 03:19:58, c...@zoffix.com wrote: FWIW, I rescind all of my previous comments on the matter and now think no special casing should be done to error out on ³² or anything like that. The only people I see complaining about it are those who just type it up randomly to see what it'd do; i.e. not an issue in real programs. I see no sufficient argument to add special casing in code, documentation, and tests, without solving any real problems.
Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
When I first started programming, any program that took physical input (which had usually been keyed very accurately by reliable young women) had to pass a test. It was fed its own machine code, backwards. It was expected to reach a normal EOJ, (albeit with a significant output of error messages). That seems like a reasonable standard of reliability. (Apologies for not deleting quoted text - damn' Gmail defaults.)
Re: [perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
When I first started programming, any program that took physical input (which had usually been keyed very accurately by reliable young women) had to pass a test. It was fed its own machine code, backwards. It was expected to reach a normal EOJ, (albeit with a significant output of error messages). That seems like a reasonable standard of reliability. On 6/7/17, Aleks-Daniel Jakimenko-Aleksejev via RT wrote: > “The only people I see complaining about it are those who just type it up > randomly to see what it'd do” > > We had a bunch of segfaults and overflows that could only be caused by > people > throwing random stuff into the compiler. And yes, very often we had to go > through this “wait, but normal people will not see this” idea, and in every > case it was fixed in rakudo instead (for example, because this kind of > stuff > makes the language look fragile). > > Let's resolve the issue by adding an error message and not by closing our > eyes > on this. > > On 2017-06-05 03:19:58, c...@zoffix.com wrote: >> FWIW, I rescind all of my previous comments on the matter and now >> think no special casing should be done to error out on ³² or anything >> like that. >> >> The only people I see complaining about it are those who just type it >> up randomly to see what it'd do; i.e. not an issue in real programs. I >> see no sufficient argument to add special casing in code, >> documentation, and tests, without solving any real problems. >
[perl #131530] [BUG] Perl6 REPL forgets the definition of infix sub
# New Ticket Created by
# Please include the string: [perl #131530]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131530 >
This is Rakudo version 2017.04.3-292-ga61746fed built on MoarVM version
2017.04-68-g5f233249
implementing Perl 6.c.
Executing the command "perl6" starts the normal REPL environment.
In the first line I define:
sub infix: { $^a + $^b }
and press ENTER. Then, in the next line:
1 w 2
===SORRY!=== Error while compiling:
Two terms in a row
--> say 1⏏ w 2
It seems that REPL forgets the definitions of infix subs. This only happens
with infix.
Re: [perl #131492] Camelia produces different error message from commandline
On Monday, June 05, 2017 5:05 PM, Will Coleda via RT wrote:
> On Fri, 02 Jun 2017 23:29:40 -0700, ben-goldb...@hotmail.com wrote:
> > On #perl6 IRC, I typed this:
> >
> > m: my \foo = Callable but role :: { };
> > <+camelia> rakudo-moar ef9872: OUTPUT: «X::Method::NotFound exception
> > produced no message in block at line 1»
> >
> > If, at my command prompt, I type perl6 –e “my \foo = Callable but role
> > :: { };”
> > I get instead:
> >
> > No such method 'mixin' for invocant of type
> > 'Perl6::Metamodel::ParametricRoleGroupHOW'
> > in block at -e line 1
> >
> >
> > Including, oddly, an extra blank line after the error and before my
> > prompt.
>
>
> Please provide the version of rakudo you're running locally so we can rule
> out any version skew.
>
C:\Users\Ben (user)>perl6 -v
This is Rakudo version 2017.01 built on MoarVM version 2017.01
implementing Perl 6.c.
Re: [perl #131492] Camelia produces different error message from commandline
On Monday, June 05, 2017 5:05 PM, Will Coleda via RT wrote:
> On Fri, 02 Jun 2017 23:29:40 -0700, ben-goldb...@hotmail.com wrote:
> > On #perl6 IRC, I typed this:
> >
> > m: my \foo = Callable but role :: { };
> > <+camelia> rakudo-moar ef9872: OUTPUT: «X::Method::NotFound exception
> > produced no message in block at line 1»
> >
> > If, at my command prompt, I type perl6 –e “my \foo = Callable but role
> > :: { };”
> > I get instead:
> >
> > No such method 'mixin' for invocant of type
> > 'Perl6::Metamodel::ParametricRoleGroupHOW'
> > in block at -e line 1
> >
> >
> > Including, oddly, an extra blank line after the error and before my
> > prompt.
>
>
> Please provide the version of rakudo you're running locally so we can rule
> out any version skew.
>
C:\Users\Ben (user)>perl6 -v
This is Rakudo version 2017.01 built on MoarVM version 2017.01
implementing Perl 6.c.
Re: [perl #131529] byte.Range should be 0..255 and not -∞^..^∞ (say byte.Range)
Fixed with https://github.com/rakudo/rakudo/commit/af85d5380b > On 7 Jun 2017, at 18:35, Aleks-Daniel Jakimenko-Aleksejev (via RT) > wrote: > > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev > # Please include the string: [perl #131529] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/Ticket/Display.html?id=131529 > > > > Code: > say byte.Range > > Result: > -Inf^..^Inf
[perl #131529] byte.Range should be 0..255 and not -∞^..^∞ (say byte.Range)
See also this discussion:
https://irclog.perlgeek.de/perl6-dev/2017-06-07#i_14699799
In other words, if you fix this, please also fix the dead code issue in
“default {}”.
On 2017-06-07 09:35:49, alex.jakime...@gmail.com wrote:
> Code:
> say byte.Range
>
> Result:
> -Inf^..^Inf
>
[perl #131529] byte.Range should be 0..255 and not -∞^..^∞ (say byte.Range)
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #131529] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131529 > Code: say byte.Range Result: -Inf^..^Inf
[perl #131528] [PRECOMP] Issues when sub itself instead of its "dispatcher" used in sub EXPORT
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #131528]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131528 >
>From what I understand subs—even `only` subs—have another Sub playing the role
>of a dispatcher or whatever:
m: sub foo {}.WHERE.say; &foo.WHERE.say
rakudo-moar dbd0f8: OUTPUT: «139686084622776139686084191728»
And it seems when the sub itself, instead of this "dispatcher", is used in sub
EXPORT in a precompiled
module that's used by another precompiled module, some wires get crossed over
and the sub cannot be called:
m: sub foo {}.WHERE.say; &foo.WHERE.say
rakudo-moar dbd0f8: OUTPUT: «139686084622776139686084191728»
$ cat Foo.pm6
sub EXPORT {
Map.new: '&foo' => sub foo { say 42 }
}
$ cat Bar.pm6
use Foo;
foo
$ perl6 -I. -MFoo -e 'foo'
42
$ perl6 -I. -MBar -e ''
===SORRY!===
Cannot invoke this object (REPR: Null; VMNull)
$
Doing any of the following fixes the above bug:
- adding `no precompilation` to Foo.pm6
- adding `no precompilation` to Bar.pm6
- instead of using the sub directly, defining it separately and using `&foo` as
value in the Map
[perl #126732] [RFC] Problem with superscripts when there is no number in front of it (³² == 9)
“The only people I see complaining about it are those who just type it up randomly to see what it'd do” We had a bunch of segfaults and overflows that could only be caused by people throwing random stuff into the compiler. And yes, very often we had to go through this “wait, but normal people will not see this” idea, and in every case it was fixed in rakudo instead (for example, because this kind of stuff makes the language look fragile). Let's resolve the issue by adding an error message and not by closing our eyes on this. On 2017-06-05 03:19:58, c...@zoffix.com wrote: > FWIW, I rescind all of my previous comments on the matter and now > think no special casing should be done to error out on ³² or anything > like that. > > The only people I see complaining about it are those who just type it > up randomly to see what it'd do; i.e. not an issue in real programs. I > see no sufficient argument to add special casing in code, > documentation, and tests, without solving any real problems.
[perl #131527] Cannot invoke this object (REPR: Null; VMNull)
# New Ticket Created by Juerd Waalboer # Please include the string: [perl #131527] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131527 > $ perl6 -I. -MFoo -e'my @foo is Foo where Str' ===SORRY!=== Cannot invoke this object (REPR: Null; VMNull) $ cat Foo.pm unit class Foo is Array; $ perl6 --ll-exception -I. -MFoo -e'my @foo is Foo where Str' Cannot invoke this object (REPR: Null; VMNull) at SETTING::src/core/TypedArray.pm:120 (/home/juerd/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm:parameterize) from src/Perl6/World.nqp:3055 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/World.moarvm:parameterize_type_with_args) from src/Perl6/World.nqp:1583 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/World.moarvm:container_type_info) from gen/moar/Perl6-Actions.nqp:3370 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Actions.moarvm:declare_variable) from gen/moar/Perl6-Actions.nqp:3227 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Actions.moarvm:variable_declarator) from gen/moar/stage2/QRegex.nqp:1671 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:!reduce) from gen/moar/stage2/QRegex.nqp:1617 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:!cursor_pass) from src/Perl6/Grammar.nqp:2645 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:variable_declarator) from src/Perl6/Grammar.nqp:2511 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:declarator) from src/Perl6/Grammar.nqp:2582 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:scoped) from :1 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:scope_declarator:sym) from gen/moar/stage2/QRegex.nqp:1708 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:!protoregex) from :1 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:scope_declarator) from :1 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:term:sym) from gen/moar/stage2/QRegex.nqp:1708 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:!protoregex) from :1 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:term) from src/Perl6/Grammar.nqp:3919 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:termish) from gen/moar/stage2/NQPHLL.nqp:935 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:EXPR) from src/Perl6/Grammar.nqp:3959 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:EXPR) from src/Perl6/Grammar.nqp:1289 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statement) from src/Perl6/Grammar.nqp:1221 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:statementlist) from gen/moar/stage2/NQPHLL.nqp:1165 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:LANG) from src/Perl6/Grammar.nqp:1657 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:FOREIGN_LANG) from src/Perl6/Grammar.nqp:1185 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:comp_unit) from src/Perl6/Grammar.nqp:492 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Grammar.moarvm:TOP) from gen/moar/stage2/QRegex.nqp:2311 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/QRegex.moarvm:parse) from gen/moar/stage2/NQPHLL.nqp:1909 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:parse) from gen/moar/stage2/NQPHLL.nqp:1851 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:run) from gen/moar/stage2/NQPHLL.nqp:1861 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:) from gen/moar/stage2/NQPHLL.nqp:1839 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:compile) from gen/moar/stage2/NQPHLL.nqp:1571 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:eval) from gen/moar/stage2/NQPHLL.nqp:1696 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:) from gen/moar/stage2/NQPHLL.nqp:1731 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:command_eval) from src/Perl6/Compiler.nqp:42 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/Perl6/Compiler.moarvm:command_eval) from gen/moar/stage2/NQPHLL.nqp:1677 (/home/juerd/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:command_line) from gen/moar/main.nqp:47 (/home/juerd/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm:MAIN) from gen/moar/main.nqp:38 (/home/juerd/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm:) from :1 (/home/juerd/.rakudobrew/moar-nom/install/share/perl6/runtime/perl6.moarvm:) from :
[perl #131481] [BUG] No perl6-debug
On Tue, 06 Jun 2017 19:50:32 -0700, rnhainswo...@gmail.com wrote: > I would like to work on perl6-debug. But where to start? > > I am daunted by the prospect. > > Some questions - hopefully easy to answer. > > 1) In earlier updates there was a perl6-debug executable. Was this > just > a link to perl6-debug-m? Most likely. > 2) perl6-debug worked before, and then stopped working. You said > 'bit-rotted'. I would think that it would help to discover at what > point > the debug version stopped working and then to look at the commits to > see > what changed. That would narrow down what needs modifying. > > Do you think this is a good strategy? Maybe. It broke around slang rework (around 2017.02-2017.03 releases). On our dev IRC channel ( https://webchat.freenode.net/?channels=#perl6-dev ) we have a bisectable bot ( https://github.com/perl6/whateverable/wiki/Bisectable ) that can take a chunk of code and tell you when its output changed. perl6-debug-m currently dies with this error. Hunting what's causing it is a good start: ``` Non ast passed to WANTED: NQPMu ===SORRY!=== Cannot find method 'named' on object of type NQPMu ``` > More difficult questions, but you may know answer. > > 3) Why is it not possible to arrange for a break inside a module? No idea. Never used perl6-debug-m > I realise it is because modules are 'pre-compiled', but is there a way > either (1) to prevent pre-compilation Yes, use `no precompilation` pragma.
[perl #131481] [BUG] No perl6-debug
On Tue, 06 Jun 2017 19:50:32 -0700, rnhainswo...@gmail.com wrote: > I would like to work on perl6-debug. But where to start? > > I am daunted by the prospect. > > Some questions - hopefully easy to answer. > > 1) In earlier updates there was a perl6-debug executable. Was this > just > a link to perl6-debug-m? Most likely. > 2) perl6-debug worked before, and then stopped working. You said > 'bit-rotted'. I would think that it would help to discover at what > point > the debug version stopped working and then to look at the commits to > see > what changed. That would narrow down what needs modifying. > > Do you think this is a good strategy? Maybe. It broke around slang rework (around 2017.02-2017.03 releases). On our dev IRC channel ( https://webchat.freenode.net/?channels=#perl6-dev ) we have a bisectable bot ( https://github.com/perl6/whateverable/wiki/Bisectable ) that can take a chunk of code and tell you when its output changed. perl6-debug-m currently dies with this error. Hunting what's causing it is a good start: ``` Non ast passed to WANTED: NQPMu ===SORRY!=== Cannot find method 'named' on object of type NQPMu ``` > More difficult questions, but you may know answer. > > 3) Why is it not possible to arrange for a break inside a module? No idea. Never used perl6-debug-m > I realise it is because modules are 'pre-compiled', but is there a way > either (1) to prevent pre-compilation Yes, use `no precompilation` pragma.
