I am trying to use nim-gdb on MacOS. When I run
nimble c --debugger:native tests/browsertester
nim-gdb --args tests/browsertester -d:actionDelayMs=0
Reading symbols from tests/browsertester...
Reading symbols from /Users/emre/code/nimforum/tests/browsertester.dSYM/Contents/Resources/DWARF/browsertester...
/opt/local/lib/nim/tools/nim-gdb.py:3: Error in sourced command file:
Undefined command: "import".
Nim-gdb works fine for me.
Since nim-gdb is a Python script, it depends also on your Python version. Could you give us the output of python -v ? You compile with nimble and not nim directly. What is nimble -v outputting ? Does this raise an error for a simple nim script ? By the way, why tests/browsertester does not have the .nim extension ?
You may look at Tomohiro's blog for some information about the gdb, if you are not already familiar with it: https://internet-of-tomohiro.netlify.app/nim/gdb.en.html
It is also strongly possible that you want to execute python3 instead of python. I believe you forgot the / in your shebang: #!/usr/bin/python3 usually on Linux, but on MacOS ¯_(ツ)_/¯
I am pretty sure shebangs for python are not required anymore like in the old time 👴
python is 3.10.7 nimble -v outputs
nimble v0.13.1 compiled at 2022-10-05 08:06:35
git hash: couldn't determine git hash
I saw that blog post. It says you need to source nim-gdb.py on Windows but it does not say anthing about MacOS. In any case, sourcing does not work.
I don't know why the nim extension is missing; it was that way in the source, but I tried it both ways and it makes no difference.
I added the shebang because I suspected that gdb is treating nim-gdb.py as a regular shell script since it does not recognize the import command.
I suspected that gdb is treating nim-gdb.py as a regular shell script
I think so. The error message seems to came from bash. Python would recognize import.
Maybe the shebang was incorrect? Also use #!/usr/bin/env python3 instead of python, as it can refer to python2.
Not on my system; python points to 3.10.
I forgot to mention that I manually copied nim-gdp.by from https://github.com/nim-lang/Nim/blob/devel/tools/nim-gdb.py
According to that blog post, running nim-gdb foo is equivalent to running gdb -eval-command "source {path-to-nim}\tools\nim-gdb.py" test -- in Windows. In MacOS, I can not run successfully run that source command.
The source command is shell-dependent, not OS dependent. By default, MacOS uses zsh, which does have the source command. If you use /bin/sh, it might point to /bin/dash instead, which does not have the source command. The issue with MacOS though, is that it is not recommended to use source on ~/.bashrc, since the shells are login shells, and will use ~/.bash_profile See: https://stackoverflow.com/questions/21211281/source-command-on-mac
Have you tried to add a slash in the shebang ? Do you really need the devel nim-gdb version ? Doesn't it work with nim 1.6.8 nim-gdb.py file ? Have you manually copied the file after trying with a normal installation ?
Isn't the point of source to run a shell script in the current shell? I have never seen a python script run with source before. I created this simple script as a test:
#!/usr/bin/env python
echo Hello
print("World")
bash-3.2$ . ~/Desktop/test.py
Hello
bash: /Users/emre/Desktop/test.py: line 3: syntax error near unexpected token `"World"'
bash: /Users/emre/Desktop/test.py: line 3: `print("World")'
According to that blog post, running nim-gdb foo is equivalent to running gdb -eval-command "source {path-to-nim}toolsnim-gdb.py" test -- in Windows.
Then try:
gdb -eval-command "python {path-to-nim}/tools/nim-gdb.py" test
Then I get:
Python scripting is not supported in this copy of GDB.
I think I need to build gdb with python support? This is more complicated that it ought to be.
Where? Can you print the line as you would like to run it?
Sorry, I just looked up the shebang correct usage on SO: https://stackoverflow.com/questions/6908143/should-i-put-shebang-in-python-scripts-and-what-form-should-it-take I believed you had to point to the exact location of the Python binary, which you should actually not do. That is why I said that you probably forgot a slash /, I was expecting something like: #! /usr/bin/env/python
I guess you managed to pinpoint the problem !
I believe the only advantage of using source over ./ is that the sourced file does not need to be executable. I have also never seen a source used for a python script.