October 13, 2018
On Saturday, 13 October 2018 at 09:22:16 UTC, Vijay Nayar wrote:
>
> I downloaded the reference NIM implementation and got the latest nim compiler, but I received the following error:
>   $ nim c --cc:gcc --d:release --threads:on twinprimes_ssoz.nim
>   twinprimes_ssoz.nim(74, 11) Error: attempting to call undeclared routine: 'sort'
>
> For a person not familiar with nim, what's the fastest way to fix that?

import algorithm

thats all but then it spits out

lib/nim/pure/algorithm.nim(144, 11) Error: interpretation requires too many iterations

October 13, 2018
On Saturday, 13 October 2018 at 14:32:33 UTC, welkam wrote:
> On Saturday, 13 October 2018 at 09:22:16 UTC, Vijay Nayar wrote:
>>
>> I downloaded the reference NIM implementation and got the latest nim compiler, but I received the following error:
>>   $ nim c --cc:gcc --d:release --threads:on twinprimes_ssoz.nim
>>   twinprimes_ssoz.nim(74, 11) Error: attempting to call undeclared routine: 'sort'
>>
>> For a person not familiar with nim, what's the fastest way to fix that?
>
> import algorithm
>
> thats all but then it spits out
>
> lib/nim/pure/algorithm.nim(144, 11) Error: interpretation requires too many iterations

I ran into the same problem as you did, and then followed the instructions from the error.  I modified the compiler source and increased the number of maximum iterations from 3_000_000 to 1_000_000_000, rebuilt and installed it, but still ran into the exact same problem.  There may be something up with the algorithm itself.
October 13, 2018
On Saturday, 13 October 2018 at 14:32:33 UTC, welkam wrote:
> On Saturday, 13 October 2018 at 09:22:16 UTC, Vijay Nayar wrote:
>>
>> I downloaded the reference NIM implementation and got the latest nim compiler, but I received the following error:
>>   $ nim c --cc:gcc --d:release --threads:on twinprimes_ssoz.nim
>>   twinprimes_ssoz.nim(74, 11) Error: attempting to call undeclared routine: 'sort'
>>
>> For a person not familiar with nim, what's the fastest way to fix that?
>
> import algorithm
>
> thats all but then it spits out
>
> lib/nim/pure/algorithm.nim(144, 11) Error: interpretation requires too many iterations

My mistake. I updated the file and forgot to include the 'import algorithm' directive. The file is now fixed to include it. Download the corrected version or patch your file accordingly.

As stated in the file intro **YOU MUST DO THIS** to get it to compile with current Nim (they were supposed to fix this in this version 0.19.0 but didn't).

 To compile for nim versions <= 0.19.0 do following:
 1) in file: ~/nim-0.19.0/compiler/vmdef.nim
 2) set variable: MaxLoopIterations* = 1_000_000_000 (1 Billion or >)
 3) then rebuild sysem: ./koch boot -d:release

If you are using 'choosenim' to install Nim (highly advisable) the full path is:

 ~/.choosenim/toolchains/nim-0.19.0/compiler/vmdef.nim

I'll post performance results from my laptop to give reference times to compare against.
October 13, 2018
On Saturday, 13 October 2018 at 15:19:07 UTC, Jabari Zakiya wrote:
> On Saturday, 13 October 2018 at 14:32:33 UTC, welkam wrote:
>> On Saturday, 13 October 2018 at 09:22:16 UTC, Vijay Nayar wrote:
>>> [...]
>>
>> import algorithm
>>
>> thats all but then it spits out
>>
>> lib/nim/pure/algorithm.nim(144, 11) Error: interpretation requires too many iterations
>
> My mistake. I updated the file and forgot to include the 'import algorithm' directive. The file is now fixed to include it. Download the corrected version or patch your file accordingly.
>
> As stated in the file intro **YOU MUST DO THIS** to get it to compile with current Nim (they were supposed to fix this in this version 0.19.0 but didn't).
>
>  To compile for nim versions <= 0.19.0 do following:
>  1) in file: ~/nim-0.19.0/compiler/vmdef.nim
>  2) set variable: MaxLoopIterations* = 1_000_000_000 (1 Billion or >)
>  3) then rebuild sysem: ./koch boot -d:release
>
> If you are using 'choosenim' to install Nim (highly advisable) the full path is:
>
>  ~/.choosenim/toolchains/nim-0.19.0/compiler/vmdef.nim
>
> I'll post performance results from my laptop to give reference times to compare against.

Ok, now it builds.  I was previously following the build instructions from the Nim website and am not super clear what the "koch" tool does, but following your instructions, the program does build and run.  I'll take a stab at making a D version.
October 13, 2018
On Saturday, 13 October 2018 at 15:50:06 UTC, Vijay Nayar wrote:
> On Saturday, 13 October 2018 at 15:19:07 UTC, Jabari Zakiya wrote:
>> On Saturday, 13 October 2018 at 14:32:33 UTC, welkam wrote:
>>> On Saturday, 13 October 2018 at 09:22:16 UTC, Vijay Nayar wrote:
>>>> [...]
>>>
>>> import algorithm
>>>
>>> thats all but then it spits out
>>>
>>> lib/nim/pure/algorithm.nim(144, 11) Error: interpretation requires too many iterations
>>
>> My mistake. I updated the file and forgot to include the 'import algorithm' directive. The file is now fixed to include it. Download the corrected version or patch your file accordingly.
>>
>> As stated in the file intro **YOU MUST DO THIS** to get it to compile with current Nim (they were supposed to fix this in this version 0.19.0 but didn't).
>>
>>  To compile for nim versions <= 0.19.0 do following:
>>  1) in file: ~/nim-0.19.0/compiler/vmdef.nim
>>  2) set variable: MaxLoopIterations* = 1_000_000_000 (1 Billion or >)
>>  3) then rebuild sysem: ./koch boot -d:release
>>
>> If you are using 'choosenim' to install Nim (highly advisable) the full path is:
>>
>>  ~/.choosenim/toolchains/nim-0.19.0/compiler/vmdef.nim
>>
>> I'll post performance results from my laptop to give reference times to compare against.
>
> Ok, now it builds.  I was previously following the build instructions from the Nim website and am not super clear what the "koch" tool does, but following your instructions, the program does build and run.  I'll take a stab at making a D version.

Interesting results so far.  I have a partially converted program here:  https://gist.github.com/vnayar/79e2d0a9850833b8859dd9f08997b4d7

The interesting part is that during compilation (with the command "dmd twinprimes_ssoz.d"), the compilation will abort with the message "Killed" and no further information. That's a new one for me, so I'm looking into the cause.
October 13, 2018
On Saturday, 13 October 2018 at 17:36:33 UTC, Vijay Nayar wrote:
> On Saturday, 13 October 2018 at 15:50:06 UTC, Vijay Nayar wrote:
>> On Saturday, 13 October 2018 at 15:19:07 UTC, Jabari Zakiya wrote:
>>> On Saturday, 13 October 2018 at 14:32:33 UTC, welkam wrote:
>>>> On Saturday, 13 October 2018 at 09:22:16 UTC, Vijay Nayar wrote:
>>>>> [...]
>>>>
>>>> import algorithm
>>>>
>>>> thats all but then it spits out
>>>>
>>>> lib/nim/pure/algorithm.nim(144, 11) Error: interpretation requires too many iterations
>>>
>>> My mistake. I updated the file and forgot to include the 'import algorithm' directive. The file is now fixed to include it. Download the corrected version or patch your file accordingly.
>>>
>>> As stated in the file intro **YOU MUST DO THIS** to get it to compile with current Nim (they were supposed to fix this in this version 0.19.0 but didn't).
>>>
>>>  To compile for nim versions <= 0.19.0 do following:
>>>  1) in file: ~/nim-0.19.0/compiler/vmdef.nim
>>>  2) set variable: MaxLoopIterations* = 1_000_000_000 (1 Billion or >)
>>>  3) then rebuild sysem: ./koch boot -d:release
>>>
>>> If you are using 'choosenim' to install Nim (highly advisable) the full path is:
>>>
>>>  ~/.choosenim/toolchains/nim-0.19.0/compiler/vmdef.nim
>>>
>>> I'll post performance results from my laptop to give reference times to compare against.
>>
>> Ok, now it builds.  I was previously following the build instructions from the Nim website and am not super clear what the "koch" tool does, but following your instructions, the program does build and run.  I'll take a stab at making a D version.
>
> Interesting results so far.  I have a partially converted program here:  https://gist.github.com/vnayar/79e2d0a9850833b8859dd9f08997b4d7
>
> The interesting part is that during compilation (with the command "dmd twinprimes_ssoz.d"), the compilation will abort with the message "Killed" and no further information. That's a new one for me, so I'm looking into the cause.

It may be also running into a hard time limit imposed on compilation that Nim had/has that prevented my code from initially compiling. I'm generating a lot of PG parameter constants at compile time, and it's doing a lot of number crunching and building larger and larger arrays of constants as the PG's get larger.

Try compiling with successive PG's (just P5, then P5 and P7, etc) to see where it fails. That will let you know the code is working correctly, and that the compiler is choking either/and because of a hard time limit and/or memory limit. That's why I put in a compiler output statement in 'genPGparameters' to see the progression of the PG parameters being built by the compiler to initially find when the compiler started choking. You may also need to patch whatever facility in the D compiler chain that controls this too.

October 13, 2018
On Saturday, 13 October 2018 at 18:05:45 UTC, Jabari Zakiya wrote:
>
> It may be also running into a hard time limit imposed on compilation that Nim had/has that prevented my code from initially compiling. I'm generating a lot of PG parameter constants at compile time, and it's doing a lot of number crunching and building larger and larger arrays of constants as the PG's get larger.
>
> Try compiling with successive PG's (just P5, then P5 and P7, etc) to see where it fails. That will let you know the code is working correctly, and that the compiler is choking either/and because of a hard time limit and/or memory limit. That's why I put in a compiler output statement in 'genPGparameters' to see the progression of the PG parameters being built by the compiler to initially find when the compiler started choking. You may also need to patch whatever facility in the D compiler chain that controls this too.

It's P17, the biggest one that takes the longest to build in the Nim version. I actually don't know what memory limits exist for the D compiler at compile-time, so I may need to do some homework.
October 13, 2018
On Saturday, 13 October 2018 at 18:14:20 UTC, Vijay Nayar wrote:
> On Saturday, 13 October 2018 at 18:05:45 UTC, Jabari Zakiya wrote:
>>
>> It may be also running into a hard time limit imposed on compilation that Nim had/has that prevented my code from initially compiling. I'm generating a lot of PG parameter constants at compile time, and it's doing a lot of number crunching and building larger and larger arrays of constants as the PG's get larger.
>>
>> Try compiling with successive PG's (just P5, then P5 and P7, etc) to see where it fails. That will let you know the code is working correctly, and that the compiler is choking either/and because of a hard time limit and/or memory limit. That's why I put in a compiler output statement in 'genPGparameters' to see the progression of the PG parameters being built by the compiler to initially find when the compiler started choking. You may also need to patch whatever facility in the D compiler chain that controls this too.
>
> It's P17, the biggest one that takes the longest to build in the Nim version. I actually don't know what memory limits exist for the D compiler at compile-time, so I may need to do some
> homework.

Yes, that's what I figured, because that's when the Nim compiler initially balked. The variable that was patched in the Nim configg file set a hard limit on number of operations the compiler could do. It's used as a break switch on a runaway process (infinite loop, etc). It's probably something like that in the D compiler too, just guessing offhand. I hope it isn't a memory limit. However, the program will run fine without using P17. It's currently selected as the optimum PG for inputs greater than 15 trillion (15,000,000,000,000), so the program will run fine and produce correct output using P13 instead, but just not as fast.
October 13, 2018
On Saturday, 13 October 2018 at 18:14:20 UTC, Vijay Nayar wrote:
> On Saturday, 13 October 2018 at 18:05:45 UTC, Jabari Zakiya wrote:
>>
>> It may be also running into a hard time limit imposed on compilation that Nim had/has that prevented my code from initially compiling. I'm generating a lot of PG parameter constants at compile time, and it's doing a lot of number crunching and building larger and larger arrays of constants as the PG's get larger.
>>
>> Try compiling with successive PG's (just P5, then P5 and P7, etc) to see where it fails. That will let you know the code is working correctly, and that the compiler is choking either/and because of a hard time limit and/or memory limit. That's why I put in a compiler output statement in 'genPGparameters' to see the progression of the PG parameters being built by the compiler to initially find when the compiler started choking. You may also need to patch whatever facility in the D compiler chain that controls this too.
>
> It's P17, the biggest one that takes the longest to build in the Nim version. I actually don't know what memory limits exist for the D compiler at compile-time, so I may need to do some homework.

It's not just DMD either.

$ ldc2 twinprimes_ssoz.d
...
generating parameters for P17
Killed

$ gdc twinprimes_ssoz.d
...
generating parameters for P17
gdc: internal compiler error: Killed (program cc1d)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.

$ dmd twinprimes_ssoz.d
...
generating parameters for P17
Killed

October 13, 2018
On Saturday, 13 October 2018 at 18:31:57 UTC, Vijay Nayar wrote:
> On Saturday, 13 October 2018 at 18:14:20 UTC, Vijay Nayar wrote:
>> On Saturday, 13 October 2018 at 18:05:45 UTC, Jabari Zakiya wrote:
>>>
>>> It may be also running into a hard time limit imposed on compilation that Nim had/has that prevented my code from initially compiling. I'm generating a lot of PG parameter constants at compile time, and it's doing a lot of number crunching and building larger and larger arrays of constants as the PG's get larger.
>>>
>>> Try compiling with successive PG's (just P5, then P5 and P7, etc) to see where it fails. That will let you know the code is working correctly, and that the compiler is choking either/and because of a hard time limit and/or memory limit. That's why I put in a compiler output statement in 'genPGparameters' to see the progression of the PG parameters being built by the compiler to initially find when the compiler started choking. You may also need to patch whatever facility in the D compiler chain that controls this too.
>>
>> It's P17, the biggest one that takes the longest to build in the Nim version. I actually don't know what memory limits exist for the D compiler at compile-time, so I may need to do some homework.
>
> It's not just DMD either.
>
> $ ldc2 twinprimes_ssoz.d
> ...
> generating parameters for P17
> Killed
>
> $ gdc twinprimes_ssoz.d
> ...
> generating parameters for P17
> gdc: internal compiler error: Killed (program cc1d)
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
>
> $ dmd twinprimes_ssoz.d
> ...
> generating parameters for P17
> Killed

In the Nim code, starting line 91 is when the PG constants are being generate at compile time.

---------------------------------------------------------
# Generate at compile time the parameters for PGs P5-P17.
const parametersp5  = genPGparameters(5)
const parametersp7  = genPGparameters(7)
const parametersp11 = genPGparameters(11)
const parametersp13 = genPGparameters(13)
const parametersp17 = genPGparameters(17)
---------------------------------------------------------

Can it compile just using P5 (the first line, others commented out), and then P7, etc?

I'm not understanding your comments now.

If you can get a working version up and running (with correct output) we can solve the P17 compiler issues later (or in a parallel forum thread), especially if you have to delve into the weeds of the compiler chain.

In my mind (same with Nim process) getting working code using any PG is first order priority (because you'll need getting multi-threading working too). Once you can do that, by default, you can then use any generator you want if you create the correct parameters for it. That's one of the advantages of the algorithm, it's PG agnostic (as long as your hardware will accommodate it).

So don't prioritize getting P17 to compile right now (in this thread). Create the working generic structure that can work with any PG first.