Funny you should mention this now as I'm fighting this issue as we speak. Previously splitting them was necessary and working when targeting the device and unnecessary and problematic when targeting the simulator. Suddenly I'm getting the same linker errors when targeting the device. So my situation is that it is now necessary and problematic to split them up for the device now :-(
Specifically, all symbols defined in the second part of bord.cpp (I called it bord_part2.cpp for now) are all unresolved by the linker. I'll let you know if/when I figure out how to fix this. Michael On Wed, Aug 29, 2012 at 1:31 PM, K. John Wu <[email protected]> wrote: > Hi, Michael, > > I remember that you mentioned that you have to split some files into > small pieces, would mind send us the split version? We will check > them into SVN as split files. This would make it easier for you to > move to the later versions when you need to. > > John > > > On 8/29/12 12:04 PM, Michael Beauregard wrote: >> The strange thing is that the lower number is actually the correct >> one. I suspect that this will require some concrete data for you to >> understand what's happening. I'll see if I can get a simple dataset >> for you that demonstrates the issue. >> >> Thanks, >> >> Michael >> >> On Wed, Aug 29, 2012 at 11:41 AM, K. John Wu <[email protected]> wrote: >>> Hi, Michael, >>> >>> Glad to hear that you are making good progress. Regarding the >>> off-by-one issue, here are a couple guesses on what could be going on. >>> >>> - The column named 'something' might have NULL values and one of the >>> NULL values happen to be included in the result set. FastBit does not >>> return any NULL values. >>> >>> - The retrieval function might have a bug. I would appreciate a >>> sample data to track down this bug. >>> >>> Thanks. >>> >>> John >>> >>> >>> On 8/29/12 11:18 AM, Michael Beauregard wrote: >>>> Thanks to John, I'm making decent progress with integrating FastBit >>>> into an iPad application. It builds and executes on my iPad and has >>>> better size and speed metrics than sqlite. So far so good. >>>> >>>> During testing I noticed that a certain FastBit aggregation was off by >>>> one compared to my sqlite result. Digging into a little, I noticed >>>> something that appears odd to me, but could just be a misunderstanding >>>> on my part. >>>> >>>> I would expect the aggregation result of the following query: >>>> >>>> ibis -d tmp/data -q 'SELECT count(*) WHERE thing_to_count = 16298' >>>> >>>> to match the number of hits returned by this query: >>>> >>>> ibis -d tmp/data -q 'SELECT something WHERE thing_to_count = 16298' >>>> >>>> However, I see that the two are off by one. The first query returns an >>>> aggregated value of 1195 and the second returns 1194 hits. >>>> Interestingly, for some reason the following query: >>>> >>>> ibis -d tmp/data -q 'SELECT thing_to_count WHERE thing_to_count = >>>> 16298' >>>> >>>> returns 1195 hits. I would expect all three queries to indicate the >>>> same number of matching rows since the conditions are exactly the >>>> same. For what it's worth, my sqlite result is 1194 and I'd consider >>>> that to be correct for my data. >>>> >>>> Any ideas? >>>> >>>> Michael >>>> _______________________________________________ >>>> FastBit-users mailing list >>>> [email protected] >>>> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users >>>> _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
