Re: Can I access arrays faster than this?
> Now that it's all working (me now understanding what's going on) I looked > around for a nice way to enforce changes to all my literals and types, and > found an example here by While Araqs example macro is very interesting, I strongly assume that performance impact of float literal types is only minimal in most cases. Because for CPU computations, what makes the performance difference is generally that for float32 number of values in caches is 2 time compared to float64. The math operations in FPU itself make no real difference (for x86 CPU), and I would even guess that C backend can optimize it when result is stored in a f32 var. For ARM CPU or GPU code literal types may make a difference indeed. Do you have an example for this case already?
Re: Can I access arrays faster than this?
> * The Nim code isn't in a main procedure > > * The C++ code is using int s (32 bits) while Nim is using int s (64 bits). > Nim's int type is always the size of a pointer, so you can use it for > indexing arrays. The difference in size between those types means that the > Nim program is processing twice as much data. The 32 bit / 64 bit made a noticeable difference - that was an excellent suggestion. I looked around for a nice way to enforce changes to all my literals and types, and found an example [here](https://forum.nim-lang.org/t/1267#19038) by @Araq that I've modified to be more generic. I love that nim supports this! I may rework it and submit it as a module since it's so useful.
Re: Wrapping an object without generics
I think the `variant` package is exactly what I need. I can't really use object variants, since I don't know what kind of data is going to be stored within the object declaration itself (the user declares their own type and stores it within the object).
Re: Can I access arrays faster than this?
That's a neat trick! Thanks for mentioning it. I'll have to learn about how the non-`.nim` files all actually work as I've been avoiding them.
Re: Can I access arrays faster than this?
If you can't break your habit, you can always add a few lines near the top (before all the `release`-dependent switching) of your `nim.cfg`: @if r: #Allow short alias -d:r to activate fast release mode define:release @end Run Perhaps somewhere you picked up a `$HOME/.config/nim.cfg` that does exactly this, and then lost it somehow moving between accounts/machines or maybe `nim.cfg` to `.nims`? There's surely also some similar Nim Script/`.nims` variant
Re: Introducing Norm: a Nim ORM
Hi all, regarding the discussion last year @ThomasTJdev mentioned I came up with my own solution of a rdbms-backend. It´s preminilary but stable for sqlite3 : [https://github.com/mikra01/nimdb](https://github.com/mikra01/nimdb) . Suggestions and PR´s welcome - I hope it´s intuitive. Sqlite's incremental blob api and rowid-handling (for inserts) is missing. I planned further examples with the chinook database. At the moment I am working at the odbc-part so it could be possible that I have to change the API a little bit..
Re: Odd behavior with pairs on string and runeAt
> The question was more centered around what the procedure of runeAt is for That is impossible to guess from the subject of your message and from its text. I am not sure for what runeAt() is intended, but from its documentation Returns the rune in s at byte index i Run and the fact that runes in unicode strings may occupy more than one single byte it is clear that when used in a loop of byte indices it will give the same rune multiple times.
