Hello `nph`, an opinionated source code formatter for Nim

> Nim's grammar unfortunately allows the use of either , or ; in some places > with a subtly different AST being produced which sometimes has a semantic > impact - nph takes a conservative approach here and uses ; to avoid ambiguity. I think this is technically wrong, the only place where you

How does 'nim secret' actually work?

nlvm recently got REPL support without the restrictions, as far as I know, haven't tried it myself yet.

Hello `nph`, an opinionated source code formatter for Nim

Awesome work, Just got it working some thoughts... I do think the uncompromising code formatter is a good idea, but I do have a wish list of things it would have done differently. * * * I really wish it adhered to the standard 80-character limit instead of creating a new 88-character rule,

How does 'nim secret' actually work?

You might also be interested in INim, which works by compiling the input on-the-fly with tcc, a small and non-optimizing, but very fast, C compiler.

Hello `nph`, an opinionated source code formatter for Nim

Awesome! I recently filled out the Nim survey, and one of the top things I found missing from the Nim tooling ecosystem is a good formatter (like black for python). Really looking forward to using this. If anyone has set this up in VS Code, let us know how. Would we need to update saem's

Nim v2: what would you change?

I don't think you follow since they are not exactly the same ("a" != 'a')

Package-Rot as growth hindrance

This makes sense. But for these kind of packages a "looked over by somebody"\- label, or anything like this, would make sense, since a newbie don't know what is stable. I guess stable packages with few changes are on average smaller packages, I currently build a analyzer for the package repo

Package-Rot as growth hindrance

I agree with @PMunch that commit age isn't the best indicator of a "rotten" package. His [termstyle](https://github.com/pmunch/termstyle) came to mind when I read your post. This package hasn't been updated in 4 years what score does it receive? Also, as I pointed out in the other thread that

Package-Rot as growth hindrance

It seems that having a simple „Verified to work with Nim: 1.4.8, 1.6.16, and 2.0.0” in README and updating it every once in a while may be very helpful at a near-zero cost.

Hello `nph`, an opinionated source code formatter for Nim

> parameters separated by ; > If you're interested in feedback,

Hello `nph`, an opinionated source code formatter for Nim

> Would auto variable renaming yes, it needs access to type and other semantic information in order to rename the right variable - the relevant style rule is that usages should match the declaration but different declarations can be .. different.

Hello `nph`, an opinionated source code formatter for Nim

> installation via nimble It works if you clone and run nimble locally like the instructions say

Package-Rot as growth hindrance

There are a lot of good ideas and initiative here. But there is one thing to keep in mind, not all packages need updates. I maintain quite a few packages, many of which I'm sure hasn't been updated this year. Some which might not have been updated for multiple years. But they still work just as

How does 'nim secret' actually work?

I was interested in knowing how does the Nim REPL actually work under the hood, and what are its limitations since I don't find any resource online.

How does 'nim secret' actually work?

It's running nimvm, so it have all nimvm limitations.

Is normal that nim ast stmt changes its ast structure in the compiler ?

semAsm get's the asm stategment like this: nkAsmStmt nkEmpty nnkTripleStrLit("some asm") Run after semAsmOrEmit it becomes and then wrong version used by C backend nkAsmStmt nnkTripleStrLit("some asm") Run node after this

Hello `nph`, an opinionated source code formatter for Nim

I'd suggest `nimfmt`, but it's a bit boring and maybe too official-sounding. `nimfo` might get my vote :-P Regarding the opinionated-ness, I see some occasional formatting in the compiler example that comes across as weird: parameters separated by `;`, short import statements like `import

Hello `nph`, an opinionated source code formatter for Nim

Very cool! Would auto variable renaming like what [nimfmt](https://github.com/FedericoCeratto/nimfmt) has be considered semantic refactoring? Think a feature like that would stop people complaining about style insensitivity and also allow quick fixing of `StyleCheck` hints

Hello `nph`, an opinionated source code formatter for Nim

This is cool! I don’t think nph is a bad name, but since you asked for suggestions and you took inspiration from black, what about “yellow” (as in nim’s crown color). Another option related to prettier could be “nimmier”.

Hello `nph`, an opinionated source code formatter for Nim

> now, I'm taking naming suggestions IMHO "nimphomaniac" or "nimpho" or "nimfo" sounds good and are easy to remember as "nim formatter."

Hello `nph`, an opinionated source code formatter for Nim

First up: Fire! I intend to basically immediately use that on the package I'm currently working on since I'm particularly curious how it will deal with macros etc. Particularly long lines because of long variables names or the like are stuff I tend to be guilty of. Second up: For name

Hello `nph`, an opinionated source code formatter for Nim

Here's something that was idling in my code attic for quite a while and finally got pushed past the "is it useful yet" line this weekend: a source code formatter for Nim! Apart from a working package manager, I can't really think of a tool that I've missed more than this on a daily basis from

Package-Rot as growth hindrance

Yes, you are right. What about the score idea beneath?

Package-Rot as growth hindrance

## Update: Some bad calculated numbers I have used the github api and some crude scripts to get an idea of the real number of packages. For now no metrics like how old is the project, how many commits at all, how many stars are applied, but there might be a lot potential for better sorting.

Package-Rot as growth hindrance

Discoverability is a foundation of good package ecosystem, which is why I liked this recent [announcement](https://forum.nim-lang.org/t/10633) of this site:

Package-Rot as growth hindrance

## Package-Rot as growth hindrance Hello! I am new to the community, but I am already in love with the language. One Problem that I have encountered is that there is "package-rot". Since nim is a small(adoption wise) language, lots of projects are by a single author and at some point this

Nim raw syscalls

its not builtin you need to do importc proc syscall(arg: cint): cint {.importc, header: "", varargs.} var SYS_write {.importc, header: "".}: cint syscall(SYS_write, 1, "hello world\n".cstring, 12) Run

Nim raw syscalls

Hey! C programmer trying to use Nim a bit more. in C, when I want to perform a raw syscall I can just execute #include #include int main(void) { syscall(SYS_write, 1, "hello, world!\n", 14); return 0; } Run I compiled it on my fedora, this is