You shouldn't need to do that. Passing `--threadAnalysis:off` to the compiler
should work too.
We shouldn't forget about @miran's awesome work here. Big thanks to him for all
his work on scheduling, planning and organising this conference. It went
incredibly smoothly, the bar has been set very high for the next conf :D
See
[https://github.com/nim-lang/Nim/issues/14564](https://github.com/nim-lang/Nim/issues/14564).
TL;DR: As the error suggests, you don't have any IO operations or timers in
progress so the event loop has nothing to do and so you get this error (if you
didn't get this error your program would b
Nice! I must say, I do like that colour.
This is awesome! As someone that has used norm in a number of his apps now I
can attest to its quality, in fact I would say this is one of the gems in Nim's
ecosystem. Keep up the awesome work!
(And if you want a challenge, help us transition the NimForum to using Norm :D)
Oh, one thing, doesn't JavaScript use a similar colour? Can we see what that
looks like? @pietroppeter?
Nice, looks good. And in the meantime it seems GitHub's new design separates
these colours better.
> Did you have a chance to try out the new version?
Not yet, been having a bit of a break from Nim development lately. Hopefully
soon I'll have time to dive back into my projects and will be able to give Norm
2.0 a try :)
Yes the current file IO "async" implementation isn't actually async.
Please please tag new versions. It's not enough to just bump the version in the
.nimble file.
> Currently I'm using Nim on an ESP32 with posix.select for a custom TCP
> protocol.
Have you given the selectors module a try? It should provide an even nicer API
on top of the raw POSIX select.
Indeed, this is hackish. Frankly I think this is a Nim bug. Not being able to
spawn a procedure that returns a non-ref is an annoying limitation, I'm
guessing there is a good reason for it though. Maybe @Araq can explain.
Nice!
The aim of nimkernel is to provide a simple base for people who want to build a
kernel, I think all these things you've added are going a bit beyond that. It's
much easier for newbies to understand something like what nimkernel is now than
all these extra bits which they might not be awar
This is an awesome idea. There is a lot of places where mentioning Nim on WP
will drive people to notice it.
Please keep things simple though. I've modified what you've added to not
include mentions of UFCS and case insensitivity, IMO it's not relevant.
> The languages are pretty close in all the other aspects though, and I run
> into async/await situations a lot. So, that's why I've been using Nim lately.
Yay! Awesome to hear something I've implemented is pushing people towards Nim.
Happy to help with any problems you run into btw, feel free t
Yeah, it's about time we change this to a nicer error. I updated the examples,
thanks for flagging @Akito.
@mratsim By the way, **never** use `waitFor` in async procs. You should use
`await` instead.
yeah, that's a current limitation. You should either use `ref` or
`FutureVar[T]`.
You should put your data into an object and then pass it around your procs.
Don't create "global" state and capture it in closures.
Here is what I mean (probably doesn't compile, but I hope you get the idea):
import redis, asyncdispatch
type
MyState = ref object
Whoa. That's a surprising reaction. I think you might be missing something
significant about how async works to think that.
> Sadly, your example does not work for me, even with tweaks, as the most
> important part proc newMyState cannot work, as it couldn't be able to return
> anything else as
Yeah, honestly I don't see this helping D's popularity all that much. It
certainly doesn't hurt, but let's not panic or make it our goal to do the same.
The most impactful way to increase Nim's popularity is to _write about it_ and
_talk about it_ at conferences and with colleagues and friends.
For reference, some more discussion about this here:
[https://github.com/nim-lang/Nim/issues/11058](https://github.com/nim-lang/Nim/issues/11058)
And quoting @Araq from my conversation with him directly:
> it's 'type' for type sections, 'typeof' for typeof and 'typedesc' as the
> metatype for t
I really love that you guys have enabled testing of Nimble packages in CI.
That said, it seems to cause a lot of noisy failures. I also don't think
running it on every single commit is necessary. So I propose you split these
tests into a cron-like job that runs every day or every 6 hours (or wha
In case it's helpful, here is an example from my book showing how to process
large files in parallel:
[https://github.com/dom96/nim-in-action-code/blob/master/Chapter6/WikipediaStats/parallel_counts.nim](https://github.com/dom96/nim-in-action-code/blob/master/Chapter6/Wikipedia
> Just replying because that logo had me rotfl for about a minute.
This. That logo is wonderful, I love it. Great job @johnconway! :)
That last image looks pretty nice, are you working on some nice slides for Nim?
or some promotional material?
I wonder how close we can come to this via the libraries we do have. The
resemblance to Nim in that image is amazing.
That error message means that `sendTo` return `void` (i.e. no value) so you
discarding it doesn't make sense. Just remove those discards and it should work
(also update the docs if you can).
> Topmost page should not contain too much text and too much details. And no
> unknown terms.
Agree with you here. In fact, I made a similar remark in the PR:
[https://github.com/nim-lang/website/pull/150#issuecomment-496166378](https://github.com/nim-lang/website/pull/150#issuecomment-496166378
I use fontawesome on this forum (which uses Karax) and it works fine (for
example
[here](https://github.com/nim-lang/nimforum/blob/5714ad0c6aafcd7b95a433d97f7b4069d5cc791b/src/frontend/threadlist.nim#L75)).
It's possible that something changed between fontawesome versions or karax
versions. Do
Nice! Thank you for writing this :)
Please consider using 2 spaces for indent though. Would make the code far more
idiomatic
I think you need to set appropriate headers, doing so in Jester is trivial
(didn't test this but should work):
routes:
get "/":
resp Http200, {"Access-Control-Allow-Origin":
"http://www.example.com"}, "Content"
Run
(Source:
[https://en.wikipedia.org/wik
How so? I see Scala in JSON serialization as being #1.
> Rust is also close to winning "JSON serialization" (99.1% of the winner).
So... not the "absolute dominant champion in every category..." then, this was
my point and I did look at your "now" link.
Nim really isn't that far behind. I don't have time, nor the will to optimise
httpbeast even fur
> Rather than catching this exception the app just stops, goes silent for 10+
> minutes and then quits with the below.
Which exception do you mean? The SslError or the SIGPIPE. I'm assuming the
latter since the output implies that you've caught the SslError successfully.
This SIGPIPE shouldn't
> These fixes will either be accepted for 1.1.x or for 2.0.x but IMO they
> shouldn't be backported to the 0.20/1.0 branch. 1.0 should be bug-compatible
> with what we have.
Let's be really specific here, because writing "1.0 should be bug-compatible
with what we have" is ambiguous. Do you mean
Since nobody else is doing it, I'll be the one to write this forum thread.
Nim v0.20.0 is here, if you have been living under a rock the release article
is here:
[https://nim-lang.org/blog/2019/06/06/version-0200-released.html](https://nim-lang.org/blog/2019/06/06/version-0200-released.html)
;)
> as one who has tried to use the current GC's system cross thread
@GordonBGood what sort of tasks have you attempted to do using the current GC
across threads? I'm curious what pain points you've experienced and whether
there is something we could do to fix them (that don't involve reworking ho
The Nim command window? Are you double clicking nim.exe and hoping the command
prompt stays open?
If so, don't do this, run cmd.exe and run nim from there.
This means my code is broken too:
[https://github.com/nim-lang/osinfo/blob/master/src/osinfo/win.nim#L243-L245](https://github.com/nim-lang/osinfo/blob/master/src/osinfo/win.nim#L243-L245)
:/
Doubt it, this is something that should be implemented as a macro in a Nimble
package and then possibly adopted into the core if it sees enough usage.
> Have a different process setup, some "supervisor" process that calls Nim and
> Python processes that then should die more frequently in order to return the
> memory.
This seems like the best workaround if your process architecture allows it. Can
you have your server spawn a process that does
Please consider including the topics discussed in the title of the video
instead of just writing "Nim Development Blog ".
> Nim´s one is more like in node.js (I think). If you process large chunks at
> once or a endless loop is placed inside you will break your entire system...
No idea what you mean here exactly, but it sounds wrong.
> A vocal portion of the community has not bought into newruntime, or is
> keeping the GC for other reasons, but everyone has accepted async.
This. đź‘‘
Thank you for writing this. I've only skimmed it, but what I've read makes
sense in general. Keep in mind that we already have issues for most th
> Sorry to be cheeky, but, New Nim users (and programmers in general) need to
> learn the difference between concurrency and parallelism. :-P
Thank you! I'll be honest and say that I've actually learned this myself when I
was writing Nim in Action. This is also why I spend quite a bit of the boo
This is a great question and I thank you for asking it.
In relation to version 1.0 however, many of the answers here point to things
which I don't believe belong to a 1.0 release. For example, good debugging
functionality is an important feature but it isn't something that must be done
before 1
There is nothing wrong with asking in two places. Please don't criticize people
for doing, or at least not in the way that you're doing it.
It would be nice if the author added a link to Reddit and vice versa, but
otherwise there is no problem in asking in both places.
Indeed, @leorize is completely right from what I understand as well.
One thing I'd like to highlight is that I am in the same boat as you, I mainly
write high-level applications, GUIs, web applications, games (targeting
browsers), CLI utilities etc. So I have very similar concerns.
**I 'm afrai
The assertions are actually there to signal a problem in your code, don't turn
them off.
In your case, the code that's wrong is this:
let future = newAsyncHttpClient().getContent(url)
future.withTimeout(timeout).addCallback(proc() =
future.fail(newException(OSError, "HTTP timed
> @Araq knows this and the fact that current GCs don't play well
> multi-threading is also well known.
I would challenge this notion. Multi-threading in Nim currently isn't perfect,
but I disagree that this is due to the GC. We can improve its efficacy within
the confines of the GC. One feature
Sounds to me like you're patching over issues. You shouldn't do that. The
exception trace you've posted above actually suggests a bug in the stdlib, can
you create a small code sample that reproduces it?
You can try debugging this, just put some `echo`'s into
[https://github.com/nim-lang/Nim/blob/devel/lib/pure/httpclient.nim#L840](https://github.com/nim-lang/Nim/blob/devel/lib/pure/httpclient.nim#L840)
and/or other relevant functions. It will show you what the bottleneck is.
A good example is Nimforum. Here is how it implements a `navigateTo` proc:
[https://github.com/nim-lang/nimforum/blob/master/src/frontend/karaxutils.nim#L73](https://github.com/nim-lang/nimforum/blob/master/src/frontend/karaxutils.nim#L73).
You might also want to copy the routing from it:
[https
Jester is already multi-platform. Httpbeast will forever stay unix-only. I may
write a different HTTP server that targets Windows for fun, but I honestly
don't see the point, even Windows nowadays has WSL.
Yes, Windows Server is still a thing, but doesn't it support WSL nowadays too?
Is Windows Server really the best choice for a performant server anyways?
Does Python allow you to
_[import](https://forum.nim-lang.org/postActivity.xml#import) a module with a
hyphen?
> but the devel version (one between 0.20.x and 0.21/1.1) has 0.20.99 version
> number
What's the reasoning behind this again?
Even if this feature existed I would recommend against its usage, and for that
reason alone I think it's simply a waste of time to support it (both from Araq
or someone else implementing it, but also the loss of time that we will have to
suffer telling people not to use this or dealing with code
> I'm using FreeBSD which has an extra unsigned char called sa_len at the
> beginning of the struct. I don't know if this is contributing to the problem.
Try adding it and see if that helps.
By the way, since you're already messing around with UDP and async. Maybe you'd
be interested in impleme
You should be able to use this for clues:
[https://github.com/dom96/nimkernel](https://github.com/dom96/nimkernel) (it's
likely that things have changed since and that it's broken now)
TL;DR: try `--os:standalone`.
Sounds like you have a corrupted Nim install. How did you install it?
In this case I think a PR to get this done is fine, it shouldn't require much
changes. It'll be easier to discuss in the PR and be more efficient time-wise.
You might have better luck removing Nim and installing it using choosenim:
[https://github.com/dom96/choosenim#unix](https://github.com/dom96/choosenim#unix)
Yes, the problem is that `withTimeout` doesn't cancel the dataEvt future. So it
continues running even though the timeout occurred, eventually reads the data
and loses it since the withTimeout has long disappeared.
Yep, this is horrible but sadly async in Nim doesn't yet support cancelling
futu
I think it's great :)
I've modified your post to get rid of that gist you've embedded (a link is
enough)
> OK, what about deleting the client object from the global array? I would have
> thought that in this particular case other instances of processClient may
> carry-on looping through clients list via
As long as your loop doesn't have await then you're fine... but you shouldn't
be looping throug
> Note that Chronos supports future cancellation since v2.2.7, 3 weeks ago.
>
> I'm not sure how different the internals are from asyncdispatch at this point
> so it might be hard to naively port the PR.
It should be possible to port this, I might work on an implementation this
weekend if it tu
> And i don't recommend to use asyncdispatch because you will fall into lot of
> bugs, leaks and problems.
Please provide some links to these bugs, leaks and problems.
Asyncdispatch is the foundation of chronos. Sure, maybe you've fixed some edge
cases, but you've also broken the API and indeed
> Without cancellation asyncdispatch could not handle timeouts.
Chronos literally [didn't support cancellation until a few weeks
ago](https://github.com/status-im/nim-chronos/pull/41#event-2463927708). Are
you telling me you haven't been using it in production until just a few weeks
ago?
> Wit
Yes, `connect` raises when it cannot connect. I'm guessing you've been using
`asyncCheck` and trying to catch the exception by wrapping `try` around that...
you need to use `await`.
Try s/response/request in the code you've found, it might work. You will also
need to use `request.getNativeReq` to get the socket and to close it. (These
details are defined here:
[https://github.com/dom96/jester/blob/master/jester/request.nim#L5-L22](https://github.com/dom96/jester
I'm not aware of anyone that has done this, but I'm sure we can improve your
hacky approach to something that is less hacky and can be put into the Karax
repo to make these things better. Can you share your approach? :)
> we believe that for typical use they will be almost as easy to use as GC'ed
> references but without GC's downfalls in taking a huge development effort to
> reduce memory access wait time latency while supporting multi-threading/Some/
> believe that. Others like myself need to see this in prac
This isn't supported. Why not just launch a few threads instead? Why are you
forking?
Ideally you should avoid sharing sockets between threads, each thread will have
its own event loop, all you need to do is perform IO for each threads'
respective sockets there.
> I really, really want the "newruntime". This kind of mistake is way too easy.
This mistake is easy, but you really should reconsider mixing such low-level
code with your high-level scripts. Any use of addr, ptr, cast should be very
deliberate, the analogy to Rust's unsafe is very apt here. I'm
As long as you don’t compile with `—threads:on` then jester will run single
threaded (and the compiler will only report a warning).
To fix this to work with threads you should use a threadvar, and initialise the
DB connection in each thread.
> Ah, but that gets me back to 2 seconds delay per page.
That should only be the case for the first request per page.
You can use `cd V:/src/anygui && nimble develop` (well, might have to change it
to be DOS-compatible but hopefully you get the idea).
This will create a symlink inside Nimble for `anygui` and point it to
`V:/src/anygui`. Then you can use `requires "anygui"` in your .nimble file. You
will run in
Looks like a bug, double check you've got the latest jester version via `nimble
install jester@#head` and if the issue is still there then report it in the
GitHub repo.
Note that in your example a custom router doesn't make sense, why are you doing
it this way?
what URLs are you requesting? and which Nim version are you using? It's
possible this is an httpclient bug
This is super awesome, thank you for writing it up.
I'm curious if you've considered using SDL2 for your project, it seems to have
pretty good iOS/Android support. Its readme also documents some good
tips/tricks for running on Android which might be applicable to all C apps
wanting to be run on
hrm, I might consider using GLFM myself. It sounds like I'll need to
reimplement a lot of things that SDL provides though, things like sound, image
loading etc.
See
[https://github.com/nim-lang/nimble#configuration](https://github.com/nim-lang/nimble#configuration)
(search for proxy)
You can also set the standard HTTP_PROXY environment vars IIRC.
if you install Nim using choosenim then all you need to do is add one path:
`%USERPROFILE%\.nimble\bin` (not sure using that `USERPROFILE` variable will
work, but if not just expand it to whatever it is on your system).
> Are all DOM updates tied to events such that the datetime value wont update
> on its own?
Yep, you need to ask Karax to refresh in your dateTimeUpdate. Afaik you can
just call `redraw` to do that.
You can also run choosenim again, chances are this was an intermittent error.
The workaround outlined in Nim in Action is still the best way to achieve this
in a cross-platform fashion. That is until we are able to `await` a FlowVar,
once that is implemented and working it'll be the same idea but the code to
achieve will be much shorter and far more efficient.
> [https://nim-lang.org/docs/theindex.html](https://nim-lang.org/docs/theindex.html)
> > > Looking for type with ctrl+f drives me crazy. I give up.
Indeed, there is a trick here: search for "Natural:" (note the trailing `:`). I
think we might want to document this.
On the other hand, I would gu
This `assert` keeps popping up because it is showing you what you should expect
that code to evaluate to, in your example you should read this as "`collection`
will be equal to `{}`".
Thanks for writing this. I tweeted it out:
[https://twitter.com/nim_lang/status/1179501926230167559](https://twitter.com/nim_lang/status/1179501926230167559)
I wrote a prometheus library too:
[https://github.com/dom96/prometheus](https://github.com/dom96/prometheus).
It features:
* Counters, Gauges and Histogram support
* Comes standard with a couple of useful collectors for tracking precisely
where memory is being used in your program or which
I'm not aware of any packages that do this, but you can write your own.
The WinAPI is fairly straightforward to use once you get the hang of it, I and
many others I'm sure are happy to help as well. This is likely what you want:
[https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-s
**Do not** discard futures, if you do you will run into problems because any
exceptions captured by the future will be lost. You should use `asyncCheck`
instead which will set a callback on the _future_ to crash your program when an
unhandled exception occurs, I hope we can make discarding of fu
This description still seems rather "Minimalistic languages" focused. What is
the official title of this devroom? Why do we need to focus on minimalistic
languages where our devroom was aimed at _emerging languages_?
Not yet AFAIK. We're still waiting on @rayman22201's patches to be finalised.
> I see not a very pressing reason to switch to Nim.
There are many reasons:
* Nim is safer than C++
* Java is a horrible language to write software in
Also, OP might just wish to learn Nim. That’s a very good reason to rewrite an
existing project, in fact, it might be the best way to lea
In that case, IMO, this whole paragraph needs to be removed or rewritten:
> Minimalism is an important topic for this devroom. Minimalism matters.
> Minimalism allows for smaller systems that take less resources and consume
> less energy. More importantly, free and open source minimalism allows
Did you follow Choosenim's instructions to modify your PATH?
> benchmarks are a game. > > you can always beat or come close to C with Nim.
Agree with you 100% and especially these statements. For compiled languages
like C/Nim/Rust/Go it really is just a case of putting in the time to optimise
the code for a specific architecture or compiler. Even language
1 - 100 of 685 matches
Mail list logo
