for i,v in ipairs(table) skipping values?

So, I'm working on a program for CCJam, and I am stumped on a problem.
I'm using for i,v in ipairs(table) in my program and it's skipping values.

Code: https://github.com/Creeper2009/CCJam-2015/blob/master/gm/gmui#L29-L43 (the post editor won't let me paste the code)


I'm loading views from the directory "testViews", and this is the output of my program:

{
  "view1",
  "view3",
  "_view1",
}
The view loading code puts the loaded file into a table called
"views". This is what the views table looks like.
{
  view3 = {
    "View",
  },
}

Any help would be appreciated.

I think I remeber that pairs or ipairs skips nils. I can't remeber which one however.

ipairs only goes over numerically indexed values, so it would skip the index "a" in this example table:

{
  "foo",
  "bar",
  a = "stuff"
}

If that is actually your problem, use "pairs" instead.

Instead of using ipairs, you could do:

for i=1,#myTable do
  --stuff: myTable[i]: current value
end

Creator, on 20 June 2015 - 05:45 PM said:

Instead of using ipairs, you could do:

for i=1,#myTable do
  --stuff: myTable[i]: current value
end

That won't handle non-numerically indexed entries either. I believe flaghacker nailed it - pairs is the answer here.

But the way he declares the table, no-non numerical indexes will be present.

Creator, on 20 June 2015 - 05:55 PM said:

But the way he declares the table, no-non numerical indexes will be present.

Hmmm…that's what I get for basing my answer off the examples in the thread. If he's just generating an ordered table then your solution would work.

Dog, on 20 June 2015 - 06:00 PM said:

Creator, on 20 June 2015 - 05:55 PM said:

But the way he declares the table, no-non numerical indexes will be present.

Hmmm…that's what I get for basing my answer off the examples in the thread. If he's just generating an ordered table then your solution would work.

Under "normal" circumstances you would be right :)/>
(your first post)

I don't think the ipairs is necassarily the problem. fs.list always returns a fully ordered jumpless table.
So the loop should actually work just fine. I think something within that, or the test code you are running to retrieve the information(that the loop is skipping entries) has/had some kind of issue instead.

Also I think line https://github.com/Creeper2009/CCJam-2015/blob/master/gm/gmui#L34 is kinda messed up. If the "dir" provided to the function does not end with a "/", you are going to check for path nil to not be a directory and call fs.open on it. I don't think this works as your are intending, is it?

Try sticking a "print(file)" in the for loop, is it really skipping values?

Creator, on 20 June 2015 - 05:45 PM said:

Instead of using ipairs, you could do:

for i=1,#myTable do
  --stuff: myTable[i]: current value
end

If ipairs were skipping values, then this would also skip values. Both methods bail out as soon as they encounter a nil-index within the table.

But I'd bet money ipairs is working perfectly fine in this instance, and it's the code within the loop that's failing.

InDieTasten, on 20 June 2015 - 09:32 PM said:

Also I think line https://github.com/Creeper2009/CCJam-2015/blob/master/gm/gmui#L34 is kinda messed up. If the "dir" provided to the function does not end with a "/", you are going to check for path nil to not be a directory and call fs.open on it. I don't think this works as your are intending, is it?

This could be fixed by changing:

    local newpth
    if(dir:sub(#dir,#dir) ~= "/") then newpth = dir.."/"..file end

… to:

    local newpth = fs.combine(dir, file)

Another point, are you certain the files in the specified directory(s) all contain unserialisable data?