While modern C compilers can do some nice auto vectorization, there are many
cases where you have to do it by hand. For instance, fractal noise:
Here's what I do when I need SIMD or vectorization:
* Write ordinary Nim code that uses arrays.
* Look at the produced assembler code.
* Tweak the Nim code until the assembler looks efficient. (Ok, that's a lie,
usually I don't have to do that.)
Alternatively, read this and port it over
There is no solution but to patch posix.nim so that it knows the actual values
for the popular OSes out there.
I am learning some Nim, and have a hunch that the metaprogramming features of
Nim may allow for a user friendly SIMD library. The primary challenge with SIMD
is that various processors support different SIMD features. So to write code
that will run as fast as possible on every CPU, you have to
Thank you @jlp765, I know about the static, but asking about a different thing:
Is there a way in nim language to use values of S_IFREG and S_IFDIR in the 'of'
clause of the 'case-of' statement? (for example, like in the post above)
@Libman
Nim has a clear vision -- it's just that I fail to communicate it:
_Nim is a simplistic systems programming language with an AST based macro
system on top of that._
Its syntax is pleasant enough that it replaced all of my "scripting" needs too.
But that's not a lack of "vision",
Thanks a mil @LeuGim, for the detailed answer. This is super helpful. I will
play around with them more by keeping your points in my mind.
I disagree.
I would like to have more Nim programming videos - those are great to make
people discover Nim.
Personally, I don't really like too much sales pitch - I grew really tired of
Rust and their happy slogans (Hack without fear - zero cost abstractions) those
gets old really fast!
I
Pardon my satiric pessimism. Nim is my #1 favorite programming language, and I
very much hope that it succeeds. But, in answer to this thread's question about
the past 9 months, I think there's very little to celebrate. Growth exists, but
it's far slower than it should be. People are
> this language claims to be rather minimalistic
does it?
Another newbie q? sorry, this is the second thread I am starting in 2 days. I
am wondering which are the ideal scenarios to use **'ref' to an object** in the
type declaration. Is 'ref' should be always used or only when class inheritance
functionality is used. Are there some best practices
@Lando I think you misunderstood me. I like properties for the reasons you
mentioned (mainly: not giving a damn). I just don't like the fact they work
differently in the module the type is defined in.
As for whether properties are good: it depends. Memoized properties are often a
good
It seems to me that concepts' vtables make methods obsolete. These are two
models, inheritance and type classes, which are different answers to the same
problem. I can see no good reason to provide both in the same language if this
language claims to be rather minimalistic. Also, vtables give
> no-copy-by-default was very appealing, Rust's arr[lb..hb] provides a view
> while Nim's arr[lb.. reimplementing everything to work on views/slices) unless immediately
> followed by assignment
Last time I checked Python's implementation, Python's slices also do copy, but
it's not a problem
I'm currently using Nim at work as a replacement for some old scripts, mostly
for provisioning servers (as part of our Ansible deployment setup). The tools
in question preform tasks such as creating MySQL databases and the required
tables/relationships and importing initial data and downloading
@rayman22201 I did the mistake you did, too in the beginning. tuple and object
are both value types like a C struct, and there is no hidden vtable in an
`object` unless you inherit from `RootObj`. I think the documentation is
misleading here.
Pull requests that include an example in the doc comment are generally welcome.
> At least Nim would have to instantiate all methods that could be called at
> runtime.
I see. Calculating the minimal set of necessary method instances at compile
time looks hard-to-impossible to me though, at least with multiple-dispatch
methods.
> I think there were suggestions about
Thx for your answers guys.
@def: Does that mean that in order to make methods work with generics, Nim
would have to be able to instantiate methods for generic parameters after
dynamic dispatch (at runtime)?
But that's not how overloading in this case would work, as proposed by evacchi.
If the function performs a different action depending on whether the value is
nil or not, it might require totally different function to handle that case.
Otherwise, putting the logic to adquire this value in a
@Udiknedormi: I see how that would make sense. There is that ambiguity that
_a.host = 34_ can mean two completely different things inside the module:
* call the assignment operator
* call a procedure named _host=_
But Nim seems to consciously embrace ambiguity to accomplish separation of
> Use getTypeInst instead of getType. Both are in macros module.
Yes, that is exactly what I need.
I read the doc comment in macros module some monts ago:
proc getTypeInst(n: NimNode): NimNode {..}
#Like getType except it includes generic parameters for a specific instance
Arrays are not special, just having them of length of 100 you won't want to
initialize them by a literal, the same for seqs.
type GlyphArray* = array[3, int]
type
TextBuffer* = tuple
position: tuple[ x : float, y : float ]
cursor : tuple[
> Am I misunderstanding the purpose of your ArrayObj type? It seems to me your
> implementation of `macro indexArray*(x: ArrayObj{call}, y: ArrayIndex):
> untyped` is little inflexible. After all, not every function returning an
> ArrayObj will be just doing element-wise calculations (or should
@Udiknedormin
+1 for finding weird edge cases! lol
Ideally I would like to be able to initialize an array in the constructor
syntax directly, like any other type. It is strange that arrays are different.
Even sequence has the special _@[]_ syntax for this.
but it is such a minor thing that I
Use getTypeInst instead of getType. Both are in macros module.
thanks wiffel, that helps
v1.0 **_should_** remain elusive - that's how it works in Open Source.
As for replacing C ...
I don't know.
I've been programming in C++ for years, and recently grew so fed up with it,
that I took up C.
Modern C is really, really neat, and not something that needs to be replaced
IMO.
C++,
Have a look at
[static](https://nim-lang.org/docs/manual.html#statements-and-expressions-static-statement-expression)
static:
# compile time stuff here
Unluckily, I can't replace Python with Nim as I need some science libraries not
yet available in Nim (maybe I'll port them another day...). While my friend
uses Nim for similar things, I chose Rust for my thesis and I had some good
reasons:
* when I started it, Nim lacked advanced generics
Is there a way to make nim compiler to evaluate constants from C-header files
at compile time?
For example, symbols S_IFREG and S_IFDIR (from posix.nim <\- sys/stat.h) used
in following code snippet:
case x:
of S_IFREG: echo "file"
of S_IFDIR: echo "dir"
else:
> I've been away from Nim for about 9 months. Can anyone give me a quick update
> ...
We keep [accelerating toward
C](https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why),
but v1.0 [remains
As far as I know, the most advanced Nim development environment so far is
[VSCode](https://en.wikipedia.org/wiki/Visual_Studio_Code) \+
[this](https://github.com/pragmagic/vscode-nim)
[extension](https://marketplace.visualstudio.com/items?itemName=kosz78.nim).
Someone please correct me if I'm
33 matches
Mail list logo
