Nimble broken for pre-built binary installs
I'm trying to write a bazel macro for compiling nim modules. In order to make the builds more reproducible, I would like to avoid using choosenim because it has an external dependency on the ~/.choosenim/current flag file. I'm trying to install an exact version of nim in docker, but it appears that I cannot use nimble to install any packages. This is the error I get: (02:12 AM):~$ docker run -it --rm ubuntu root@539b4affad2f:/# apt-get update -qq && apt-get install -y curl xz-utils git > /dev/null debconf: delaying package configuration, since apt-utils is not installed root@539b4affad2f:/# curl -sL https://nim-lang.org/download/nim-1.0.4-linux_x64.tar.xz -o /tmp/nim-1.0.4-linux_x64.tar.xz && tar -xf /tmp/nim-1.0.4-linux_x64.tar.xz -C /tmp/ && cp -r /tmp/nim-1.0.4/bin/* /usr/local/bin && cp -r /tmp/nim-1.0.4/lib/* /usr/local/lib && nimble install -y nimpy Prompt: No local packages.json found, download it from internet? -> [forced yes] Downloading Official package list Success Package list downloaded. Downloading https://github.com/yglukhov/nimpy using git Tip: 2 messages have been suppressed, use --verbose to show them. Error: Could not read package info file in /tmp/nimble_3109/githubcom_yglukhovnimpy/nimpy.nimble; ... Reading as ini file failed with: ... Invalid section: . ... Evaluating as NimScript file failed with: ... /tmp/nimblecache/nimscriptapi.nim(7, 8) Error: cannot open file: strformat ... printPkgInfo() failed. root@539b4affad2f:/# nim -v Nim Compiler Version 1.0.4 [Linux: amd64] Compiled at 2019-11-27 Copyright (c) 2006-2019 by Andreas Rumpf active boot switches: -d:release root@539b4affad2f:/# nimble -v nimble v0.11.0 compiled at 2019-11-27 09:21:44 git hash: couldn't determine git hash Run I don't get the same issue if I install nim through choosenim. Any idea how I could fix this? I found this other post from a month ago that may be related. [https://forum.nim-lang.org/t/5627#34964](https://forum.nim-lang.org/t/5627#34964)
Re: Tables or seq
We cannot help without more details. What database / database library / ORM are you using? How does it treat [Table](https://nim-lang.org/docs/tables.html#Table) objects differently from seq? If it's an SQL database, what SQL does it execute? Etc.
Re: Error: 'solve' doesn't have a concrete type, due to unspecified generic parameters.
Thank you, I understand now! **In case of inner procs, the generic context is already defined for them coming from the outer proc and you don 't need to redefine it (but if you introduce new generic parameters).** If the compiler had issued a warning that I was redefining already existing generic variables in the inner procs, it would have given me a hint of the problem. I had tried using other generic variable names in the inner procs without success and I was stuck with that strange compiler error message about generic instanciation... Now it make sense. Perhaps this rule about generic scope and inner procs should be listed in the documentation. Thanks again @hyl and @mashingan!
Re: hello world issues
> Now what if I wanted to create 32-bit-executable? In your current cmd session, invoke `set PATH=d:\your-mingw32-i686-path-bin;%PATH%` , this way the mingw32 32bit will be prioritized.
Re: hello world issues
Success: I deleted the manual extracted mingw-folder and restarted `finish.exe`, which subsequently downloaded the appropriate mingw-package. Thanks to you both for the help. Now what if I wanted to create 32-bit-executable? In my understanding I have to download mingw32 additionally and invoke the nim-compiler using `--cpu:i386` , but that alone won't do it, I assume, because the path is set to the 64bit-mingw.
Re: hello world issues
If you're sure that you've installed 64 bit version of mingw, probably you've already had 32 bit one from previous installation of some other IDE/tool and it takes precedence on your system path.
hello world issues
Newbie. Downloaded and installed on win10x64 as explained on the download page. Choose the 64bit-packages of nim and mingw, because I'm working on win64. After reboot new path is available. Now I tried the easiest, compile helloworld: nim c helloworld.nim It results in a longer error message: Error: execution of an external compiler program 'gcc.exe -c -w -mno-ms-bitfields -IC:\nim-1.0.4\lib -IE:\Nim\Test -o C:\Users\cs\nimcache\hello_d\@mhello.nim.c.o C:\Users\cs\nimcache\hello_d\@mhello.nim.c' failed with exit code: 1 In file included from C:\Users\cs\nimcache\hello_d\@mhello.nim.c:9:0: C:\nim-1.0.4\lib/nimbase.h:457:13: error: size of array 'Nim_and_C_compiler_disagree_on_target_architecture' is negative typedef int Nim_and_C_compiler_disagree_on_target_architecture[sizeof(NI) == sizeof(void*) && NIM_INTBITS == sizeof(NI)*8 ? 1 : -1]; Not really understanding but reading _target_ and "architecture* I look into the compiler manual and find `--cpu:SYMBOL` . But where are the SYMBOLS listed and explained? I found an example `--cpu:i386` and simply tried it: nim c --cpu:i386 helloworld.nim Bingo, exe is generated without complains. But I feel uncomfortable because I don't really understand the things happening here. What did I do wrong? How can I avoid frustration already on the very basic step? Where do I find systematic documentation about those issues?
Re: Object Variants and redefinition of labels or reusbility of field names
@treeform, that's the way it's usually done, but the idea is to prevent redundant naming for those entities that represent the same. If either the labels or the field names can be duplicated, then the code from then forward is cleaner and less cryptic. Here how it works in Pascal, for the 1D, 2D and 3D part. It doesn't look as nice, but the principle is the same: field x will be shared by 1D, 2D and 3D points; field y for 2D and 3D; and field z will only be used by 3D. Type Point = Record X : Longint; Case byte of 2 : (Y : Longint; case byte of 3 : (Z : Longint); ); end; Run That's the way is not done that way because
