Re: Change Nim colour on GitHub
PR for color change has been merged: [https://github.com/github/linguist/pull/4900](https://github.com/github/linguist/pull/4900)! It will go live on next release. Last release was 10 days ago, so we will probably wait at least a month for that.
Re: Change Nim colour on GitHub
like this
Re: Change Nim colour on GitHub
btw, note that color-proximity test is something that _might_ be dropped in the future. There is an open issue of languages that have an off brand color and we might want to add Nim to that list with our original (ffdf00) proposal: [https://github.com/github/linguist/issues/4506](https://github.com/github/linguist/issues/4506) Although I must say that orange color is growing on me, I actually realize now for the first time that nim forum is actually using a similar shade of orange!
Re: Change Nim colour on GitHub
it seems `.nimf` is missing instead, see [https://github.com/nim-lang/Nim/issues/9647](https://github.com/nim-lang/Nim/issues/9647)
Re: Change Nim colour on GitHub
Thank you @Yardanico!
Re: Change Nim colour on GitHub
I tested to see how #ffc200 would look on github (changing manually the color using inspect element). You see it on the left above. It might be a bit too light against github white (I kind of see it out-of-focus). A slightly darker option (on the right) could be [https://www.color-hex.com/color/ebb800](https://www.color-hex.com/color/ebb800) Another advantage of the #e **BB8** 0 option is that it contains name of [https://en.wikipedia.org/wiki/BB-8](https://en.wikipedia.org/wiki/BB-8)
Re: Change Nim colour on GitHub
thanks to @PMunch we now have a nice image from which to pick from (currently) valid colors for github: [https://github.com/PMunch/colourfinder](https://github.com/PMunch/colourfinder) In the image the blacked out areas are those that color-proximity test in linguist would declare invalid. This is based on CIEDE2000 color distance, see [https://github.com/pietroppeter/color_distance](https://github.com/pietroppeter/color_distance). My proposal would be to use #ffc200: [https://www.color-hex.com/color/ffc200](https://www.color-hex.com/color/ffc200) * it is in the middle of the spectrum (full saturation). * it is between Yellow (color of crown) and Orange (Araq's favorite color). **Note 1** : to pick a color I used: [https://pinetools.com/image-color-picker](https://pinetools.com/image-color-picker) **Note 2** : I was not able to use the `.. raw::html` rst directive in forum to add ``. I am not sure why since the rst parser seems to support it, maybe it would be fixed by a forum update or maybe I just did something wrong.
Re: Name of nim file at compile time
I think either [StackTraceEntry](https://nim-lang.org/docs/system.html#StackTraceEntry) or [instantiationInfo](https://nim-lang.org/docs/system.html#instantiationInfo) could work.
Re: Is --gc:arc completely independent from the older ownership model?
and the result of arc is now down to 6.75s, see: [https://youtu.be/aUJcYTnPWCg](https://youtu.be/aUJcYTnPWCg)
Re: Is --gc:arc completely independent from the older ownership model?
original post here: [https://forum.nim-lang.org/t/5734#36277](https://forum.nim-lang.org/t/5734#36277)
Re: Awk-Style text processing with Nim
It is also a very nice, self-contained and general enough example that could be added to source code filters [documentation](https://nim-lang.org/docs/filters.html). All other examples start with a proc and are used through an include. This actually makes it clear that Source code filters can be standalone and used for scripting. It definitely improved my knowledge on what Source Code Filters are! Thanks for sharing!
Re: Having problems porting a Python script for computing two cofactors of a number
Yes, there is definitely room for improvements. I just wanted to check if using bigints with minimal changes would be working. And I am actually surprised it does, since I was not able to find a gcd prox overloaded for BigInt (I was expecting to have to provide an implementation). Not sure what is being used there. Also, I I think in place addition and multiplication are not exported in bigints. Regarding the usage of stint, I would guess the actual Telegram protocol might go beyond uint64 and might have a specific size that one can work with.
Re: Having problems porting a Python script for computing two cofactors of a number
Hi, out of curiosity I decided to do a naive "port" of the algorithm to use [https://github.com/def-/nim-bigints](https://github.com/def-/nim-bigints) Apart from the fact that doing that I ran into an issue with bigints ([https://github.com/def-/nim-bigints/issues/27](https://github.com/def-/nim-bigints/issues/27)) the result ([https://play.nim-lang.org/#ix=2lU5](https://play.nim-lang.org/#ix=2lU5)) works and on my machine compiled with `-d:danger` it takes a bit more than 500ms. It might also be interesting to use [https://github.com/status-im/nim-stint](https://github.com/status-im/nim-stint) instead of bigints.
Re: Number of items in a tuple
You can write one like this: [https://forum.nim-lang.org/t/3809#23767](https://forum.nim-lang.org/t/3809#23767)
Re: Detect englobing scope in macros
As an example this is what `unittest` does with templates `setup` and `teardown` inside `suite`: [https://github.com/nim-lang/Nim/blob/version-1-2/lib/pure/unittest.nim#L466](https://github.com/nim-lang/Nim/blob/version-1-2/lib/pure/unittest.nim#L466)
Re: Nim Forum build error
I can confirm changing the requirement to "karax >= 1.1.2" I am able to build successfully nim forum with Nim 1.2 拾!
Re: Nim Forum build error
Thanks for the suggestions. In the end I was able to solve the issue by making a copy of `libsass.so` in `usr/lib`. I did actually find a plain `libsass.so` installing `sassc` with snap (I did run `find \ -name "libsass.so"` to find out I had such a file). I think it is kind of critical to have it in `usr/lib` (at least it might be so according to [this](https://forum.nim-lang.org/t/4509#28184) forum thread). So now the `buildcss` part goes through fine. I still have an issue when compiling frontend because of a Karax error, but I see that it is an [issue](https://github.com/pragmagic/karax/issues/138) that should not be available with a more recent Karax release (it probably is tied to 1.2, that is why in recent nimforum updates it was not caught). I will try later if this is the case and report back here.
Re: Nim Forum build error
I was trying to work through the [Development](https://github.com/nim-lang/nimforum#development) instructions and I ran into the same issue as above while running `nimble devdb`. Running `nimble install karax@#f6bda9a` indeed fixes this issue for me. I do still have a problem: `nimble frontend` fails since it is not able to load `libsass.so`. I did try to install it both trying* `apt install libsass0` and following** [this](https://gist.github.com/edouard-lopez/503d40a5c1a49cf8ae87) install script, but I was not successful. Anyone has suggestions on how to install that? *: `libsass0` provides a `libsass.so.0` (which is an alias for a `libsass.so.0.0.9`) in a folder (`/usr/lib/x86_64-linux-gnu`). Adding that folder to path or copying in nimforum folder and renaming `libsass.so.0.0.9` to `libsass.so` does not solve the issue. **: I end up with a libsass.a which is a static library. I guess it should not be that difficult to ask to compile a dynamic library but I know very little of that to just guess.
Re: RuneImpl doc
The result is correct, the normal way to find out is to click the source link in the docs. It will bring you here: [https://github.com/nim-lang/Nim/blob/version-1-2/lib/pure/unicode.nim#L27](https://github.com/nim-lang/Nim/blob/version-1-2/lib/pure/unicode.nim#L27) The reason is that the implementation of Rune is not to be accessed for the user of the library, so the symbol is not exported. And documentation is generated only for exported symbols.
Re: Nim 1.2 is here
Thank you all! Might as well share this: [https://news.ycombinator.com/item?id=22770700](https://news.ycombinator.com/item?id=22770700)
Re: Handling case in getSectionValue in parsecfg
For the first issue, you could -after parsing the ini file - turn all section keys and parameter keys in lower case.
Re: strformat, use a variant as format specifier?
You can use formatValue from strformat module: [https://play.nim-lang.org/#ix=2etN](https://play.nim-lang.org/#ix=2etN) (see [https://nim-lang.org/docs/strformat.html#implementation-details](https://nim-lang.org/docs/strformat.html#implementation-details))
Re: How does nim infer that a cpu on windows is 64-bit
I guess it is possible that 32bit sqlite is broken (I checked and the md5sum is the same as yours). Anyway now I am happier that I have a 64 bit Nim and gcc running on my 64 bit Windows (and I can use sqlite and ormin). :)
Re: How does nim infer that a cpu on windows is 64-bit
Yes, good suggestion, thank you. It worked and I was able to compile and run the test script! Also when compiling a running a simple echo hostCPU with the 64 bit compiler I do get amd64 as an answer. After this succesful experiment my tentative answer to "How does nim infer that a cpu on windows is 64-bit" would be that it is not inferred at all, but instead it is baked in the compiler (both for nim and gcc). A still outstanding issue is how come the choosenim released version `choosenim-0.5.1_windows_amd64.zip` has a i386 baked in instead of amd64. But this I guess it belongs to choosenim issue tracker. I will open an issue there.
Re: How does nim infer that a cpu on windows is 64-bit
And I think I found my answer in this closed issue in choosenim: [https://github.com/dom96/choosenim/issues/128](https://github.com/dom96/choosenim/issues/128) It appears that if it finds a gcc 32 bit compiler, choosenim will download the 32 bit Nim compiler. I did have in my path only the gcc 32 bit compiler so it was expected behaviour of choosenim.
Re: How does nim infer that a cpu on windows is 64-bit
today to try and solve this issue I did remove all previous nim folders and I installed it again using the most recent choosenim I could find: the release choosenim-0.5.1_windows_amd64 from github. I would assume that to install the 64bit version of Nim but maybe I am wrong (or maybe choosenim tries to infer the architecture and install the version he thinks is the correct). Regardless of arch, even moving the dll sqlite3_32.dll in the same folder as my nim test file (and the resulting .exe) the error is still (when running the exe): could not load sqlite3_32.dll
Re: How does nim infer that a cpu on windows is 64-bit
thank you, I did download mingw64 (I actually used the one which would have been downloaded from choosenim at url [https://nim-lang.org/download/mingw64.7z](https://nim-lang.org/download/mingw64.7z)) and now I have a different error message when compiling a simple `echo "hello"` program which is quite explicit (nim compiler and gcc do not agree on target architecture): In file included from C:\Users\ppeterlongo\nimcache\hello_d\@mhello.nim.c:9:0: C:\Users\ppeterlongo\.choosenim\toolchains\nim-1.0.6\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]; ^~ Run So it appears I am back to square one. Even if my gcc compiler is a 64 bit one now, nim compiler still thinks I am on a 32 bit architecture (which is probably also the reason why chooesnim installed mingw32 instead of mingw64).
Re: How does nim infer that a cpu on windows is 64-bit
thank you, I see now that mingw is the 32 bit version (I did learn that i686-w64-mingw32 is 32 bits while x86_64-w64-mingw32 would be the 64 bit version). I think I will try first to download and install mingw64. Yes, I checked and the dlls are in my path.
Re: How does nim infer that a cpu on windows is 64-bit
yes, sure. -v Nim Compiler Version 1.0.6 [Windows: i386] Compiled at 2020-01-23 Copyright (c) 2006-2019 by Andreas Rumpf git hash: 89b39ee8fe271d0e1b75c15a4c6cf82eb9c13aea active boot switches: -d:release Run -v Using built-in specs. COLLECT_GCC=C:\Users\ppeterlongo\.choosenim\toolchains\mingw32\bin\gcc.exe COLLECT_LTO_WRAPPER=C:/Users/ppeterlongo/.choosenim/toolchains/mingw32/bin/../libexec/gcc/i686-w64-mingw32/6.3.0/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: ../../../src/gcc-6.3.0/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw630/i686-630-win32-dwarf-rt_v5-rev1/mingw32 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-sjlj-exceptions --with-dwarf2 --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/c/mingw630/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw630/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw630/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw630/prerequisites/i686-w64-mingw32-static --with-pkgversion='i686-win32-dwarf-rev1, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/c/mingw630/i686-630-win32-dwarf-rt_v5-rev1/mingw32/opt/include -I/c/mingw630/prerequisites/i686-zlib-static/include -I/c/mingw630/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/c/mingw630/i686-630-win32-dwarf-rt_v5-rev1/mingw32/opt/include -I/c/mingw630/prerequisites/i686-zlib-static/include -I/c/mingw630/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS=' -I/c/mingw630/i686-630-win32-dwarf-rt_v5-rev1/mingw32/opt/include -I/c/mingw630/prerequisites/i686-zlib-static/include -I/c/mingw630/prerequisites/i686-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/mingw630/i686-630-win32-dwarf-rt_v5-rev1/mingw32/opt/lib -L/c/mingw630/prerequisites/i686-zlib-static/lib -L/c/mingw630/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware' Thread model: win32 gcc version 6.3.0 (i686-win32-dwarf-rev1, Built by MinGW-W64 project) Run I actually did a fresh install using latest released choosenim (for windows 64 bit).
How does nim infer that a cpu on windows is 64-bit
Hi, I am trying to understand why Nim compiler thinks that my windows CPU is 32 bits. I ran into this while trying to sue sqlite where the smallest reproducible error would be: import db_sqlite var db = open(connection="test.db", user="test", password="", database="test") Run and the error of the compiler is `could not load: sqlite3_32.dll`. I did try to understand if this was a path problem but the dll are correct so I suppose it is due to the fact that the library selected is the wrong one and it should try to load `sqlite3_64.dll`. in fact if I run `echo hostCPU` the result is `i386` and I see from source that it is due to compiler magic. My Windiws system instead thinks that my cpu is this one: `https://en.wikichip.org/wiki/intel/core_i5/i5-8350u`
Re: Introducing --gc:arc
Just for confirmation I ran it on a Windows 32 bit machine:Memory management | strategy Time ---|--- arc| **15s** markAndSweep| 21s refc| 24s
Re: Using discard for comments
I did fix something related to that and I might have missed that reference which might need to be removed. I will review it and possibly open a pull request for that fix. I will update here also.
Re: Advent of Nim 2019 megathread
happy to participate again! [https://github.com/pietroppeter/adventofnim](https://github.com/pietroppeter/adventofnim)
Re: Advent of Code 2018 megathread
> We had a long discussion on #nim IRC channel about this today, and there are
> two possible solutions
yes, thank you! I saw the discussion earlier this morning and I was able to fix
that (I did initialize the HashSet with the defaults...). I pushed the changes
and also activated the issues. :)
As a first day it was definitely fun.
As far as the learning process went, I struggled a little bit with the types (I
realize now how much type inference and casting is done in Python) and also I
still do not get the syntax right at the beginning (in particular when handling
types, initializing variables and calling functions).
As could have been expected, searching how to do stuff is less easy than in
python (where, for every "dumb" question - and I had a lot - you find the
answer on Stack Overflow).
I was impressed by the help from Visual Code in spotting errors (and giving
hints on what is wrong). Is this because of nimsuggest that I saw mentioned
around? What exactly is that?
Anyway, Visual Code was even able to tell me that I could not use the built in
set implementation because my input file contained integer that did not fit in
16 bits. It would highlight an error over the parseInt below and give me
instances of illegal conversions:
const changes = map(readFile("./inputs/01.txt").splitLines, proc(x:
string): int16 = int16 parseInt(x))
Run
I guess this was due to the fact that I was using the const (I really like the
idea of compile time constants). In fact when I change the declaration to a
let, the error disappears (well, it still there, I just do not know about it).
In order to do that it has to do the compilation on the fly, right? Are there
mechanism to prevent computations that might take too much time?
I still would like to fire up an interpreter (a couple of times I did use `nim
secret`). I very much look forward too the REPL that is in the works.
Something in the end I was not able to understand how to do is how to print the
type of a variable. It is something that in python I do once in a while and I
realize that it might not make much sense in Nim (where I can just hover over
the variable in the IDE), but still, what is the correct way to make this work?
const instructions = @["+1", "-1"]
echo type(instructions) # this raises error
Run
Re: Advent of Code 2018 megathread
Hi all, ran into Nim in Hacker News a couple months ago, and this year's Advent of Code seems an excellent way to finally learn by doing. Inspired by @miran's repo I will be posting my solutions here: [https://github.com/pietroppeter/AdventOfCode2018](https://github.com/pietroppeter/AdventOfCode2018) I plan to solve them first with Python, then by Nim. Only when they are solved also in Nim I will put in my solution. I joined the private leaderboard. It is going to be fun!
