Re: Creating a seq or openarray on unmanaged memory
I have just been researching something similar for string slices. I found this RFC: [https://github.com/nim-lang/RFCs/issues/12](https://github.com/nim-lang/RFCs/issues/12) which lead me to this issue: [https://github.com/nim-lang/RFCs/issues/178](https://github.com/nim-lang/RFCs/issues/178). Right now openarray is the only method to do this, but better approaches are coming soon.
Re: Generate warnings for default returns
one questions is for generics, conditional compilation, and when templates are in the mix which can complicate things. > The extra line result = 0 or similar in the beginning of a proc how about used(result); it's more generic and would work with any type, and doesn't change semantics
Re: Can I "prune" directories with walkDirRect?
this is probably what you're looking for [https://github.com/citycide/glob](https://github.com/citycide/glob) but IMO there should be something equivalent in stdlib
VSCode debug: strings and booleans are ugly
Is there a way to get human readable strings and booleans in VSCode debugging?
Debugging successfully stops at breakpoints. Ints, floats, arrays are human
readable in the debug panel.
But string values look like 0x00010012c048 and booleans look like 'x01'.
I use mac, native debug and lldb (gdb doesn't work). Here are my code,
launch.json and tasks.json:
proc run =
var a = 123
var b = "456"
var c = true
echo a, b, c
run()
#[
tasks.json:
{
"version": "2.0.0",
"tasks": [{
"label": "nimbuild",
"type": "shell",
"command": "nim c --debugger:native ${file}",
}]
}
launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "(lldb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}/${fileBasenameNoExtension}",
"args": [],
"preLaunchTask": "nimbuild",
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"MIMode": "lldb"
}
]
}
]#
Run
Re: Faster and Safer Raytracing in Nim
A weekend past and some new updates: * The raytracer is now parallelized. * I have found a parallel RNG scheme that allows reproducible multithreaded result for those who wants to do parallel reproducible Monte-Carlo simulations: * writeup [https://github.com/mratsim/weave/issues/147#issuecomment-633198832](https://github.com/mratsim/weave/issues/147#issuecomment-633198832) * the magic: [https://github.com/mratsim/trace-of-radiance/blob/26ef9ed5/trace_of_radiance/support/rng.nim#L21-L29](https://github.com/mratsim/trace-of-radiance/blob/26ef9ed5/trace_of_radiance/support/rng.nim#L21-L29) a `pair` function that can take 2 integers (for example one produced by a "master RNG" and one from a loop variable, or 2 from nested loop variables) and that can be used to reseed RNGs across threads to: * ensure different RNG streams * ensure reproducibility * I departed a bit from the book to add an animation: * For this I have added: * a mini physics engine that can simulate gravity and bounce * the output can now be a series of PPM images * the output can be a mp4 video in H.264 format * The H264 encoder is lossless and less than 300 lines of pure Nim: * [https://github.com/mratsim/trace-of-radiance/blob/26ef9ed5/trace_of_radiance/io/h264.nim](https://github.com/mratsim/trace-of-radiance/blob/26ef9ed5/trace_of_radiance/io/h264.nim) * When passed to FFMPEG, it will complain about corrupted frames but sss, don't let it say otherwise, it's spec compliant and can be read by media players ;) * I've added a MP4 muxer (this one is full-featured via the minimp4 header-only library) * color conversion for RGB to Y'CbCr 420 (also known as YUV420 i.e. with chroma subsampling). Limitations: * It's very very slow, ~3 hours of rendering on 18 cores for a 576x324 image with 400+ spheres and 300 rays per pixels. The reason why is that each ray must test if it encounters any of the sphere, and redo that after each bounce, a ray can bounce up to 50 times (artificial limit otherwise compute never finishes). * Solution is in the volume 2 "Raytracing the next week", via Bounding Volume Hierarchy (BVH), which will make the time needed logarithmic (and assuming 1 seconds of initial rendering time ln(1) == 9) * No Motion blur, I added animation but no motion blur. * Solution is in the volume 2 "Raytracing the next week", as well. But the book simulates motion blur but has no animation code ;). Note: Feel free to reuse the video code to record the NimConf but 6 seconds of size 576x324 took 53MB ;)
Re: Creating a seq or openarray on unmanaged memory
I want to provide a (reasonably) safe interface, and returning an `UncheckedArray` clearly wouldn't be safe. The other approach I'm thinking of is to make the proc take a function parameter, and pass the `openarray` to the callback function. It makes the call site a bit ugly, but it'll be safe.
Re: Creating a seq or openarray on unmanaged memory
`openarray` as value don't work at the moment [https://github.com/nim-lang/RFCs/issues/178](https://github.com/nim-lang/RFCs/issues/178) You can store as `ptr UncheckedArray[byte]` \+ len. On use either you use directly like you would index a pointer in C or if you interface with Nim libraries there is a zero-cost transformation to openarray via `toOpenArray(ptr UncheckedArray[T], start, stopInclusive)`
Re: Creating a seq or openarray on unmanaged memory
I haven't enough experience with inter-library memory sharing but have a look at [Keeping track of memory](https://nim-lang.org/docs/gc.html).
Creating a seq or openarray on unmanaged memory
I'm wrapping a C function, a getter that returns a `{const void*, size_t}`
struct pointing into memory managed by the C library. The obvious wrapper proc
would copy the bytes into a `seq[byte]` and return that.
However, this C library is a high-performance key-value store (a relative of
LMDB) that gets a lot of its speed by using memory-mapping and avoiding
copying. So I want to avoid copying the bytes.
The only collection I've found that lets me do this is `openarray`, and I've
found the functions that let me create one from a `cstring` and a length, but
the manual says `openarray` can only be used as a parameter. That doesn't seem
to be enforced, however: I can declare an object type containing an `openarray`
without errors.
I'm thinking of doing something like this:
type Transaction* = ref object
...
type Result* = object
bytes*: openarray[byte]
owner: Transaction
proc get(t: Transaction, key: string): Result =
...
Run
The `owner` field of the `Result` holds onto the `Transaction` object, keeping
it alive so the `bytes` remain valid. (The C API only guarantees the
availability of the data during the transaction it was accessed in.)
Is this OK, or something that could cause trouble?
—Jens
Re: Question about type safety and OOP
> `var a:seq[A] = @[B(val:1), B(val:2)]` > can not work as Nim is a statically
> typed language, seq[A] and seq[B] are different types, so assignment is not
> allowed.
There's nothing about static typing that forbids this; the collection class
just needs the appropriate generic assignment operator. I thought C++'s
`vector` allowed it, but I just tried it and it doesn't. But Swift's `Array`
does, so this compiles:
// This is Swift 5.2
class A { }
class B : A { }
var a: [A] = []
var b: [B] = []
a = b
Run
In Nim I think you could write a generic proc to assign a `seq[B]` to a
`seq[A]`, using the restriction `when B is A`.
Re: Defining an iterator in a template
Ah, interesting. I didn't know about that comment issue. I learned something too :)
Re: Introducing --gc:arc
See [https://github.com/nim-lang/Nim/issues/13997](https://github.com/nim-lang/Nim/issues/13997)
Re: Introducing --gc:arc
There is no workaround, I am trying to implement deepCopy for arc right now. Though it proven to be not easy exercise.
Re: Introducing --gc:arc
Is there a reason why `deepCopy` doesn't exist on `--gc:arc` / is there a
workaround that works on the normal `gc` and `arc`? I don't think I see it
mentioned on your todo list above.
when hasAlloc and notJSnotNims and not usesDestructors:
# XXX how to implement 'deepCopy' is an open problem.
proc deepCopy*[T](x: var T, y: T) {.noSideEffect, magic: "DeepCopy".} =
## Performs a deep copy of `y` and copies it into `x`.
##
## This is also used by the code generator
## for the implementation of ``spawn``.
discard
proc deepCopy*[T](y: T): T =
## Convenience wrapper around `deepCopy` overload.
deepCopy(result, y)
Run
Re: Generate warnings for default returns
I completely agree with this proposal. It's time to make implicit result values a warning. The extra line `result = 0` or similar in the beginning of a proc won't kill us.
