I have wasted 2 days now hunting down a problem on FreeBSD and in particular to get some acceptable way to debug my Nim code in the first place.
Result so far: about the only way to debug Nim code known to me is the bloated perverse Visual Studio Code monstrosity - which isn't available on FreeBSD anyway.
Simply using gdb - which isn't exactly user friendly - doesn't work either. All I see (gdb -tui) is "system.nim", setting a breakpoint on a function doesn't work at all and setting one on my main functions line number is accepted by gdb but doesn't work.
All I get is "warning: could not trace the inferior process", then "warning: ptrace: operation not permitted", and finally "During startup program exited with code 127".
So, what I'm to take away? Am I back to write dummy C functions to check whether Nim passes the parameters the way it should? Plus a whole load of debugEchos? And no, I can not develop on Linux (where VSC works) and debug on FreeBSD; for one my code is FreeBSD specific plus gdb seems to not be properly supporting Nim on FreeBSD.
I'm seriously pissed off. I have commented, discussed, begged and preached for weeks how important it is to have a usable basis working reliably only to get dressed down. To add insult to injury I'm stuck now and bleeding time due to exactly the damn problems I complained about. VSC not available on a - Nim supported! - platform and gdb not working (with Nim code). Thanks so much.
Bloody give us a reliable reasonable minimum before adding more gadgets, please, pretty please!
Here's my thinking:
My favourite would be textadept. It's open source, relatively small, and works both as a gtk based graphical as well as a cli (terminal) editor. Available on Windows, Linux, Mac, BSD - plus there is some Nim support module available that works (but could profit from some love). Should lend itself very well to becoming a Nim "basic IDE" (or luxurious editor). GDB interface should be quite feasible. My second choice would be Geany.
Risking to not make friends, but it seems important: One of Ada's major advantages (practically speaking) is GNAT, it's IDE (which is available pretty much everywhere) and has a working debugger. Hell, I'd be better off (in this specific case) even with C due to a choice of well supported editors and/incl. debuggers.
This is not a luxury issue or one of personal taste. It's a thrive or starve issue that makes Nim a practically usable everyday language - or not. It MUST be possible to have a reasonable and reasonably small editor with Nim support as well as good gdb support on all supported platforms!
Well if you please go into more details, we will be able to help you. As you know GDB works without any editor and we even produced a video about how to use GDB with Nim via its --debugger:native switch. We are also actively working on improving Nim's stack/line traces and GDB will benefit from it too. Emacs also works with Nim, but as I said, GDB doesn't even require any editor whatsoever. Yes, I know it can be annoying to use, but it's not impossible.
So once again, please be more specific and we'll be able to help you.
First, thanks for your constructive and friendly reaction.
I have a module, let's call it F.nim with, say, proc "fsysctl" that calls into FreeBSDs sysctl. Module F is imported into and called by, let's call it prog.nim. Within prog.nim I have a "tmain" proc that sets up some variables and then calls fsysctl from F.
(After compiling with --lineDir:on and --debugger:native ... and gdb prog (in the source directory)) when trying b tmain" gdb says "function tmain not defined in prog.nim". Hmm, OK, let's be modest and just break at the first line within tmain, line 5 (something like ``var foo: int = 42) which seems to work ... but then when running ("r" in gdb) I get "warning: could not trace the inferior process", then "warning: ptrace: operation not permitted", and finally "During startup program exited with code 127".
Re "editor" and "gdb is ugly":
You are absolutely right, gdb of course can be used without a nice GUI. And in fact I wouldn't have complained if it worked - but it doesn't, at least not on FreeBSD (using gcc6-aux which is just gcc6 plus Ada support). BTW, using clang throws up an error within Nim using my (quite tough and tight) flags (something about "gcc ranges").
But we should also keep in mind that very many developers aren't used to "naked" gdb but rather to a nice GUI. And it more often than not really makes debugging a lot more efficient.
As for the editor: I - and certainly not just me - want, need, must have a "basic tool set" that works on all supported systems and the editor, a critical component of that tool set, should be relatively small and have modest dependencies. VSC (and some other bloat monsters) just don't cut it and are not available everywhere. Geany and textadept both are reasonably small with modest dependencies (that are available!) and are flexible (or programmable) enough to build Nim support (for textadept some support already exists).
I'm absolutely convinced that if we could say - and show - that Nim has a reasonable tool set - incl. a not too shabby and widely acceptable editor - and at least some kind of basic GUI debugging that will be a very major factor in attracting more Nim users.
b tmain<tab>? Nim does name mangling. You can also use proc tmain() {.exportc: "tmain".} to disable the name mangling. The other error messages are puzzling for me too, no offense, but it seems like an installation problem or at least like problems that are not Nim specific.
We use Emacs with GDB here https://www.youtube.com/watch?v=DmYOPkI_LzU
As far as I know Emacs runs on FreeBSD.
I'm absolutely convinced that if we could say - and show - that Nim has a reasonable tool set - incl. a not too shabby and widely acceptable editor - and at least some kind of basic GUI debugging that will be a very major factor in attracting more Nim users.
Yes and I agree but you are asking for this "reasonable tool set" on FreeBSD. And that is simply not a popular OS, regardless of its merits.
As for the editor: I - and certainly not just me - want, need, must have a "basic tool set" that works on all supported systems and the editor, a critical component of that tool set, should be relatively small and have modest dependencies.
May I suggest neovim with:
This should be basic enough and works on most OS :), not to mention that neovim is rather lightweight. The only downside IMO would be that not everyone is familiar (n)vim.
I know vim - and I also know that many strongly dislike it (and others like it). For the kind of basic tool set for everybody that I have in mind any editor with a "religious" follower or a "religious" hater group seems to be a bad choice.
That also means that it's not about "the best editor" and, in fact, not even about a particularly good editor, but about one that a) is acceptable (at least as a good compromise) and preferably even liked by many, b) is available on all Nim supported desktop and server platforms, c) has modest dependencies and demands (disk space, memory, processor), d) is (relatively) easily quite configurable and versatile and allows for the (relatively) easy creation of an interface to the Nim compiler back end.
I think Geany demonstrates well what I mean. Some even love it, most can easily work with it and have no bad feelings re. Geany and only very few hate it. That IMO important requirement is not met by both vim and Emacs (although many value them highly). That said I personally would prefer Textadept because it meets all criteria plus also works in the terminal.
As I just happened to come across it, Geany is a (more or less dead) zombie, PRs are not getting merged. https://forum.nim-lang.org/t/303 ;-)
More seriously though, we had a survey about these things, "give us an editor for every platform" wasn't mentioned. But you can use Geany with Nim, see the linked thread.
b) is available on all Nim supported desktop and server platforms
That would include VxWorks and Haiku, not to mention the 14+ different CPU architectures we (try to) support.
Geany is a (more or less dead) zombie, PRs are not getting merged.
Ts, their last release was in january. It seems though that the Nim support project did indeed end up somewhere between the taiga and a black hole.
For your other point: OK, OK, I see it and you are right. When I said "all" I didn't think of Haiku or VxWorks. So I'll limit my criterion to "Win, Mac, Linux, BSD", i.e. all Nim supported systems with more than 1% (0.5%? 0.1%?) of "market" share.
As for your "we had a survey" argument, pardon me, and I know I won't get love for this, but: Nim isn't the result of a survey - and that's GREAT. Nim is the result of one knowledgeable professional who stubbornly followed his understanding of how a great language should be. The fact, that you also listen to Nim's users is an added plus. YOU are the reason that Nim isn't just yet another Java, js, ML, a-better-C.
Nim is the result of "A. Rumpf thinks a good language must be like ...".
I don't say that to sugar you. I say it because (I expect lightning to strike me for heresy) democracy is a quite worthless mechanism in the world of technology and engineering. That's why I don't care the least about "the top 10 languages/editors/IDEs/OSs, ...". And please kindly try to follow my argument, that's particularly true for Nim which tries to do things the right way, an element of which is not "Windows and be done" or "Linux and be done".
I still think Geany is a good example for what I mean. Actually I myself only rarely use it and I do not consider it to be a great editor or IDE - but that's not what this is about. This is about another set of criteria. One might describe it as "what's a reasonable minimum to work efficiently, preferably with a GUI?" - plus - enough flexibility to allow for supporting Nim.
VSC may be a great editor for many. But VSC is also the antithesis of what we really need as a basis.
@moerm > Thanks for the hint! Now with the <Tab> "trick" setting a breakpoint at a proc does work
if you need to script this, (gdb) rbreak main_ or (lldb) br s -r main_ for regex breakpoint (ie that works with mangled names)