Nim v2.0.0 RC2 is out

When using the compiler available via homebrew, it generates an arm64 executable: $ /opt/homebrew/bin/nim --version Nim Compiler Version 1.6.12 [MacOSX: arm64] Compiled at 2023-03-10 Copyright (c) 2006-2023 by Andreas Rumpf active boot switches: -d:release -d:nim

How to return from a function back to the main application loop

Thanks. I was thinking about removing the function and putting it in the loops to have better control of it. I think I will however on the server have a callable function so it can be used by multiple blocks of code.

How to return from a function back to the main application loop

> I am able to download a file via sockets Fine that you had some success. Without studying your actual code, I would suggest that you use an outer loop to archive your desire. In Nim, as in many other programming languages, loops like "while" and "for" can be nested. And note, that in Nim we g

Maybe can add a pragma let nim proc/func easy call cproc/cfunc

You can write some `converter`.

Nim 1.6 vs 2 (1.9) Working with channels

Please share some code that contains your channel setup and the involved types.

Nim v2.0.0 RC2 is out

> Stable version points to 1.9.3 instead of 1.6... Sorry I messed this up yet again, the build program does not automate "release candidates" properly. It should be fixed now.

How to return from a function back to the main application loop

I am able to download a file via sockets between the client / server successfully, however, after making the function call (proc), for the download of the file, I am pulled out of the loop of the Main program and am not able to return back into the loop of the main program. I need some guidance

Why to_seq not overloaded properly?

This is a limitation of template overloading. To disambiguate the `sequtils.toSeq` and your `proc toSeq` the compiler has to semantically analyze `some_iterator("input")` since there is a procedure overload. First it checks to see the type of `some_iterator` this is a inline iterator so is inval

Why to_seq not overloaded properly?

This code would fail, because if you define new proc for `to_seq` old version with iterator would stop working, [play](https://play.nim-lang.org/#ix=4smH). Isn't it supposed to work? I just add one more version of `to_seq` multiple dispatch function. import std/[sequtils, tables]

Announce: LimDB 0.2.0

This looks nice! Thank you for sharing and for your work on the wrapper!

Announce: LimDB 0.2.0

I just released a new version of LimDB, the table-like interface to the LMDB in-process key value store. I've been using it in almost all my projects, mostly small web apps, and it works like a charm. I also found the interface very satisfying to use, so I think I struck the right balance betwee

Why Svelte is far superior than React (Karax)

Im currently working on a svelte-like framework: Its not finished yet (theres just `for` no `if` `else` in template syntax, no css ..), but the basic system of defining components and the patching mechanisms work (for the small tests ive done so far)

Nim v2.0.0 RC2 is out

I have the same problem except I cannot even install choosenim because of it. Stable version points to 1.9.3 instead of 1.6... deck@ubuntu-22-10:~$ curl https://nim-lang.org/choosenim/init.sh -sSf | sh choosenim-init: Downloading choosenim-0.8.4_linux_amd64 Prompt: Can ch

Nim 1.6 vs 2 (1.9) Working with channels

Dear all, when I compile my code (with sending value to the thread's `Channel`) using 1.6.12 compiler, I get the error message: _SIGSEGV: Illegal storage access. (Attempt to read from nil?)_ This doesn't happen all the time - only if I send something repeatedly (of course I close/open the chan

Maybe can add a pragma let nim proc/func easy call cproc/cfunc

Because call c func (cint cstring cfloat ...) must convert variant type very cumbersome. Have to write many nim templates/func yourself everytime to reduce the trouble, Relatively find yourself writing these templates is the trouble Think maybe add pragma let us easier to use c functions

Nim v2.0.0 RC2 is out

> Is this expected on macOS M1? I used to have the same problem but I don't remember what I did about it. :-) OSX is weird.

Nim v2.0.0 RC2 is out

So is the situation with exceptions going to stay the same?

Nim v2.0.0 RC2 is out

Wow, my boy `.forbids` will get into mainline! It can be used to enforce logical order at compile-time in some cases.

Nim v2.0.0 RC2 is out

Is this expected on macOS M1? $ file ./bin/nim ./bin/nim: Mach-O 64-bit executable arm64 But after compiling a simple hello.nim file: $ file ./hello ./hello: Mach-O 64-bit executable x86_64 Can be specific to my system. Compiled from source. > Nim Compiler Version 1.9.3 [MacOSX: arm64] Compil

Nim v2.0.0 RC2 is out

Small improvement suggestion: I think the title "Nim 2.0.0 RC2" instead of "Version 2.0.0 RC2" would be more expressive, for example when the link is posted on another website without Nim context, which uses the page title as a description of the link.

Nim v2.0.0 RC2 is out

Yes it is unrelated with choosenim, I have seen a couple of messages in the internals channel about it in the Matrix server. I confirm that choosenim update "#version-2-0" does install 1.9.3

RFC: compiler support for object construction shorthand (full fields initializer)

Here is my RFC for adding compiler support for object construction shorthand (full fields initializer) => You might leave your concerns there.

Nim v2.0.0 RC2 is out

Not sure it is related, but something is broken with stable channel and 1.9.3:

Mutable return type works fine for myTable.mgetOrPut but not for a custom proc

Great, thanks for the `lent` tip I thought that required a switch to enable. Suggested documentation is in this pull request, comments welcome.

Nim v2.0.0 RC2 is out

Does `choosenim "#version-2-0"` works ?

Any bad consequence of redefining equality for ref types?

I tried to write a macro to have a pragma for the type definition. When used as a pragma, the untyped parameter is different though and I am not sure how to adapt it. import std/macros macro defineEquality(typedef: untyped): untyped = result = quote do: `typed

Nim v2.0.0 RC2 is out

Very nice! Would be good though with choosenim install instructions as well

Nim v2.0.0 RC2 is out

The second release candidate for Nim v2.0.0 is ready for testing! See more:

My Nim Development Weekly Report (3/26)

Nope, it is used to eliminate the `wasMoved(x); =copy(x, y)` pair.

My Nim Development Weekly Report (3/26)

Are `=copy` / `=sink` going to be removed for `=dup` ?

Mutable return type works fine for myTable.mgetOrPut but not for a custom proc

> But if I have a table-like object that does not support its memory to be > modified directly, then I assume I probably shouldn't be using var T in the > first place. Correct, you can use `lent T` then in order to avoid the copy and yet keep the immutability. > Is there a place in the manual

Mutable return type works fine for myTable.mgetOrPut but not for a custom proc

Okay I think I can see dawn... so if I were to simply use a dummy value, then I would be creating unpredictable behavior in those instances where the `var T` is passed to another function. So the reason to return a `var T` from a table is to allow another proc to modify it. But if I have a tab

Mutable return type works fine for myTable.mgetOrPut but not for a custom proc

> But if it's going to be a copy anyway, why can't I do this? It is **not** going to be a copy anyway. You can pass the `var T` to some other `var T`: inc tab[x] # mutates the value in `tab`! # compare that with: inc a[i] Run The key to understa

Mutable return type works fine for myTable.mgetOrPut but not for a custom proc

`var T` is just a compiler checked `ptr T` so it can point to stack and heap.

Mutable return type works fine for myTable.mgetOrPut but not for a custom proc

Oh yeah I understand heap values, refs and pointers, I specifically want to understand how mutable objects work, where there memory resides, and how the compiler treats them. I am also facing the practical problem of wanting a proc to return `var string` for consistency with similar procs with t

Mutable return type works fine for myTable.mgetOrPut but not for a custom proc

The point of my post was to point out `var T` copies if it's not directly used so proc doThing(s: var (string, )): var string = s[0] var a = ("hello", ) let b = a.doThing() # copies `"hello"` and assigns b to it (a.doThing) = "world" assert b != a[0]

Mutable return type works fine for myTable.mgetOrPut but not for a custom proc

@ElegantBeef @Araq Thanks! That makes sense. But if it's going to be a copy anyway, why can't I do this? proc foo(): var string return "foo" var a = foo() Run I know the direct answer is 'because it's not an l-expression', but my question is, why does i

Any bad consequence of redefining equality for ref types?

> Thanks, I guess the solution then is something like I don't encourage that solution either. ;-)