OK, so basically let's say we have a Table and we're either trying to retrieve
a value using a specific key, or trying to see if our Table contains a specific
key.
The normal way I guess would be with a call to hasKey.
Now, what if we're - possibly - going to perform the same lookup many
What would you think of using... ?:
type
SeqRef[T] = ref seq[T]
proc newSeq[T](s:seq[T]): SeqRef[T] =
new(result)
result[] = s
Run
Thanks for the sample!
Do you use this xName naming convention to make procs look more like types?
Makes sense, just clarifying.
Also, how would you handle state in your app model?
You could have tables-of-refs-to-objects, e.g. allInts:@seq[int],
allFloat:@seq[float], and NaN tag the indices to those lists; it would require
one more redirection to actually get the value, but would otherwise work well
with any gc.
Also, subnormals (neé denormals) are also useful for
Thank you, Vindaar. That's very helpful!
You can use components with local state, but I haven't experimented with them,
I'm more than fine with functions and variables, each in their own file:
[https://github.com/kidandcat/nimforum2](https://github.com/kidandcat/nimforum2)
deepCopy has value independent of memory management. I don't use it much, if
it's not a problem I'd vote for it to remain.
Pass the sequence to `shallow()` before processing or create a custom object
type MyShallowSeq[T] {.shallow.} = object
buffer: seq[T]
Run
Your solution will create 2 pointer indirections, it's idiomatic but slower.
I've tried exploring component-based architecture in Karax once:
[https://moigagoo.svbtle.com/exploring-karax](https://moigagoo.svbtle.com/exploring-karax)
However, I now see there is VCompoment type in Karax and there are
examples/tests that demonstrate its usage.
Is this the official way to
I second dom96, recursive module dependency is a sign of bad code organization.
Avoid it.
Looks cool!
I was thinking of packaging the seq in a ref object, and then move those ref
objects around. but wouldn't that be an overkill?
But this makes a copy of the sequence, doesn't it?
Is there any way to do the same thing, using the reference? (after all, it's a
pointer, if I'm not mistaken... all I want to do is change the value/sequence
to which that pointer is pointing)
I have a template like this:
template ARR(v:Val):seq[Val] =
cast[seq[Val]](bitand(v,bitnot(UNMASK)))
Run
however, I want to be able to change the result like :
a = ARR(x)
a[0] =
Run
How can I return a var seq[Val] (or
`var a: seq[Val] a = ARR(x) a[0] = `
Run
Second that, `include` will effectively duplicate your type declarations and
will probably cause your code to get ambiguous symbol warnings.
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.
Sorry, I didn't see the post before.
You're almost there. There's two small things missing in your code.
1. you should add a newline to the string you write to the input stream. cat
wants that newline
2. instead of closing the input stream, you flush it.
Note however that with cat at
Still hoping someone can offer some insight on the use of inputStream. Is the
documentation simply wrong on this point?
In c it depends which allocator you use. Most people don't use the default
malloc because it's slow. They have a layer above it which uses it for big
chunks while using internal thing for small chunks.
For really big chunks Nim will use the standard is malloc and they will free
back. This does
No, the memory will be released to the OS.
The GC does release memory under certain
[circumstances](https://github.com/nim-lang/Nim/blob/b07694cd90ab7c6eb4660971ddb818b461d4eed8/lib/system/alloc.nim#L861).
The code is rather hard to follow though, and I'm not sure _when_ exactly
would the GC release memory back to OS. But if you
Is this true with manual memory management as well, or just the built-in memory
management and GC?
Like, if you were to, say, manually allocate space to load and copy/resize a 20
megapixel photo, will the app continue to occupy 200 MB of RAM even after the
memory is released by the app?
\--opt:speed implies -O3|
---|---
\--opt:size implies -Os|
passing -O4 will impli -O3
It's either -O3 or -Os, you can't have both at the same time hence the conflict.
Now it seems like there might still be an issue but without reproducible
example it's hard to investigate. You can
I don't think they are interfering. The -O4 option is only set for speed and
I'm getting the exact same result (900+KB vs 600+KB) even after completely
removing it.
Hmm... I see your point. But then how would I be able to store an object's
address? (perhaps, the solution would be to use no GC whatsoever which is
pretty much what I'm doing?)
Btw... here is an experimental implementation of NaN-tagging I've just written
(roughly based on this article:
`-O4` will conflict with building for size `-Os`
Don't cast ref objects unless the underlying representation is compatible
(seq[byte] and strings).
Definitely don't cast ref objects to int. How would the garbage collector
collect that?
Do you see anything wrong (particularly memory-safety-wise) with this code?
let v = Value(kind: stringValue, s: "hello")
let z = cast[int](v)
echo repr(cast[Value](z))
echo cast[Value](z).stringify()
Run
I've yet to see such code for Nim, but Nim's `cast` is well prepared for it.
The only difference is the `-d:mini` flag, you don't use `--opt:size`.
In additon to what @mratsim said both `shallowCopy` and `deepCopy` will likely
be deprecated. `shallowCopy(x, y)` should have been `x = move(y)` and
`deepCopy` should be something like `send` (send data to a different thread).
32 matches
Mail list logo
