Hi Nim people,
I was using Nim for some Project Euler exercises. When I tried to compile with nim c -r -d:debug test.nim, it got stuck after printing
Hint: used config file '/etc/nim/nim.cfg' [Conf]
Hint: used config file '/etc/nim/config.nims' [Conf]
......
The processes nim and nimsuggest then completely pegged 2 of my CPU cores. I then had to kill the two processes in the terminal. I'm on Manjaro Linux.
I found the minimal code (test.nim) to cause this bug to be
import sequtils
const n = 2000000
const list = toSeq(0..n)
func f(): int =
var i = 0
const p = list[i]
p
It seems like n has to be large. All variables have to be const except for i. If these two criteria are not met I get the correct error "cannot evaluate at compile time: list".
it's not an oom, and it's not an infinite loop, it's just adding n constants is accidentally quadratic, issue link
do you need p to be const?
import sequtils
const n = 2000000
const list = toSeq(0..n)
func f(): int =
var i = 0
list[i]
works for meHi @pietroppeter - I agree that it's quite a silly example. But shouldn't the compiler catch this or preferably crash? It seems wrong that it just pegs two om my CPU cores until i manually kill the processes.
Also this example compiles and runs without any problems:
import sequtils
const n = 2000000
const list = toSeq(0..n)
echo list[0]
(Uses 700MB of memory for compile) Curiously this program:
import sequtils
const n = 2000000
const list = toSeq(0..n)
var i = 0
echo list[i]
uses 2GB og memory to compile!
I'm kind of curios why the amount of memory explodes in this manner, and why my initial example might use way more ram?
Hi @shirleyquirk
Thanks for clarifying. This makes sense to me.
I stumbled upon this bug while doing some Project Euler exercises, and fixed the problem by using let instead of const. I posted in on here as I was curious. :)