y: 1.2E3
Run
Thanks for that hint. Of course the book is in an very early state still, I
wrote most of the two first chapters in April. But I hope and think that it can
be already useful for beginners with nearly no CS knowledge. I have just
yesterday applied a lot fixes
I use async/await in production, but only server side on Linux. It's pretty
mature for a simple web application. My app runs on multiple servers instead of
threds. Async does not mesh well with threds. Multiprocessing is more scalable
anyways.
Hi All, I'm having a problem compiling nim sources with nimble, but I do not
have the same problem when running "nim c -r src/firmware_update_compiler.nim"
from the command line. Please see this transcript:
me@host:~/repositories/gecko-logger/firmware_update_compiler$ nimble
Parallelism/concurrency and async are some of the few pain points of the
language. ARC/ORC together with
[https://github.com/mratsim/weave](https://github.com/mratsim/weave) might be
very promising.
you need to add requires "crc32" to nimble file
> At this point I'm unclear on how much of this stuff is solid and
> enabled-by-default (in particular, what's the difference between "arc" and
> "orc"?)
ARC is in version 1.2 with significant stability improvements around the corner
in 1.2.2. Many Nimble packages already work with `--gc:arc`.
> for new projects I wouldn't use anything else because the tooling is so much
> better
That would be great, but it requires an introduction that explains to users
what ARC is, how to make use of it, how it impacts multithreading, the new sync
and lent parameters, how to design collections and
> Async does not mesh well with threds.
Could you explain why not? My understanding is that it’s thread-agnostic; an
unfinished async call is just a sort of lightweight continuation that can be
restarted in any context.
> Multiprocessing is more scalable anyways.
This project is a library for
> it requires an introduction that explains to users what ARC is, how to make
> use of it
+1 The existing documentation is **great** (I’ve read the tutorial, manual,
and “Nim In Action” cover to cover), but in some areas seems to lag behind.
Which is understandable since the language is
Are you using Jester or another web framework?
> Could you explain why not?
Current current gc:refc does not allow refs object to be passed between threads
willy nilly. Async creates a reactor ref object per thread. So you can't really
share the async corutines between threads. Threads are just kind of hard to use
with gc:refc, that is why
> You can use closures or pass the data parameter as an input to the function.
In some sense closures and objects are isomorphic, as are functional and OOP.
There’s a famous old _koan_ about this:
> The venerable master Qc Na was walking with his student, Anton. Hoping to
> prompt the master
Hello,
I wish to make modification on a Nimble package that is archived on Github
([https://github.com/ziotom78/nimfftw3)](https://github.com/ziotom78/nimfftw3\)).
I wanted to know how should be handled the case of a package being effectively
"dead" (i.e. not maintained anymore) ?
Should I
Create your own repo with fixes and updates and make a pull request on
nim-lang/packages
> Threads are just kind of hard to use with gc:refc, that is why gc:arc is
> getting worked on.
I'm still confused as to which GC is the default. I thought it was ARC, but
what I'm reading recently makes it sound like ARC isn't quite stable enough yet.
> Just regular threads are probably
> For stdlib's async you need --gc:orc and Nim devel, otherwise it leaks
> memory. Sorry, I hope we can get 1.2.2 out soon! The good news is that we're
> also planning an async more suited for embedded.
Ah, that makes sense. I look forward to 1.2.2! A better async for embedded
would be great.
In this traceback, the line number of the main module causing the fault is not
displayed:
ms:nim jim$ nim c -r x4
Hint: used config file '/Users/jim/nim-1.2.1/config/nim.cfg' [Conf]
Hint: system [Processing]
Hint: widestrs [Processing]
Hint: io [Processing]
I guess posting the code would be a good idea:
var i: string
i[10] = 'j'
echo i
Run
> Again, I'm considering porting a large existing project, not writing
> something from scratch. I already know the requirements and the architecture.
> Nim is different from C++ but that doesn't mean I'm going to change the
> design to single-threaded. I definitely need multiple threads
> which GC is the default
The _\--gc:refc_ (deferred reference counting/heap per thread) is the default
right now. The _\--gc:arc_ (immediate reference counting/shared heap) or
_\--gc:orc_ (immediate reference counting/shared heap + cycle detector) is set
to replace it.
The _async_ stuff
Workaround - if you do
var i = ""
Run
instead, it shows the line number :)
> how does your C++ architecture share data between threads?
Carefully ;-) The Actor library doesn't restrict what parameters you can pass,
but by convention we're careful to limit it to primitives, pass-by-copy objects
(like std::string), immutable ref-counted objects, and Actor references. Or
THANK YOU SO MUCH!!! I feel a little silly that the problem was so simple to
solve, but I honestly had not worked out that the nimble tool has different
dependencies to a plain compiler run. Your solution has helped me a lot.
23 matches
Mail list logo
