-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
myfuns[runtimeIndex]() gives FieldError when myfuns
is a CT array of closures
#14340
Comments
Same with
|
This change makes it possible to use `jexport` together with `jnimDexWrite` to emit .dex files. The `jnimDexWrite` proc builds a .nim file, which can then be compiled using package dali to generate a .dex file. Currently, the intermediate step of generating a .nim file is required, as Nim's compile-time has a lot of limitations. In this particular case, see e.g.: - nim-lang/Nim#14339 - nim-lang/Nim#14340
This change makes it possible to use `jexport` together with `jnimDexWrite` to emit .dex files. The `jnimDexWrite` proc builds a .nim file, which can then be compiled using package dali to generate a .dex file. Currently, the intermediate step of generating a .nim file is required, as Nim's compile-time has a lot of limitations. In this particular case, see e.g.: - nim-lang/Nim#14339 - nim-lang/Nim#14340
This change makes it possible to use `jexport` together with `jnimDexWrite` to emit .dex files. The `jnimDexWrite` proc builds a .nim file, which can then be compiled using package dali to generate a .dex file. Currently, the intermediate step of generating a .nim file is required, as Nim's compile-time has a lot of limitations. In this particular case, see e.g.: - nim-lang/Nim#14339 - nim-lang/Nim#14340
I "fixed" the crash but your dex code is better with |
@akavel here are some debugging tips for next time:
and some more advanced flags when --stacktrace isn't enough:
it's inside compiler code (as would've been apparent with a nim compiled in debug mode) anyway, after araq's fix, you should now get a cleaner stacktrace. Also, always try to minimize your issues, even if a bit more work for your (eg you have |
@timotheecour thanks; can I do it somehow quickly if I'm just using choosenim? or do I have to git clone nim, then find and follow the instructions to build it, then somehow inject to nimble or something? |
@Araq @timotheecour Also, after some thinking, I realized I'm honestly somewhat confused as to how in particular I could best understand this issue being closed now; if that's not too much to ask for, I'd be super grateful if you could try and help me better understand a few things! Please assume no ill will in those questions, they're 100% sincere; I fully understand you guys are busy, and I'd just like to try and be helpful in a way that's best use of your time, and mine as well! Therefore, in particular:
Thanks! |
I'm sorry, the reason this was closed was mostly an accident. That were two bugs here, one of which I fixed but that doesn't help you. :-) However, whether your code can work with the VM is unclear, the VM doesn't support |
@Araq thanks! :) As a side note, I'm happy to try and use workarounds for features not available in nimvm when possible, for example I specifically:
But when the compiler itself is breaking, it's waaaay over my head, so all I can do for now is try and report an issue, and hope one day it might get fixed... :) Will try to minimize it If I Find Time At Some Point™; for now, I find consolation for myself in that what I reported seems to be at least a deterministic reproducer ;) |
Uh oh, so I actually couldn't resist and tried to at least find the line of code which triggers this, and it seems to be a call to sha1's
With it, I'm getting the following results
Surprisingly to me, when I tried to extract just the problematic lines to a separate file (included in the new branch), I got a very different error:
That's all I could get to for now; maybe this helps you understand more about it already? Trying to reduce the code gradually while still reproducing the error would be more work than the "line bisect" I did for now, so again not sure when and if I'll have time for that. Cheers! |
@akavel thanks for not giving up! bugs should be fixed, not worked around (otherwise it'll just impact the next person). => I've reduced the problem here: #14368 note (for next time): reducing this was really a mechanical operation. All i did was add some debugging statement |
@timotheecour Um, but #14368 seems to print a different error message than what I reported here, no? so I'm now confused how #14368 is a reduction of this one? Also what copyMem are you referring to in the original code? In addition to that, with regards to the side comments, if this is about modifying stdlib or compiler, please kindly note that jumping into koch territory is definitely not trivial from a casual nim & choosenim user's persective. I know there are better reports and worse reports, but please also note this is a spectrum, and I believe reporting a poor reproducer is still better than not reporting any, so that's what I did... and also I must go with workarounds first for best effectiveness on both mine and Araq's side. I'm happy to also report simpler issues once the tougher ones are out of the way. |
it's the same as one you get in original post: following your OP instructions, and updating to devel >= 278b458 (I don't think you're using latest devel since
which is the same error and same root cause as in reduction I gave in #14368
the bug happens before
not judging whether it's easy/hard but it's really just:
I was just trying to give helpful tips so that you can make progress debugging on your end if you're the impatient kind (like I am and some other ppl as well) and would rather dig into a problem than wait for someone to fix it. The issue you've reported is real and thanks for reporting them (which will happen in time regardless). Fixing a bug is often a sequence of steps, and anyone (including reporter) is welcome to help along those steps:
there is experimental support for CT FFI but it's not default enabled (and currently doesn't support intrinsics,like
|
@timotheecour ❤️ Thanks for your patience. After writing my last reply, I started thinking about it more, what is the reason I'm whining and complaining so much, and I realized what would probably help me overcome it and ease the testing for me would be, I think, if I had a good simple guide how to build nim devel from source in a choosenim-based environment, in a way where I could be sure it won't break my usual working Nim setup. I will try to test the koch temp commands you provided for this function (when I have time). If they work for me, I will try and open a PR for including them as a guidance/hint in the Nim bug report template. |
I think we already have guides for that so you could link to it instead of creating such guide https://github.com/nim-lang/Nim/blob/devel/.github/ISSUE_TEMPLATE/bug_report.md could IMO emphasize more on need for generating Another thing that could help is if compiler messages start linking to relevant doc section, so that instead of
you'll get:
likewise with many more error messages. Good docs, like good code, should be DRY (only explained in a single place, and linked to where needed) |
Hello, I am writing a program and got the same error message. I can't give a condensed example, as I don't know what in about 33k lines of code causes it. Versions of Nim used: 1.0.6, 1.4.0, devel @61352d5a203e76e3334b21766bdbd4ebc71c300a Using the |
compile nim with (introduced in #13351, see PR for what this does) and show the stacktrace again |
Ok, here is the new stacktrace2.txt |
@akavel I've tried to reproduce the problem, and with Nim 1.2.x I can reproduce it, but with Nim 1.4.x and devel the reported error is not happening anymore. (There is an error happening at |
@BarrOff Yes, it is usually something that calls If you cannot share your code, I would recommend you to go to |
@narimiran from my side I agree, the error I'm getting is now different, so for my original case the issue is resolved; I guess I'm handing off to @BarrOff if they want to double down on this from some more info from their side (or if you want them to open a separate issue for their case). |
@narimiran Right now it is still a private repo, but I hope to publish it in the near future. Please be patient just a little bit. Just compiled Nim on Linux and FreeBSD with your suggested patch and can confirm that it now works! The error disappears and code creation works, on both plattforms. Nim version: devel@c9a10bb9e47c5227b32f49f5876e965cc2308541 |
@narimiran: the repo can now be found here. The error can be reproduced simply by calling As I pointed out above, your commit fixes it for me. |
use the PR instead for reference + discussion: #16168 EDIT: case in point, see #16375
|
@timotheecour as the PR is seems to be rejected and is currently closed, I have to continue here @narimiran @timotheecour Using the simple bracketing algorithm, I found commit 6152eb3 to cause the compilation error. Until the previous commit, compilation works, from this commit on, it doesn't. |
you mean next step to debug this: since according to https://gist.github.com/BarrOff/9ca157692d7a894749305c1911580538 it crashes here
we need line info in user code + more context at the place it crashes, can you try: of tyProc:
if typ.callConv == ccClosure and n.len > 1 and n[1].kind == nkNilLit: => of tyProc:
if typ.callConv == ccClosure and n.safeLen == 0:
echo ("BUG", p.config$n.info, isConst, p.prc.sym)
debug(n) # from astalgo
debug(typ)
if typ.callConv == ccClosure and n.len > 1 and n[1].kind == nkNilLit: (adapt as needed) EDIT: one obvious difference from the commit that introduces the regression 6152eb3 is this: before commit: after commit: Once again, debug(n) and debug(typ) as mentioned above should help figure out what's going on |
@timotheecour Adding your suggested change, I got an error message, trying to compile nim: The output can be found here EDIT: I just changed the closure from |
I've reduced your code: when true:
#[
Error: unhandled exception: 'sons' is not accessible using discriminant 'kind' of type 'TNode' [FieldDefect]
]#
proc opl3EnvelopeCalcSin0() = discard
type EnvelopeSinfunc = proc()
# const EnvelopeCalcSin0 = opl3EnvelopeCalcSin0 # ok
const EnvelopeCalcSin0: EnvelopeSinfunc = opl3EnvelopeCalcSin0 # bug
const envelopeSin = [EnvelopeCalcSin0]
var a = 0
envelopeSin[a]() that's what I meant by "please reduce" :-) => see PR #16386 |
myfuns
is a CT array of closures
When trying to run complex code at compilation time, I'm getting a weird error, with no stack trace, that I don't know how to further debug. Nimvm compiler bug?
Example
Current Output
No stacktrace, no idea where this comes from :( running
git grep sons
on my code doesn't seem to show up any occurences ofsons
:/Expected Output
A
q_comptime.dex
file should be silently created and written to.Possible Solution
Additional Information
Nim version:
The text was updated successfully, but these errors were encountered: