Keep in mind that you can write some of your own compile time methods if (for
example) you're regularly checking for something in the AST.
> I'm also reached this limit before, but avoided it by simplifying
> compile-time code.
Alright, I take it back.
BTW `let` instead of `const` for computed lookup tables is also an option.
Depends, but not really. An object does not only consist of fields, it can have
`case` and `when` etc.
I'm also reached this limit before, but avoided it by simplifying compile-time
code. You may try to find a way to reduce number of function calls per loop
iteration to fit the limit.
1. It is perfectly feasible to write a Nim program that outputs an array
literal as a string. The compiler supports this out of the box with
`staticExec` and its caching mechanism. No need for Ruby.
2. You're the first person on earth that did run into this limit of Nim's VM,
afaict anyway.
> I could use Ruby to create all the parameters and dump them into a file too,
> which would be easier.
You could, couldn't you? It does sound better than doing this:
> displayed to terminal, copied, pasted into an editor, line formatted, copied,
> then pasted the formatted array values into
I could use Ruby to create all the parameters and dump them into a file too,
which would be easier.
**I Don 't want to jump through extra HOOPs because the Nim compiler is
deficient!!**
I don't have to do this in C++.
The compiler should work for the human, not the other way around.
As a temporary workaround, couldn't you just take your existing Nim function,
use it to generate your stuff at runtime, then dump it into a .nim file?
I raised this issue regarding 0.17.2 but it still persists in 0.18.0.
I want to generate some system constants at compile time.
I need to generate some constant arrays of numbers for a (selectable) prime
generator (PG).
When the array size gets past some (?) value the compiler quits with this
Doesn't the Nim compiler already have a set of such functions for internal use?
Nim is not Delphi. You cannot compile and run this.
The full output of `sh build.sh && bin/nim c koch && ./koch tools` would be
useful.
The idea always was to have more convenient accessors for the ASTs that
`getType` returns. But for now we're stuck with the primitives.
Are you sure that is what's happening? Never heard of such a problem before.
Thank you, worked)
if line =~ re".*\d{4}\/\d{2}\/\d{2}":
`find` looks for the pattern all over the string, while `=~` expects the entire
string to match the pattern.
I know it's possible to get information by examining the AST associated with a
type's symbol, but wouldn't it make more sense to provide a compile-time API
that allows one to query it directly? For instance, something like
`TypeName.hasField("fieldName")` or `for field in TypeName.fields` would
I have started [RFC #7337](https://github.com/nim-lang/Nim/issues/7337) to
discuss a common standard on how Nim and its ecosystem should interface with
binary data.
This was started for cryptographic and hashing needs but it seems to be a much
broader issue than that: graphics, networking,
parseopt.
Please see this article
[version-0180-released](https://nim-lang.org/blog/2018/03/01/version-0180-released.html)
I upgraded from nim version 0.17 to 0.18 and I'm in the process of updating my
code to remove the deprecated warnings.
What is the replacement for parseopt2?
I am trying to compile nim on AWS instances of linux. I've tried on the amazon
linux -which descends from Fedora- and on an Ubuntu instance.
I get the following message:
> ... Hint: gcc -c -w -pthread -O3 -fno-strict-aliasing
> -I/home/ubuntu/.choosenim/toolchains/nim-0.18.0/lib -o
>
21 matches
Mail list logo
