Can Nim interact with the hardware at a lower level than the C programming language?

Nevertheless, I find Nim's syntax a joy to work with. May you get a huge load of funding soon (if you are looking for it).

Can Nim interact with the hardware at a lower level than the C programming language?

It's a bit unclear, but yes, Zig bundles Clang and a lot of headers and stuff (like musl, etc) for easy cross-compilation. It's not really dependent on Zig itself (I mean that you can create a separate tool that'll do the same), and usually it's called "zig cc".

Can Nim interact with the hardware at a lower level than the C programming language?

Zip is not only a programming language, but also a c compiler and a cross compiler toolchain. You can (cross) compile your nim application with zig for a lot of targets. This is how i use Zig for the most part actually.

Can Nim interact with the hardware at a lower level than the C programming language?

So, essentially, Nim is the better replacement to C than Zig (IMO). It has a beautiful syntax; well done Nim team!

Can Nim interact with the hardware at a lower level than the C programming language?

Thanks I guess but it's a weird way of looking at things. Before Nim Pascal/Delphi could be used instead of C, there is also C++, Modula 2, Modula 3, Ada, Oberon. There never was a shortage of PLs that could do what C can do.

Can Nim interact with the hardware at a lower level than the C programming language?

Yes, `ptr UncheckedArray[T]` and `cast` tend to be used for this.

Can Nim interact with the hardware at a lower level than the C programming language?

Impressive; with an elegant syntax too. So, Nim can go as low as C, right? I mean, without using FFI.

Can Nim interact with the hardware at a lower level than the C programming language?

Or does it have to rely on FFI to use direct memory access and such using C?

Package-Rot as growth hindrance

maybe nimble should be extended to keep anonymous (and opt-in?) usage statistics?

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

With regards to treeform's suggestions; 1. I personally like the increased length to 88 chars 2. On the subject of blank lines, my impression, which may be mistaken, is that black changes the lines in between top-level functions/classes/methods but leaves blank lines within functions unchang

Package-Rot as growth hindrance

[OT] > I've seen some spammy use in the AUR with marking packages out-of-date mostly on the -git packages. That's not spammy, just user too lazy too read the wiki. Which I can kinda understand. The VCS package case is weird enough, that it should be made more obvious to the user, not only the p

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

Habemus binaries:

Nim v2: what would you change?

As I understand your proposal, `"\""` would not equal `'"'` since the latter would still be a character???

Operators.

Hello. Perfect explanation. Thank you very much. Best regards. Antonio F.S.

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

IIRC, semicolons can be necessary with the `using` construct. type Vec = tuple[x, y: float] using vec: Vec func `*`(vec; a: float): Vec = Vec(x: vec.x * a, y: vec.y * a) Run

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

A limit of 100 is fine too, IMO.

Operators.

`[:` it used for generics, like so `obj.myfunc[:int, char](1, 2, 3)`. The "dot parenthesis" `(. .)` are currently unused but exist for future extensions of Nim.

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

Is that the first node of nkStmtAsm node, reserved for pragmas, is deleted after semAsmOrEmit and essentially loses its structure, yes nodes can change, but the structure of nodes always remains, for example the structure of nkInfix will always be like this: nkInfix name

Operators.

Hello again. >From the list of tokens displayed in the Nim manual, these two I don't >understand: (. .) [: Any explanation and especially examples, please? Best regards. Antonio F.S.

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

For what is worth, I think the increased default max line length is fine, given that that is one of the knobs that nimpretty supports. In fact I'd argue that 88 is perhaps still a bit too low if you are going to break from the old-school 80 character default.

Package-Rot as growth hindrance

> I definitely think something like what the Arch user repositories does with > their "Flagged out of date" feature would be a better solution. AUR packages have a `PKGBUILD` or separate versioning which can become "out-of-date". The only valid "out-of-date" flag I think that would work for `ni

Package-Rot as growth hindrance

That's a big problem on `nimble`'s end if so... because if I understand in demoing just now that is the ONLY way that nimble can satisfy a version check. Meaning for example, I can't specify `requires "weave == 0.4.9"` because the only existing tags are `0.1.0`, `0.2.0`, `0.3.0` and `0.4.0`.

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

What's the rationale behind this style choice? import std/[parseopt, strutils, os, sequtils] Run Seems unnecessary wasteful with vertical space to me.

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

I don't get what you mean, I think you need to provide more context? I think an empty statement was removed? I think its very common for nodes to shift around and morph into other nodes when Nim goes through various passes from untyped to typed for example.

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

> > proc covers(entry: AttestationEntry; bits: CommitteeValidatorsBits): bool > = > ... > > > Run Today I learned arguments can be separated by semicolon instead of comma

Package-Rot as growth hindrance

## Collection of Ideas so far * Small packages don't rot necessarily - they can be like honey, so small packages need special treatment * a flagging "not working anymore" is needed, with message to author * parsing of the nimble files would make sense to get an tree of interdependence betw

Package-Rot as growth hindrance

So basically parsing all nimble files of all packages. This is a good idea.

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

> And the comments too. for 95%, nph looks good enough as far as I'm concerned at least, ie the "attach-to-node" strategy is really good and you quickly can adapt to it - the tricky bits are for example `proc f(p #[comment here]#: int)` and the like where it's hard to inspect in depth what a va

Package-Rot as growth hindrance

Flagging for out of date is a good idea.

Package-Rot as growth hindrance

That's actually not that hard, e.g. see

Nimforum custom theme

> This dark theme is awesome, by the way. Thanks!

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

> The nimpretty approach doesn't practically work for our codebase which has a > lot of creatively placed comments, ie it causes too many actual bugs and > reformattings the end result being that we can't use nimpretty at all - if we > could, we would have but trying to fix some of the bugs is w

Nimforum custom theme

> Is there a Stylus equivalent for WebKit based browsers? A quick search suggests [Cascadea](https://cascadea.app/) for Safari on MacOS. It looks like [Stylus might work](https://github.com/openstyles/stylus/issues/982) in Safari but unfortunately not supported by the team and you'd have to do

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

> And in the generic declarations This in particular is a problem - ie `[T, V: static int]` vs `[T; V: static int]` causes `T` to be an integer and a type respectively. I **think** it was template arguments that broken when I tried using `,` consistently on parameter lists.

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

> name suggestions thanks all! this is a hard one - it needs to be convenient to type on a qwerty keyboard, not too long and not taken - the last point invalidates many suggestions unfortunately (I did my homework with nimph years ago but .. ) .. nph isn't too bad after all maybe. > treeform

Package-Rot as growth hindrance

> "looked over by somebody" This one has fairly simple heuristic - a package is "recent" through transitivity, ie if it's used by another recent package.

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

> I think this is technically wrong, the only place where you can use both is > in parameter declaration lists and you can always use , here. nimpretty uses > what is used as the first occurence in the source code in order to decide but > it's not necessary as , is always valid. And in the gene

Package-Rot as growth hindrance

> Something that's more alarming to me is the lack of "versioned" packages, > only ~850 packages have a single version git tag associated with them. Iirc, Nimble has or had weird interactions between git tags and nimble versioning that forced updating tags to install the latest which at on point

Forum dark theme

Please contact the forum administrators or support team to request a dark theme as we don't have control over the forum's design.

Package-Rot as growth hindrance

Haha, the termstyle package was the module I had in mind as well. Just had a look and my oldest non-updated package [drawille-nim](https://github.com/PMunch/drawille-nim) and it still works just fine on Nim 2.0.0. I definitely think something like what the Arch user repositories does with thei

Nim raw syscalls

Additionally you can add the `{.discardable.}` pragma if you want using the return value or explicitly discarding it to not be mandatory.

Package-Rot as growth hindrance

If you want some kind of metric, look in to lifetime/cycle of issues and pulls, number of issues and pulls, all versus size of code base. Complexity of code base, number of maintainers, numbers of committers as weight factors. But what does it all mean in the end? There's software that gets upda

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

Personally, I systematically use `;` in parameter list as this is more readable than `,` when successive parameters have the same type. proc p(x, y: int, c: char) Run seems to me confusing compared to proc p(x, y: int; c: char) Run

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

> comments in particular are tricky and might get moved to slightly unexpected > places FWIW I found it so "tricky" that I abandoned the "render AST" idea altogether and went with "render tokens instead". I have never regretted this decision. However, `nimpretty` does get semantic feedback from