Yesterday I got this pull request for gintro:
https://patch-diff.githubusercontent.com/raw/StefanSalewski/gintro/pull/23.diff
Well the problem seems to be that I am working on Linux 64 bit and wrote code like
for j in 0 .. m:
let arg = gCallableInfoGetArg(info, j)
The low level gCallableInfoGetArg() takes an cint as second parameter. Unfortunately I ignored that fact -- the for loop is working fine for me but I guess the user who posted the patch is using a 32 bit OS and so for him it may not compile.
Can I catch such traps? Would be not much fun to install an additional 32 bit OS just for testing for such trouble.
You can run something like
nim check --cpu:i386 mynimfile.nimI haven't tried that with your specific example though. Can you try that and see if it catches it?
No,
nim check --cpu:i386 gen.nim
gives no errors on my 64 bit Linux box.
Hm... The following does not compile for me on both 64-bit Windows 7 and 32-bit Windows XP (nim version 0.17.2):
proc foo(ci: cint) = discard
for i in 0 .. 5:
foo(i)
That is interesting.
My actual code in gen.nim of package gintro seems to be more like this:
proc numArgs: cint = 6
let n = numArgs() - 1
proc foo(ci: cint) = discard
for i in 0 .. n:
foo(i)
That compiles fine for me on Linux 64bit. But I had the strong feeling that it compiles not for the user who send the pull request. See
https://github.com/StefanSalewski/gintro/pulls
Unfortunately that user is fully anonymous, submitted not an issue first and gave only a very short note.
Indeed I was going to ignore his pull request fully. But then I thought well, when some users have trouble I should not ignore it. I may have to investigate his request more carefully. I hope that he made not just a joke to fool me.
@woggioni I do understand why it does not compile. I was surprised that the version Stefan_Salewski initially presented compiles for him.
@Stefan_Salewski The latest version of your example code does compile OK for me on both 64-bit Windows 7 and 32-bit Windows XP. (Which is expected, because the type of i becomes cint via type inference from the type of n, I guess)
I think the problem is in the fact that the .. iterator returns the same type of its upper bound:
import typetraits
proc foo(ci: cint) = discard
let n : int32 = 1
for i in 0..<n:
echo type(i).name
foo(i)
for i in 0..<1:
echo type(i).name
iterator ..S, T: T {..}
I expect the example Stefan_Salewski posted to compile everywhere simply because he always used cint
Unfortunately that user is fully anonymous, submitted not an issue first and gave only a very short note.
But as far as I understand you can add comments to his PR, so you can ask him there in which particular configuration it does not compile for him. I think he monitors his PR.
Sorry for generating so much noise...
I get the feeling that user idlewan only wants to fool us. Maybe he assumed that we would just apply his patches without carefully checking. I will ignore it. (Well, maybe he is using an very old Nim compiler version where problems existed long time ago. But also in this case we can ignore him.)
[EDIT]
Well, now from
https://github.com/StefanSalewski/gintro/pull/23
it seems that he does not try to fool us on purpose. He uses 64 bit Linux as most of us, and it seems not to compile for him without his patch. That is strange.