Hi,
Given two templates splitre() and splitnre() which are almost identical
import strutils, re, nre
proc makeDiscardable[T](a: T): T {.discardable.} = a
template splitre*(source: string, dest: untyped, match: string): int =
when compiles(dest):
You can share a Nim source file containing only the procedure headers. What the
body of those procedures should be is up for debate. What comes to mind is
leaving the body empty and specifying a `importc` and `dynlib` pragma which
imports a Nim DLL built by you.
Something in the language to mak
Thank you for taking the time to write this up. Unfortunately I don't have any
suggestions on what we can do to improve the current situation.
> The solution? Prefixing or more-explicit-but-far-less-obvious naming. This is
> exactly what's happening in Julia (which shares a lot of concepts with
> This invariably ends by Araq stating that there is no problem since an IDE is
> just the right tool to code.
Well to encourage further discussions: If a decent proposal arrives, I am
willing to accept and even implement changes.
I have a question about following Nim compiler/language use case: suppose, I
created a library and want to share it's functionality with others. But, I do
not want to share the source code, but just a binary distribution plus an
interface. This use case can be solved by creating a C-header file
As I understand it, Nim's development has always been done with tooling in mind.
This has some wonderful advantages: uniform function call syntax, awesome IDE
support built-in, unobtrusive syntax, convenient import system, etc. All of
these would not be possible without proper tooling in the fir
@dom96
By the way, I think event-driven models are useful for plug-in programming. How
about adding events to asyncdispath and asynchttpserver? Such as :
proc handleError() {.async.} =
await sleepAsync(1000)
echo "handleError"
proc handleRequest(req) {.async.} =
I started this project with the following assumptions:
* use libuv (or something similar) to avoid having to support code for every
platform (this is really important, I don't want to test everything on >3
platforms even when making small changes)
* have API as clean as possible.
I don't
I really appreciate your efforts but I must ask, why did you decide to write a
new library instead of helping improve the standard lib async modules?
My fear is that we will end up with 30% of libraries supporting reactor.nim,
40% of libraries supporting stdlib async and 30% supporting async fut
> I think is very unethical.
It's not "unethical" at all. The thread had nothing to do with Nim and only
does Nim harm.
> In the hacker culture, you should be judged by your work and your work alone.
And what work was shown in that thread? Never mind, I'm quite familiar with the
inconsistencie
@Krux02 That sounds like a good idea; certainly something worth looking into.
Well, `filter` samples until a condition is true.
Where conditions on a _different_ random variable. It does exactly what you
say: it samples from p until the condition in true, then return what g samples
in that point.
The example above is really artificial, since the two random variables are
Thank you! Right now
[Rosencrantz](https://github.com/andreaferretti/rosencrantz) is based on the
stdlib HTTP server, but I have been wanting to base it on something
multithreaded for a while
There is no direct compatiblity with standard async, but porting code from
stdlib should be easy (many features have similar syntax).
Currently there is support for running tasks in a thread pool, but the tasks
can't use event loop at all
([https://networkos.net/nim/reactor.nim/doc/api/reactor/
Ok, I looked at it, and I do not really get what `where` does. All I got was
that it samples from `p` until the condition is true, but then as far as I can
see it does not use that value.
Does reactor support any kind of compatibility with the standard async?
In particular, there is the module `asynchttpserver`: how hard would it be to
port it to reactor?
As a second question: what, if any, is the interaction between reactor event
loop and threading? Would it be possible to buil
Hi, I just wanted to mention that I have just published
[Alea](https://github.com/unicredit/alea), a library to work with random
variables.
It is still in a pretty early stage, and some things may not work very well,
but this is an example of use:
import alea, future
import ra
This would be extremely cool!
There was [some discussion](http://forum.nim-lang.org/t/937) on the forum about
multiple modules per file, which could give some of the same advantages. And
source-files archives treated as folders exist yet for Java and PHP (.jar and
.phar).
# The question is
* (what is it)?
* should Nim have a vfs?
and part of answering the above question
* is it a Nim way of doing things
* if so, should it be part of stdlib or a nimble package
# What is a vfs
* packaging multiple files into an embedded or archived file (zip, tar, b
I looked into your collections library, and I saw your View library. I have my
own implementation of the same thing
[here](https://github.com/krux02/opengl-sandbox/blob/master/glwrapper.nim#L8).
Maybe it has minor differences, but generally it is the same thing. `openArray`
in parameters also s
20 matches
Mail list logo
