downloading big files

This is something related that !Patitotective and I have been talking about on discord. I think that there could be a better way to recv data from httpclient. Welcoming anyones brain power to help with this Currently httpClient.bodyStream is Stream | FutureStream[string] which means you can ac

Nim packages dependencies visualizations

It is updated but sums all versions

Nim packages dependencies visualizations

Changed mindmap to digraph

Nim packages dependencies visualizations

Added both forward and backward list

downloading big files

I also noticed that pipeTo has no effect on MaxRSS. httpclient.nim: when client is HttpClient: result.bodyStream = newStringStream() else: result.bodyStream = newFutureStream[string]("parseResponse") ... when client is AsyncHttpClient: client.b

downloading big files

I need to download big files and I have this code: proc pipeTo(input: Stream, output: Stream, chunkSize = 512) = var buff = repeat("\0", chunkSize) while true: let len = input.readDataStr(buff, 0..https://i.imgur.com/7DBlgbw.png) In theory, it should download a ch

how to update macro nim1.2 to nim1.6.6?

This is a known issue.

how to update macro nim1.2 to nim1.6.6?

Elegantbeef helped me out to determine a smaller actual MRE. macro DefineAndInstance = genast(): type MyObject = object var myParams* = MyObject() Run Error inconsistent typing for reintroduced symbol 'myParams`gensym1': previous typ

streams and memory usage

I have this code: proc pipeTo(input: Stream, output: Stream, chunkSize = 512) = var buff = repeat("\0", chunkSize) while true: let len = input.readDataStr(buff, 0..

Carbon lang

I'd actually rather write C++ than Carbon, but then I don't know the language well. C++ is evolving rapidly these days, to be safer and more usable. You don't have to use the subset of C++ that isn't safe.

how to update macro nim1.2 to nim1.6.6?

I have this macro that seems to work in older versions of Nim. What am I missing? Nim complains of `inconsistent typing for reintroduced symbol 'paramsGlobal' previous type was: object; new type is: object` MRE below, where the macro creates a new type, then instances that type with `var`. My a

Nim packages dependencies visualizations

This should be built into nimble.directory! Would be great to see a PlantUML link on every package's page. Nexus doesn't use many dependencies, most seem related to Chronicles:

Carbon lang

> I think the original question is worth considering. If Nim can wrap Carbon > easily, it could be a faster gateway to 100% C++ compatibility. Or even better: Lets ditch Nim and switch to Carbon. After all, it's from Google, it's got electrolytes :)

Nim packages dependencies visualizations

Nice! Though it seems slightly outdated, did you grab an older choosenim? Choosenim hasn't depended on nimterop for a long while now.

Implement api rate limiting with jester

Yeah, we need manual docs for this stuff.

Carbon lang

If Carbon can wrap C++ really well, perhaps Nim could wrap Carbon easier than C++?

Nim packages dependencies visualizations

Please ;-) Ok, I have bias on this feature request. Since I did for myself.

Implement api rate limiting with jester

Because "before" is not a proc or template or macro, it is a special name reserved for the untyped routes macros=>

Implement api rate limiting with jester

Also it'll be nice if we could get a full documentation of the jester routes macros without having to read the code

Implement api rate limiting with jester

Ok, thanks. For some reason Nim doc failed to generate proper docs on the routes macro in general it doesn't usually generate proper docs for macros so I couldn't find this in the jester docs.

Carbon lang

I still believe Nim's killer use case is becoming the go to language for up C++ in a C ABI. It's annoying how much useful software is currently locked away in C++, eg. Tensorflow, Qt. The good news is Nim 90% there, the bad news is 90% remains.

could javascript backend make use of new javascript ES6 module support?

> So once WebAssembly can call the DOM directly, you would consider Nim's > JavaScript support unnecessary? I would love to say "yes" but there is a gigantic amount of JavaScript code out there that we can interface with quite easily thanks to the JS backend.

Carbon lang

If Carbon stays focused on becoming what TypeScript is to Javascript but for C++ then it will do very well. Nim may have good C++ interop but it's not focused on that, Carbon seems to be specifically focused on making a transition from a C++ code base to a easy (and there is a lot of C++ develo

could javascript backend make use of new javascript ES6 module support?

So once WebAssembly can call the DOM directly, you would consider Nim's JavaScript support unnecessary?

Implement api rate limiting with jester

You don't need middleware for this. You can create a route that runs before all requests (or all requests under a specific sub-path), for example: . So the following should work for you: before re"/*?": if ra

could javascript backend make use of new javascript ES6 module support?

The macro facilities of Nim seem very impressive. So maybe ES6 module support can be done simply as a Nim library, along the lines you describe here? My main concern here is not to duplicate generated code: If I make two modules in Nim, A and B, and A imports B, and B imports A, then of course t

Ctrie in Nim for concurrent iterators?

So let's assume that you iterate over every entry in a list and compute something simply like a `sum`. While you iterate new entries are being added. Since it's threadsafe and lockfree there is no real bug here, the linked list supports this traversal. But what are the actual semantics? You comp

Ctrie in Nim for concurrent iterators?

> Controversial opinion ahead: All this lockfree stuff is so severely limited > and error-prone and hard to reason about that it's to be avoided at almost > all costs. I'd be disappointed if you didn't. ;) Generally I'd agree with you about lock's being simpler and better. The use case on my m

could javascript backend make use of new javascript ES6 module support?

You can make an ES6 module in Nim easily. proc sayHello() {.exportc.} = echo "hello" proc sayGoodbye() {.exportc.} = echo "goodbye" {.emit: "export { sayHello, sayGoodbye }".} Run

could javascript backend make use of new javascript ES6 module support?

Because WebAssembly does/did not support the DOM which makes all the difference.