Skip Menu |
Report information
Id: 127086
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: rob [at] hoelz.ro
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: Moar



Subject: Calling subroutines from CORE fails in BEGIN blocks in loaded modules
Download (untitled) / with headers
text/plain 264b
For example, in test.pl: Show quoted text
> use TestModule;
in TestModule.pm: Show quoted text
> BEGIN say 'hi';
If we run test.pl, we get the following failure: ===SORRY!=== Constraint type check failed for parameter '$precomp-id' The commit that introduces the problem is 54e0577 on Rakudo.
Download (untitled) / with headers
text/plain 556b
Your demonstration code does not show an error like you described. What it does show is that the precompilation process uses STDOUT to communicate back the dependencies of a precompiled module. That means, that you cannot also use STDOUT in your module's main line. There shouldn't be a reason for a module to say anything during BEGIN time. For debugging, use note. STDERR is unused. If you find a use case where a module really has to print something to STDOUT during loading, please also find a good way for the precompilation process to communicate :)
Date: Thu, 31 Dec 2015 05:43:47 +0000
Subject: Re: [perl #127086] Calling subroutines from CORE fails in BEGIN blocks in loaded modules
From: Lloyd Fournier <lloyd.fourn [...] gmail.com>
To: perl6-compiler [...] perl.org, bugs-bitbucket [...] rt.perl.org
Download (untitled) / with headers
text/plain 745b
I have had this happen too. I think it's actually doing anything that writes to stdout during compile time rather than calling CORE but I could be wrong.
On Thu, 31 Dec 2015 at 1:26 AM, Rob Hoelz <perl6-bugs-followup@perl.org> wrote:
Show quoted text
# New Ticket Created by  Rob Hoelz
# Please include the string:  [perl #127086]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=127086 >


For example, in test.pl:

> use TestModule;

in TestModule.pm:

> BEGIN say 'hi';

If we run test.pl, we get the following failure:

===SORRY!===
Constraint type check failed for parameter '$precomp-id'

The commit that introduces the problem is 54e0577 on Rakudo.
Download (untitled) / with headers
text/plain 1.5k
On 2015-12-30 21:44:42, lloyd.fourn@gmail.com wrote: Show quoted text
> I have had this happen too. I think it's actually doing anything that > writes to stdout during compile time rather than calling CORE but I could > be wrong. > On Thu, 31 Dec 2015 at 1:26 AM, Rob Hoelz <perl6-bugs-followup@perl.org> > wrote: >
> > # New Ticket Created by Rob Hoelz > > # Please include the string: [perl #127086] > > # in the subject line of all future correspondence about this issue. > > # <URL: https://rt.perl.org/Ticket/Display.html?id=127086 > > > > > > > For example, in test.pl: > >
> > > use TestModule;
> > > > in TestModule.pm: > >
> > > BEGIN say 'hi';
> > > > If we run test.pl, we get the following failure: > > > > ===SORRY!=== > > Constraint type check failed for parameter '$precomp-id' > > > > The commit that introduces the problem is 54e0577 on Rakudo. > >
From IRC (http://irclog.perlgeek.de/perl6/2016-01-03#i_11823821): Show quoted text
> 21:49 nine hoelzro: I would not mind you reopening the ticket either. But if you do, I'd really appreciate a suggestion for a fix, because I have no idea :)
My only suggestion for a fix at this time is to perhaps dup standard output to a file descriptor for writing precomp IDs, open standard output to /dev/null (or the platform equivalent), and perhaps make $*OUT a fake handle that notifies the user that $*OUT isn't available at BEGIN time. The open() is just a safety measure for things that can access standard output without going through $*OUT (ex. nqp::say). Another idea is to avoid writing precomp IDs to standard output, and instead provide an output filename via the command line.
Feedback from Stefan: Show quoted text
> 22:22 nine hoelzro: one word: Windows > 22:23 hoelzro: everything would be dead simple if we only supported Unix. Then I'd just open a pipe and pass the file descriptor to the child process.
http://irclog.perlgeek.de/perl6/2016-01-03#i_11823946 On 2016-01-03 14:20:34, rob@hoelz.ro wrote: Show quoted text
> On 2015-12-30 21:44:42, lloyd.fourn@gmail.com wrote:
> > I have had this happen too. I think it's actually doing anything that > > writes to stdout during compile time rather than calling CORE but I > > could > > be wrong. > > On Thu, 31 Dec 2015 at 1:26 AM, Rob Hoelz <perl6-bugs- > > followup@perl.org> > > wrote: > >
> > > # New Ticket Created by Rob Hoelz > > > # Please include the string: [perl #127086] > > > # in the subject line of all future correspondence about this > > > issue. > > > # <URL: https://rt.perl.org/Ticket/Display.html?id=127086 > > > > > > > > > > For example, in test.pl: > > >
> > > > use TestModule;
> > > > > > in TestModule.pm: > > >
> > > > BEGIN say 'hi';
> > > > > > If we run test.pl, we get the following failure: > > > > > > ===SORRY!=== > > > Constraint type check failed for parameter '$precomp-id' > > > > > > The commit that introduces the problem is 54e0577 on Rakudo. > > >
> > From IRC (http://irclog.perlgeek.de/perl6/2016-01-03#i_11823821): >
> > 21:49 nine hoelzro: I would not mind you reopening the > > ticket either. But if you do, I'd really appreciate a suggestion for > > a fix, because I have no idea :)
> > My only suggestion for a fix at this time is to perhaps dup standard > output to a file descriptor for writing precomp IDs, open standard > output to /dev/null (or the platform equivalent), and perhaps make > $*OUT a fake handle that notifies the user that $*OUT > isn't available at BEGIN time. The open() is just a safety measure > for things that can access standard output without going through $*OUT > (ex. nqp::say). > > Another idea is to avoid writing precomp IDs to standard output, and > instead provide an output filename via the command line.


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