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

Issues when sub itself instead of its "dispatcher" used in sub EXPORT #6331

Open
p6rt opened this issue Jun 7, 2017 · 3 comments
Open

Issues when sub itself instead of its "dispatcher" used in sub EXPORT #6331

p6rt opened this issue Jun 7, 2017 · 3 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Jun 7, 2017

Migrated from rt.perl.org#131528 (status was 'open')

Searchable as RT131528$

@p6rt
Copy link
Author

p6rt commented Jun 7, 2017

From @zoffixznet

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​: «139686084622776␤139686084191728␤»

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​: «139686084622776␤139686084191728␤»
 
 
  $ 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

@p6rt
Copy link
Author

p6rt commented Jun 8, 2017

From @LLFourn

I think this is just another example of the compile time closures problem
since EXPORT runs at compile time in during the loading module's
compilation.

https://rt.perl.org/Public/Bug/Display.html?id=128636

For an example in my own code​:

https://github.com/spitsh/spitsh/blob/master/lib/Spit/Constants.pm6

I can't put that sub definition in the constant assignment because it runs
at compile time.

On Thu, Jun 8, 2017 at 2​:31 AM Zoffix Znet <perl6-bugs-followup@​perl.org>
wrote​:

# New Ticket Created by Zoffix Znet
# Please include the string​: [perl #​131528]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/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​: «139686084622776␤139686084191728␤»

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&#8203;: sub foo \{\}\.WHERE\.say; &foo\.WHERE\.say
rakudo\-moar dbd0f8&#8203;: OUTPUT&#8203;: «139686084622776␤139686084191728␤»


$ cat Foo\.pm6
sub EXPORT \{
    Map\.new&#8203;: '&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&#8203;: 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

@p6rt
Copy link
Author

p6rt commented Jun 8, 2017

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

@p6rt p6rt added the precomp label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant