Re: meta programming a nice SIMD library
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/FastNoise3d.cpp#L25) I'm betting with Nim it is possible to write the code such that you don't have to compile a separate DLL for each architecture, with a nice pubic api.
Re: meta programming a nice SIMD library
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 to Nim (not trivial but not impossible either): [http://www.codersnotes.com/notes/maths-lib-2016](http://www.codersnotes.com/notes/maths-lib-2016)/
Re: Compile Time Evaluation of Constants From C-Header Files
There is no solution but to patch posix.nim so that it knows the actual values for the popular OSes out there.
meta programming a nice SIMD library
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 write many versions of the same function, then detect CPU features at run time and use the appropriate one. I would like to approximate the APIs available in Boost.SIM or .NET, both of which allow you to write the code for your algorithm once, and at runtime the appropriate thing happens. With C# the way this works is if you have an array of say, 32 bit floats, you can access Vector and that will have a property Count, which is figure out when the code is Jitted, tell you how wide the SIMD lane is for that type, on that cpu. So you can then write your algorithm appropriately by looping over your array Vector.Count at a time and then do whatever SIMD operations you want inside the loop. I know in Nim we don't have the benefit of a JIT but boost.simd is able to do something similar with C++ templates. I'm not entirely sure what the best way to approach this is in Nim, so was just looking for some high level guidance/ideas.
Re: Compile Time Evaluation of Constants From C-Header Files
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)
Re: Been away for 9 months. What changed? Need some help to get back on track.
@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 because the split between systems and application and scripting programming languages is a historical accident, ymmv. Note that the split between (pure) FP, imperative, OO and logic programming makes much more sense and indeed Nim doesn't even try to be a functional or logic programming language! Or much of an OO language for that matter. And about the "zillion unfocussed ideas", that's quite biased. Facts are: * Almost all of its features can be found in other languages too. * New features arrive slowly (heck, isn't that what you just complained about?) and more effort is spent on bugfixing and QA than on anything else. * Features I would remove again have little significance: For example, I know for a fact that the "tag tracking" is useless, it has not found a single bug in any Nim project out there. Ok, let's remove it already. Well, not so fast, the general effect system is also about exception tracking (useful) and `gcsafe`'ty (essential for Nim's thread local GCs!). * Many features are not Nim features, but stdlib features but it's hard for newcomers to understand that and even if they do, they complain anyway: * "How come slices do copy? These need to be a builtin language feature!" * "What do you mean 'an interface is just a tuple of closures'?" * "Why are the error messages so bad?" It's because `.async` is not a compiler/language feature, it's a macro! In order to turn it into a fruitful discussion: What feature should we **remove** from Nim?
Re:
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.
Re: Been away for 9 months. What changed? Need some help to get back on track.
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 also don't believe that a language exist to better another language. If you like the performance of C, the expressiveness of Python and the macro-ness of Lisp, then Nim is perfect! We need more videos on YouTube on Nim, so that people can discover it. Other than that: it sells itself. There is no rush, in my opinion, for Nim to achieve world domination (or need?)
Re: Been away for 9 months. What changed? Need some help to get back on track.
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 experimenting with Nim and doing cool things, [dom's book finally hit paper](https://www.amazon.com/Nim-Action-Dominik-Picheta/dp/1617293431), etc - but something is clearly missing. Nim has many virtues, but it also needs a lot of work to catch up to other languages. A new programming language is like a business: the first million is always the hardest. People need a clear reason to invest their efforts into Nim rather than something else, especially when Nim's competitors are so much bigger. A bigger community means more libraries and tooling, more answers when you $searchEngine a problem, more job / freelancing opportunities, etc. Unless you have Rich Uncle Google (or Apple, Mozilla, etc) to boost you right from the start, breaking through and achieving growth is very hard - but other languages have done it. I think Nim's greatest competitors are Dlang and Crystal - two grass-roots languages that surpassed Nim in popularity. I think the greatest reason for this is vision, clarity of purpose - they had a specific audience that helped lift them off the ground. In these past months DMD also [went after](http://forum.dlang.org/thread/oc8acc$1ei9$1...@digitalmars.com) Nim's permissive license freedom crown, and it has an estimated 872 (79%) [dub packages](http://code.dlang.org/api/packages/dump) that are [copyfree](http://copyfree.org/standard/licenses) (nimble is at 448 or 88% copyfree). The question of "[What is the Nim programming language good for?](https://www.quora.com/unanswered/What-is-the-Nim-programming-language-good-for)" does not (yet) have a clear answer. D and Crystal are clear, even in their names: to be a better modernized C++ or a more solid Ruby. Nim is a mix of many cool ideas: some more practical and some more academic than others; some offer a better C++, some a better in-browser JS target, or Python, or Ada, etc. No one group can have any confidence in what direction Nim will continue to evolve, and how much faith they should put in it making significant progress. [Nim's roadmap](https://github.com/nim-lang/Nim/wiki/Roadmap) hasn't been updated in over a year... With a new business, you write a [business plan](https://en.wikipedia.org/wiki/Business_plan) and you knock on a lot of doors (banks, etc) asking for investments, persuading people that in a few years you'll have something great. But you cannot be great at everything all at once: some things will clearly and decisively need to be put on the back-burner. A good business plan doesn't contain a zillion unfocused ideas, but a few ideas that are focused and complementary. I think Nim needs precisely that: a VISION of why, if it's not the best programming language for a specific target audience yet, in a few years it will be, and how it will get there.
Re: Bug with generic methods?
> this language claims to be rather minimalistic does it?
" ref object of " - when to use
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 have to be followed. Can you please advise.
Re: Question regarding the setter method/proc
@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: after the first access it actually is just a simple read (although one could argue that as the very first call is expensive, it should not mimic simple access). Also, properties can be an alias --- in one of my projects I used some generic N-spaces but aliased a few first elements of any N-dimentional array by x, y, z etc. As for solution: why not use the same one as with assignments? system.`host=`(s, 34) sounds weird but hey, it IS weird to directly access a field when a setter for this field is defined!
Re: Bug with generic methods?
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 more elasticity as the same type can implement many vertical concepts/protocols.
Re: What are you writing using nim? :)
> 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 because people believe they don't copy and beliefs tend to win over facts. > Rust supports submodules and has better visibility rules If you say so. I think submodules are a strange idea and most languages (Python included) do fine without. > no easy moving in Nim while moving is default argument passing method in Rust > (Nim's is by-ref for ref types and by-val for other types) Moving is actually easy enough in Nim but zero-copy slices cannot be moved in any language since it's pretty much a logical impossibility. Probably not a real problem but it feels a bit weird that the two features of Rust you wish Nim had do not work together. More importantly, which libraries would you need?
Re: What are you writing using nim? :)
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 a set of applications from our SVN server, zipping them up (using the zipfiles module) and then deploying them onto the servers. We've also written some other small utilities in Nim that would have been written in Python or other languages in the past to do tasks such as monitoring data coming in from a serial port and logging that data with timestamps per packet.
Re: Defining an array inside a tuple
@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.
Re: GetType() for object type macro parameter
Pull requests that include an example in the doc comment are generally welcome.
Re: Bug with generic methods?
> 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 removing methods from the language, but > I'm not aware what the result was. AFAIK, araq favors making methods single-dispatch (only the first parameter determines the method instance called at runtime). Should make fixing this easier.
Re: Bug with generic 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)?
Re: optional int parameters for a proc
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 different function saves you an import and bloated code. I'd rather write a second function than import options, some(5) everytime.
Re: Question regarding the setter method/proc
@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 concerns: I can write _a.host_ in another module and not give a damn about whether this accesses a field or calls a proc which returns the value of a field and I like that. I don't want to know what encapsulation model the module I use has, I just want to use it. Much better than Java's getter/setter scheme. Also having to use a tweaked field name inside the module would feel bad to me. Maybe a big fat ambiguity warning instead of an error would do.
Re: GetType() for object type macro parameter
> 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
But it was not really obvious for me...
Re: Defining an array inside a tuple
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[ row : int, col : int ] glyphPositions : GlyphArray linePositions : seq[tuple[ start: int, stop: int]] text: string var my_text : TextBuffer = (position: (25.0, 25.0), cursor: (0,0), glyphPositions: [3,5,7].GlyphArray, linePositions: @[(0,0)], text:"") echo my_text.repr
Re: A talk on HPC
> 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 it?)...
You are absolutely correct. The current definition of `indexArray` in the
repository is incomplete. You can find an improved one at
> [https://github.com/jcosborn/qex/blob/devel/src/new/fieldProxy.nim#L100](https://github.com/jcosborn/qex/blob/devel/src/new/fieldProxy.nim#L100)
Your suggestion of using a macro to annotate procs and modify a global compile
time list of element-wise calculations is a good option, too. Perhaps that is a
nice option for users to define their own element-wise operations. I will
consider this. (J's rank system is in the back of my head, but I will not go
down that path anytime soon.)
The complexity of `shift` goes up easily with MPI and vectorization. In QEX, we
have something similar, which is probably the most complicated piece in the
code base.
Re: Defining an array inside a tuple
@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 am not bothered by it too much.
I would make a github issue if the people or the core devs think it is worth
it? ¯\\_(ツ)_/¯
I was avoiding _object_ because I wanted to avoid things like extra magic
pointers; if I can just avoid the using _of_ to get the same effect then that's
fine with me!
Good point about the cost of default initialization. In this case that is the
exact behavior that I want, but it is definitely something to keep in mind. I
will remember {.noinit.} for the future.
Re: GetType() for object type macro parameter
Use getTypeInst instead of getType. Both are in macros module.
Re: SIMD question
thanks wiffel, that helps
Re: Been away for 9 months. What changed? Need some help to get back on track.
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++, on the other hand (and Java, Ruby and C#), yes: they could use a replacement. I've tried Rust and Go, and they did not click with me, at all. Go has some weird limitations, that makes sense (I guess) for what use it is intended for, and Rust ... no, I don't think I want to subject myself to a passive aggressive compiler like that :p My use case is primarily performance critical game programming, mind you. Not server (Go) or system (Rust) software. My first serious programming efforts were in Delphi (Object Pascal), and I have had dreams of doing serious stuff in Lisp, so Nim is extremely attractive! Not as a C replacement, but as an enhancement; a step up, so to speak.
Re: Compile Time Evaluation of Constants From C-Header Files
Have a look at [static](https://nim-lang.org/docs/manual.html#statements-and-expressions-static-statement-expression) static: # compile time stuff here
Re: What are you writing using nim? :)
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 it has now, Rust had traits long before * Rust's traits are everywhere in the standard library, Nim's concepts are not, its generics are more towards duck-typed * no-copy-by-default was very appealing, Rust's arr[lb..hb] provides a view while Nim's arr[lb..
Compile Time Evaluation of Constants From C-Header Files
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:echo "other" are resulting in error "cannot evaluate at compile time: S_IFREG" because these symbols declared as 'var' in posix.nim, when they are constants actually. What would be a nice workaround for this?
Re: Been away for 9 months. What changed? Need some help to get back on track.
> 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 elusive](https://en.wikipedia.org/wiki/Time_dilation)...
Re: Editor profiles fo Nim
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 wrong. It would be nice to have a features table comparing what various editors / IDEs can do for Nim...
