Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cannot print junctions, gives unboxing error message #2711

Closed
p6rt opened this issue Apr 11, 2012 · 6 comments
Closed

cannot print junctions, gives unboxing error message #2711

p6rt opened this issue Apr 11, 2012 · 6 comments

Comments

@p6rt
Copy link

p6rt commented Apr 11, 2012

Migrated from rt.perl.org#112392 (status was 'resolved')

Searchable as RT112392$

@p6rt
Copy link
Author

p6rt commented Apr 11, 2012

From @moritz

11​:18 < jaffa4> rakudo​: print 1|2|3;
11​:18 <+p6eval> rakudo 3bd91f​: OUTPUT«This type cannot unbox to a native
  string␤ in method print at src/gen/CORE.setting​:6381␤
  in sub
  print at src/gen/CORE.setting​:6252␤ in block <anon> at
  /tmp/I_61q5dNjv​:1␤␤»

Should either autothread, or stringify the junction as a whole

@p6rt
Copy link
Author

p6rt commented Nov 21, 2012

From @FROGGS

still the same​:

<FROGGS> rakudo​: print 1 | 2 | 3;
<p6eval> rakudo bf472b​: OUTPUT«This type cannot unbox to a native
string␤ in method print at src/gen/CORE.setting​:7644␤ in sub print at
src/gen/CORE.setting​:7454␤ in block at /tmp/xB1f5M7g6V​:1␤␤»

but this is a related/new bug ($v shouldnt be visible)​:
<FROGGS> rakudo​: print (1 | 2 | 3).WHAT;
<p6eval> rakudo bf472b​: OUTPUT«use of uninitialized variable $v of type
Junction in string context in block at /tmp/iA1JwAYkxB​:1␤␤»

@p6rt
Copy link
Author

p6rt commented Nov 21, 2012

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Jan 11, 2013

From @jnthn

On Wed Apr 11 02​:22​:30 2012, moritz wrote​:

11​:18 < jaffa4> rakudo​: print 1|2|3;
11​:18 <+p6eval> rakudo 3bd91f​: OUTPUT«This type cannot unbox to a native
string␤ in method print at src/gen/CORE.setting​:6381␤
in sub
print at src/gen/CORE.setting​:6252␤ in block <anon> at
/tmp/I_61q5dNjv​:1␤␤»

Should either autothread, or stringify the junction as a whole

The root of the trouble is that .Str auto-threaded, meaning that it gave
back another Junction, not a Str. Fixed that, and now​:

print 1|2|3;
any(1, 2, 3)>

So, tagging testneeded.

/jnthn

@p6rt
Copy link
Author

p6rt commented Feb 3, 2013

From @moritz

Tested in the ever-growing S03-junctions/misc.t

@p6rt
Copy link
Author

p6rt commented Feb 3, 2013

@moritz - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Feb 3, 2013
@p6rt p6rt added the testneeded label Jan 5, 2020
vrurg added a commit to vrurg/roast that referenced this issue Jan 4, 2022
It had different meaning long ago
(Raku/old-issue-tracker#2711). But since then
only specialized `gist` and `raku` methods are supposed to evade
autothreading over a Junction. Contrary to them, `Str` and alikes must
autothread and result in a new junction with their outcomes as
eigenstates.

Despite of the long-ago decided shift in meaning, the test was passing
by accident simply meaning that all eigenstates of the resulting LHS
junction are `Str`. Since this behavior is covered by other tests, this
line can be safely removed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant