Which tools do you use to code in Nim?

I often include it. And of course Futhark has become more and more used in my projects as I've finally gotten away from the tedium of C wrapping. Once my follow-up to superlog is released though I expect I'll use that pretty much everywhere as wellhttps://pikashow.fyi/get-apk/";>pikashow](https:

What's stopping Nim from going mainstream? (And how to fix it?)

As far as I understand, the problem is not IDE, the problem is that it's very hard to create Nim "language server" (type checks, autocomplete etc.), and there's probably no way to make it work well until the Incremental Compilation is done. As soon as you have "language server", the IDE part wi

NIR

I meant - use it for things like VRCode autocomplete, you don't need the executable, only type check, so the Nim -> NIR part of the compiler should be enough...

What's stopping Nim from going mainstream? (And how to fix it?)

Disagree with the IDE comment. Most people use the editor/IDE of their choice. I'm not going to switch editor/IDE just for a new-to-me language. Any killer feature one editor/IDE has is usually replicated to other editor/IDEs in a matter of months. I would enjoy seeing a debugger because I work

NIR

In order of preference: 1. View types 2. Not-nil checking and static array index bounds checking 3. IC

NIR

IC is x10 more important than all other listed features combined. P.S. Maybe also simplifying the compiler, to attract more contributers to the core, and make progress faster. If I understand correctly the Nim -> NIR transpiler is the main part, and could be a standalone. Without C-compiler, C

What's stopping Nim from going mainstream? (And how to fix it?)

When reading the various posts comparing languages (including Nim) the conclusion many times says something like "Nim is everything you want in a language but ...". If it is highly regarded what's stopping it from gaining that critical mass required to be considered mainstream? (A small digress

NIR

The point of a repl with native interop is to embed it into the app. That’s a couple of order magnitude faster iteration times than IC can dream to be :-)

Which smartptrs to use?

Thanks.

NIR

Hard agree on view types. Getting deterministic resource management as robust as possible would be great, I'm actually more jazzed about that than IC. And I recommend avoiding REPLs or any kind of runtime interactivity in Nim. IME with Haskell and Scala: REPL + types = PAIN!

NIR

IC -> view types -> anything else :)

NIR

I concur, IC and view types are the more important features. Better tooling and safely allowing a commonly desired operation seems like the best for Nim developers. A REPL although beneficial can mostly just be a scratch pad in `/tmp` or similar. So I'd vote for Views and IC first, in whichever

NIR

> [ ] NIR-to-AST mapping ("back to AST for backwards compat") so that we can > use this technology to finally give us IC. As someone working on a larger Nim codebase, this! Especially if it can be used to improve Nimsuggest. I'm willing to pitch in on helping with Nimsuggest too if possible. It

NIR

FYI C(++) doesnt mean a new C++ backend. It means a new C and C++ backend. AFAIK It wouldnt improve much the situation of wrapping C++ and it is already quite good (specially for those in `devel` :P) I vote for it as a second option mostly because it shows the way of how to do backends from now

NIR

View types, view types, view types.

Cosmo3 multi-os fat binaries with threads

I know, but projects like `greenbean` just further encourage the mindshare that async doesn't have to be the only way to do hi perf networking. Especially if normal OS threads can be made just as cheap as a stack of Futures without a special runtime like Go requires. Also this setup might be ch

NIR

I would definitely vote for the REPL followed by NIR-to-AST mapping to finally get IC. I don't know if the new backed would be needed in order to make the NIR-to-AST useful though?

NIR

* [x] Not-nil checking and static array index bounds checking. * [x] Better borrow checker to refine the "view types" implementation. All other options looks like mental gymnastics more: * REPL - interesting, but no real usage at the moment * New C(++) backend. Are there many users of o

NIR

All the proposed features are very valuable. I agree with @juancarlospaco that this seems like a good time for a cleanup, but, since that wasn't on your list, I'll say incremental compilation is the most important thing to me. I hadn't even been expecting a REPL for Nim in the near term, and I

NIR

I'd personally find a REPL most fun, but I think adding features that benefit larger projects first like IC might be worth it more. And also of course I'm always in favour of something that makes an existing codebase more stable and easier to maintain, so juancarlos' suggestion (assuming it is a

NIR

I believe they are all incredible features and especially looking forwards `view-types` but I have to vote for tooling first and foremost, so IC it is. `inim` and `nim secret` serve me well already, but I can see the merits of an official REPL that can finally interop with C /C++ so that's my se

NIR

+1 for IC -> REPL -> then everything else. Mostly because I don't know what the hell this other stuff is ;)

NIR

* [x] NIR-to-AST mapping ("back to AST for backwards compat") so that we can use this technology to finally give us IC. Would be my vote.

NIR

Incremental compilation first, REPL second. The rest is all fine but would be much lower down my list.

NIR

All are awesome features. If I had to pick one it will be `REPL` but closely followed by `New C(++) backend` as I feel the latter will incentivize the creation of new backends, especially if the compiler doesnt need to be forked.

Nim Slack Community

Does Slack still has a 10k message limit? Would be very annoying to take a lot of time to answer something, and then the answer disappears after 3 weeks because of too much activity. Also in general what kind of audience do you want that would use Slack that doe snot use IRC, Matrix, Discord or

NIR

I would try to use the big refactor opportunity to clean out and remove/deprecate/improve experimental and legacy stuff like: `--experimental:dotOperators|callOperator|parallel|destructor|notnil|dynamicBindSym|forLoopMacros|caseStmtMacros|codeReordering|compiletimeFFI|vmopsDanger|strictFuncs|view

NIR

I vote for AST mapping if it could bring us IC sooner. I'm happy about the general status of current Nim. IC is the last piece to the real productivity Nim yet to show.

NIR

Upcoming major versions of Nim will be based on NIR, an intermediate format that is lower level than Nim's AST: * NIR has its own type system that maps cleanly to a C++-like language but remains easy to traverse and interpret. The type system is basically C's without C's array decay design bu

https://www.facebook.com/KetoVexACVGummiesUS/

Official Website:- Keto Vex ACV Gummies:- Although many individuals make assumptions about the effectiveness of weight-loss medications, there is little scientific evidence to back up their usage. Facebook:-

With what parameters does echo call fwrite? Trying to implement fwrite in Nim.

Thank you, that looks much cleaner.

Which smartptrs to use?

The ones `threading` offers.

With what parameters does echo call fwrite? Trying to implement fwrite in Nim.

Nim has an operator for non-inclusive iteration `..<`. That, some proper handling of newlines, and a little refactor and your code can look like this: type VGABuffer* = ptr array[0..2000, uint16] FILE = object var stdout* {.exportc.} : ptr FILE const video_me

What is Guardian Blood Balance Australia?

Official Website@:- Guardian Blood Balance Australia:- were emerging and advise the effectiveness of the method, its substances, and the long-time period fitness blessings that it gives. Official Website@:-

Which smartptrs to use?

There are two different implementations of `smartptrs` \- one in the `fusion` package and another in the `threading` package. Which one is supported going forward? My guess is `threading`, since it is mentioned in Mastering Nim 2ed. But I want to be sure.

With what parameters does echo call fwrite? Trying to implement fwrite in Nim.

Thank you for all your replies! I did increase both by one! I have no debugging facilities yet because I couldn't get gdb to run with QEMU so I figured I'd print a random character in a loop `size` times, then `nbitems` times and count them. So I did `for i in 0..size`... when I should have bee

With what parameters does echo call fwrite? Trying to implement fwrite in Nim.

The implementation seems to view the C string as a whole, and the terminator is not counted, so the size is 12 and the number of items is 1 (1 is hard-coded) for "Hello world!". I don't know where 13 and 2 came from. Maybe you accidentally increased both arguments by one?

With what parameters does echo call fwrite? Trying to implement fwrite in Nim.

Educated guess: You use `addr s` where you should have used `addr s[0]` where `s` is `string` or a sequence.

Cosmo3 multi-os fat binaries with threads

Already we have production ready servers who skip `async`... ;-)

With what parameters does echo call fwrite? Trying to implement fwrite in Nim.

Going through the Nim sources with `grep -Hnr fwrite **/*.nim` you can quickly discover where Nim calls it. For echo it's in `lib/system.nim`, more specifically [here](https://github.com/nim-lang/Nim/blob/devel/lib/system.nim#L2885). As you can see it should call it the way you expect it to be

With what parameters does echo call fwrite? Trying to implement fwrite in Nim.

Well, I think that size is the number of bytes. Each character is stored on a char (1 byte) and "Hello world!" is indeed made of 13 characters in C. The size of the cstring is indeed 13 bytes. Now, nitems is probably the number of arguments with `echo` counting as one (similar as argc for comma