why does JS backend return array with object?

The usage of arrays in this context is to emulate pointers and the codegen sometimes needs pointers so that Nim's semantics can work. Consider: proc mutate(x: var int) = x = 4 var global: int mutate(global) Run The code generator sometimes does this where it wo

Can I pass different types to static generic parameters?

Thank you for the detailed & helpful explanation!

why does JS backend return array with object?

I think this is intended behaviour as Nim correctly uses the first value out of the array when you use the actual value. Maybe it's something to do with undefined, I'm not sure.

why does JS backend return array with object?

Hi guys, I'm wrapping some of Google's Apps Script (targets the js backend): type SpreadsheetAppObj* = object Spreadsheet* = object Sheet* = object var SpreadsheetApp* {.importcpp, nodecl.}: SpreadsheetAppObj {.push importcpp.} proc getAc

why does JS backend return array with object?

I've played around with the `importcpp` pragma and converting `ref object` to `object` to no success. I've wrapped a js library before many months ago and remember it generating code with just the object being returned. Idk beats me

Mastering Nim: A complete guide to the programming language

Currently reading, so far so good!

Mastering Nim: A complete guide to the programming language

I just received the book. I'm hoping to get through the whole book slowly as I find time to try out all the examples. P.S.: The acknowledgement section gave me a nice surprise. Thanks 😀

Mastering Nim: A complete guide to the programming language

Just ordered a copy. Looking forward to reading through it!

If imported name conflicts with Nim keyword, what would you call it?

In this case I would go for `httpMethod`.

If imported name conflicts with Nim keyword, what would you call it?

`cmethod` & `ctype` would seem to be most along the lines of the usual Nim FFI conventions, even if the "C" in this case is JS (like `cstring` is "c)ompatible string" which is also the Nim type of both fields here).

If imported name conflicts with Nim keyword, what would you call it?

If imported name conflicts with Nim keyword, what would you call it?

If it's a field exposed to the end user, better a misspelling than forcing them to use backticks.

Mastering Nim: A complete guide to the programming language

I bought the paper-back should be here by Saturday. Thanks

If imported name conflicts with Nim keyword, what would you call it?

Why not use `methodName` and `typeName`?

Can I pass different types to static generic parameters?

What's happening here is since `ABC` is a non-concrete type, it also gets converted into its own generic type, and [implicit generics](https://nim-lang.org/docs/manual.html#generics-implicit-generics) group both ABCs into the same generic (this is an intentional design choice) even with the sem

If imported name conflicts with Nim keyword, what would you call it?

As far as I'm aware, misspelling is the most popular method.

If imported name conflicts with Nim keyword, what would you call it?

Ref type FetchOptions* = ref object of JsRoot ## Options for Fetch API. keepalive*: bool metod* {.importjs: "method".}: cstring body*, integrity*, referrer*, mode*, credentials*, cache*

Can I pass different types to static generic parameters?

Thanks, my goal is to change only function implementation and keep function signature unchanged.

Nim 2.0 is already here.

> n that case, if those are going to be the new defaults, couldn’t nim use > nimalloc by default when those flags are used as well? Well not necessarily "by default" but if it's a recommended optimization at least having a switch `-d:useMimAlloc` like `-d:useMalloc` would be useful

Nim 2.0 is already here.

In that case, if those are going to be the new defaults, couldn’t nim use nimalloc by default when those flags are used as well?

Nim 2.0 is already here.

> Could mímalloc be used by nim by default when threads is enabled (in > supported platforms if that’s a limitation)? What would be the drawback? I don't know of any drawbacks for `--threads:on --mm:orc`. In other combinations Nim's memory manager can be better.

Can I pass different types to static generic parameters?

This works: proc f[T1: ABC, T2: ABC](V1: static T1; V2: static T2) = discard f(A(10), A(20)) f(B("hello"), B("world")) f(A(10), B("abc")) Run

Can I pass different types to static generic parameters?

Looks like a bug.

Mastering Nim: A complete guide to the programming language

I second wanting an eBook, would've loved to download this today and read it on my Kindle during my vacation instead of having to wait for a physical copy after my vacation when I don't have much time to read anyways.

Nim v2: what would you change?

> creating a constructor so that default elements - for example in an array - > all get the same value is pretty cool. What's wrong with `sequtils.newSeqWith`?

Nim v2: what would you change?

This is already a pretty long list here, and I'm sure some of the things are already mentioned. I would love to see some of the features that make me currently avoid using Nim in production: * **memory safety** : My most severe concern. There is "ptr", "async", "new", "allocShared" and all h

Can I pass different types to static generic parameters?

This version doesn't work type A = distinct int B = distinct string ABC = A | B proc f[V1: static ABC; V2: static ABC]() = discard f[A(10), A(20)]() f[B("hello"), B("world")]() # Error: cannot instantiate: 'f[A(10), B("a

Nim 2.0 is already here.

> Shouldn't at least files and sockets auto-close with Orc? "uniformity over comfort". If it means that I have to think about whether auto-close works in 'this' situation/library, I'd prefer no auto-close at all.

Nim 2.0 is already here.

Could mímalloc be used by nim by default when threads is enabled (in supported platforms if that’s a limitation)? What would be the drawback?

Nim 2.0 is already here.

Created a project to keep track of these tasks =>

Nim 2.0 is already here.

> The primary reason for this is that the compiler's data structures have been > optimized for the old GC and Orc changes the seq implementation. This is where we are, those of us that actually have written lots of good Nim code > This is my preferred solution Rewrite it in C while you're at i

Nim 2.0 is already here.

Making Orc the default is not just a matter of fixing the remaining bugs, the compiler bootstrapped with Orc uses much more memory than the compiler that uses the old default GC. The primary reason for this is that the compiler's data structures have been optimized for the old GC and Orc changes