`=destroy` ref object of RootObj?

I think it would be enough to place the destroy hook before the first usage of the `TextBox` type. Essentially as Nim reads through this it sees that it needs a destructor for that type, sees that it doesn't have one, and creates one implicitly. Then it encounters yours and fails because it alre

Do I need to call NimMain from C if I am using arc or orc?

Yes and no. In the past `NimMain` was very important to call because it is what set up the garbage collector. With ARC however that is no longer the case. But `NimMain` does another quite important thing, namely initializing (some) global variables. Some libraries might have global state that ne

System.sink & System.lent

@exelotl, @ynfle, Thank you for your explanations.

`=destroy` ref object of RootObj?

I don't think the GC has anything to do with `ptr` or `pointer`. They're simply untraced. The error message says `=destroy` is constructed at line 14, where `TextBox` is. Maybe `=destroy` should be defined before `TextBox`?

What is Data Science?

Data science continues to evolve collectively of the foremost promising and in-demand career ways in which for skilled professionals. Today, prosperous knowledge professionals perceive that they need to advance past the standard skills of analyzing massive amounts of data, processing, and progra

`=destroy` ref object of RootObj?

That does appear to work, but I'm running into an issue trying it for my particular use case: Why would there be an implicit construction of the `=destroy` hook, perhaps because `Image` is a `ptr object` or `Font` is a `pointer`? Even if that's the case, how would I gain control of the deconstr

Issues with proxy authentication

What version of Nim are you running?

jsFetch fetch

Hello, I am experimenting with js fetch API in Nim language (devel, jsfetch is experimental). proc ajaxOptions(metoda: HttpMethod = HttpGet): FetchOptions = let headers = newHeaders() headers.add("key", "value") result = newFetchOptions( metod

`=destroy` ref object of RootObj?

I do not know if this is the proper way of doing it but the following does work. type FooObj = object of RootObj Foo = ref FooObj proc `=destroy`(foo: var FooObj) = echo "Destroy" var foo = Foo() Run

System.sink & System.lent

The different between inheriting from `RootObj` or `RefRoot` and from a base object, is the 2 object hierarchies that both inherit from one of the system define roots can interfere with each other. . In this example `A` and it's "siblings" may be the intended

problem when casting string to cstring on js backend

Maybe `proc toJsString(s: string): cstring {.importjs: "String.fromCharCode(...(#))".}`, since strings are arrays of bytes in JS. Not sure if it would convert flawlessly back to string though.

`=destroy` ref object of RootObj?

I have not found a way to create a destroy hook for objects that inherit from RootObj (or even futher down an inheritance hierarchy): type Foo = ref object of RootObj proc `=destroy`(foo: Foo) = discard Run Is there a way to accomplish this? * * * For

problem when casting string to cstring on js backend

So is there any other way to convert to cstring? Probably just by importing concat method and building the cstring manually from chars or something? > Don't know why you want to convert to cstring here though. the problem arrived in a server-client webframework Im developing. and for automatic

{.nodecl} VS {.importc, nodecl} and return VS result

It was my preferred way of getting value out of **emit** body to nim side. That was working with global variables for me and using it in local scope seemed not against the rules of the Manual. Now with your help i know how it works in reality, so I must use another way (declare variable before

problem when casting string to cstring on js backend

JS strings (cstrings) are UTF-16, which means the cstring `items` iterator which returns chars needs to deal with UTF-16 on the JS backend somehow, since they can have "characters" bigger than Nim's `char` type allows. My guess is this is where the difference happens, but I am not sure if the cs

Do I need to call NimMain from C if I am using arc or orc?

I am trying to implement the libretro(1) api for a very simple game I made. This document (2) mentions that I have to initialize nim using NimMain. I just don't know exactly where to place since the library will be called by retroarch. Any suggestion? 1.

runnableExample considered harmful / good feature to deprecate before 1.0?

Personally I think runnableExamples make Nim harder to learn for newcomers. When viewing docs I would much rather read: > **Example:** > > > echo some(42).get # prints 42 > echo none(string).get # error! raises UnpackDefect > > Run instead of: > **Example:** >

why multithreading execition take time almost equal to single thread execution?

Thx for your example. It's like middle level of handling futures. Is where any high level Nim API for handle futures? Like this in Python: ... with ThreadPoolExecutor(thread_name_prefix='Transport', max_workers=20) as executor: executor.submit(self.delman

{.nodecl} VS {.importc, nodecl} and return VS result

You cannot `nodecl` a local variable indeed. But I don't know why that would be useful.

{.nodecl} VS {.importc, nodecl} and return VS result

as for **return** vs **result** , i found the difference in generated c code. new scope is created when using **return**. example: int i; ... { // < this int i; ... goto BeforeRet_; // < this }BeforeRet_: ; // < t

problem when casting string to cstring on js backend

> A serialization library usually has no special logic for UTF-8, it just see > strings as raw bytes. yes i know, I thought that is the problem, that js tries to make the string into valid utf8 or something, which it isnt. > However int8 can store up to 127 and beyond you need int16 yes but a

{.nodecl} VS {.importc, nodecl} and return VS result

but Manual says: > The nodecl pragma can be applied to almost any symbol (variable, proc, type, > etc.)

problem when casting string to cstring on js backend

A serialization library usually has no special logic for UTF-8, it just see strings as raw bytes. However int8 can store up to 127 and beyond you need int16.

{.nodecl} VS {.importc, nodecl} and return VS result

nodecl/cdecl/fastcall/nimcall are **function** calling convention. They are not for variables. **nodecl** main use-case is to wrap compiler builtin functions that are not defined in any header.

System.sink & System.lent

I can at least explain the `{.inline.}` pragma: Say I have two Nim files: # foo.nim import bar proc getNum*(): int = add(10, 20) Run # bar.nim proc add*(a, b: int): int = a + b Run Each `.nim` file is compil

runnableExample considered harmful / good feature to deprecate before 1.0?

Sorry for necrobumping, just wanted to note that [best practices](https://nim-lang.github.io/Nim/contributing.html#best-practices) paragraph from contributing guide recommends **assert** for runnableExamples currently: > An exception to the above rule is runnableExamples and code-block rst bloc

C++ interop via Dynamic Library

Maybe Im missing something, but I was already using dynlib and it does require the extern "C" prefix on the Cpp header which implies FFI. Im looking for something like it's shown here: () A pure C+

{.nodecl} VS {.importc, nodecl} and return VS result

Sorry for bringing confusion and for being so unclear with describing the issue. To understand what I mean let's stick to " **nodecl** " pragma. (we don't need to discuss "backticks" or "emit array" because they are serving a different purpose.) Manual says, "It tells Nim that it should not gen

Impure libraries ???

hello, how can we see what V2 will be please for example for sqlite

why multithreading execition take time almost equal to single thread execution?

Sorry, there's a typo in line 11: the first arg to `splitToTerms` should be `n-i`, not `n-1`. Unfortunately, the time limit for editing the post has passed. Correct program runs faster. Regarding your other question, I suggest you use `getMonoTime` instead of `cpuTime` in threading situations.

problem when casting string to cstring on js backend

Hi, I want to cast a string generated by flatty (a serialization lib) to a cstring. But when the string contains a char with value over 127 the string gets completly wrong. I guess that has something todo with chars over 127 normaly indicating the beginning of a utf8 char, but not being a corre

System.sink & System.lent

I don't want to put aside what I don't understand, but to learn it rather 🥺🥺🥺

why multithreading execition take time almost equal to single thread execution?

it's executed more than 2 minutes for me, so i escape the execution.

why multithreading execition take time almost equal to single thread execution?

^ - block current thread before receiving result/control of/from spawned proc. If so, i must have consecutive execution. Why then time template return 0,986s for threaded(n)?

System.sink & System.lent

If you have to ask, don't use `.inheritable`. An `.inline` proc is a proc that is inlined. If you have to ask, don't use it. The Nim manual has enough details but it doesn't try to reinvent Wikipedia.

Memory leak

Thank you for sharing! It solved the memory leak for me! It is a halpful thread.

Memory leak

Thank you for sharing! It solved the memory leak for me! It is a helpful thread.

System.sink & System.lent

Sadly, it is still very hard to understand some things in Nim documentation, because the information is scattered and difficult to search. I would like to know for example : * What is the difference between declaring my type as a `ref object of RootObj` and declaring it as inheritable (with a

C++ interop via Dynamic Library

This should be helpful:

C++ interop via Dynamic Library

Hi guys, Im trying to integrate Nim into an existing C++ application via a dynamic library. I got it working via FFI I was wondering if it could be possible to make it work without FFI, like if the Nim dynlib were an actual C++ dynlib (which it actually is). If so, how the process would be? I