See
[https://github.com/nim-lang/Nim/blob/master/lib/system.nim#L438](https://github.com/nim-lang/Nim/blob/master/lib/system.nim#L438)
and
[https://github.com/nim-lang/Nim/blob/master/lib/pure/os.nim#L137](https://github.com/nim-lang/Nim/blob/master/lib/pure/os.nim#L137)
for example
Nim can be Haskell This is an example from the real project. This code reads
application config from json with defaults handling in functional style. It
uses `data` macro from the `nimboost` library to generate immutable data
structures, constructors, `copy` operators, and functional types and
Wow, didn't know about syntax skins. This feature needs to be documented
What do you think about the possibility to specify syntax skin described in
external nim source? This can be used like the reader macros in Lisp or like
readtables in sweet.js
@Krux02, thanks, that's it!
How can I get generic parameters of ref object in this example?
import macros
type A[T] = object
x: T
type B[T] = ref object
x: T
macro genConstructor(`type`: typed): untyped =
let t = `type`.getType[1]
if t.typeKind == ntyGenericBody:
> We will introduce you to the compiler internals, garbage collector internals
> and anything else that may be required to work on Nim.
@dom96, please record these introductions in some form and publish them. It
will be the great help for newbies
Interesting. I got the results above on Ububtu 16.04. Rechecked on Windows 8.
The problem is that SyncClient test is so slow only on linux! And it's faster
then DeprecatedAPI on windows.
Debugging shows that it hangs for some time here:
I don't want to file an issue, because maybe the problem is in my code. Below
is the minimal test (also available [as
gist](https://gist.github.com/vegansk/8d4126fa5205f1d86145891b02467f46)).
So, the problem is that if I use deprecated API from httpclient, I get maximum
performance while
@andrea, see this log from gitter
Anatoly Galiulin @vegansk Nov 30 17:03
Hi to all. It was a long road back to Nim I have a question about
generic-concepts branch
(https://github.com/nim-lang/Nim/tree/generic-concepts). Is it dead? GitHub
says "836 commits behind devel".
@Araq, can the search be optional? For example, I don't need it here:
[http://vegansk.github.io/nimboost/docs/0.3.0/boost/data/rbtreem.html](http://forum.nim-lang.org///vegansk.github.io/nimboost/docs/0.3.0/boost/data/rbtreem.html)
While working on PR
[https://github.com/nim-lang/Nim/pull/4683](https://github.com/nim-lang/Nim/pull/4683),
I found some different naming schemes in I/O while working with buffers. For
example:
* `readBuffer/writeBuffer` in system.nim, asyncfile.nim (from PR)
* `recv/send` in net.nim
*
@endragor, I agree about the endianness problem. For now, `asyncstreams` copies
API from `streams`. Next, we can add BE/LE functions to the both these modules
to unify the API.
@endragor, here it is. And it's not for network lib, it's from my new library
`asyncstreams`.
@Krux02, `seq[byte]` deals with GC. And If I need to implement readInt for the
stream for example, first of all I'll read seq of sizeof(int) bytes and then
`copyMem` them into result. Too much overhead. I need the pointer and size pair
to remove that overhead.
Now there are another questions about current asyncdispatch implementation :)
1. Isn't it a leak here:
[https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncdispatch.nim#L835](https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncdispatch.nim#L835)?
GC_unref will be called only if
Thanks to all, I got it.
I agreed with @_tulayang, we need both low and high level APIs.
@dom96, you are the author of async libraries, don't you? Maybe you can help me
with it. Here is my experiments with it:
[https://github.com/vegansk/Nim/tree/async_buffers](https://github.com/vegansk/Nim/tree/async_buffers).
I don't want to create the PR right now. Here is the problem. The
What is the reason to use the `string` as the buffer to send data and
`Future[string]` to receive data asynchronously? And it's the standard for
asyncdispatch, asyncnet and asyncfile. For example, synchronous API works with
strings and with data pointers. So, is it related with interoperability
Wow, cool! Thats what I wanted to do in the nearest future :) But I want to
create this tool as a Nim macro that imports .d.ts files at compile time
@_tulayang, I think that `asyncstreams` must implement generic streams, not
http. And API that you suggest can be implemented in asynchttpserver or another
http related module, but not in generic streams.
More opinions?
WIP is here:
[https://github.com/vegansk/asyncstreams](https://github.com/vegansk/asyncstreams)
I created the fork of asynchttpserver for the test:
[https://github.com/vegansk/asynchttpserver2](https://github.com/vegansk/asynchttpserver2)
where you can read entire body using `request.body.readAll`, get the length of
the request without reading it via `request.body.len`. And the main
Request body is readed in memory at once. So, we can't receive big `POST`
requests. Maybe we can introduce new type, `RequestBody`, that can be used to
get body as a string/file/stream/whatever, or maybe even handle
`application/x-www-form-urlencoded` or `multipart/form-data mime types`?
@alexsad, you can do it using low level bindings (jnim.private.jni_wrapper)
from jnim library for now, but it's no good. I'll make high level API for that
ASAP.
moigagoo, did you try this?
[https://github.com/vegansk/nrpl](https://github.com/vegansk/nrpl)
25 matches
Mail list logo
