> 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.
Please please tag new versions. It's not enough to just bump the version in the
.nimble file.
Yes the current file IO "async" implementation isn't actually async.
> 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 :)
Nice, looks good. And in the meantime it seems GitHub's new design separates
these colours better.
Oh, one thing, doesn't JavaScript use a similar colour? Can we see what that
looks like? @pietroppeter?
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)
Nice! I must say, I do like that colour.
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
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
You shouldn't need to do that. Passing `--threadAnalysis:off` to the compiler
should work too.
Likely after Tuesday which is the deadline for recording submissions.
I wouldn't depend on the do notation. The reason it's experimental is that it
doesn't fit the language and may be removed entirely eventually.
Personally, I don't think this is too verbose:
let fourthPower = twice(10,
proc(n: int): int =
echo "Gratuitous echo!"
> Read mratsim's post from the same thread then,
> [https://forum.nim-lang.org/t/6352#39200](https://forum.nim-lang.org/t/6352#39200)
@mratsim shows no examples of what ARC can do, but I assume that ARC can help
with the third scenario that he describes...
> You need a shared state, for
> I have limited experience with nim mobile apps. But knowing what I know don't
> think I would use async on the client. Async is great if you are doing tons
> of http style requests. But really a mobile client? Just regular threads are
> probably better if you are just writing and reading from
ding out hope for my suggestion above.
There are alternatives, and I have been pretty successful in creating a very
performant HTTP server for example:
[https://github.com/dom96/httpbeast](https://github.com/dom96/httpbeast) (which
this forum runs on).
Now to answer some of your questions...
&
Please no. If you want someone to have a look at your PR then bump the PR so it
gets put at the top of our notifications or just ping the best person to review
that PR (if you know who they are). All these title/tag changes are just noise
and we've got enough of that already.
I think the consensus so far is that we will let the participants choose
whether they wish to pre-record their talk or to do it live. I would personally
suggest pre-recording it to give us the ability to stream the highest quality
talk possible, but I understand that some dislike that approach
The time is important I agree, but the platform shouldn't matter. It's unlikely
to be anything other than Twitch/YouTube, streaming to those services is always
just a case of using OBS and watching just needs a browser.
We can already do italics and bold via * though, so it really isn't so bad.
What is more annoying is the inability to respond with just a code block, those
are bugs that need to be fixed.
> "Compile your code with --gc:arc". That's it, the rest are details, the
> document describes how --gc:arc is implemented.
Don't you need to at least mention `--gc:orc` as well? The difference between
them at least is useful knowledge, since as soon as someone compiles async code
with
Yes, we have been after marrying the parallelism and concurrency primitives in
Nim for a while now. You can see some efforts for this being made in
[https://github.com/nim-lang/Nim/pull/11724](https://github.com/nim-lang/Nim/pull/11724),
but it didn't get to a point where it could be merged.
> I'm also thinking that since now JavaScript modules landed in browsers,
> perhaps Nim could target a javascript module with export directives instead
> of a script to include inline on a webpage.
Keep in mind that a lot of us want to have support for a large variety of
browsers, and this
I use this in my [upcoming game](https://twitter.com/stardust_dev), and I must
confirm that it works beautifully (not only on Windows but also on Android!).
@treeform is also very responsive to bug reports and fixed the fonts that I
found were rendering incorrectly very quickly, thanks
Depends on an external dylib though, would be nice to have a native Nim
implementation, it shouldn't be hard to implement either, someone just needs to
commit some time.
> Memory management seems to be going in the right direction but I fear "ARC"
> needlessly fractured the small community
A lot of implication here that ARC is going to be the new default. While this
_may_ happen, it's far from certain, and even if it does it won't be until Nim
2.0. So there is
Have you tried symlinking `libsass.so` to `libsass.so.0` in
`/usr/lib/x86_64-linux-gnu`, or just straight up changing the DLL name inside
the sass Nim module?
> 3\. I'd argue that Jester (and it's underlying httpbeast) are mostly
> production-ready
Yeah. You're all using it right now through this forum, been running in prod
for years.
> Funny to hear that from someone who wrote a Nim book. Wisdom of the ages or
> more a result of dissapointment by tiny selling rates :-) ?
This isn't about my experience with writing the book, it's about my experience
as a kid learning how to program. For what it's worth, I consider Nim in
> Although I don't think it's for kids.
I'd have to agree, this is great work you're doing @Stefan_Salewski. But
personally I am of the opinion that kids rarely enjoy learning by reading
books, there is a minority that do, but I think a much better way to teach kids
(and many adults)
Yep, it's trying to install karax and that fails for some reason (I think there
might be a Nimble bug here). Try to install it manually by running nimble
install karax@#f6bda9a.
Stop mixing callbacks and async procs. Your `download` async proc finishes
before your download operation finishes because you are not awaiting the
`download` proc. Just do this:
await downloader.downloadFile(node.mediaLink(board, thread), downFileName)
Run
You'll need to copy this file beside your .cpp file. This is supposed to be
copied automatically when using `--genScript` (if you're using 1.0.6 it should
work), with latest versions of Nim it doesn't get copied (see
Are you sure you're not getting this error because of a dependency that's being
installed? Can you paste the full output of `nimble c -r src/buildcss --debug`?
> Writing a synchronous downloader script was a breeze:
> [https://gitlab.com/snippets/1967018](https://gitlab.com/snippets/1967018)
Is this a wrong link? because that doesn't look synchronous.
You're doing a number of things incorrectly here. One important thing to know
is that you should
> I thought Digital Ocean wouldn't have been an option with Nim, but Docker
> seems to make it possible...
You don't need Docker to run Nim on Digital Ocean (or any VPS/server hosting
provider). You've got a whole Linux machine to do with what you wish. Most of
the time Docker is overkill.
300k/s nice, usually people see much less. What specced hardware are you
running this on? :)
could not import: X509_check_host
Run
> > every time I invoke nimble :-(
This is because we removed dead code elimination from the openssl wrapper, why
did we do this? I was fixing something in openssl and noticed this yesterday
(very time I invoke nimble :-(), can we
I cannot test these right now but I just want to say thank you for your work on
this!
Since nobody else is reaping the NimForum karma, I might as well share this.
Nim 1.2 is here:
[https://nim-lang.org/blog/2020/04/03/version-120-released.html](https://nim-lang.org/blog/2020/04/03/version-120-released.html)
As always, update via:
choosenim update stable
@moigagoo that heading is far too large :)
I would prefer if we have a more structured submission process (i.e. a google
form). It's too easy for submissions to get lost in a forum thread like this
(speaking partially from experience here).
Great idea. Happy to help with promoting and setting this up.
I should be able to come up with something to talk about too :)
Whether something is a "Beginner" question or not is largely subjective, hence
it is a bad category.
We will have categories, but we will not be getting categories like "Beginner
Question" or "Advanced Question", instead it'll be "Question", "Announcement"
and probably "Off-topic" and that's
We will get categories soon. They won't be that granular though.
Yep, Andrew pinged me on IRC to suggest Nim adopts this. It might not be a half
bad idea, we can pretty easily add it to choosenim for example to make
cross-compilation much easier.
It's looking like Nimble cannot find git for some reason, are you sure it's in
the PATH of the terminal you're running it from?
Nope, you're correct. Someone needs to create an async mysql/sqlite/postgres
etc. driver.
yes, it can. You "just" need to get it into gedit's source code, send them a
patch.
asyncdispatcher's FD and ask Python to tell when it should be
polled. Then simply poll it. I take this approach in my HTTP server:
[https://github.com/dom96/httpbeast/blob/master/src/httpbeast.nim#L168-L171](https://github.com/dom96/httpbeast/blob/master/src/httpbeast.nim#L168-L171).
Happy to help
The VS Code plugin is community supported. I do agree that it would be nice to
have an official plugin.
Not with the stdlib. You might have some luck using
[https://github.com/cheatfate/asynctools/blob/master/asynctools/asyncproc.nim](https://github.com/cheatfate/asynctools/blob/master/asynctools/asyncproc.nim)
though.
](https://fosdem.org/2020/schedule/event/nimultralowoverheadruntime/)
@mratsim
* [Async await in Nim](https://fosdem.org/2020/schedule/event/asyncawaitnim/)
@dom96
All talk videos bar @mratsim's are ready to view at time of writing.
Videos should be up soon, and we'll likely post links in a separate forum
thread or in this once which is more recent:
[https://forum.nim-lang.org/t/5866](https://forum.nim-lang.org/t/5866).
Please try to find a more recent thread before bumping an old one like this.
I'm going to lock this
Even though this happened before 1.0 (AFAIK) it would have broken a lot of
code, so it makes perfect sense that we should consider this to be a bug and a
serious one at that.
That's a shame, we will miss you. Maybe this could be our excuse to have a
meetup in London finally :)
To be honest I'm now confused about 1.1 being skipped. We've always only
skipped odd numbers in the "patch" number (i.e. last number in the version).
Wasn't the weird 1.0.99 thing used for the in-development 1.1 version?
`htmlgen` is part of 1.0 so it won't be removed, but it may be deprecated.
Mention that in your video but do show it off.
You need to install the dynamic library to use it, homebrew is indeed the
easiest way.
As for passing that flag to Nim via Nimble, you can simply run `nimble c
-d:nimDebugDlOpen ` (or maybe even `nimble build -d:nimDebugDlOpen`).
> I don't think it makes sense for a game to be in someone's ~/.nimble/bin (or
> equivalent), and I don't expect anyone to use this project as a library.
Why not? If someone wants to play your game they may want to install it into
their PATH :)
> Can the user provide the name of a text file
> Another update: The async bugs on Windows have been fixed and async is now in
> the state "almost working" for all major OSes.
That's brilliant! Thanks to everyone that helped with this :)
I'd love to see someone give httpbeast a shot with --gc:arc vs. normal GC to
see what the numbers look
That code looks like it does what you intend. One thing to keep in mind is:
never ever discard the result of an `async` call. You need to use `asyncCheck`
already otherwise you'll be swallowing exceptions in your sessions_manager
function.
Wonderful, short and sweet write up. I really enjoyed reading this and am
becoming more and more excited about ARC :)
When's the cut-off?
I've had a very similar idea and I actually have a pretty nice libclang wrapper
which I've used for my C/C++ code obfuscator
([https://picheta.me/obfuscator)](https://picheta.me/obfuscator\)). I've been
meaning to open source it for a while now...
My idea differs in one important way though:
hrm, that's weird. Can you report it on GitHub?
Like this?
requires "https://url/repo.git #head"
Run
wow, that's a significant app. Nice job :)
Yeah, it's definitely not perfect and indeed the deviation from original naming
conventions was my number one annoyance too (would love to fix that if I had
the time). Getting rid of the need to destroy pointers manually should now be
possible with Nim's better destructors and/or ARC (but at
That's a poor error from Nimble, can you report this as an issue? IMO we need a
better error message here.
This is awesome, and a great overview thanks for writing it up.
I am also curious about the shared heap, the implication from your post is that
you are still sticking to the "one heap per thread" model and that we will
continue to restrict the sharing of memory between threads. Is that the
`-d:release` will remove any `assert` calls, apart from that it shouldn't
change any behaviour, so this may be a JS backend bug.
Make sure you aren't running any procedures that have side effects with
`assert` as those statements will just be removed.
You can introduce a page which lists each tag, sorted by how many packages are
in that tag. This would already give a nice way to explore our packages.
Yeah, there is nothing for this in the stdlib. You will have to call out into
posix/win api to do it, if you're up for it contributing this to the stdlib
would be much appreciated :)
Decided to give this a proper try this year. Let's see how this goes. My repo
is here:
[https://github.com/dom96/aoc2019](https://github.com/dom96/aoc2019)
Already found a bug in Nim heh:
[https://github.com/nim-lang/Nim/issues/12788](https://github.com/nim-lang/Nim/issues/12788)
If you'd like we can look into giving you the permissions needed to implement
this, I'm not familiar with Discord's permissions, do you know what is required
to be able to structure channels this way?
> Maybe @dom96 have some experience with this ?
Never attempted to transfer FDs between processes, personally I would avoid it
as I doubt it's well supported across different platforms, but I'm no expert on
this particular aspect of how sockets/FDs behave when sent across processes.
You sho
> Any decent non-video async socket tutorials in c#
Is that a typo or are you trolling us?
Last chance to submit is today! Bumping for visibility.
Submitted 3 talks:
* Nim - A walk-through of a new emerging language
* Async await in Nim - A demonstration of the flexibility metaprogramming can
bring to a language
* Karax - SPAs in a compiled systems programming language
I'm quite proud of my abstract for the first one, the others I
Can someone explain what this project is? This is literally the first I'm
hearing of it and I'm quite puzzled about what I've read so far, do we have
gardeners working on a Nim programming language book?
@enthus1ast You can also use `FutureVar[T]` as a workaround for this
restriction. Eventually my hope was to have the `async` macro do this
automatically, but I wonder if it would make more sense to push for `var T` to
be supported in closure iterators instead.
We are nearing the deadline to submit a talk for the Minimalistic, Experimental
and Emerging Languages devroom. This is a devroom that is co-run by one of our
very own, @PMunch.
**The deadline is Tuesday, 26th November 2019.**
This devroom, alongside being aimed at Minimalistic languages (like
Yeah, I think this is a bug in asynctools. I recall running into similar
things, I created an issue for this a while ago:
[https://github.com/cheatfate/asynctools/issues/9](https://github.com/cheatfate/asynctools/issues/9).
If you have some time it would be brilliant if you could look into the
I would strongly recommend avoiding `include` as much as possible, and in
particular in this case.
What works usually is to create a module for your types, or to think about how
you structure your program, usually you will see that you aren't organising
your code in the best way.
Cool, thanks for testing. I can't imagine what could cause this difference in
httpbeast, perhaps Nim's kqueue implementation is significantly worse than its
epoll implementation.
Maybe Amazon's EC2 has worse performance on FreeBSD? Have you tried comparing
other http servers?
This curly bracket structure is called the "Table constructor":
[https://nim-lang.org/docs/manual.html#statements-and-expressions-table-constructor](https://nim-lang.org/docs/manual.html#statements-and-expressions-table-constructor).
You should be able use `varargs[(string, string)]` as the type
This is interesting. Can you test httpbeast on its own?
For something like an embedded system the current async/await is likely to be
far too heavy (it allocates far too much on the heap).
What I would personally like to see is alloc-free async/await which is, I
believe, what Rust achieves. Since you're working on an embedded system
already, this
Does it ever rise above 12mb? To be honest, 12mb isn't bad and I don't think
the GC will aggressively free that. Maybe it's too much for you?
Are you using async await in your program?
In any case, the best way I've found to diagnose memory leaks for long-running
programs is by logging the memory usage of each object to something like
prometheus. My [prometheus package](https://github.com/dom96/prometheus) can do
that automatically
Guessing @JPLRouge means that our donations page does not list their donation.
We need to update that page more often.
You can always workaround this by creating a nice macro which will generate
something like:
{.emit: """
const int a[] = {1,2,3};
""".}
Run
The link to share, now that we've got an article:
[https://nim-lang.org/blog/2019/10/23/version-102-released.html](https://nim-lang.org/blog/2019/10/23/version-102-released.html)
Since this thread has popped up again, I should ask, what ever happened to
these lost episodes? Among them is one of mine, would love to hear it again.
Done. Sorry it took so long :)
Where has this been emailed out? Is there not a page which has this description
on the FOSDEM website somewhere? It would be great to update it if so, and also
the description in your original post.
> 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
Did you follow Choosenim's instructions to modify your PATH?
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
Not yet AFAIK. We're still waiting on @rayman22201's patches to be finalised.
1 - 100 of 634 matches
Mail list logo
