Yes, I've had roughly the same realization. I'm not sure why this worked before, but maybe it was because I was using the query and bundle classes and now I'm using the table class for queries.
Compiling everything together is only a problem when targeting the ARM processor. I found this potentially relevant comment http://stackoverflow.com/a/5777909/516581. I ended up splitting bord.cpp around line 6666. On Wed, Aug 29, 2012 at 2:13 PM, K. John Wu <[email protected]> wrote: > Hi, Michael, > > This might be related to implicit instantiation of template functions. > When in the same translation unit, most compilers will automatically > instantiate versions of templated functions as needed. However, when > crossing .o files, explicit instantiation is necessary usually. > > If you are simply splitting the existing file by two, may be you can > simple tell me the line number you are doing the cutting.. I will do > some experiment to figure out what needs to be explicitly instantiated. > > John > > > On 8/29/12 1:49 PM, Michael Beauregard wrote: >> 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
