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

nimly Uses Too Many Loops In Compile-time #11

Open
loloicci opened this issue Mar 21, 2019 · 14 comments
Open

nimly Uses Too Many Loops In Compile-time #11

loloicci opened this issue Mar 21, 2019 · 14 comments
Labels

Comments

@loloicci
Copy link
Owner

No description provided.

@loloicci loloicci added the bug label Mar 21, 2019
@loloicci
Copy link
Owner Author

loloicci commented Mar 21, 2019

You can avoid this error to use the new compiler option maxLoopIterationsVM:N (maybe later than Nim v1.0.6) (See also https://nim-lang.org/docs/nimc.html).

Before v1.0.6, you can use niml with compiler build with vmdef patched as follows

diff --git a/compiler/vmdef.nim b/compiler/vmdef.nim
index 7a2bc1607..91706ae5d 100644
--- a/compiler/vmdef.nim
+++ b/compiler/vmdef.nim
@@ -17,7 +17,7 @@ const
   byteExcess* = 128 # we use excess-K for immediates
   wordExcess* = 32768
 
-  MaxLoopIterations* = 3_000_000 # max iterations of all loops
+  MaxLoopIterations* = high(int) #3_000_000 # max iterations of all loops

@loloicci loloicci changed the title niml uses too many stack niml Uses Too Many Times of Loop In Compile-time Mar 22, 2019
@loloicci loloicci changed the title niml Uses Too Many Times of Loop In Compile-time nimly Uses Too Many Loops In Compile-time Apr 11, 2019
@loloicci
Copy link
Owner Author

improve some #25

@loloicci
Copy link
Owner Author

It maybe solved when nim becomes version 1.0.0.

@samdmarshall
Copy link

Hi, I'm encountering this issue using nim 1.0.6.

@loloicci
Copy link
Owner Author

@samdmarshall thanks for your reporting.
Could you share the code with the bug if you can?

@loloicci loloicci reopened this Mar 20, 2020
@samdmarshall
Copy link

oh, sorry, yeah - of course. i'll try to isolate into a stand-alone sample. do you want me posting here in this issue or as a new one?

@loloicci
Copy link
Owner Author

Thanks!
Either is fine.
Link to #11 if you post as a new issue.

@bung87
Copy link

bung87 commented Jun 2, 2020

https://github.com/bung87/rust2nim I face this when compile entry file.

it's the first time I try to use a parser generator, I may doing something wrong, but this stop me get ing further information.

@bung87
Copy link

bung87 commented Jun 3, 2020

lexgen.nim line:378

if toSeq(sTran.keys) == toSeq(tran.keys): I modify to this , reduce the iterations, it seems under the compare calls the argument changes dynamically.
there's proc defaultAndOther called by lexgen.nim(567, 33) convertToLexData throw too many iterations error .

@loloicci
Copy link
Owner Author

loloicci commented Jun 4, 2020

@bung87 Thank you for your analysis!

if toSeq(sTran.keys) == toSeq(tran.keys): I modify to this , reduce the iterations, it seems under the compare calls the argument changes dynamically.

If you will create a new PR, I will merge this change after checking this has no unexpected effects.

You can avoid this error to use the new compiler option maxLoopIterationsVM:N (maybe later than Nim v1.0.6) (See also https://nim-lang.org/docs/nimc.html).

@bung87
Copy link

bung87 commented Jun 4, 2020

I will create a PR later, merge if you think that's correct since I has no much knowledge in this domain. write a wrong grammar also will cause this?

I checked after modified test will not pass.

@loloicci
Copy link
Owner Author

loloicci commented Jun 4, 2020

Sorry, @bung87.
Your suggestion does not work expectedly.

toSeq(sTran.keys) == toSeq(tran.keys)

This returns always true and causes error in nimble test.
(nim c -r tests/test_lexgen.nim provides more information)

I did some refactoring in lexgen.nim in the #40.
Check this if you are interested in what this part does.

@loloicci
Copy link
Owner Author

loloicci commented Jun 4, 2020

@bung87

write a wrong grammar also will cause this?

No (as far as I know).
This error is caused when the calculation needed to generate the lexer is too much.
Without bug in the implementation, this generation does not cause infinite loops.

@bung87
Copy link

bung87 commented Jun 4, 2020

Thanks for your explaintion! then I feel fine with maxLoopIterationsVM, from what I understand the lexer parser generate during compile time, that probably exceed the limit even code is fine, that sounds reasonable.

I just aware you removed the bug label, guess I can just try :P

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

3 participants