Well noted, I'm not at all opposed to what you wish. It's just that I don't
agree with it being the big turbo for Nims uptake.
For a start, very many if not most professionals have little choice anyway;
projects are done in whatever language management decides. The next major user
group are
> I'm afraid that "being the most libertarian programming language: no
> restrictive licenses / patents" also has quite little influence; for most
> "it's free" (beer & freedom) is good enough.
We are talking about small niches. Using
[TIOBE](https://www.tiobe.com/tiobe-index/) as a rough
It's my hope that we see more posts in the Nim blog, and generally more written
materials outside of the IRC channel. A summary of the video would be nice.
IMO, following Nim development is rather difficult, compared to some other
languages, and that's a pity.
Hi @Kvothe Welcome to Nim.
In async problem, I think it's because the hit not actually executed yet but
only registered on dispatcher.
Usually when using async, we run it forever with runForever or wait each
invocation with waitFor (but this is not what you wanted).
Oh, and yes, this is the place to ask such questions. Welcome to the Nim
community. We're always glad to have newcomers!
I just had a look at the docs, and I'm going to suggest dropping that `await`
after the echo (see above). Let us know if that works!
Cheers!
Hmm, I don't immediately see why the `async` version doesn't print.
I believe there's no real difference between putting `sync()` at the end of the
`proc` or after you call it. It's a matter of preference/design.
By the way, it's better not to `discard` `Future` s, because `async` code has a
That would be nice to have. It would perhaps make sense to include it only in
debug mode, as I believe it would require a branch for a nil check before each
call, though. The Segfault isn't caused by userland checking for NULL pointers,
but rather by the protected memory system getting angry
P.S. @Araq and team
If it's not too much trouble it might be a good thing to differentiate between
illegal memory access and _calling_ a nil proc. Would probably be helpful and
errors like the above would be easier to see/understand for new Nim users.
Here is a little update regarding Nim's development:
[https://www.youtube.com/watch?v=xUsAKstP-AQ](https://www.youtube.com/watch?v=xUsAKstP-AQ)
It is my hope we do more of these and become better at producing videos. ;-)
ah sorry, missed
proc registerEvents(wrapper: var SomeWrapper) =
wrapper.events.onload =
proc (name: string) =
echo "loaded " & name
wrapper.onload(name)
Run
why call onload recursively?
Hmm, am I supposed to moderate here? Keep it civilized @moerm, @carterza
> I hope you scored all the brownie points with Araq
My respect for Araq is well earned and deserved. Thinking that it's about
brownie points tells more about you than about me.
As for the matter:
You were (and are) free to clearly show how Zig's importing C stuff is not
insignificantly
a) I don't see the big difference or how using C stuff in Nim is more labour or
more complicated than in Zig.
b) Again: Even _if_ you were right I wouldn't care because that would be a
discussion about a Ferrari being oh so much slower than a Lamborghini; looking
from the perspective of a
It's hard to debate with someone whose counter-argument to facts is - "I don't
care."
Day 20 forced me to abandon nim, because for whatever reason my hash searches
started taking seconds.
I probably fucked up somewhere around
type
Room = object
coord: Coord doors: Table[char, Door]
Door = object
name: char frm: Room to: Room
proc hash(room: Room) : Hash =
Hello everybody, I don't know if this is the right place to ask for simple
things. I'm a complete novice to NIM and programming in general. I'm trying to
make a few http post requests. I managed to create the code to execute them
sequentially but then i wanted to speed it up. I attempted with
Gameplay code is written in C# - the game engine itself is written in C/C++
How does Unity get away with C#?
@moerm \- We get you like Nim and that it suits your use case(s) fine.
It still doesn't make any of what I said, untrue.
@mratsim \- yes I think Nim is well-suited to ML, Data Science, Crypto etc...
I know Parallelism is difficult - but Nim makes things even more difficult.
OpenMP is nice in
Yes, I think that's exactly what I wanted. Thank you!
Yes, I think that's exactly what I wanted. Thank you!
# Parallelism
Parallelism is a hard problem and it really depends on what kind of parallelism
you need.
For my problem domain (numerical computing, machine learning, deep learning),
Nim macros + OpenMP offer me unparalleled flexibility. For example I can reach
the speed of OpenBLAS which is a
No, it doesn't. It just seems it does but as soon as a call like
`s.events.onload("some event"` is made it segfaults with `Illegal storage
access. (Attempt to read from nil?)`
Please note that the approach of @Araq also fails because in the OP
`wrapper.onload` was left nil which leads to the
> Zig and Kit have arguably better interop capabilities with C than Nim does atm
One might see it like that - I, however, do not. One reason is c2nim and the
other reason is that I'm interested in an easy comfortable way. In a way we
talk about different things; I talk about that it's easy
26 matches
Mail list logo
