"Calling x will never work with the declared signature" error when EVAL is done in a BEGIN block #2779
Comments
|
bisect log: running 1 787d5bf This is Rakudo version 2019.03.1-102-g787d5bf6e built on MoarVM version 2019.03-44-g079d67002 FAIL |
AlexDaniel
added
the
BLOCKER
|
I've golfed this to: which is quite a different error? This is on: |
So that users can bisect arbitrary code. The code can depend on modules, in which case these have to be listed on the command line (e.g. for a script depending on WWW you should list WWW module, dependencies will be detected automatically). Using this ticket as an example: rakudo/rakudo#2779 Create file foo.p6 with this content: use WWW; my @StationS; @StationS = | jpost "https://www.perl6.org", :limit(42); Then run Blin: ./bin/blin.p6 --old=2018.12 --new=HEAD --custom-script=foo.p6 WWW Then check out the output folder to see the results. Resolves #11.
|
Looking at the blog post, I realized that there's a problem with tooling. So now it's possible to use Blin with custom scripts! @gfldex++ |
|
@lizmat: You golfed the bug away. What you got is expected, because |
|
On 26 Mar 2019, at 18:12, Wenzel P. P. Peppmeyer ***@***.***> wrote:
@lizmat: You golfed the bug away. What you got is expected, because jpost is calling from-json.
I’m NOT seeing that error:
$ perl6 -e 'use WWW; my @A = | jpost "https://www.perl6.org", :limit(42)'
at 1: expected a json object, but got < (context: "<!DOCTYP")
in sub jpost at /Users/liz/Github/rakudo.moar/install/bin/../share/perl6/site/sources/674E3526955FCB738B7B736D9DBBD3BD5B162E5C (WWW) line 9
in block <unit> at -e line 1
$ perl6 --version
This is Rakudo version 2019.03.1-119-g89b4467 built on MoarVM version 2019.03-61-g645a70c
implementing Perl 6.d.
|
|
tracked on travis via https://travis-ci.org/gfldex/perl6-hard-tests |
|
@gfldex not sure what your plan for perl6-hard-tests repo is, it looks promising. However, if you add the same test to WWW itself, we would notice this issue before the release (if the problem appears again). Looking at https://github.com/perl6/ecosystem-unbitrot, there's no ticket for WWW, meaning that the tests were green before the release. And Blin bisected the issue to 4ffb408 (similarly to your results)… However, the current status of WWW module is |
|
That repo is running on a travis cron job once a week. If by chance a future Rakudo commit fixes this bug as well, I will get an e-mail. That may allow to narrow it down. I would come up with a better idea if I had one. |
|
Just run travis again over a PR I did some time ago, with the test results being a bit more informative: https://travis-ci.org/perl6-community-modules/perl6-WWW/builds/491289924?utm_source=github_status&utm_medium=notification |
|
OTOH, and just as a reminder, LWP::Simple works correctly (AFAIK) |
|
I have merged my pull request and tested it locally, and there does not seem to be a problem. I'm going to run more tests to see if I find out what. |
|
The error is here: 72 goes all the way through as an Int, but that function requires a String. I'm not sure how to mitigate that, of where the error is along the line. I'll try to see if I can fix it there in origin and submit a PR. |
|
That was introduced in Feb 28th here: |
|
Posted a patch: /sergot/http-useragent#223 |
|
Part of the confusion is the original post in this issue has the wrong URL; it should be the one in this commit to try to reproduce the bug. I've tried it with something close to Rakudo |
|
@jnthn I don't think it makes a difference. It should be fixed with my patch to HTTP::UserAgent. I can add that test to WWW if you want. |
kawaii
removed
the
BLOCKER
|
I may have found another way to trigger this odd bug. yields: |
This situation could occur in the case of a begin-time EVAL that had a code expression that contained an immediate QAST block. This led to the failed $_ lookup reported in #2779, meaning that compilation of that module no longer fails. Unfortunately, that isn't enough to make it actually work, but it's a step closer.
|
I don't think this First, why It seems that somehow, the Which is, well, oops. |
|
Also, the patch I submitted has not been merged yet... so the same error is
bound to happen
El mar., 14 may. 2019 a las 16:05, Jonathan Worthington (<
[email protected]>) escribió:
… I don't think this NoNilList thing here is the same thing. I've taken a
look into it. The heart of the matter is this:
sub EXPORT($_?) {
given $_ {
when 'Warning' {
EVAL ‚use MONKEY-TYPING; augment class Nil {
method list() {
note 'Trying to turn Nil into a list.';
note Backtrace.new.list.tail.Str;
Empty
}
}‘;
}
when 'Fatal' {
EVAL ‚use MONKEY-TYPING; augment class Nil {
method list() {
X::TypeCheck::NilToList.new().fail();
}
}‘;
}
default {
die 'Please use NoNilList::Warning or NoNilList::Fatal.';
}
}
%()
}
First, why EVAL and not just use the MOP? But OK, it should still work.
It turns out that in BEGIN-time mode, when we EVAL, we compile code
immediately. I think that was to address an earlier issue, and it probably
makes some sense. Unfortunately, since we compile *everything*, then we'd
also end up compiling immediate blocks, and then executing them rather than
just producing them. I addressed that in b9f8995
<b9f8995>.
Now the error is:
Too many positionals passed; expected 0 arguments but got 1
at <unknown>:1 (/home/jnthn/dev/perl6-nonillist/lib/.precomp/F0410381E8657AD8BB8FAA6C55BB868DE9B158DB/A2/A27A785FBAA3C9C57ADFA999D72B40C0DEDA55A8:<dependencies+deserialize>)
from t/02-warn.t:16 (<ephemeral file>:<unit>)
from t/02-warn.t:1 (<ephemeral file>:<unit-outer>)
It seems that somehow, the <dependencies+deserialize> block is ending up
being installed in the Nil.list method instead of the intended one:
$ perl6 -Ilib -e 'use NoNilList::Warning; dd Nil.^find_method("list")'
Method <dependencies+deserialize> = method <dependencies+deserialize> (Nil: *%_) { #`(Method|66502368) ... }
Which is, well, oops.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2779?email_source=notifications&email_token=AAAAD5BWNKWGY5BCDLMPLLDPVLBMJA5CNFSM4HAKDGBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVLSXHQ#issuecomment-492252062>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAAD5AJMJBPCB2ZYISNHP3PVLBMJANCNFSM4HAKDGBA>
.
--
JJ
|
|
@niner Don't suppose you have any guesses? I'm wondering if it's some kind of cuid conflict or some such, but if beats me where... |
|
Not yet a guess, but an even smaller example of where it's going wrong: And a different error when there's no argument: Seems like the sub's code obj definitely ends up in the wrong place when we compile it in a BEGIN time EVAL. FWIW this is certainly not the only BEGIN time EVAL issue left and I'm sure I didn't think about code objects in the EVALed code when I fixed it up to at least work somehow. So there may be some hidden and wrong assumptions about the "current block" |
|
Fwiw I got the augment in my module running by adding an ENTER phaser in the when block. That breaks something else tho. |
|
This bug got magically fixed quite some commits ago. |
|
I don't think the bug is really gone away. The reduced test case still behaves the same: |
JJ
changed the title
|
I thought eeb4f43f87 might have made a difference, but it doesn't, I get the exact same output. |
|
Now there's a new error: |
OUTPUT:
There parameter
$sis nowhere to be found. That includes the routines called in WWW.This used to work just fine. The last good commit is da2b758 2019.03.1 built on MoarVM version 2019.03. Interestingly this bug apeard before the last good commit a few times too.
The text was updated successfully, but these errors were encountered: