[perl #126855] [BUG] .WHAT does not allow spaces around the dot (42 . WHAT)

[Zoffix Znet via RT]

On Sun, 04 Jun 2017 11:19:57 -0700, c...@zoffix.com wrote:
> On Wed, 09 Dec 2015 08:12:00 -0800, alex.jakime...@gmail.com wrote:
> > Code:
> > say 42 .WHAT
> >
> > Result:
> > ===SORRY!===
> > Method call must either supply a name or have a child node that
> > evaluates
> > to the name
> >
> >
> > Well, I think that it should work. One practical use is ｢^42 .WHAT｣.
> >
> > Some explanation:
> >
> >  well, .WHAT anywhere in a space-y method call chain didn't
> > work with
> >  the original commit either
> >  so it's at least not a regression
> >  okay, interesting
> >  probably 'cause .WHAT doesn't go the normal
> >  QAST::Op(:op,...) route
> >  right, it's macro-Y
> >  which fits the error message, 'cause we apparently build such
> > an Op
> > but
> >  don't populate the children correctly, because .WHAT
> > isn't a
> > method
> >  that can be called with callmethod
> >
> >
> > Well, if it is not supposed to work, then at least the error message
> > should
> > be awesome. Right now it doesn't even mention the line number.
> 
> 
> +1 on fixing this or improving error message.
> 
> In my production code I encountered this bug while trying to test the
> term's type object
> and I added the space after the method to align stuff:
> 
> is make-temp-path.WHAT === IO::Path, *.not, 'made path is not ===
> IO::Path';
> is make-temp-dir .WHAT === IO::Path, *.not, 'made dir  is not ===
> IO::Path';
> 
> The second line crashed.
> 
> The current error doesn't even include a location, so it has the
> potential for a tedious bug hunt.


Hit on this bug again. Even while knowing you can't put spaces before .WHAT, it 
took me a couple of minutes trying to find where this error was coming from.

[perl #126855] [BUG] .WHAT does not allow spaces around the dot (42 . WHAT)

[Zoffix Znet via RT]

On Sun, 04 Jun 2017 11:19:57 -0700, c...@zoffix.com wrote:
> On Wed, 09 Dec 2015 08:12:00 -0800, alex.jakime...@gmail.com wrote:
> > Code:
> > say 42 .WHAT
> >
> > Result:
> > ===SORRY!===
> > Method call must either supply a name or have a child node that
> > evaluates
> > to the name
> >
> >
> > Well, I think that it should work. One practical use is ｢^42 .WHAT｣.
> >
> > Some explanation:
> >
> >  well, .WHAT anywhere in a space-y method call chain didn't
> > work with
> >  the original commit either
> >  so it's at least not a regression
> >  okay, interesting
> >  probably 'cause .WHAT doesn't go the normal
> >  QAST::Op(:op,...) route
> >  right, it's macro-Y
> >  which fits the error message, 'cause we apparently build such
> > an Op
> > but
> >  don't populate the children correctly, because .WHAT
> > isn't a
> > method
> >  that can be called with callmethod
> >
> >
> > Well, if it is not supposed to work, then at least the error message
> > should
> > be awesome. Right now it doesn't even mention the line number.
> 
> 
> +1 on fixing this or improving error message.
> 
> In my production code I encountered this bug while trying to test the
> term's type object
> and I added the space after the method to align stuff:
> 
> is make-temp-path.WHAT === IO::Path, *.not, 'made path is not ===
> IO::Path';
> is make-temp-dir .WHAT === IO::Path, *.not, 'made dir  is not ===
> IO::Path';
> 
> The second line crashed.
> 
> The current error doesn't even include a location, so it has the
> potential for a tedious bug hunt.


Hit on this bug again. Even while knowing you can't put spaces before .WHAT, it 
took me a couple of minutes trying to find where this error was coming from.

[perl #131887] [BUG] method freeze(Pair:D:) changes object identity

[Jan-Olof Hendig via RT]

On Sun, 13 Aug 2017 15:14:41 -0700, elizabeth wrote:
> Fixed with https://github.com/rakudo/rakudo/commit/c229022cb0 , tests
> needed
> 
> > On 12 Aug 2017, at 14:36, Peter du Marchie van Voorthuysen (via RT)
> >  wrote:
> >
> > # New Ticket Created by  Peter du Marchie van Voorthuysen
> > # Please include the string:  [perl #131887]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/Ticket/Display.html?id=131887 >
> >
> >
> > This is Rakudo version 2017.07 built on MoarVM version 2017.07
> > implementing Perl 6.c.
> >
> > If the value of a Pair is a Scalar container, then the Pair can be
> > modified, e.g.
> >
> >> my $value = 0;
> > 0
> >> my $pair = number => $value;
> > number => 0
> >> $pair.value = 1; $pair;
> > number => 1
> >
> > Method freeze make the value of the Pair read-only, by removing it
> > from its
> > Scalar container, and returns the value.
> >
> >> $pair.freeze;
> > 1
> >> $pair.value = 2;
> > Cannot modify an immutable Int (1)
> >   in block  at  line 1
> >
> > The problem is that freeze does more than that. It changes the object
> > identity as returned by WHICH as well:
> >
> >> $pair = number => $value;
> > number => 1
> >> $pair.WHICH;
> > Pair|127791728
> >> $pair.freeze;
> > 1
> >> $pair.WHICH;
> > Pair|Str|number|Int|1
> >
> > Now by itself having a 2-tuple that is identified by its two elements
> > is a
> > nice feature (if it would be documented). But _changing_ the object
> > identity is not consistent with the behavior of other built-in Perl 6
> > classes and actually breaks the implementation of some of these
> > classes.
> >
> > For example, a SetHash represents a mutable set. The Set method
> > returns a
> > _new_ object that is immutable:
> >
> >> $pair = number => $value;
> > number => 1
> >> my $set = SetHash.new($pair);
> > SetHash.new(number => 1)
> >> my $set2 = $set.Set;
> > set(number => 1)
> >> $set.WHICH;
> > SetHash|136539408
> >> $set2.WHICH;
> > Set|0EC3BFFD57719F5C6A3EE91A5EFAA5AEFE273964
> >
> > But because freezing a Pair changes the identity of the _original_
> > object
> > it's possible to add a second instance of the _same_ Pair to the
> > SetHash,
> > causing it to violate its contract:
> >
> >> $pair.freeze;
> > 1
> >> $set{$pair} = True;
> > True
> >> my ($a, $b) = $set.keys;
> > (number => 1 number => 1)
> >> $a === $b;
> > True
> >
> > I think it's clear that changing the identity of the original object
> > is not
> > correct. So I propose to remove the undocumented behavior of the
> > freeze
> > method that it changes the object identity.
> >
> > Now I can imagine that at some implementation level there are
> > benefits to
> > having a kind of Pair that is identified by its key _and_ value. I
> > also
> > think it could be generally useful to have a class implementing a
> > truly
> > immutable (2-)tuple that is identified by its elements. But that
> > should be
> > a separate class and the Pair class should provide a method to create
> > a
> > _new_ object of this class from a Pair object.

Test added with commit https://github.com/perl6/roast/commit/d7d42d6c37

[perl #127093] gist missing for non-native typed array that doesn't get initialized

[Aleks-Daniel Jakimenko-Aleksejev via RT]

OK this issue is resolved with the commit mentioned above. Tests needed.

As for *int* native array having NaNs in it, that's not going to happen. It's
an array of native ints, it just can't and won't ever store any other type of a
value. A native int can't be NaN.

On 2016-01-02 06:34:50, lhermida wrote:
> On Sat Jan 02 06:31:40 2016, lhermida wrote:
> > On Sat Jan 02 04:14:47 2016, elizabeth wrote:
> > > > On 30 Dec 2015, at 19:41, Leandro Hermida (via RT)  > > > follo...@perl.org> wrote:
> > > >
> > > > # New Ticket Created by Leandro Hermida
> > > > # Please include the string: [perl #127093]
> > > > # in the subject line of all future correspondence about this
> > > > issue.
> > > > # https://rt.perl.org/Ticket/Display.html?id=127093 >
> > > >
> > > >
> > > >> my @a[4]
> > > > [(Any) (Any) (Any) (Any)]
> > > >> my Int @a[4] = 0..3
> > > > [0 1 2 3]
> > > >> my Int @a[4]
> > > > Method 'gist' not found for invocant of class 'NQPMu'
> > > >
> > > > I expected:
> > > > [(Int) (Int) (Int) (Int)]
> > > >
> > > > By defining native typed arrays do have a gist:
> > > >
> > > >> my int @a[4]
> > > > [0 0 0 0]
> > >
> > > Thanks for reporting!
> > >
> > > This was fixed, at least temporarily, with 42326d1b72f658f6dc5 .
> > > No
> > > tests have been added yet, in lieu of finding out how we’re going
> > > to
> > > do this post 6.c .
> > >
> > >
> > >
> > > Liz
> >
> >
> > Thanks Liz, another thing I forgot to ask about in the ticket, the
> > other unexpected behavior for me at least is when a native typed
> > array
> > is declared but not initialized each element of the array has a zero
> > where I would've expected it to be sized but not initialized and have
> > no value within each element. Is this part of spec?
> >
> > > my int @a[4]
> > [0 0 0 0]
>
> Sorry sent too fast, from what I read Perl 6 has no undef value I
> would expect the declaration of a native-typed numeric or integer
> array to be this:
>
> > my int @a[4]
> [NaN NaN NaN NaN]

[perl #126955] [BUG] more .perl string quoting problems

[Jan-Olof Hendig via RT]

On Mon, 21 Dec 2015 11:09:40 -0800, zef...@fysh.org wrote:
> Elizabeth Mattijsen via RT wrote:
> >All of that goodness now in 591783d116a56d4b2c54f .
> 
> You left a stray line in IO::Path.perl, which calls PERLIFY-STR in
> sink context.
> 
> >Indeed!   Now, if this had been in a Pull Request, I could have just
> >clicked on Merge, which would have been less work for me  :-)
> 
> But it being a Pull Request would involve me signing over my firstborn
> to github.
> 
> >Ever considered getting a commit bit ?
> 
> I think that would be a bad idea, for a number of reasons.  I'm suffering
> project overload as it is, and haven't used my Perl 5 commit bit in ages.
> You also know my overall opinion of Perl 6, and that doesn't make Rakudo
> an attractive bugfixing target for me.  It seems best that my involvement
> remain peripheral.
> 
> -zefram
> 

The stray line was removed with commit 34c4fe977e067b4e4eb02b5d. Test needed.

[perl #127352] [BUG] Behavior of Regular Expressions Contained in a Constant with a Sigil

[Jan-Olof Hendig via RT]

On Fri, 05 Aug 2016 18:04:36 -0700, c...@zoffix.com wrote:
> Still present today:
> 
>  m: my $sepreg = rx/(<[\\/]>)/; my $filenameW =
> "c:\\g\\b.mp4"; $filenameW ~~ $sepreg; say $/;
>  rakudo-moar 589061: OUTPUT«｢\｣␤ 0 => ｢\｣␤»
>  m: constant $sepreg = rx/(<[\\/]>)/; my $filenameW =
> "c:\\g\\b.mp4"; $filenameW ~~ $sepreg; say $/;
>  rakudo-moar 589061: OUTPUT«Nil␤»
>  m: constant sepreg = rx/(<[\\/]>)/; my $filenameW =
> "c:\\g\\b.mp4"; $filenameW ~~ sepreg; say $/;
>  rakudo-moar 589061: OUTPUT«｢\｣␤ 0 => ｢\｣␤»

Fixed with commit 
https://github.com/rakudo/rakudo/commit/5ac593ee098f204ea69ef57edd9ae0925c544ea4

[perl #132909] [LTA?] Failure return from require when load fails

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Pretty sure this is a dup of https://github.com/rakudo/rakudo/issues/1515 , you
can follow the progress on the issue there. Let us know if your problem is
actually different.

Closing

On 2018-02-25 11:11:55, mt1...@gmail.com wrote:
> Hi,
>
> According to the documentation one should use the following to trap a
> failure when loading a module fails using require;
>
> try require ::('Foo');
> note ::('Foo').Str if ::('Foo') ~~ Failure;
>
> The problem with this is that it isn't visible what is going wrong.
> Using plain
>
> require ::('Foo');
>
> an exception is thrown with a proper error and stack dump. However
> when
> there are no errors in the module, there are other exceptions thrown
> with messages like
>
> WARNING: unhandled Failure detected in DESTROY. If you meant to ignore
> it, you can mark it as handled by
> calling .Bool, .so, .not, or .defined methods. The Failure was:
> No such symbol 'Foo'
> in block at ... (...) line ...
> ...
>
> This seems to me a bug. The only way to handle this properly is the
> following
>
> try {
> require ::('Foo');
>
> ...
>
> CATCH {
> .note;
> }
> }
>
>
>
> Perl6 version: 2018.01-195-g5ae1ca51f built on MoarVM version
> 2018.01-89-ga01cdb449 implementing Perl 6.c.
>
> Regards,
> Marcel