Congratulations to Araq and the team for this epic achievement.
Posting in this thread for posterity's sake. ;-)
> I am a long time Smalltalker.
Smalltalk environments are actually the closest thing to Emacs. Imagine Pharo,
but running on Lisp instead of Smalltalk and defaulting to a tiled WM: that's
Emacs in a nutshell. If that sounds enticing to you, go for it.
> If I were to learn Vim first, am I
> Are you using the lsp plugin?
Nah, I'm going raw with just the
[nim.kak](https://github.com/mawww/kakoune/blob/master/rc/filetype/nim.kak)
file. The default "dirty" autocompletion of kakoune is good enough that you
don't really need intelligent completion.
As for whether you should learn
> In Vim I have to press Esc to come out of Insert mode then Shift-; to get :
> then I have to enter w and finally press Enter then to carry on editing
> text I have to press I again is that right Vim users? WTF!
Ehm, no. You could just use the default shortcut: `ZQ`
Or, if you want to
Just replying because that logo had me rotfl for about a minute.
Anyway, what SolitudeSF said: it's good to have a new project, but you should
use the default nim package manager, nimble.
Download nimble, if you haven't already, run the command `nimble init`, follow
the instructions and copy
> Not a huge issue but it breaks a common work flow that many developers bring
> from other languages and I have no clue how to solve it.
[Sounds like you need this](https://nim-lang.org/docs/nimgrep.html)
But I understand where you come from. All I can say is that, as a guy who uses
Linux +
`static: const block`
`proc ... {.compileTime.}: const proc`
I strongly disagree about these two. What's wrong with the `static` keyword? It
comes from C and that's what has always been used to signal things that should
be either included into the binary itself or be executed at compile time.
This is actually a very well written critique. Usually we get things like
"MOMMY! T-THAT GUY'S LANGUAGE IS NOT CASE SENSITIVE! M-MAKE HIM STOP!!!"
However, as Araq said, there are a few things which are incorrect. It's not
actually your fault: in fact, it's actually a documentation problem. But
Looking at this line
[(1)](https://github.com/cdunn2001/compile-times/blob/91c41d81a1ccb46406bf64eb9f923ee6eacdd679/driver.py#L22),
which I assume to be the actual command that runs the Nim compiler, it seems
that you're not using [tcc](https://en.wikipedia.org/wiki/Tiny_C_Compiler),
which
Haven't you considered macros? You could have something like this:
import
my_awesome_DSL_macros
func_declare:
test1(arg: DATA): DATA
func_create:
test2(arg: int): string = do_something(arg)
Run
The `func_declare:` and `func_create:` are
> You're entirely missing my point. I find that refusing to compile this code
> is one of Nim's greatest strengths, exactly because it helps in preventing
> variable name clashes.
Huh, I misread your post. I thought you were complaining about Nim not being
able to compile the code.
> Such a mixture of styles would immediately trigger an error in Nim, as Result
> and result are the same variable.
No. No, it wouldn't. Nim is neither case sensitive nor case insensitive, but
rather it goes for [Partial Case
Use this:
[https://narimiran.github.io/nim-basics](https://narimiran.github.io/nim-basics)/
It's free and it already covers most of Nim (except for metaprogramming and
generics, but if you're interested in game development (judging by your
previous posts) you won't be needing those).
Nim in
Works for me too.
Just tested it on Void Linux x64, with Nim 0.18.1 (recompiled a few hours ago
with choosenim).
> bitsets - why are these even in the language and not a library?
Because they're **SUPER USEFUL** in game development, and from what I can tell
lots of people use Nim for game development.
You need resistances in you RPG?
type
Element* = enum
eFire, eWater, eEarth,
There isn't direct support for Android yet, but since Nim compiles to C, you
could use the Android NDK. [See this thread](https://forum.nim-lang.org/t/3575).
As tewtzel59 said, Nim usually compiles to C (and I guess that's what most
people who program in Nim use). Even if modules were to be added to C, it
wouldn't happen before
2022[[1](http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2086.htm)], which is
when the new standard will probably be
Hmm, I thought the compiler would be smart enough to have a range type default
to its type.low value.
Although, even adding a
c.g = 'a'
immediately below the declaration doesn't remove the warning.
It seems that the only way to avoid this is by fusing declaration and
Yo guyz, I'm on Nim devel (nim -v says 0.18.1).
This snippet of code gives me the ProveInit warning.
type
Glyph = range['a'..'z']
type
Cell = tuple
g: Glyph
fg, bg: int
var c: Cell
Specifically, the last line gives me the warning.
Yeah, I suspected as much. In fact, I was compiling the project from the
command line with the nim executable. I'll have to see if compiling from an IDE
actually changes things.
Yeah, sorry if I've been more of a lurker, I'm spending all of my time on the
game.
I had in mind to introduce myself to the community after I ship the game, maybe
write a post-mortem and release the source code. I should be able to do so in
March.
As of now I can say that Nim has proven to
Nevermind, I managed to have it work with a trick: I moved the entire project
folder in the root of the C:/ volume. That way, all the filenames now are
automatically shorter. It compiled just fine and it linked too. The game runs
perfectly now.
Araq, thanks for the quick reply.
I tried your workaraound, but it didn't work. Specifically, nim doesn't seem to
recognise the jsonscript command. But from having a look into the json file, it
seems like the faulty line is the last one, which goes something like this:
"linkcmd":
Yo guys, new guy here.
I'm a game dev who just finished his game in nim (well, wrote 90% of the engine
in C first and then I rewrote it in nim a half a year ago). Since I primarily
use Linux for devving, I only tested an early version of the game on windows,
and it compiled just fine.
The
24 matches
Mail list logo
