Skip Menu |
Report information

Date: Fri, 8 Dec 2017 11:27:45 -0500
To: rakudobug [...] perl.org
From: brian d foy <brian.d.foy [...] gmail.com>
Subject: Can't put() any(): This type cannot unbox to a native string
Download (untitled) / with headers
text/plain 715b
This comes from an answer to a Perl 6 question on Stackoverflow that showed a different bug: https://stackoverflow.com/q/45527881/2766176 With put() it does not and gives a strange error: $ perl6 -e 'put any( 1, 3, 7 ) ' This type cannot unbox to a native string: P6opaque, Junction in block <unit> at -e line 1 $ perl6 -e 'put( any( 1, 3, 7 ) )' This type cannot unbox to a native string: P6opaque, Junction in block <unit> at -e line 1 With say it has no problem: $ perl6 -e 'say any( 1, 3, 7 )' any(1, 3, 7) $ perl6 -e 'put any( 1, 3, 7 ).gist' any(1, 3, 7) I'd expect anything that can .gist would be able to .Str. This is Rakudo 2017.10 on macOS 10.13.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
On Fri, 08 Dec 2017 08:28:32 -0800, comdog wrote: Show quoted text
> This comes from an answer to a Perl 6 question on Stackoverflow that > showed a different bug: > > https://stackoverflow.com/q/45527881/2766176 > > With put() it does not and gives a strange error:
I guess jnthn++ gets a score point for predicting[^1] this would happen: <jnthn> Hmmm...not too keen on the Junction.Str patch <jnthn> Anything that (quite reasonably) does nqp::unbox_s($foo.Str) is now going to (quite rightly) explode <timotimo> clearly we have to build UNBOXABLE_STR :) <jnthn> No, it can just explode, and then I'll point people at this commit. :P If put() were made to work here, I'd expect it to junct and be equivalent to `put 1`, `put 3`, `put 7` executed in random order, but the OP in that SO has an entirely different expectation. Show quoted text
> I'd expect anything that can .gist would be able to .Str.
Side note on that: only the opposite is true. A basic class would .gist to its name, while its .Str would be an empty string accompanied by a warning. Also, some things, like self-referential structures or non-lazy infinite iterables, would take an infinite time to .Str, while getting .gisted is no trouble. [1] https://irclog.perlgeek.de/perl6-dev/2017-08-09#i_14992203
Date: Sat, 9 Dec 2017 22:19:02 +0100
To: perl6-bugs-followup [...] perl.org
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: Re: [perl #132549] Can't put() any(): This type cannot unbox to a native string
Download (untitled) / with headers
text/plain 1.2k
Show quoted text
> On 8 Dec 2017, at 19:21, Zoffix Znet via RT <perl6-bugs-followup@perl.org> wrote: > > On Fri, 08 Dec 2017 08:28:32 -0800, comdog wrote:
>> This comes from an answer to a Perl 6 question on Stackoverflow that >> showed a different bug: >> >> https://stackoverflow.com/q/45527881/2766176 >> >> With put() it does not and gives a strange error:
> > I guess jnthn++ gets a score point for predicting[^1] this would happen: > > <jnthn> Hmmm...not too keen on the Junction.Str patch > <jnthn> Anything that (quite reasonably) does nqp::unbox_s($foo.Str) is now > going to (quite rightly) explode > <timotimo> clearly we have to build UNBOXABLE_STR :) > <jnthn> No, it can just explode, and then I'll point people at this commit. :P
Which would be me. And as far as I recall atm, that was in response to making: $ 6 'dd "foo" ~ any(1,3,5) ~ "bar"' any("foo1bar", "foo3bar", "foo5bar”) work. If that shouldn’t work, or work differently, it can be ripped out / replaced. If that should work, then we need to look at fixing -put-. Show quoted text
> If put() were made to work here, I'd expect it to junct and be equivalent to `put 1`, `put 3`, `put 7` executed in random order, but the OP in that SO has an entirely different expectation.
FWIW, I would also expect it to junct.
RT-Send-CC: perl6-compiler [...] perl.org
On Sat, 09 Dec 2017 13:19:23 -0800, elizabeth wrote: Show quoted text
> If that shouldn’t work, or work differently, it can be ripped > out / replaced. If that should work, then we need to look at fixing > -put-.
IMO it should work, considering you can't nqp::unbox_n/nqp::unbox_i Junctions either, yet we don't have Junction-related explosions with numeric stuff. I also found another issue: IO::Handle.print/put infiniloop in dispatch when given a Junction. Show quoted text
> FWIW, I would also expect it to junct.
I started a fix down that path, but it kinda looks gross and dirty. Similar thing would be needed in src/core/io_operators.pm for subroutine versions. The Junctions go through the **@foo slurpy candidates and the explosions then happen inside optimizations, where we assume x.Str gives an unboxable Str. Is there a better way? Here's my thing: 2017.11.50 zoffix@VirtualBox~/CPANPRC/rakudo (master)$ gd diff --git a/src/core/IO/Handle.pm b/src/core/IO/Handle.pm index 55ff911..0303047 100644 --- a/src/core/IO/Handle.pm +++ b/src/core/IO/Handle.pm @@ -652,6 +652,11 @@ my class IO::Handle { multi method print(IO::Handle:D: **@list is raw --> True) { # is raw gives List, which is cheaper self.print(@list.join); } + multi method print(IO::Handle:D: Junction \j --> True) { + # junct the Junction. Without this candidate, we'd go through the + # **@list slurpy candidate and dispatch infiniloop. + -> Any \el { self.print: el }(j) + } proto method put(|) {*} multi method put(IO::Handle:D: Str:D \x --> True) { @@ -662,6 +667,11 @@ my class IO::Handle { multi method put(IO::Handle:D: **@list is raw --> True) { # is raw gives List, which is cheaper self.put(@list.join); } + multi method put(IO::Handle:D: Junction \j --> True) { + # junct the Junction. Without this candidate, we'd go through the + # **@list slurpy candidate and dispatch infiniloop. + -> Any \el { self.put: el }(j) + } multi method say(IO::Handle:D: Str:D $x --> True) { $!decoder or die X::IO::BinaryMode.new(:trying<say>);
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 2.4k
On Sat, 09 Dec 2017 15:26:25 -0800, cpan@zoffix.com wrote: Show quoted text
> On Sat, 09 Dec 2017 13:19:23 -0800, elizabeth wrote:
> > If that shouldn’t work, or work differently, it can be ripped > > out / replaced. If that should work, then we need to look at fixing > > -put-.
> > IMO it should work, considering you can't nqp::unbox_n/nqp::unbox_i > Junctions either, yet we don't have Junction-related explosions with > numeric stuff. > > I also found another issue: IO::Handle.print/put infiniloop in > dispatch when given a Junction. > >
> > FWIW, I would also expect it to junct.
> > I started a fix down that path, but it kinda looks gross and dirty. > Similar thing would be needed > in src/core/io_operators.pm for subroutine versions. The Junctions go > through the **@foo slurpy candidates > and the explosions then happen inside optimizations, where we assume > x.Str gives an unboxable Str. > > Is there a better way? Here's my thing: > > 2017.11.50 zoffix@VirtualBox~/CPANPRC/rakudo (master)$ gd > diff --git a/src/core/IO/Handle.pm b/src/core/IO/Handle.pm > index 55ff911..0303047 100644 > --- a/src/core/IO/Handle.pm > +++ b/src/core/IO/Handle.pm > @@ -652,6 +652,11 @@ my class IO::Handle { > multi method print(IO::Handle:D: **@list is raw --> True) { # is > raw gives List, which is cheaper > self.print(@list.join); > } > + multi method print(IO::Handle:D: Junction \j --> True) { > + # junct the Junction. Without this candidate, we'd go through > the > + # **@list slurpy candidate and dispatch infiniloop. > + -> Any \el { self.print: el }(j) > + } > > proto method put(|) {*} > multi method put(IO::Handle:D: Str:D \x --> True) { > @@ -662,6 +667,11 @@ my class IO::Handle { > multi method put(IO::Handle:D: **@list is raw --> True) { # is raw > gives List, which is cheaper > self.put(@list.join); > } > + multi method put(IO::Handle:D: Junction \j --> True) { > + # junct the Junction. Without this candidate, we'd go through > the > + # **@list slurpy candidate and dispatch infiniloop. > + -> Any \el { self.put: el }(j) > + } > > multi method say(IO::Handle:D: Str:D $x --> True) { > $!decoder or die X::IO::BinaryMode.new(:trying<say>);
Thank you for the report. lizmat++ fixed this. Fix: https://github.com/rakudo/rakudo/commit/8155c4b885 https://github.com/rakudo/rakudo/commit/9de4a60efe https://github.com/rakudo/rakudo/commit/07616effd1 Test: https://github.com/perl6/roast/commit/97ceb93f40214cb7c


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org