**1)** In **nextp_init** in the line below, **i** can start from eithre '0' or
'1'.
for i in 0|1..
The only operator with this gotcha is < right? Maybe it would be best to just
deprecate it. Is there unary >?
By the way, Nim manual has a part with the discouraged syntax
[here](https://nim-lang.org/docs/manual.html#generics-generic-concepts-and-type-binding-rules)
proc
He, good catch. In general we advocate to use `..<` instead of `.. <`. I see no
alternative to "unary operators bind tighter than binary operators".
As it turns out, it was a somewhat subtle bug in the code. The compiler is fine.
Change the following code:
proc segsieve(Kn: int) = # for Kn resgroups in segment
for b in 0 ..
> Can you show me how to do that?
When you are using the Nim compiler from the command line, then in the current
working directory a subdirectory with name nimcache is created. For example
"nim c test.nim" creates "nimcache/test.c". You can inspect that intermediate C
code. When you have clang
> The inexorable conclusion is there is a fundamental bug in the structure of
> the language which causes this error to occur.
Are you sure about this? I found at least one difference between the C++ and
the Nim implementation (the first loop in `next_pinit` starts with 1 in C++ and
and with 0
Actually I'm not a C/C++ programmer, I'm (mostly now) a Ruby programmer who is
functional in C++, and haven't really done anything in C of any note.
I've been looking to see how to view the C/C++ that Nim is generating but I
don't know how to do that. Can you show me how to do that?
Remember,
> The inexorable conclusion
Does your code really only works when uint is used? Because most of us try to
avoid using uint, so uint is not that much tested.
Have you tried without optimization or different C compiler backend?
Have you tried compiling to C++ instead of C? (nim cpp test.nim)?
I
You can do pretty traditional OOP in Nim if you want to (except for proper
abstract methods). Here's an example:
# main.nim
# Free Public License 1.0.0
#
# Permission to use, copy, modify, and/or distribute this software for
# any purpose with or without fee is
Yeah ok, you can only compile a single Nim program to JS. But that program can
consist of as many Nim modules as necessary.
@alexsad - don't try to compare JS code compiled by Nim with hand-written JS.
It's almost the same if you compare hand-written C++ with C++ code compiled by
Nim
I've heard assembler is very unsafe and low level -- is asm generation possible
to avoid with GCC?
After compilation to js and run it in the browser I see in developer tools that
window object has many variables. You can also detect them in
[https://nim-lang.org/docs/theindex.html](https://nim-lang.org/docs/theindex.html)
[I've heard global variables are
In other words, the "problem" is that in order for you to be able to stuff a
bunch of items into a "bag", shake the bag, and then pull one out of it - and
**still knowing the type of what you pulled out** \- requires storing type
information together with each item. Nim, as many statically
I see that you are using the pairs iterator followed by a if condition in the
Nim code. Can you check without? so that it's more in line with the C++ code?
for j, prime in primes: # for each prime r1..sqrt(N)
if nextp[row + j] < uint(Kn): # if 1st mult resgroup
15 matches
Mail list logo