Hi all!
First post... After waiting about nine months for Nim in Action to finally be delivered to me, I got it 3 days ago. In the 3rd chapter, I should start to code. So I decided the first thing to do was obviously to install some Nim editor (I'm on Win10 x64). Now, after two whole evening, I haven't go a single one to work. I tried Aporia, but it seems to be built in x64, when calling "nimble install aporia", which according to the doc is the reason it doesn't "find the DLLs" even when they are in the path. I also tried the Visual Studio extension (which apparently, hasn't been updated for 3 years, and didn't compile) and the Notepad++ plugin (which seem to fail because it uses the name of an "official plugin"). So far no luck, even when I try to "build it myself". I wasn't expecting the "first steps" would be so hard. I guess the "VSCode" editor is the "main" one, since it's the first in the list, but since I already must have Visual Studio installed, it seemed to me like overkill to bloat my drive with VSCode as well just to get "syntax highlight".
So, I'd need some help getting either Aporia or the Notepad++ plugin (which also seems "current") to work, unless there is an "easier solution" (I don't use Emacs, but I can get by in vim, if all else fails).
I guess the "VSCode" editor is the "main" one, since it's the first in the list, but since I already must have Visual Studio installed, it seemed to me like overkill to bloat my drive with VSCode as well just to get "syntax highlight".
Huh? What makes you think you "must have Visual Studio installed?" You don't. Just install VS code.
Hi Dominik. You misread me; I "must" have "Visual Studio" installed, because of something that has nothing to do with Nim...
Now that I have your attention ... I have a question relating to your book, "Nim in Action" (I haven't finished it yet; I might have more questions later). I hope it's OK if I ask it here, and I also don't think it's important/general enough to ask as a separate forum post.
In section 5.6.1, "Choosing a name", you say:
"A package's name is very important." (No question about that)
"It needs to be as short as possible"
Why? Is that your personal preference, or is there some actual technical reason for this?
If I may present a "counter example", I could not get the Nim Notepad++ plugin to work, because the plugin name was too short, and therefore eventually overlapped an "official" plugin name, which then "won" over the (too short) non-official plugin. Or at least, that is my interpretation of what happened on my system.
I don't see how having a clear, comprehensible, unique package name (which is the opposite of "as short as possible") could possibly be a bad thing. If there is a technical reason, I think you should mention it explicitly, because it's not obvious, at least not to me.
"It needs to be as short as possible"
Why? Is that your personal preference, or is there some actual technical reason for this?
There is no technical reason, it's just easier for users to use your package if its name is short. Writing import mylongpackagethatisawesome everywhere would be a PITA.
On the one hand, long module names are annoying to keyboard.
On the other, module names must be unique within a module. If would be great if aliasing allowed collisions of the source, e.g.
import "me/foo" as foo1
import "you/foo" as foo2
I come from the Land of Java ... I guess my "pain threshold" for long names is higher. :D
I used to code in C++, when "The C++ Programming Language" was still in it's first edition. And I'm here because for my "at home" coding, I'd like something that doesn't force me to choose between:
and also, there's UE4 ...
Use Nim 32 bit version instead 64 bit version and use 32 bit C compiler toolchains.
Nimble package by its nature just a library and it depends on the library itself how to behave when it's compiled to different architecture.
As for editor, you can opt to VS code which easier to setup. You can use Vim too with this plugin, https://github.com/zah/nim.vim .
In both cases, you need to put nimsuggest, nimble, and nim executable in your path.
I come from the Land of Java ... I guess my "pain threshold" for long names is higher.
@monster, My problem is that I am porting code from other languages. I want to follow the directory structure of Python networkx. For example, I want something in a directory path like algorithms/shortest_paths/simple.nim. But then the module name is simple. So nobody else on Earth can use simple.nim as an exported filename. That is quite restrictive.
There is a nice as syntax (discussed in https://forum.nim-lang.org/t/3154#19926 ), but it does not release us from the requirement of module-name uniqueness. For example:
from bar/me/foo as fooa import a
from bar/you/foo as foob import b
a()
b()
$ cat bar/me/foo.nim
proc a*() =
echo "in a"
$ cat bar/you/foo.nim
proc b*() =
echo "in b"
bar/you/foo.nim(1, 2) Error: module names need to be unique per Nimble package; module clashes with bar/me/foo.nim