Minor change? Nim supports ~8 Posix-like OSes on ~5 different CPU
architectures. I wrote a tool "detect.nim" to extract these values at build
time (similar to what autoconf does) but it's not clear how to incorporate it
into Nim's build system.
Thanks Andreas. Would you consider such a minor change in stdlib as desirable?
I'm pretty sure you are correct. At the very least, VSCode is quite easy to set
up for Nim, and works well.
The only thing I can't get working well is the debugging. I've managed to set
it up so that I can make breakpoints for Nim programs within VSCode, but I
can't find a way to look at any va
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:
[https://github.com/jackmott/FastNoise-SIMD/blob/master/FastNoise/FastNoise3d.cpp#L25](https://github.com/jackmott/FastNoise-SIMD/blob/master/FastNoise/
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 w
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", that's
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 al
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 experimenti
> this language claims to be rather minimalistic
does it?
* yes, to make inheritance easier (vars of different types (ancestors,
descendants) are of the same size, size of a pointer)
* no copying when passing - good for large objects, or when transmitted or
used as arguments often
* you can use arrays/seqs of different-sized (disregarding inherita
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 which
@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 usecase:
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 mo
> 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 bec
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 removi
At least Nim would have to instantiate all methods that could be called at
runtime. I think there were suggestions about removing methods from the
language, but I'm not aware what the result was. Personally I'm ok with storing
function pointers in objects instead of using methods.
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 diffe
@Lando: That works because by explicitly creating a var b: ViewportConsole and
then calling b.draw(2) you instantiate the method draw with T = int. I would
say methods and generics just don't work together in Nim right now.
@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[ r
> 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 a
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
35 matches
Mail list logo