Is this a good idea?

> Don't use -d:danger nor --panics:on and you'll be fine. This doesn't make for good library code though where someone else controls the conditions under which your code runs - also, the manual explicitly that catching `Defect` is UB - can't have it both ways (even if the current compiler versi

Is this a good idea?

Raising a Defect is undefined behavior - it's an exception type that cannot be caught reliably so how your program behaves will differ depending on compiler flags, platform and/or other things.

`nph` opinionated formatter v0.6

calls - the change is easiest to see in the [PR that introduced it](https://github.com/arnetheduck/nph/pull/75): # pre initSrcGen( g, if conf == nil: newPartialConfigRef() else: conf , ) #post initSrcGen

Alternative to powmod in Nim

> Because it's so so slow, even naively converting multiplication in a series > of modular additions is much faster: dunno about this one - after fixing the insanely slow recursion, changing the implementation to a simple natural mul+divrem 100x:ed the performance - this is the textbook impleme

Why is the implicit `result` so widely used?

FWIW, we've had great success eliminating pointless bugs by avoiding `result` in most code: \- both in nested and early-return code. Even if you insist on using `result`, you can avoid many of its pitfalls and t

StableSeq

Indeed, this looks mostly like an [unrolled linked list](https://en.wikipedia.org/wiki/Unrolled_linked_list) except for the potentially slow `[]` operator

Cheap exceptions, opinionated error handling

> I often find myself wishing the nim standard library used results instead of > exceptions (this is extra painful with async code because the stack traces > are a nightmare to understand). fwiw, we've rewritten large parts of stdlib to do exactly this -

Rust interop/FFI experiments?

We have a guide written here: The short story is that it's easy to make rust behave like C for FFI purposes, and from there, everything you know about C-Nim FFI becomes applicable (which can be seen in the above guide: most of the

How to combine nim-metrics and chronos for simple rest api?

That's right.

How to combine nim-metrics and chronos for simple rest api?

Indeed, the new way of starting gives you control over which thread runs the metrics server .. depending on how you want to use it and how much load you have, it can run on the same or a different thread

How to combine nim-metrics and chronos for simple rest api?

A good starting point is this example: On top of that, you have this test that shows how to start metrics: Each of those can be put

List of GC'ed types

Nice! This would be an excellent addition to typetraits (`isGcType` or something) where it would work recursively for objects and tuples - I've often wanted such a utility to avoid passing GC:d stuff across thread boundaries etc.

chronos 4.0

[v4.0.2](https://github.com/status-im/nim-chronos/tree/v4.0.2) tagged to work around a [regression](https://github.com/nim-lang/Nim/issues/23432) in 2.0.

chronos 4.0

correct v4.0.1 link

chronos 4.0

[v4.0.1](https://github.com/status-im/nim-chronos/compare/v4.0.0...v4.0.1 -) tagged: * removes usage of `sink` ([currently broken](https://github.com/nim-lang/Nim/issues/23354) in all Nim versions, both refc/arc) * fixes some circular refs in timers for better ARC support * fixes a bunch

[arnetheduck] `nph` opinionated formatter v0.5

vscode extension updated to format nims and nimble too: <https://marketplace.visualstudio.com/items?itemName=arnetheduck.vscode-nph> A few projects I know of that migrated to `nph` 0.5.1, in case you're curious about what it looks like in the wild: * [results](https://github.com/

Challenge: Weak linking on Windows

> The idea behind it is that we can leave the merging of duplicated generic > instantiations to the linker and simplify the frontend. This means though that the (c) compiler has to re-parse, re-codegen and potentially re-optimize them leading to quite a lot of extra work for it before it gets t

Nim procedure args vs C and the need for pointers.

Next step: get rid of the `lent` keyword:

Tooling update: new version of the nimlangserver and the vscode extension

It's a simple matter of killing the process group and not just the proxies -

[arnetheduck] `nph` opinionated formatter v0.5

[v0.5.1](https://github.com/arnetheduck/nph/releases/tag/v0.5.1) fixes some small annoyances found in fluffy - [nlvm](https://github.com/arnetheduck/nlvm/pull/65) had its rite of `nph` passage as well - fluffly and nph both show strategies for checking formatting in CI.

[arnetheduck] `nph` opinionated formatter v0.5

There we go, v0.5 of the `nph` formatter [released](https://github.com/arnetheduck/nph/releases/tag/v0.5). The release comes slightly earlier than I was planning but is also fairly small, cleaning up a few inconsistencies found while applying it to [fluffy](https://github.com/status-im/nimbus

How do Nim exceptions work?

For a pragmatic introduction to how to deal with exceptions in applications that shouldn't crash, we have a chapter on describing their safe use and some of their pitfalls here: Notably though, for scripts and other simple app

Fused multiply-add instruction

\- FMA will be used if there's a reasonable instruction for it - `-march=haswell` for example has one. Regarding rounding, IEEE allows the use of FMA even if rounding differs:

`nph` opinionated formatter v0.4

[0.4.1](https://github.com/arnetheduck/nph/releases/tag/v0.4.1) out to fix a small comment-eating bug

`nph` opinionated formatter v0.4

> A doc comment cannot refer to "any" node, it's documentation that belongs to > a declarative construct. fair - nph has to handle non-doc-comments as well however, hence the "every node" thing in `nph` specifically. By holistic, this is probably more or less - the problem of comments, doc com

`nph` opinionated formatter v0.4

> core of the problem .. no dedicated slot Yes and no - it's relatively easy to add a "comment slot" to every node (like the upstream AST has a magic comment field that is used sometimes and how `nph` has 3 - pre/mid/post-comment) - what's hard is knowing which node a particular comment belongs

`nph` opinionated formatter v0.4

Well, the way docs are implemented right now is that the parser shoehorns doc comments into somewhat random locations in the AST and gives this to `nim doc`, but there isn't a comprehensive set of rules for what comment belongs to which item: proc f( arg: int, ## Is this a

`nph` opinionated formatter v0.4

up taking too much vertical space - this release saw the addition of `.` to the list of "simple" things, such that introducing a module or object name (`mymodule.symbol`) doesn't cause an explosion. Finally, [NeoVim](https://github.com/arnetheduck/nph/pull/38) editor integration wa

chronos 4.0

> multithreading the focus of this release has been on security, stability and feature completeness, mainly because we haven't yet reached the point where http performance is an actual bottleneck anywhere (ie when we benchmark whole-application performance, it's not the http part that stands ou

chronos 4.0

[It's out](https://github.com/status-im/nim-chronos/pull/494)! v4 is the async/await framework release where we circle back experience from building libraries for [p2p networking](https://github.com/status-im/nim-libp2p), [standards-compliant websockets](https://github.com/status-im/nim-websock

Argon2 in Pure Nim.

Here's one with you can compare with:

What are your options for dealing with leaks in asyncCheck under arc?

For anyone reading the above snippets and wondering how come the async tasks get processed at all, `waitFor someFuture` will complete all ongoing async work (including "detached" work like that of `asyncSpawn` but return only when the particular given future is finished. It is unusual in async

What are your options for dealing with leaks in asyncCheck under arc?

I'm not entirely sure what you want to achieve to be honest as your two examples point in slightly different directions: Here's a way to structure the code so the channel is checked for messages every 10 mills no matter of there's ongoing async work or not: proc readWork() =

What are your options for dealing with leaks in asyncCheck under arc?

> Is one offender this one doesn't really matter greatly - the worst problem in asyncdispatch is that every async call creates a cyclic reference between the future and the closure environment of the iterator whose body is generated by the async macro - one needs a fair bit of rewriting to elim

What are your options for dealing with leaks in asyncCheck under arc?

> Chronos has an eternally ongoing poll call that never times out `chronos` poll returns after it has processed one round of callbacks - thus, you can use a timer to make it return on a regular basis like so (`waitFor` calls `poll`): import chronos proc work(v: int) {.asyn

`nph` opinionated formatter v0.3

> What you are learning is that nph should not be enforcing a style but rather > a view. i.e. nph can take nim however it is written and then present it in > the ide in a format preferred by the user. I'd recommend to better understand what `nph`

`nph` opinionated formatter v0.3

Quite a few people have provided feedback that `1 .. 3` and `1 ..< 3` should have spaces to match all the other operators while NEP1 says they shouldn't. I've seen both styles in the wild but obviously because `nph` removes the spaces, those wanting their spaces back have been more vocal. Who ca

`nph` opinionated formatter v0.3

Strings of dot calls sounds like a reasonable place to apply the general list logic - can you open an issue with a few examples?

`nph` opinionated formatter v0.3

`nph` 0.3 is out! Binaries from the [release page](https://github.com/arnetheduck/nph/releases) * Back to `,` as parameter separator - this helps compatibility with inline procs due to a parsing quirk where `;` gets eaten by the inline parser while `,` (mostly) does not * New manual at

Sum types, 2024 variant

This becomes even more obvious when you look at `Option[T]` \- `None` for `Option` doesn't know/care about `T` \- when you construct a `None` you don't have to provide a value for the "some" side - why would you have to provide its type? It's completely irrelevant for the none side (see

Sum types, 2024 variant

> Wait ... what? That looks like the kind of feature that saves a couple of key > strokes for the end user No, this is actually quite an important feature! Imagine a function constructing an error return for `Either` \- consider `return Either.Le(42)` \- there is no need to repeat the full eith

Sum types, 2024 variant

For those thinking of this as a special case of an object variant, it is .. here's an equivalent "desugaring" syntax: type ExtraEither[A, B] = object field: int case _: _ of Le: _: tuple[le: A] of Ri: _: tuple[ri: B] Run It is r

`nph` opinonated formatter v0.2

docs are up:

`nph` opinonated formatter v0.2

> Am I missing something? Is there any problem with the AST in this case? Read (and test) the post above with the proc in it. > only fair to respect the choice of those who have adopted it. Happy comma users, happy semicolon users, opinionated formatter - pick any 2. Semi-colons are indeed a le

`nph` opinonated formatter v0.2

So, diving into the identifier lists, the situation is the following: * Using `,` is ambiguous if the identifier does not have a type or a default, because it then gets parsed as an extra name for the same identifier group - `;` is used to break groups * Using `;` is not possible for identif

`nph` opinonated formatter v0.2

> For example, it could use semicolons if some proc declaration in the source > code file already uses semicolons. The semantic difference between using them and not using them makes this kind of detection fickle at best - there are many edge cases and irregularities in the parser - ditto can b

`nph` opinonated formatter v0.2

> decisions and coding guidelines are an important step indeed - "use nph" takes about 2s to write down, then you can productively move on to more important decisions ;) > Is planned something like in nph ? no:

`nph` opinonated formatter v0.2

> But it's fine, I don't have to agree with nph's goals and can choose not to > use it. You can also fork it and build a max-options variant off it, which is probably more productive ;) The codebase is easy and I'm happy to make it easier for anyone that wants to. I'm curious though, what opti

`nph` opinonated formatter v0.2

2.0.0 is for compiling the project - you can use it with your other code. If you have the latest nimble installed, it should install the right version for you.

`nph` opinonated formatter v0.2

> options <https://github.com/arnetheduck/nph#why-are-there-no-options>

`nph` opinonated formatter v0.2

Oh, for those that like style debates, I've also recommended that NEP1 is modernised to take into account the development of the language as a whole and switch to hanging indent:

`nph` opinonated formatter v0.2

Alright, we're here - the first numbered release of [nph](https://github.com/arnetheduck/nph) is here! In case you didn't read the [massive thread](https://forum.nim-lang.org/t/10754) introducing the project, `nph` is an opinionated code formatter for Nim. It will take Nim code and

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

No sorting or other reorganisation of imports planned for `nph` due to the order being semantically significant in nim (top-level statement execution order, generics bugs and so on). Sounds like a job for a separate tool (like python).

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

`nph` does not re-group imports - if you have an `import` keyword per module, that stays. `nph` merely splits a list of modules for a single `import` across one or more lines similar to the function parameter example in the initial post: * if the imports fit on one line, do one line * if th

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

lol, so.. for the blood pressure, a cup of tea and a moment of reflection perhaps, then head over to <https://github.com/arnetheduck/nph#do-you-accept-style-suggestions-and-changes>. Latest commit fixes some spurious commas, among [other things](https://github.com/arnetheduck/nph/p

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

A round of fixes to all kinds of strange parses - in particular around [do expressions](https://github.com/arnetheduck/nph/pull/14) and the like. Expressions are generally rendered a little more compact with the opening pars not sitting on an otherwise empty line - infix are a bit nasty to

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

[Comment handling](https://github.com/arnetheduck/nph/pull/12) updated to deal with this and many other fringe cases - starting to look pretty good ;) <https://github.com/arnetheduck/Nim/commit/9d8dda248f700fdef869fcbb6788cfb1383efbf8>

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

sounds like an excellent PR opportunity ;)

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

[Vertical spacing](https://github.com/arnetheduck/nph/pull/10) update: semi-retained, per feedback - black indeed does something similar. Compiler: <https://github.com/arnetheduck/Nim/commit/f48973fdd206c8f98f4738614c1446bad2513455> > It'd be nice if it could run on a folder b

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

...and a vscode extension: (you need to have it installed - if someone could figure out how to include the binaries, PR:s are welcome)

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

[Style updates](https://github.com/arnetheduck/nph/pull/9): * more compact import/type/var/let/const/etc sections when subnodes are simple * fix infix line breaks * single indent in proc forward declarations and typedefs - double when there's a body * if/elif/except/while cond

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

Habemus binaries: <https://github.com/arnetheduck/nph/releases/tag/latest>

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

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

to detectable incompatibilities - ie one `IdentDefs` with many of sub-idents vs many identdefs which has semantic nuances that I haven't had time to investigate, beyond seeing it causes actual bugs in our code. This is something I'd like to improve, see <https://github.com/arnetheduc

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

> parameters separated by ; <https://github.com/arnetheduck/nph#whats-with-the-semicolons> > If you're interested in feedback, <https://github.com/arnetheduck/nph#do-you-accept-style-suggestions-and-changes>

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

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

his on a daily basis from other languages, so without further ado: <https://github.com/arnetheduck/nph/>. **I intend to never ever format Nim code manually again - it is an utterly useless waste of time** `nph` takes the opinionated route of discarding existing formatting and normalizing

nlvm 1.6.16 - now with a REPL

above iterative approach would replace the traditional, "linear" pipeline where nim does its semantic analysis, then passes the result to nlvm which generates IR, then optimizes, then generates machine code then links (nlvm already does LTO by default which inverts the last two steps, but

Chronos v4 RC

> Congrats, but will that fix the nim-faststreams problem with chronos backend? No, this is an architectural problem with faststreams more than chronos (ie the faststream backend needs to be reengineered). fwiw, chronos also has its own stream implementation which may or may not suite your need

Chronos v4 RC

I wish arc didn't exist as a separate option - can never tell which is which and I don't really care as long as it works reasonably ;) well-suited -> efficient, then.

Chronos v4 RC

We've just wrapped up a round of feature and refactoring work on `chronos`, which will soon become chronos v4 - since we tagged 3.2, a lot has happened: * Exception effects / `raises` for async procedures helping you write more efficient leak-free code * Cross-thread notification mechanism f

Pure Nim FFT library

> publish eh I guess I'll get to it eventually but feel free to PR it yourself in the meantime ;)

Pure Nim FFT library

> signal = (0..length) btw, you have an off-by-one in normalisation due to the unfortunate design in nim that intervals are closed.. the length of this signal is 457 elements.

related_post_gen benchmark

> Should be well, ideally it should be detected by the language like for parameters and done automatically so users don't have to ..

Pure Nim FFT library

> When going back from the frequency domain to signal, I have to divide the > real part of the result by the length of the signal. Is it the convention > that I do that, or should the library? Looks like every library does its own thing here - ie scale, not scale, offer options to scale - for n

idea : reuse libraries from other languages

Nim and go are a bit hard to combine due to both of them relying on incompatible GC:s and go having a built-in thread scheduler while nim threading support is missing at best, but here's how we do it at least:

Pure Nim FFT library

Now 2x faster ;) > small issue in your example. fixed, thanks > friendly license "Add MIT license" button clicked to appease those that find this .. important.

range[a..b] semantics is a bit unclear to me

> Given > that seems that is how they are supposed to work. maybe, but "fixing" them by making them explicit would break practically all code out there - ie unfortunately, `Natural` is a `range` and it's used all over the pla

range[a..b] semantics is a bit unclear to me

We don't use it as a matter of policy due to the implict / silent `Defect` raises that it introduces - ie proc function(v: range[0..10]) = echo v var x = 11 function(x) Run Another way to put it is that it's quite broken compared to other downsizing i

unittest2 face lift

> What tooling does junit have that integrates with this and benefit you here? The obvious ones are CI tools like github actions and jenkins that have plugins that allow tracking statistics, making graphical / easry-to-read failure reports where you get HTML links to each failure and its output

unittest2 face lift

synchronous process management test suite F. (14.5s) ======= /home/arnetheduck/status/nimbus-eth2/vendor/nim-chronos/build/testall 'Asynchronous process management test suite::File descriptors leaks test' ----

Pure Nim FFT library

> Do you have any performance measurements? They're in the readme along with similar benches for `fftw` > CPU only Yes, though it would be fun to add GPU as well and have it auto-select

Pure Nim FFT library

thub.com/arnetheduck/nim-fftr> Enjoy!

Equivalent to Rust's Command spawn/try_wait?

> I think the Chronos library also offers similar. Indeed, chronos is the successor to asynctools and implements non-blocking process handling in general - here are some examples:

Any way to produce Arm64 binaries for MacOS from choosenim versions of nim?

> Atlas can do the same already. ditto nimble - in fact, life would be so much easier if we treated nim just like any other dependency and had the package manager download and use a version compatible with the project (as discovered via `requires nim >=... < ...`) - there's no difference betwee

Is ORC considered production-ready? What is the consensus on its use?

> On that topic, @arnetheduck is Chronos non-cyclic / ARC capable now? I recall > reading that it was, but would be curious if there have been updates in that > world. Especially it looks looks like there was some big refactoring in > Chronos recently. chronos has been acyclic for

crosscompiling - SSL

In chronos we use to avoid this problem - ie the ssl library is compiled as part of your application.

asyncdispatch debugging

You might be interested in chronos' future tracking feature: The way we use it is to expose it via a REST interface so that all in-flight tasks can be tracked:

how to importcpp a C++ class within namespaces in non-sloppy way

> @arnetheduck hope that's a bad joke and you are trolling around :P not really - the semantic mismatch between nim and (modern) C++ is significant, starting with trivial basic stuff like `r-value refs` and `const` that have no semantic equivalent in Nim - on the other hand, the one th

how to importcpp a C++ class within namespaces in non-sloppy way

every c++ problem can be solved with a wrapper written in c++ that exposes a C api instead ;)

NimQML> How to pack resource files or gui files in compiled package

Here's one way to do it with `staticExec`:

End of function in Nim binary

`-ffunction-sections` provides another, slightly more explicit, mechanism for achieving this:

Need suggestions for time scheduling async tasks

The classic approach to rate limiting is via the use of a [token bucket](https://en.wikipedia.org/wiki/Token_bucket) \- here's an implementation for `chronos` (asyncdispatch alternative):

Alternative to powmod in Nim

The fundamental problem with stint currently is a consequence of its unfortunate recursive design which renders every single operation exponentially slower than it has to be in the number of bytes used for the size of the integer. The first step to any stint work is to replace the implementatio

Declaring an uninitialized seq & avoid unnecessary zero-mem's

> No, these only mean that you need to use a custom seq. But I agree it's not > ideal. all other idiomatic nim code uses a seq -> one would have to copy from custom seq to seq -> defeats the purpose of avoiding zero:ing.

Declaring an uninitialized seq & avoid unnecessary zero-mem's

See also and \- these prevent writing code that is possible to write efficiently in other languages.

intops - core primtives for working with integers efficiently

> One thing to note is that surprisingly, compilers have no notion of > carry-flag or overflow-flag in their IR, well, the builtins do: they simply return the result + carry in a tuple: which is close enough as far as IR go

  1   2   3   >