I am using winim <https://github.com/khchen/winim>. But I don't know whether the problem roots from winim <https://github.com/khchen/winim> or not
the following code can launch Excel, display "false" then close Excel as expected
import os
import winim/com
comScript:
var fn = r"e:\test.xlsx"
var excel = CreateObject("Excel.Application")
excel.Visible = True
echo excel == nil # will display "false"
os.sleep(1000)
excel.Quit()
COM_FullRelease()
but for the following one
import os
import winim/com
comScript:
var fn = r"e:\test.xlsx"
var excel = CreateObject("Excel.Application")
excel.Visible = True
echo excel == nil
os.sleep(1000)
var wbIn = excel.workbooks.open(fn, readonly=true)
#~ var activeSheetIn = excel.ActiveSheet
#~ echo activeSheetIn.UsedRange.Rows.Count
excel.Quit()
COM_FullRelease()
$ nim c -d:release -r /r/b.nim
Hint: used config file 'E:\msys64\home\USER\_nim\nim\config\nim.cfg' [Conf]
Hint: used config file 'E:\msys64\home\USER\_nim\nim\config\config.nims' [Conf]
..........................................................SIGSEGV: Illegal storage access. (Attempt to read from nil?)
why? I am totally confused.
Thank you in advance
nim c -d:release -r /r/b.nim
There are rumours that one can compile Nim programs without -d:release option for debugging purpose. Well, may not help much if the source code is too wrong.
I have not used debugger ever. So I searched and found https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html
but is there any debugger with GUI to do step in, step out, and set breakpoint just like VisualStudio does?
My comment was not related to using a debugger, but for the fact that some people permanently use
nim c -d:release -r /r/b.nim
As long as a program is not already carefully tested the standard command should be
nim c myfile.nim
That command would have made it obvious even for fools like me that the problem is a compiler crash. And as Araq said, compiler crashes should be reported at github issue tracker. When possible you should try to provide a small code example which generates the problem without import of winim, as that makes reproducing the issue easier.
You may tell us your compiler version -- makes not much sense that devs try to reproduce the issue with latest devil compiler which may not have this bug.
Or maybe test some other compiler options like --gc:arc -- that may makes it easier for devs to guess the problem.
Please report compiler bugs on github, thanks!
To a lot of people it's likely not obvious that this is a compiler bug, they may not even realise that it's the compiler that crashed and not their program (since they are compiling with -r).
Can we make this more explicit in the compiler and show some instructions on how to submit a bug report?