Mirror of forum.nim-lang.org

2642 :: Strange problems with --os:standalone --gc:stack

• colinc (orginal) [2016-11-30T10:11:49+01:00] view original

  I came across https://github.com/nim-lang/Nim/issues/4437, which said that the "--gc:none" setting is about to be replaced by "--gc:stack", so I tried it, and found various problems, such as

  • assert is not defined
  • "+=" is not defined

  var
    str: string
  for ch in str:
    # whatever
  Run

  gives the error message: Error: ambiguous call; both system.items(a: cstring) and system.items(a: openarray[T]) match for: (string)

  But... when I tried to make a small test file to post here, it compiled without errors!

  So my question is: is the "--gc:stack" implementation still just work-in-progress, or should I put in some more work to reproduce these symptoms and raise proper issues on Github?

  PS: This problem is present on the latest nim version from Github, downloaded and compiled yesterday. My host system is an up-to-date x86_64 with Arch Linux, trying to cross-compile for --cpu:arm

---

• Araq (orginal) [2016-11-30T10:52:10+01:00] view original

  --gc:stack is fine and I am not aware of code that doesn't compile with it. --os:standalone implies that lots of stuff is unavailable, perhaps including "assert", I don't remember. Why "+=" is among this list ... who knows. ;-) Github reports are fine, but as I said, I blame the standalone switch, not the gc:stack.

---

• colinc (orginal) [2016-11-30T11:28:42+01:00] view original

  Oops, I should have said that my project (a few thousand lines of nim code) already compiles without errors using --os:standalone and --gc:none.

  It was only after changing to --gc:stack that I had to spend half an hour or so hacking my code around to compile successfully again.

  Okay, if I manage to reproduce any of these in a simple test program, I will raise them on Github.

  Thanks for the rapid response!

---

• andrea (orginal) [2016-11-30T11:36:53+01:00] view original

  Is --gc:stack documented anywhere? I am not sure how it is supposed to work exactly. I remember there were memory regions introduced somewhere, but I am not sure whether they are working or not

---

• colinc (orginal) [2016-12-03T12:25:23+01:00] view original

  PROBLEM SOLVED! The garbage collector is innocent.

  When using --os:standalone, you must provide a file panicoverride.nim. I wanted to prettify my output_message, so I imported another module (which contained the asserts etc.) in to panicoverride.

  It seems that the panicoverride code is processed somewhere in the middle of compiling stdlib/system, so it's no surprise that parts of the system module itself have not been declared before that point.

---