Introducing an async library inspired by Go in Nim

My response is so what if name collisions happen. The import system is there to help you can do `import nimfibers as fibers` and then do `fibers.Async`. I doubt everyone agrees with me, but name collisions are to be resolved by users not developers in my view.

Introducing an async library inspired by Go in Nim

If we're suggesting fiber based names. My pun based naming scheme means I nominate 'gunnysack' as a package name.

Sum types, 2024 variant

A possible solution is to use `as` for matching the branches so it'd be `string as s` instead. For specific field matching `Type(a, b, c)` would do positional matching. With an added `Type(a: fieldName)` it could even be expanded for named matching where it'd grab the field of typed branched

Cheap exceptions, opinionated error handling

If each error code were to be turned into a `Defect`, everything would be here to have that. Since defects should not be caught already they should not have fields this likely should have 0 issues with present code. This means `MyDefect = object of Defect` could add an 'enum' value to the

Object variant, which contains no references, does not conform to the 'NoRef' concept

Calling `containsRef` manually shows the issue: proc containsRef(t: object or tuple): bool = typeit(t, {titAllFields}): if containsRef(it): return true false Run Attempts to access a field that depends on the kind: proc

Proc inheritance for distinct type in Nim 2.0.0

Well it does not "inherit" but yes the base types hooks are implicitly called, but you can override them if you want.

Where does the complexity of quote from the manual comes from

The LLM cynic in me feels the need to post this. You really think an LLM would do that? Just Go on the internet and tell lies?

Help storing *reference* instead of copy in an object constructor.

> Value types were managed memory Nope value types are allocated on the stack when declared locally or contiguously at the pointer when there is a reference type involved. This means one cannot safely take an address to a value type unless they know the usage of that pointer does not outlive

Help storing *reference* instead of copy in an object constructor.

Nim has no mechanism to safely reference a value type, as such you need to raise the `original` to a `ref seq[int]` like so var original = new seq[int] original[] = @[1, 2, 3, 4, 5] type Thing = object # I would like `list` to be set to a *reference *of

Use of typeof() in object member definition inside macro fails

Firstly `typeof(T.color)` is invalid cause `T` is a typedesc it does not have a `color` field. `typeof(default(T).color)` should work but Nim's generics always fight you to the death so this does not work. If we define `template color(T: typedesc): untyped = typeof(default(T).color)` to delay

Declaring ambigious tuples

`type EntryFunctionPayload*[ScriptArgs: tuple] = object moduleid* : ModuleId function* : string type_arguments* : seq[string] ## tuple of TypeTags ## TODO :: check if error occurs here arguments* : ScriptArgs ` Run

Trying to get "interfaced" to run with latest nim

> Error: internal error: environment misses: this Likely means you're emitting a `symbol` in a place that it should be an `ident`. I have not taken a look at trying to fix it but properly desyming the typed ast will likely solve it. Otherwise I can suggest

Wasm3 (nim library) how to run c functions

Using non-sized strings across the barrier will always be a pain since you manually have to copy each byte. I did push out a new version with a test example and introducing `copyFromMem` to make it easier to copy byte buffers from VM to Nim.

Wasm3 (nim library) how to run c functions

You need to think of wasm as a completely separate environment so you cannot really share anything but `ptr UncheckedArray[uint8]` or `cstring` **from** the VM to the host since the VM and the Nim code have two completely different runtimes and data layout. The VM is also sandboxed so it cannot

Wasm3 (nim library) how to run c functions

When calling procedures you need to marshal the data from the host to the environment and vice I have an example of host to client is the wasm module

How to remove the N_LIB_PRIVATE from exported c code.

I am generally of the view packages should only be on a package registry if they're of sufficient quality. Which means have tests, and documentation. Since Nimble is decentralized there is not much reason to add what I consider incomplete packages.

How to remove the N_LIB_PRIVATE from exported c code.

If you're sharing code with other languages the correct annotation is `cdecl, exportc, dynlib` though in many cases `nimcall` is compatible with `cdecl`

How to properly make a static type-checking macro?

> Note: There is also an issue with the return arg saying that arg is unused? You do not have a return type it should be `: untyped`. Is there a reason for you to use a macro here, a template works just fine. template typeCheck(arg: typed, typ: typedesc): untyped = when arg

How to remove the N_LIB_PRIVATE from exported c code.

You should use `exportc, dynlib` to ensure a procedure is not dead code removed. Depending on your wasm compiler you may also want to use `codegenDecl` to add the correct annotation to your procedure.

Which Nim Paradigm could I use instead of OOP with Generics and Inheritance?

Even though there is a warning for generic methods they do work in my experience. Otherwise you could do pointer proc interfaces where you abstract all procs into `proc(_: Widget, )` then inside do like proc label(str: string): Widget = Label( str: str,

Gedit syntax highlighting.

Right I forgot, from my looking there is no way to override the default lsp settings. So what I did was install `nimlangserver` then rename it to `nimlsp`. It works, but less than ideal of course.

Gedit syntax highlighting.

Another option is [Kate](https://kate-editor.org/) it's the kounterpart(Yes lame joke fite me) to code, it has LSP support so you can use nimlsp or nimlangserver.

JS bindings question - Quill

Given that it's `static` one must emit `Blot.blotName` so the correct import is likely proc blotName(_: typedesc[Blot]): cstring {.importJs: "Blot.blotName".} Run

How to preallocate cstring for FFI call that fills it up

> Feels like a flaw to me... I can find out the length by iterating the > cstrings in the array until I arrive at nil, I feel like this should already > be there. Welcome to why sentinel terminated collections were replaced with pascal collections. To encode the length you need more data and

How to preallocate cstring for FFI call that fills it up

> Can you tell me where I should have found this information in the manual? > Because I had been searching for something like this. There is no explicit mention but says > The terminating zero cannot be accessed unless the string is

How to preallocate cstring for FFI call that fills it up

The best way to allocate cstrings in Nim is to do var a = newString(len) someProcThatTakesCstr(a.cstring, a.len) Run > when passing the cStringArray (in earlier call glShaderSource), I need to > pass the size of that array. I know it is 1 so I hard code it, but is

Austral (a simple-ish language with a linear type system)

Cause I disagree with parts of the linear type system. RAII exists so let's use it instead of pretending that doing what a compiler can do for you makes good code. Like I mentioned it does not need to be discardable. I think compilers should protect you from yourself in a non interfering way.

Austral (a simple-ish language with a linear type system)

The "only allow a single use of an instantiation" is quite easy to do with present Nim just by disabling `=copy` or `=dup` . You can make all the procedures that operate on a type take a `sink T` and return `T` then the following is possible type MyFile = distinct File proc

Show Nim: Sunny, JSON in Nim with Go-like field tags

One possible pragma solution is to do the following. type JsonFlag = enum omitEmpty asString template json(name: string = "", flags: set[JsonFlag] = {}) {.pragma.} type Example = object myField {.json(flags = {omitEmpty, asString}).}: int

Show Nim: Sunny, JSON in Nim with Go-like field tags

> It is totally possible to have a -d:sunnyGo and -d:sunnyNim or similar to > enable devs That will get you into a territory that only the toplevel can use `sunny` as one dependency might rely on `-d:sunnyGo` but another needs `-d:sunnyNim` if you want to support two syntax two pragmas makes

single line ref seq[int] assignment

Worth noting this gets a `ptr seq[int]` and not `ref seq[int]` which means you need to ensure the lifetime manually. If one is making many ref types one can simply do: proc new[T: not ref](val: sink T): ref T = result = new T result[] = val var a = new @[10

static checking of strings

You're always overprotective. `func toIpv4(str: static string): static Ipv4 {.inline.}` how does one inline code that requires the result to be static? Anyway I would suggest naming the proc `ipv4str` so you can use `ipv4str"127.0.0.1"` as it reads much nicer in my view.

fusion/matching case statement behavior

> So nim doesn't know that the Some(_) and None() branches form an exhaustive > check of Option values? Well it's cause the macro expands the case statement into if elif branches this can be seen in the following. # compile with --expandMacro: case {.experimental:

How to declare a string containing an untyped?

`template declareName*(name: untyped): untyped = const `name Str`* {.inject.} = astToStr(name) declareName(Bob) echo BobStr # desired output: Bob ` Run

2D sequence setter

For `[]` you likely should annotate the result `lent` that way if you do `someCall(mySeq[0])` it does not copy. Since this seems to represent a rectangular grid you may want to use

Definition of name equivalence

`type D = C` is a type alias as such `C is D` and ` D is C` , whilst a new type is introduced the type is just a new name for the right hand side.

Custom constructors

is a `Rect` agnostic guillotine square packer. Ideally this would work on any type but the concept needs expanded, as it is it should work with a Rect made of any builtin type. My library Gooey constraints `Vec` s to the

Custom constructors

I mean I can provide code I've written that uses this to enable reusable generic procedures, but hey I'm just a numpty with a keyboard I do not really exist.

Custom constructors

If it is a value type you should use `init` if it's a reference type you should use `new` personally I find `initT` a terrible pattern as it does not compose with generics as ssuch the better convention is proc init(_: typedesc[YourType], ): YourType = ... # Use `new` if using

subclassed Iterator dispatch question

`iterator`s are statically dispatched so you need to change the type inside of your typecheck branch and call the corresponding iterators. The only builtin dynamic dispatch Nim has is `method`.

Dynamic Typing in Nim

Remember friends don't let friends ask a LLM solve the halting problem on the off chance Skynet frowns upon it.

Sum types, 2024 variant

Pointer indirection and heap allocation make using OOP a very unfriendly choice. It's also `of` not `is` for checking inheritance :)

Sum types, 2024 variant

One noteworthy thing is that in the `case` assuming each branch label emits a distinct type(like my package fungus does ) you can dispatch on those types type Shape = case of Circle: r: int of Triangle, Square: w, h: int proc area(circ: Circle): int = circ.r *

=destroy and enum

You should be able to do var myVariant = Object(kind: ...) let newKind = YourNewKind copyMem(myVariant.kind.addr, newKind.addr, sizeof(YourKindType)) Run

fixme: the proc parameters always use Copy by default?

`seq` s and `strings` are 2 pointer sizes so do not experience that optimization their value component is passed as copy, but since they own heap data that is not copied this can be seen below: proc f(t: seq[string]) = echo "f:", cast[int](t[0].addr) proc fv(t: var

Mocking overloaded function

To start an arms race of "the best way to get a proc symbol" I enter my improved `extractProc` :P import std/[macros, genasts] macro extractProcImpl(call: typed): untyped = call[0] macro extractProc(prc: typed, params: varargs[typed]): untyped = result

Mocking overloaded function

Personally I find a macro like the following to work the best for grabbing overloaded symbols import std/macros macro extractProc(t: typed): untyped = if t.kind != nnkCall: error("Expected a call", t) t[0] var myAdd = static: var i:

Sum types, 2024 variant

Though since `case` also can be used for flow control I assume the typeclass would also not be `case` as that'd make parsing more complex?

Sum types, 2024 variant

The issue is that there is code that presently works that only works with numeric `enum`s. By accepting both you now have code that appears like it should work but will result in instantiation errors. By all accounts of current Nim`SumEnum` is a specialization of `object` not `enum`, you cannot

Sum types, 2024 variant

The biggest issue I see is the usage of `enum` now makes it so any code that expects a `enum` typeclass has to delimit three different types of `enum` (OrdinalEnum, HoleyEnum, and SumEnum). Consider `parseEnum` it's constrained to the typeclass but obviously will only work on the numeric

Are generic procedures default to `mixin`?

No, only overloaded symbols are defaulted to open(mixin), non overloaded are bound to the symbol. This can be seen with a simple macro: import std/macros proc printSymChoice(impl: NimNode) = for n in impl: case n.kind of nnkOpenSymChoice:

Nim need restrictions for values in type system

The code is there, be the super small package maintainer you want in the world.

Nim need restrictions for values in type system

It's less than ideal, but thanks to `converter` and distinct a subset of refinement types are possible with present Nim. import std/[macros, genasts] type RefinementError* = object of CatchableError macro refineType(name: untyped, base: typedesc, expressions:

Sitemap Parser

Looking at the code there are a few things I'd suggest although relatively opinionated. Modules imported from stdlib should be prefixed with `std/[a, b, c,]`. proc hasURLSet(sitemapContent: string): bool = let doc = q(sitemapContent) let urlset = doc.select("urlset")

Using the var type to modify a separate object from another

To do this safely one needs some form of borrow checker. Nim's experimental `views` does this but it's likely to be easier to just use a `ptr T` or `ref T` which ever suffices for your problem until that feature becomes more

Capture atomics in closure

I'd say just turn it into a `Thread[a, b: int, c: ptr Atomic[int]]` you already want to refer to the stack of the spawning thread. Threading does not allow closure procedures, so you have to pass the 'environment' explicitly.

Is Nim Dead?

The mythological figure? Probably. The language that had a PR merged 15 hours ago at the time of writing this? You decide.

What would I lose if I turn of garbage collection?

Anything in the stdlib that operates using automatic memory management `seq`, `std/[sets, intsets, packedsets, tables, deques,]`. There is really no reason to disable automatic memory management in Nim since with Arc you can just write hooks and it'd be indistinguishable from the C without

Some sort of interface-like functionality or varargs

To break this down into multiple steps `varargs[T, conversionProc]` allows you to take in comma separated values or arrays, but since arrays have to be homogeneous you cannot do `query = {}` or `query = []`. proc toStrTup[T, Y](a: (T, Y)): (string, string) = ($a[0], $a[1])

Concept generics

You can just do `: auto` then in the first line `result = default(myVal.x)` it's not ideal, but it's totally workable

Concept generics

type Vector3*[T] = concept var v v.x is var T v.y is var T v.z is var T proc doThing(v: Vector3[int]) = echo v doThing (x: 100, y: 200, z: 400) Run Although `V.x is var T` did work in my testing this is likely a more

How can templates detech if argument is let value or expression?

It is certainly documented There is no copying in the above code. As can be seen by the pointers. > Obviously, with literals and expressions the string does not exist on the > stack so copying is necessary Strings never exist on

How can templates detech if argument is let value or expression?

Thanks to Orc/Arc cursors and COW string literals in this example you can likely use the following: import sugar import strutils template test2(src:string, lab: string = "Inner tmpl") = let s {.cursor.} = src # This works for let values but fails for

How to iterate over a sequence using a pointer to avoid making copies of every item

type Person = object name: string age: int data: array[0.., int] # big data proc getNames(people: openArray[Person]): seq[string] = for val in people.items: echo cast[int](val.data.addr) result.add val.name var a =

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

_Then again comparatively speaking Nim only has 10 packages_ :D

mixed typed varargs?

`import std/macros macro printThings(x: varargs[typed, `$`]): untyped = result = newCall("echo", newLit"Mine: ") for arg in x: result.add arg printThings "Hello", [1, 2, 3, 4,], 10, 200, 300, true ` Run

No =destroy hook(s) in std/tables?

Yes Pmunch was incorrect, when defining a custom destructor you need to destroy all fields. The same issue arises in and my comment to work around the issue applies here as well.

Why iterating over slices is so slow？

Cause in default Nim `a[b..c]` copies a new sequence and iterates that. [This](https://www.jasonbeetham.com/slicerator/#%5B%5D.i%2CopenArray%5BT%5D%2CHSlice%5Bint%2CBackwardsIndex%5D) can be used instead to 0 cost iterate a slice without any syntax changes.

Compile to NIM to WASM with the Wasi-SDK

You likely should use `--os:linux --cpu:wasm32`

Concepts as type classes in generics

I have no idea what you were trying to do with the concept. You seem to be mixing newstyle with old style and have created a monstrosity of wrong :D type PluggableHashAlgorithmU64 = concept x, var varx open_default(varx) # if you do this: #

Decimal operation

Everything else but point 4 is beyond me... but if you want to make it a bit nicer you can define your own literal: import decimal proc `'dec`(s: string): DecimalType = newDecimal(s) echo 1e4'dec Run

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

Labelled exceptions for smoother error handling

Could be cause it should be 'coarse error handling'.

Changing an object's field is rejected in a destructor with new syntax

Hooks must be declared before first use. If I am not wrong the correct way of doing this would be: type AObj = object name: string proc `=wasMoved`(x: var AObj) = x.name = "" proc `=destroy`(x: AObj) = `=destroy`(x.name) var a: AObj

Issue with calling a routine defined in a concept

Of some note: type Thing = concept t work(t) proc start(t: Thing) = mixin work t.work() work(t) # undeclared identifier Run Will make it `work` :P

Playing with type states and lifetime-tracking hooks, facing some unexpected behavior

It's likely the best way to achieve what you're after is to use distinct typing, so you can convert inbetween them: type State = enum sGas sLiquid sSolid ExperimentImpl[T] = object data: T Experiment[T; MaterialState: static

Best way to architect a Nim dll/so that is used by other Nim dll/so/executables

It requires a lot of duplication(And I do not allow the program to allocate then send to the DLL. Meaning no need to link NimRTL), but is a fairly good way to wrap an API providing import and export.

Using Concepts for abstracting display graphics

It's just the wonderful in action :D

Using Concepts for abstracting display graphics

On that topic is likely a nice resource.

Type introspection

Not that it's well documented, but a ton of type operations are defined inside . Most important to this question would be

Using Concepts for abstracting display graphics

Personally I always have better luck with old style concepts import bitops # Concept describing a display, analogous to "Indexable" in tests/concepts/tspec.nim type AnyDisplay*[T] = concept display display.getPixel(int, int) is T

Declaring a global proc variable to be gcsafe has no effect

`proc` in type positions are default `closure` so it likely should be `var newW: proc(): W {.gcsafe, nimcall.}`

Nim boilerplate

Odin also implements Unions but it does not implement auto dispatching based off runtime time, as such you need to do the same thing as Nim

Nim boilerplate

I no longer get the point of this forum post and should no longer participate, but...Thank's to leorize's there is a usable union solution. import union type CodeCmd = distinct string ReplaceCmd = object elementId, content:

Nim boilerplate

"From the makers of Advanced Wars Advanced Types", eh I use new `concept` style concepts, but there is not any reason it has to. I'm sorta confused why sum types are advanced, meanwhile OOP types are not. Inheritance is a more complex and advanced topic than "We overlay types to reduce

Nim boilerplate

See I was going to do that but it felt like it was a bad faith argument. The following is a more good faith argument. import traitor #https://github.com/beef331/traitor/tree/master type Unit = concept proc act(_: Self) Marine = object Tank = object

Nim boilerplate

Now maybe I'm an idiot, but did you not just say "Good luck doing polymorphism without polymorphism"? As far as I know Typescript interfaces used in the way you showed is polymorphism.

Why can't you echo a ref object?

I did answer the question, there is no `$` defined for `ref`. The 'exercise to the reader' was a joke response due to my ineptitude to proofread a `$` implementation. As I mentioned the issue is that a naive `$` on a cyclical data type will enter an endless loop. So yes it's to avoid printing

Type mismatch on Future's

Nim does not have first class union types, those are generic constraints which means the type can be either `seq[Post]` or `seq[Get]`. You need to use object variants or inheritance to allow either type at runtime.

Why can't you echo a ref object?

We'll pretend instead of failing to proofread it was an exercise for the dear reader.

Why can't you echo a ref object?

Nim's default `$` are implemented for value types not reference types. You _could_ implement: proc `$`(r: ref): string = if r.isNil: "nil" else: $r Run But this naive approach and will explode when using cyclical types.

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

> I think the best thing that can happen is that the range type is phased out > to be replaced with something more explicit. Given that seems that is how they are supposed to work.

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

Just briefly looking at these, most of them seem to be bugs in likely caused by `range` checks not being emitted inside implicit generic code. `proc stat0(n: static[range[0..5]]): string` seems to be caused by an issue with implicit conversions from literals to static ranges not being checked.

How can I shorten the compile time?

`nim r app.nim` makes a binary.

Idiomatic way to zero-copy iterface with binary bitmap array

You can define a `toOpenArray` template for any type that does this, but like I said you do not have a sequence of bools so it's mostly moot.

Idiomatic way to zero-copy iterface with binary bitmap array

I mean you could make a `openArray[byte]` but an `openArray[byte]` is incompatible with the zero copy, since the data is stored in a bitset and not sequential bools.

Idiomatic way to zero-copy iterface with binary bitmap array

Since `bool`s are not bits you have to copy to make an `openarray[bool]`. What makes a bit more sense is to make the following then implement operations on the type. type MyBitset = object start: ptr UncheckedArray[byte] size: int Run

Circular imports for procs

Delayed imports are your friend: # objs.nim type App* = object files*: seq[MyFileHandle] MyFileHandle* = object app*: App path*: string func `==`*(a, b: MyFileHandle): bool = # Some Nim `==` func issue a.app == b.app and

[Advice] Ways to handle "dynamicity"

Did you miss the purpose of this conversation? The OP wanted to use Nim/Nimscript as a configuration language for their program. What you've done is made a odd compilation pipeline that does not configure a running program. To do that you'd need to do some form of IPC.

[Advice] Ways to handle "dynamicity"

Using `nim r bleh.nim` uses Nim directly which requires a C compiler and an established Nim environment. Using embedded Nimscript does not require this, you either ship the NimVm as a library or embedded in your program. This is the difference between using lua as a library or lua through the

  1   2   3   4   5   6   >