db_sqlite prepared statement

That works fine. To sqlite3.nim I added the: proc sqlite3_db_handle*(para1: Pstmt): PSqlite3 {.cdecl, dynlib: Lib, importc: "sqlite3_db_handle".} Run To db_sqlite.nim i added: template exec*( stmtName: SqlPrepared, args: varargs[typed]

Can I somehow share a C++ class with Nim, either by reading it from a dll or otherwise?

> If the cpp class changes, I'd have to update the local version as well. But if you use c2nim you can run c2nim again should the cpp class change.

Nim 1.6.0 RC1

> Can we do the 1.6 release using old nimble before all of this is sorted out? Yes but is it that bad? All that Nimble needs to do is to update the Nimble directory itself, isn't it?

Can I somehow share a C++ class with Nim, either by reading it from a dll or otherwise?

The problem with that kind of solution is that it looks like I would have to locally do some of the class implementation. If the cpp class changes, I'd have to update the local version as well. Keeping these classes in-sync can become difficult as projects grow. I could flip it around and drive

Nim in Action

It's absolutely still worth reading, I still use it for reference from time to time. I hope there will be a rewritten version in the near future- but for the time being here is a reference for things that have been updated since the book came out:

Nim in Action

Just a stupid question: is it still worth reading Nim in Action and in the possible future there will be a rewritten version of this latter?

db_sqlite prepared statement

I'll give it a try. Thanks.

db_sqlite prepared statement

just wrap it this way: proc sqlite3_db_handle*(para1: Pstmt): PSqlite3 {.cdecl, dynlib: Lib, importc: "sqlite3_db_handle".} Run

Nim 1.6.0 RC1

Can we do the 1.6 release using old nimble before all of this is sorted out? The change is too breaking, so maybe it is a good idea to first figure out how to deal with it and then update nimble in one of the patch updates? People who want to try out latest nimble can always do `nimble install n

Building Nim Devel on Termux (Android)

For the record I _have to_ apply the following patches to build Nim devel on Termux(Android) --- build_all.sh.orig 2021-09-17 11:10:48.041226309 +0200 +++ build_all.sh2021-09-17 11:11:33.081226277 +0200 @@ -11,7 +11,7 @@ . ci/funs.sh nimBuildCsourcesIfNeed

Can I somehow share a C++ class with Nim, either by reading it from a dll or otherwise?

See my answer to this thread: You can also see [here](https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-importcpp-pragma) for the section in the manual.

Might be a bug in compiler

The idea was to show the complete case implemented and failed. Especially that there's several different ambiguous calls depending on what lines are going after what are generated. Sorry for a big dump of code.

Might be a bug in compiler

type ConnectionRequest* = ref object of RootObj ConnectionStrBool* = distinct bool ConnectionSetRequest = ref object of ConnectionRequestT[ConnectionStrBool] ConnectionRequestT*[T] = ref object of ConnectionRequest proc execute*(req: ConnectionRequestT[bool]) = disc

"No handles or timers registered in dispatcher" in Chapter 3.17 example of Nim In Action

You've advised me to do so in my bug report somewhere. I don't really understand why there should be a 100% CPU usage while waiting for callbacks to fire? Neither asyncio python, nor even 2.7's twisted and tornado main loops never caused 100% cpu usage when waiting for callbacks. We're awaiting

Might be a bug in compiler

`type Connection* = ref ConnectionObj ConnectionObj* = object of RootObj ConnectionRequest* = ref ConnectionRequestObj ConnectionRequestObj* = object of RootObj ConnectionStrBool* = distinct bool ConnectionRequestT*[T] = ref object of ConnectionRequest ConnectionSetRequest = ref object of Conne

Might be a bug in compiler

Minimizing code before asking for question does **really** help when others try to solve your problem ... at least out pure pragmatism - debugging 124 lines is easier than 23, so more likely to get an answer import std/[asyncdispatch, times, options, strutils, sha1] type

Might be a bug in compiler

Seems that there's a bug in compiler while compiling code heavily using generics. Look at the sample code: The ambiguous call error message is in different compile cases is different. I've had the error message that there are conflicts in system.string and

high precission -> f1024

Article about f8: / i've used a c source to support **f16** as a cshort, directly embedded it w/emit and coded a basic wrapper in terms of performance it's about 15% slower th

Weave+ARC WIP or my bug?

> I'm very confused about how to avoid threadvar, if I understand you > correctly. It sounds like global ID won't be unique, and threadvar is similar > to using global ID. So with Weave, how is thread-local memory achieved? For > instance, each thread having a global counter for something. Avoid

Can I somehow share a C++ class with Nim, either by reading it from a dll or otherwise?

I am completely new at the Nim language so pardon my ignorance. I tried to google this and search through docs, but I didn't see anything definitive. I saw a post related to this but it was from 2014 and thought maybe something has changed since then. In my particular case I have a simple class