As shown in many other threads, you can get the same speed in Nim as in C or
Assembly, especially for scientific computing:
* [https://forum.nim-lang.org/t/5124](https://forum.nim-lang.org/t/5124)
* my experiments for Project Picasso:
[https://github.com/mratsim/weave/tree/master/benchmarks/
Anyway, your help saved the day. I'm expanding our use of Nim internally.
I still have a lot of concerns about performance for simple things, but Nim has
so much upside that I think we'll be ok.
Yes, a "canary field" would be a good debug-mode for reference-counting. That's
a very good idea.
Buffer-overflow is hard to detect, but when you switch to malloc/free there is
a very good chance that valgrind will notice something. Maybe that's wishful
thinking on my part.
I agree, generic int parsing would be a very nice addition to
strutils/parseutils.
Somehow binary, hex and octal got generic int parsing before plain number
stored in strings:
[https://github.com/nim-lang/Nim/pull/11107/files](https://github.com/nim-lang/Nim/pull/11107/files).
And haha good ca
Oh, I should also mention that I am parsing GBs of data. In bioinformatics, we
deal with TBs.
On **strscans** , apparently `$+` is the way to parse non-whitespace into a
`sting`. That was not at all obvious to me. But even that feature is not
enough. The failure to specify integer sizes is real
Yes, the suggestion to use **parseutils** and **strscans** is not a bad one,
and thanks for the code example. But I did consider both of those before
proceeding.
First, I couldn't figure out how `parseBiggestInt` works. It is very important
to specify the size of integer. I don't want a machine
I wasn't sure whether you actually fixed your code with that post now, but I
was already looking at your code when I saw the post, so I continued.
I fixed the code differently, by just removing the c types you used. I trust
that the test case works, because I'm not sure if I broke something. :)
> I really, really want the "newruntime". This kind of mistake is way too easy.
This mistake is easy, but you really should reconsider mixing such low-level
code with your high-level scripts. Any use of addr, ptr, cast should be very
deliberate, the analogy to Rust's unsafe is very apt here. I'm
You're right that returning `Db` instead of `ref Db` "fixes" the problem, but
is that really a solution? Returning a "ref" simply means that `load_rdb()` is
really a Db constructor. That should work.
And no, an alias for `DbRef = ref Db` does
_[not](https://forum.nim-lang.org/postActivity.xml#n
Fixed:
[https://github.com/pb-cdunn/nim-help/pull/1](https://github.com/pb-cdunn/nim-help/pull/1)
TL;DR: returning a ref Db that contains string is buggy.
I expect it would work with an alias type DbRef = ref Db as its a common
pattern.
It seems a bit tricky to get a small reproducible example to raise on the
tracker though :/.
This will not compile:
nim c --debugger:native -d:nimBurnFree -d:logGC -f -r t_raptor_db.nim
/pbi/flash/cdunn/gh/Nim/lib/system/gc.nim(163, 17) Error: undeclared
identifier: 'stdout'
Run
This will not compile:
nim c --gc:none -d:useMalloc --debugger:native -d:nimBurnFree --newruntime
-f -r t_raptor_db.nim
/pbi/flash/cdunn/gh/Nim/lib/system/mmdisp.nim(414, 48) Error: undeclared
field: 'base' for type system.PNimType [declared in
/pbi/flash/cdunn/gh/Nim/lib/syst
After fixing that (or turning off threads), the whole thing passes. Still no
info on the crash.
With `-d:useMalloc`, **valgrind** finds something interesting, but there are no
line numbers.
==45708== Invalid read of size 8
==45708==at 0x40C5DF: ??? (in
/pbi/flash/cdunn/repo/falconc/try/t_raptor_db)
==45708==by 0xFFEFFE3FF: ???
==45708==by 0x42A043: ???
I thought I'd try `-d:useMalloc`:
nim c --gc:none -d:useMalloc -d:useSysAssert -d:useGcAssert
--debugger:native -d:nimBurnFree -d:corruption -r t_raptor_db.nim
/pbi/flash/cdunn/gh/Nim/lib/system/mmdisp.nim(443, 25) Error: pragmas are
only allowed in the header of a proc; redefi
`-d:nimBurnFree` and `-d:corruption` have not helped so far.
I haven't tried these yet:
* `-d:nimBurnFree`
* `-d:corruption`
* editing `lib/system/mmdisp.nim` "Most of these have no --define equivalent,
unfortunately."
May this help:
[https://github.com/nim-lang/Nim/wiki/Hunting-crashes:-The-ultimate-guide](https://github.com/nim-lang/Nim/wiki/Hunting-crashes:-The-ultimate-guide)
-var sr: SequenceRecord
+var sr = SequenceRecord()
Run
Shoot. That didn't make any difference.
I am not over-stating the problem here. If we cannot fix this, probably the
entire Bioinformatics community will be forced to give up on Nim. (A colleague
Can you try changing [line
236](https://github.com/pb-cdunn/nim-help/blob/master/raptor_db.nim#L236) with
`var sr = SequenceRecord()` ?
I'm not sure but maybe what you're doing is scope-escaping memory? That `var
sr: SequenceRecord` only available in the stack and it got destroyed after you
co
Switching to your wrapper makes no difference for me.
Yes, if you make small changes the code can crash in different places, though I
haven't been able to reproduce your assertion failure.
Do you think you've the actual bug? Could you point me to it?
Hi cdunn
change your strlen wrapper in raptor_db.nim to
proc strlen(a: var Headroom): int =
let n = strlen(cast[cstring](a[0].addr))
echo " calc'd:", n
return n
Run
You'll then get an assertion error in t_raptor_db.nim:
: unhandle
I've pushed a commit to `master` which completely drops all use of the
**unittest** module. It still fails in GC, so it's not a result of any
unittest-macro magic.
There must be something fundamental that I'm doing wrong.
This fairly simple program will fail, and I cannot find my bug:
git clone https://github.com/pb-cdunn/nim-help.git
cd nim-help
make
# nim c -r t_raptor_db.nim
Run
(I am using the `devel` branch of **Nim** , but the problem happens on 0.20.2
also.)
25 matches
Mail list logo
