@Gregbalfourd I added a multithreaded test to [1] and improved the library a
bit.
[1]
[https://github.com/FedericoCeratto/nim-lmdb](https://github.com/FedericoCeratto/nim-lmdb)
Hi Peeps, I'm very pleased to being checking out this language that you've been
growing. The set up procedure is difficult to me. I have 0 unix experience and
know basics about cmd line. It gets loaded and then it just sits there. I do
run finish and thats all it does; I press on the nim crown
Thanks for the reply.
func someFunc(f: func(): bool {.nimcall, noSideEffect.}): bool =
f()
Run
This is the workaround I use (nimcall or closure) and it does the job, though a
bit repetitive.
I forgot to tell the compiler version I used: `0.19.4`.
This should be in a separate thread.
Seems like a bug
func someFunc(f: func(): bool {.nimcall, noSideEffect.}): bool =
f()
echo someFunc.type() # proc (f: proc (): bool{.noSideEffect.}):
bool{.noSideEffect, gcsafe, locks: 0.}
Run
There is nothing wrong with `len [0]` vs `len[0]`, it's quite intuitive and
even C has `x / *v` vs `x /* v`. Sometimes you have to learn a bit of syntax,
big deal.
Is it a linting tool one way to handle something like this, a tool that gives
warnings if a some some syntax is used that doesn't match some personal or
company coding preferences or standards?
