[https://github.com/nim-lang/zip/issues/39](https://github.com/nim-lang/zip/issues/39)
Hi JohnAD,
there is already an issue open :
[https://github.com/nim-lang/Nim/issues/9453](https://github.com/nim-lang/Nim/issues/9453)
The sqlite3-part is finished - if you like to dive in please take a look at the
sqlite3_examples folder of my project. You can "mix" my module with Nim´s
(db_s
Currently the database modules (db_mysql, db_postgre, and db_sqlite) all rely
on using `nil` to represent NULL when passing data in/out of the module.
As most folks know, Nim is moving away from production support of `nil`, so it
would be good to make changes to those libraries. I'm happy to hel
Yes, there is indeed a change in the documentation between 0.19.6 and 0.19.9.
Personally, for signed integers I would find more consistent to use an
arithmetic shift to the right. With a logical shift, _-2 shr 1_ is equal to
9223372036854775807 on a 64 bits machine which may seem odd. We would r
I use fontawesome on this forum (which uses Karax) and it works fine (for
example
[here](https://github.com/nim-lang/nimforum/blob/5714ad0c6aafcd7b95a433d97f7b4069d5cc791b/src/frontend/threadlist.nim#L75)).
It's possible that something changed between fontawesome versions or karax
versions. Do
I hope that by C++'s approach(unique_ptrs) you meant Rust's approach(smart
unique pointers) because the former's way is neither safe(allows dangling
pointers) nor nice(useless and verbose wrapper) nor efficient(allows leaks,
requires extra steps to work with the data).
Having a single-alias ref
C and most importantly its std lib never really cared about performance, it's
just a low-level language with low-level features. If we look at how it manages
strings(strlen, strcat etc. hardly better than immutable strings), memory(cost
of many mallocs(poorly managed blocks) and how free works)
> I have not been able to reproduce
Well, it is very confusing. I looked in 019.9 docs this morning, and indeed it
was said that shr behaves as ashr. But example was stlll like shr, and
additional a separate ashr was mentioned. So maybe just a bug in docs.
Otherwise for sure adrianv would be ri
I have not been able to reproduce this behavior. On my Manjaro Linux with the
last development version (built with _choosenim_ ) _shr_ is a logical right
shift, not an arithmetic one. This is also the case with the last stable
version.
And there is already an arithmetic right shift in the syste
The problem is that iterators default to being **inline**. This means the
compiler transforms the iterator into a block of code that is executed **only
when it is in an iteration construct** like a for loop.
So in
for file in walkDir(datapath / source / $instrument / "Prices"):
I read through the document "Ownership You Can Count On" on which this idea is
based, and it seems to me that the positive results were pretty nebulous, with
memory use just a little bit down compared to as used by GC on the average and
performance not all that different at all, with my point be
> Nim probably will never reach 100% of C's speed
I have some code where the straightforward Nim code runs faster than the
straightforward C code. I haven't figured out why yet, but it's about a 10-15%
improvement, and the code strikes me as a straightforward port.
While I do want to look into
If I use fontawesome in karax app, eamply:
tdiv(class = "control has-icons-left"):
input(required = "", `type` = "text",
class = "input",
placeholder = "uživatelské jméno"
[CODE] import streams import zip/zlib
var FinName = "" var FouName = ""
let FinStream = newFilestream( FinName, fmRead ) let FouStream = newFilestream(
FouName, fmWrite )
var Uncompressed = readAll( FinStream ) var Compressed = compress(
Uncompressed, Uncompressed.len, Z_DEFAULT_COMPRE
I don't know if I am overreacting, but just realized that
Run
has changed its meaning from unsigned shit to sign preserving shift. IMHO this
breaks a lot of code in a very dangerous way. A more thoughtful solution would
have been to introduce a sign preserving operator
15 matches
Mail list logo
