I envy your productivity and inventiveness.
It's different because `AsyncFile` keeps its `fd` field private. The Windows
one is using the version from `winlean` which actually wrapper for
`GetFileSize` from win32.
Also, windows has peculiarity of different handling whether the file handle is
synchronous and asynchronous one. That's why
I've never used async file I/O APIs, but my understanding is that they just
cover reading/writing the file itself. The size is metadata that comes from the
filesystem's catalog / inodes / whatever, not the file itself, and is very
cheap to get.
I suppose you _could_ get the file size
The second one isn't strange, it's a hint which can improve performance if you
follow it sometimes :) but it can come from the library code too
Running your example gives me nice working results:
[OK] foo
Run
But I also have strange suggestion like you:
Hint: passing 'n[i].key' to a sink parameter introduces an implicit copy;
if possible, rearrange your program's control flow to prevent it
Turns out it's pretty trivial to reproduce. I've filed
[https://github.com/nim-lang/Nim/issues/14865](https://github.com/nim-lang/Nim/issues/14865)
.
$ cat test.nim
import unittest
test "foo":
check 3 + 4 == 7
$ nim c -r --threads:on --gc:orc test.nim
Hint:
Well, it would be nice if you try on the latest devel compiler :)
And if it still doesn't work - try to minimize it and report, like e.g. I did
in some cases -
OK, here's a weird bug. Once I enable both `--threads:on` and `--gc:orc`, all
of my unit tests (which uses the `unittest` module) fail to compile, with
gnarly looking C errors:
/Users/snej/.cache/nim/testCodec_d/@mtestCodec.nim.c:1144:112: error:
incomplete definition of type
Not everyone uses async/await, and it's more common to use it for networking
than for files (in my experience.) The async file I/O is for code that does use
async and is worried enough about disk latency to want to avoid blocking on
disk I/O. That's more extreme than I've ever gone, but I've
OK, but in "async" version, there is nothing async at all (as I can understand).
So that asyncfile can use proc from io module for example.
...OK, I have [some code that appears to
work](https://gist.github.com/snej/653856212361be805751e4208a87d131), at least
in Nim 1.2.2 with gc:orc. It lets you
* Wrap a Future in another Future that can be passed to and completed on
another thread, and will then invoke the original Future on
Hi, working with async stuff decided to look at what async way of getting file
size and compare it to sync way.
Got no difference in principle, but there is 2 different implementations:
The "sync" version in io.nim:
proc getFileSize*(f: File): int64 {.tags: [ReadIOEffect],
Yeah, I still have [your
example](https://gist.github.com/treeform/3e8c3be53b2999d709dadc2bc2b4e097)
open in a browser tab, and I think I may need to start borrowing from it, since
it doesn't look like I can use Nim's thread pools with ORC (see above).
Thanks for the example! I'm doing it slightly differently but using your basic
technique.
Next roadblock is that `FlowVar` doesn't seem compatible with ORC (which I need
so I can pass object graphs across threads):
`nim-1.2.2/lib/pure/concurrency/threadpool.nim(214, 6) Error: cannot bind
In my system I do all async/await and asyncdispatch on a single thread. Then I
have a work Q to do other the actual work. Was very simple to put together.
Very nice blog post!
Right now, the most straight forward way to achieve this is by manually
creating an asyncEvent that you can pass to the other thread. That secondary
thread can then use the asyncEvent to trigger a wakeup on the event loop.
@see here for an example:
> I'm not considering Weave, for now, because it looks like it's oriented
> toward finer-grained parallelism and is probably more complex than I need.
Weave is indeed focused on CPU-bound workloads and not IO workloads, i.e. it
optimize for throughput and not latency.
OK, I've got a WebSocket-based client running on a single thread with
async/await and asyncdispatch. Now I want this to interact with other threads —
for example, I'd like another thread to be able to post a message for the
WebSocket to send.
The sticking point is how to wake up the async
{.pragma: raisesssz, raises: [Defect, MalformedSszError,
SszSizeMismatchError].}
Run
Makes a new pragma called `raisesssz`, which, when used, will imply `raises:
[Defect, MalformedSszError, SszSizeMismatchError]`
What does the `{.raises:[...].}` pragma at the top of a source file do, as in
your ssz_serialization.nim? The manual only describes it as a proc annotation.
Nice article! I like the explanation of Nim's benefits. I forwarded it to my
team.
Module names seem to be lowercase by convention, and types uppercase.
Good point so probably we should require `ptr T not nil` for auto-deref...
Ok, I also tried replacing this line:
var imgTable: Table[string, Image]
Run
by this one:
var imgTable: Table[string, Image.Image]
Run
And it still gives the same error.
Anyway I will change the module names
We use it in our code to:
* Enforce noSideEffect (i.e. no access to globals, including stdin/stdout).
* Enforce handling of recoverable exceptions and make sure all kinds of
exceptions that can be thrown in inner function calls are accounted for or
handled or considered irrecoverable:
*
no, you named a module same way as another symbol, and module takes precedence.
nothing to do with tables.
Hello,
I am doing a simple test with tables and have problems using import.
I have a file Image.nim:
type
Image* = ref object of RootObj
filepath*: string
Run
And a main file:
import tables
import Image
var imgTable:
i think Image is first recognized as module. rename it to lowercase.
Yes it works that way, thanks!
But it is strange the type can be created but cannot be recognized in as the
Table value type, isn't it ?
Guest post by @mratsim:
[https://nim-lang.org/blog/2020/06/30/ray-tracing-in-nim.html](https://nim-lang.org/blog/2020/06/30/ray-tracing-in-nim.html)
31 matches
Mail list logo
