Jason Beetham
Jason Beetham
There is a type bug here. Even if one corrects the arrays, incorrect C is generated unless one explicitly converts to a type alias. ```nim type ChannelId = enum ch1,...
If you really care about performance you'd change the `seq` to `HashSet`, but now it depends on `std/sets`.
Are you actively using the name? Cause `cstring` and `UncheckedArray[char]` have vastly different semantics. For reference are more correctly Nimified bindings for Inotify.
It should be a `UncheckedArray[char]` yes, the fact cstring works for you astounds me :smile:
A workaround could be using `varargs[typed]` and just checking the type of Nodes manually, like so: ```nim import std/[sequtils, macros] type Future[T] = object InternalRaisesFuture[T, E] = object macro Raising*[T](F:...
The one issue I see is that you're using a `ref object` so hooks do not abide by mutability, if you must have a `ref` might I suggest distinct `JsonyParseContext`...
You could tag your procs with your own `Defective` then on any consuming modules push `forbids: [Defective]`, but yea that aside there is nothing. https://nim-lang.org/docs/manual.html#effect-system-tag-tracking
Fairly certain this is just an issue with Nim + mingw it auto converts paths when using mingw. Perhaps using `{.compile.}` was a fools errand and it's best to have...
Finally got around to bodging this in, fixed in 0.1.18. I know I know it's been ages and you've grown to have an entire family and put them through Uni.
> rarely seems to be a good idea `--panics:on` means it's just not a good idea unless you're testing.