How should system library support be structured?

You're right that we have no guideline but the following is the guideline that we should have: # Forward declarations that describe the interface proc featureA*() {.tags: , raises: , gcsafe etc.} ## Documentation proc featureB*() {.tags: , raises: , gcsafe e

generating dll with nim

i have been installed MinGW . This error only occurs when compiling the DLL, not other programs

How should system library support be structured?

The latter method you described is how I personally handle it as it properly uses `module`s to be `modular`. You describe a required API that modules must meet and use them that way.

How should system library support be structured?

Right now the standard library and how it connects to the actual OS primitives a mix of different approaches. Let's look at a few examples. lib/pure/os.nim, sleep proc sleep*(milsecs: int) {.rtl, extern: "nos$1", tags: [TimeEffect], noWeirdTarget.} = ## Sleeps `milsecs` milli

Struggling to understand `asyncjs`'s `PromiseJs`

The closest experiment I get to is: # nim js -d:release -d:nodejs -r tmp.nim import std/[jsffi, asyncjs, dom, strformat, sugar] type Data = JsObject proc newFileReader*():EventTarget {.importcpp:"new FileReader()".} proc getResult(reader:EventTarge

Struggling to understand `asyncjs`'s `PromiseJs`

I am playing with a javascript library. I am struggling to convert the following function to nim: function readBlob(blob) { return new Promise((resolve, reject) => { const reader = new FileReader(); reader.addEventListener('load', () => resolve(reader.

nim-pipexp

This also seems an interesting library. It should be useful for functional programming style.

Return value for joinThread?

> What's the "old ways" of threading? Haven't you see benchmarks, where > creating and joining threads >was slower than single threaded? None ever done > it that way. If you have a long running thread and >don't want to use a > threadpool then the solution is to use a synchronization primitive.

Return value for joinThread?

What's the "old ways" of threading? Haven't you see benchmarks, where creating and joining threads was slower than single threaded? None ever done it that way. If you have a long running thread and don't want to use a threadpool then the solution is to use a synchronization primitive. There are

Return value for joinThread?

> Ive done this but I'm not sure it was worth the trouble, it's just separating > the discriminant from a >discriminated union. > > Even in the pointer case, what's the thread going to give you? A pointer to > something on it's stack or >on its local heap? No thanks. I was thinking more an alig

nim-pipexp

Also from the same author

Set Length Seq

Agreed. See also which could maybe be fleshed out/fixed up.

Return value for joinThread?

Seems to me that you use "createThread" when you want to use a "spawn".

Naylib - yet another raylib wrapper becomes available

I did quite a few changes for naylib 1.10, and I am quite happy to share them with you: * The written from scratch and untested on other platforms, build system was removed. Instructions for using the library are now crystal-clear. Just `nimble install naylib`. The only downside is, cloning t

A question about random returns

You can write your code into the playground at than pasting the link generated we can check your code

A question about random returns

Try formatting your code and posting a complete minimal reproducible example, otherwise it's hard to help you

A question about random returns

Sorry, reading better seems you did use `randomize` was at the beginning of the module?

A question about random returns

I guess you missed to call `randomize` #from https://nim-lang.org/docs/random.html import std/random # Call randomize() once to initialize the default random number generator. # If this is not called, the same results will occur every time these # examples are run.

A question about random returns

proc RandomImg(ctx: Context) {.async.} = let images = [ 1.jpeg", "2.jpeg", "3.jpeg", "4.jpeg", "5.jpeg", "6.jpeg" ] let pick = sample(images) doAssert pick in images resp "" I'm using the random library to do a function that returns a random image but when I use randomize() and initRan

A new way for Nim to shine ? Faster than NodeJS interpreted Nim, taking advantage of declared types

Python users will not jump to something faster than python if this does not mean 100% compatibility with existing packages, just look at PyPy. Nim already can be included in python projects by using . Nim has it's place, we just need to grow the context around

A new way for Nim to shine ? Faster than NodeJS interpreted Nim, taking advantage of declared types

Personally, using python, my biggest concern is to have too much runtime exceptions due to absence of typing. Anyway what you ask could be covered by incremental compilation which as far as I know is already a priority and core developers are working hard on it.