As always I suggest some kind of Cookbook examples. One way to do this would be
a blog series on how you approached Nim for the tasks you need. I still think
that something like this has the biggest impact. Especially if there is a
comments section in the Blog or platform used to present code +
> I hope this does not sound rude.
Not at all. I appreciate the pointers. The distinction between function and
iterator is important.
I have to find ways to help researchers "migrate" to Nim. It's a daunting
language if you look at the full manual.
> Should we also have "Ben".cstring?
You don't need to do it, because "Nim string values will be converted to C
strings automatically" for `{.varargs.}`.
Thank you **@moigagoo** for your feedback!
> 1\. In 8.1.3 Type compatibility, you point out that we can't use int and
> string and should use cint and cstring instead. But instead of explaining the
> differences, you state that cstring is actually similar to string (to the
> point where string
AFAIK the "c" in `cstring`, `cint` etc. means "compatible" so it makes some
sense.
I like Nim because:
* I can use it to unify, typify and abstract code between different target
languages.
* At the same time Nim is a full native code systems programming language.
* NimScript lets me write mundane tasks which would otherwise written in
another (scripting) language.
*
_wulfklaue:_ Predominance of negative opinions over positive ones is common,
not only in this case, and for a simple reason: when people are content with
something, they have nothing to say against, and they mostly are silent, and
when they annoyed or uncomfortable with something, then they
@Stefan_Salewski
> The %d should refer to a cint. Should we have to provide 30.cint for the
> argument?
Should we also have `"Ben".cstring`?
* While bootstrapping is surely a demanding test, a NIM beginner like me may
be statisfied to get hello.nim compiled and executing.
* I have serious doubts concerning concentration on 3 compilers when in
embedded environment the compiler is likely to be produced by a company, one
may never
> About the {.importc.}, {.importcpp.}, cstring thing, they should really be
> called {.importnp.}, {.importnoo.}, nstring, etc, where n means "native", np
> means "native procedural style", noo means "native object-oriented style". Or
> even better, {.import.}, {.importoo.}, and nstring
Just a little update:
The module is doing well. @Araq and me even found and fixed quite some compiler
and nimsuggest problems as result of me "working" on it. I also learned some
stuff about interfacing Javascript and creating a typed interface to an
originally non (really) typed API. This
When your CPU is idle. Or: When you build from `devel`.
"compiler family" is a perfectly fine term.
Pelles C used to be supported, try `cc=pcc`:
# Pelles C Compiler
compiler pcc:
# Pelles C
result = (
name: "pcc",
objExt: "obj",
optSpeed: " -Ox ",
optSize: " -Os ",
compilerExe:
After some playing around with --listCmd I found out, that the generated
compiler call is something like
| ...cc.exe -c -IC:Nimlib -o ..nimnimcachehello.o ..nimnimcachehello.c
Apparently the "-o" option is not understood by the Pelles C compiler. I would
prefer to have it configurable in the
You're missing that RST supports `.. include:: moredocs.rst`. So we can keep
the doc comments slim and yet can add many more examples for every proc in the
stdlib. :)
Partial casing is simply the next logical step, IMHO. As our editors grow
smarter and smarter they should allow us to present the code in the way we're
most comfortable with. This means the freedom to render `fooBar` as `foo_bar`
instead. What's necessary to accomplish this goal? `fooBar` has
> But instead of explaining
>From Araq's manual we know
proc printf(format: cstring): cint {.importc, varargs, header: "".}
var n: cint
n = printf("My name is %s and I am %d years old!\n", "Ben", 30)
echo n
This works fine for me, but I still have to
cjxgm: Your the first person who i have ever seen to give a real world example
as to why Partial casing can be useful. Seen so many topics in reddit etc where
people express frustrated by the free casing/merger but nobody ever provides a
example as to why it can be useful. I only see the
About the `{.importc.}`, `{.importcpp.}`, `cstring` thing, they should really
be called `{.importnp.}`, `{.importnoo.}`, `nstring`, etc, where `n` means
"native", `np` means "native procedural style", `noo` means "native
object-oriented style". Or even better, `{.import.}`, `{.importoo.}`, and
Said it at the end of that topic, we need to look more towards a WIKI example.
Code: Basic functionality + Link Website: Basic functionality + expanded
information + examples + searchable/link-able by google etc
**Website Documentation Wiki**
[Basic information produced automatically from the
A little disclaimer: I dont think "compiler family" is the official term for
what cc option stands for. It is more of my own understanding. Maybe @Araq will
correct me.
Normally common options like optimization level are emitted by nim
automatically (given that you tell nim proper compiler family). Other options
you can provide with passC and passL options or pragmas right in the source
code. Maybe if you provide a better example of what you want your compiler
I just finished the new chapter and wanted to share some feedback.
1\. In 8.1.3 Type compatibility, you point out that we can't use int and string
and should use cint and cstring instead. But instead of explaining the
differences, you state that cstring is actually similar to string (to the
What I liked so far:
* * *
* **Express the intention of "base" instead of "override".**
We have `override` keyword in C++ and `@Override` annotation in Java, to
express our intention of "overriding the base function instead of creating a
new base function/overloading/overwriting". That's
@yglukhov, maybe you can add that info to FAQ, last entry
[http://nim-lang.org/question.html](http://forum.nim-lang.org///nim-lang.org/question.html)
First you have to select compiler family (vcc, gcc, clang, etc.). Then provide
executable paths. Then the options. E.g.
Emscripten (clang family):
nim c --cc:clang --clang.exe=emcc --clang.linkerexe=emcc myFile.nim
MXE cross-compiler (gcc family):
nim c
Especially for using NIM for embedded development I find the selection of
supported compilers somewhat slim. Even for my offline Windows-box I have
serious difficulties to get a C compiler working. (The installers of all
compilers I donwloaded fail without internet connection). The nearly
Nim language bootstrap, when to do?
There was quite a bit of good discussion [in this forum
thread](http://forum.nim-lang.org///forum.nim-lang.org/t/2364) on the perceived
limitations of the Nim's documentation, and possible improvements (I don't
think it reached concesus on a clear way forward).
My question is this:
For me, I was looking for
* a python-like syntax (fast-to-write/easy-to-read coding)
* c-like speed
* GC to handle memory allocation/de-allocation
30 matches
Mail list logo
