Failed to compile in Debian

I tried compile Nimongo by importing it but it failed immediately
import nimongo.mongo

Just that line, it failed with error message was:
/home/rahma/nim/nimcache/nimongo_auth.o: In function `nimongo_authInit000':
nimongo_auth.c:(.text+0x97): multiple definition of `nimongo_authInit000'
/home/rahma/nim/nimcache/nimongo_auth.o:nimongo_auth.c:(.text+0x97): first defined here
/home/rahma/nim/nimcache/nimongo_auth.o: In function `nimongo_authDatInit000':
nimongo_auth.c:(.text+0xd0): multiple definition of `nimongo_authDatInit000'
/home/rahma/nim/nimcache/nimongo_auth.o:nimongo_auth.c:(.text+0xd0): first defined here
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
/home/rahma/nim/nimcache/nimongo_mongo.o: In function `newMongo_KMrCR5eKpKUfDf4DP9a5i1Q':
nimongo_mongo.c:(.text+0x435): undefined reference to `init_C5TJYGhjrn3WAZC436gFrQ'
/home/rahma/nim/nimcache/nimongo_mongo.o: In function `newMongoWithURI_l1RGvNbDzWJyW54OYFA1rQ':
nimongo_mongo.c:(.text+0x536): undefined reference to `init_wc5Ol0q7KfDiv1xe661FtA'
/home/rahma/nim/nimcache/nimongo_mongo.o: In function `newAsyncMongo_nMYNEvG9apPbjHuKZBtseLQ':
nimongo_mongo.c:(.text+0xce9): undefined reference to `init_C5TJYGhjrn3WAZC436gFrQ'
/home/rahma/nim/nimcache/nimongo_mongo.o: In function `newAsyncMongoWithURI_ysEbTZ9c6ZNldeQOVtKHV9aw':
nimongo_mongo.c:(.text+0xf0c): undefined reference to `init_wc5Ol0q7KfDiv1xe661FtA'
/home/rahma/nim/nimcache/nimongo_clientbase.o: In function `init_IG9a9ajkUBDcc65sXE6JOxTQ':
nimongo_clientbase.c:(.text+0x728): undefined reference to `init_C5TJYGhjrn3WAZC436gFrQ'
collect2: error: ld returned 1 exit status

$ uname -a returns Linux instance-2 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) x86_64 GNU/Linux
GCC version
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

Any idea what did it go wrong?
(I tried in Windows 10 with msys-2, it compiles and run)

remove your nimcache directory and try again

It's same even after deleting the nimcache directory.
I tried with different version of Nim, I'm using choosenim to install multiple Nim versions. It failed with 0.17.0 too.
With 0.16.0, the error was different, as Nim couldn't find modules private/utils (I think it's Nimble's problem).
After looking a bit nimongo/mongo.nim and error message, I think it's method overloading failure.
Maybe this problem is specific to older GCC or not, I'll try with different version of GCC later.
Also, it was failed to compile too using clang and LLVM 3.5

Hi @mashingan. Unfortunately I do not have Debian currently, but I can try to check on latest Ubuntu

@federicoceratto maybe you could give this a try?

@mashingan Are you using this version of GCC from Jessie? https://packages.debian.org/jessie/gcc
Have you tried a newer GCC? 7.2.0-14 works

@FedericoCeratto Yes, I'm using the official package from Jessie. I'm trying to compile newer GCC to make it separated from system GCC. I'll report back the result.
I think it should work for newer GCC, I compiled in Windows 10 using mingw-w64 with GCC 7.2 and it worked fine.
@SSPkrolik I checked on latest Mint and it's worked. On Mint, the GCC is about version 5. It worked OK, but I never able to authenticate, it happened both in Windows and Mint.
Should I report this as another issue?
Looking the error, I think I missed some silly steps installing compiler toolchains or something like that.
I did what I usually do on Ubuntu/Mint and it worked fine on those. I think I'll look more for the cause. Any advice would help.

It's really silly, I named the file with nimongo_auth.nim and I just realized nimongo has inner module named auth.nim. Hence I got multiple definition
Sorry for this silly mistake, and many thanks for help.


Provide way to get index in T.forEach (...) functions

Currently there's no way to get the current index in T.forEach, T.forEachPar etc.
Note sure if possible but ideally this could be done with a function overload and therefor avoiding a duplication of the related exports.

How about a solution similar to https://ramdajs.com/docs/#addIndex?

Not sure there is a valid typing for an addIndex, doing it via function overload isn't advisable because you could pass to forEach a function with an optional second argument (like succeed, fail, or anything that has tracing) and there is no way of distinguishing at runtime if the function you pass in wants an index or not.
The easiest would be to add T.forEachWithIndex and similar variants, or maybe think of returning extended functions and like from forEach return a function with a .indexed method like T.forEach.indexed(() =>  even though that could have perf implication in constructing the forEach

I'd say this can be closed no? With #968 being merged?


Split Prevouts errors out into specific error types

Done as part of the great error clean up.
Currently we are returning a general Error from Prevouts functions, this is un-informative, we can do better by returning specific types that indicate the exact error path.

Nice!
I wonder if the new dummy-struct error types should be marked #[non_exhaustive]? Fine by me either way.

I wonder if the new dummy-struct error types should be marked #[non_exhaustive]? Fine by me either way.

Is the aim to non_exhaustive anything with the slightest chance of being changed? Either way I'd say before we go 1.0 someone will need to look hard at each error to decide if we are committed to not changing it, or else add non_exhaustive, FTR I did not think super hard about these errors, I'm doing error work when my brain is half dead so I'd prefer to put the thinking off to another time. (I'm playing with this method of splitting deep tasks and shallow tasks up into different work sessions.)

They should also have Copy on them if they don't have non_exhaustive, that is what I stated before that I was doing. I'll wait for any more comments then do one or the other.

They should also have Copy on them if they don't have non_exhaustive, that is what I stated before that I was doing. I'll wait for any more comments then do one or the other.

Yeah, agreed with this.
My feeling is that for errors we should default to #[non_exhaustive] unless somebody can argue otherwise (since in theory we can basically always add more context to errors, if somebody asks). And for other thingsn we should default to Copy unless somebody argues otherwise.
I'm also fine with "let's not think about it during this PR" :).
Note that we can add Copy after the fact as a non-breaking change.

Two birds with one stone, this works for me and I also don't have to think that hard :)

Force push adds non_exhaustive, no other changes.

Heads up that you didn't actually push :)

Thanks :)

I'm not sure if error handling should be considered "trivial API redesign" and considered for the refactor carve-out. I definitely think error handling is too boring and produces too many notifications to think anyone is going to review this other than for high level discussion. IMO this can merge. If it turns out the concepts are not liked I'll come back and do it all again.

On ice until next release.

My feeling is that for errors we should default to #[non_exhaustive] unless somebody can argue otherwise (since in theory we can basically always add more context to errors, if somebody asks).

Exactly.

I definitely think error handling is too boring

Not for me. But it's challenging (which IMO makes it not boring).

I definitely think error handling is too boring

Not for me. But it's challenging (which IMO makes it not boring).

Oh I wasn't clear, I meant too boring for reviewers (outside of you and Andrew), I also find it interesting because its challenging. We've (I've) had a fair bit of struggle getting things reviewed while you were gone, hence the two carve-outs in CONTRIBUTING. One of the reasons, I believe, is the refactor and minor API things are 'too boring' for other reviewers. That is the 'too boring' I was referring to :)


update magnum submodule to origin/master to get Phong.vert fix

Motivation and Context
Update magnum submodule to get @mosra 's Phong.vert fix
How Has This Been Tested
I built and ran the viewer.
Types of changes

[ ] Docs change / refactoring / dependency upgrade
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have completed my CLA (see CONTRIBUTING)
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Sorry, accidentally committed it in for you. Hope you do not mind! @eundersander