Hi, Greg, The problem you encountered was due to an erroneous complaint about empty data file during index (ibis::direkte) building process. A number of other index construction functions have the same problem. They have been corrected and the updated source code is checked in as SVN 530. Please take a look when you get the chance.
Thanks. John On 7/30/12 2:37 AM, Greg Barker wrote: > Underscore might not be the cause of it. Does it matter if the "db" > folder is empty initially? If I run that multiple times, first time > will hit the error (when db & db_tmp are empty) but the second time > will succeed. > > Thanks, > Greg > > On Mon, Jul 30, 2012 at 2:05 AM, Greg Barker <[email protected] > <mailto:[email protected]>> wrote: > > Sorry meant to include the snippet of code that causes the issue: > > std::auto_ptr<ibis::tablex> tmpTblx(ibis::tablex::create()); > tmpTblx->addColumn("col_1", CATEGORY); > tmpTblx->addColumn("col_2", DOUBLE); > int ierr = tmpTblx->readCSV("data.csv", 0, "db_tmp, ","); > ierr = tmpTblx->write("db_tmp", "working", NULL, NULL, NULL); > tmpTblx->clearData(); > ibis::part working_part("db"); > working_part.append("db_tmp"); > > data.csv is simply: > "value_1",12.34 > > The cause appears to be the underscore in the data file. If I > change "value_1" to "value1" I no longer hit the error. > > On Sun, Jul 29, 2012 at 11:13 PM, Greg Barker > <[email protected] <mailto:[email protected]>> wrote: > > Hi John, > > Thank you for the quick response and the updated code. The > issue with the long where in clause appears to be fixed now, > but I ran into a different issue with the program I use to > load data: > > Error -- direkte::construct0 failed with error code -1 > Segmentation fault (core dumped) > > #0 0x0074a228 in ?? () from /lib/tls/i686/cmov/libc.so.6 > #1 0x01de781d in ibis::category::fillIndex (this=0x98adb20, > dir=0x98a8e68 "/home/greg/fastbit_test/db") at category.cpp:363 > #2 0x01dec5ef in ibis::category::append (this=0x98adb20, > dt=0x98a8e68 "/home/greg/fastbit_test/db", df=0x98a62fc > "/home/greg/fastbit_test/db_tmp", nold=0, nnew=22458, > nbuf=16777216, > buf=0xa1ee9008 "value0") at category.cpp:1253 > #3 0x01f659d2 in ibis::part::appendToBackup (this=0xbfa245c4, > dir=0x98a62fc "/home/greg/fastbit_test/db_tmp") at parti.cpp:1143 > #4 0x01f687ad in ibis::part::append1 (this=0xbfa245c4, > dir=0x98a62fc "/home/greg/fastbit_test/db_tmp") at parti.cpp:633 > #5 0x01f69dae in ibis::part::append (this=0xbfa245c4, > dir=0x98a62fc "/home/greg/fastbit_test/db_tmp") at parti.cpp:584 > > I'm not sure if the problem lies within my code though. We > have been using fastbit 1.2.8 before this. Do you know what > the problem might be? > > Thanks again, > Greg > > On Sat, Jul 28, 2012 at 12:17 AM, K. John Wu <[email protected] > <mailto:[email protected]>> wrote: > > Hi, Greg, > > Thanks for your patience. Your issue has been getting a > little > tangled with a couple of other changes. There has been a > large update > to SVN. Please give revision 528 a try when you get a > chance and let > us know how it works for you. > > John > > > On 7/27/12 4:54 PM, Greg Barker wrote: > > Hi John, > > > > Sorry to bug you about this, but do you know when the > fix for this > > might be ready? > > > > Thanks, > > Greg > > > > On Wed, Jul 25, 2012 at 11:24 AM, K. John Wu > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > Hi, Greg, > > > > I just realized the problem myself. Please bear > with us while as we > > work through this. > > > > John > > > > > > On 7/25/12 11:21 AM, Greg Barker wrote: > > > John, > > > > > > Thanks again for the quick response. Unfortunately > I am running > > into a > > > different issue now with 527. > > > > > > When I try to run a query (using ibis) like my > original example > > I hit > > > the following: > > > > > > Warning -- query[RWYNnK-FCtB----0]::doEvaluate -- > unable to > > evaluate a > > > query term of unknown type, copy the mask as the > solution > > > doQuery -- failed to evaluate "col_a in ('value1', > 'value2')", error > > > code = -21 > > > > > > Thanks, > > > Greg > > > > > > On Tue, Jul 24, 2012 at 9:39 PM, K. John Wu > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>> wrote: > > > > > > Hi, Greg, > > > > > > Please give SVN 527 a try. It should have > fixed the > > problems you've > > > reported. Feel free to let us know if you > encounter any other > > > problems. > > > > > > Thanks. > > > > > > John > > > > > > > > > On 7/24/12 7:27 PM, K. John Wu wrote: > > > > Hi, Greg, > > > > > > > > Thanks for the note. I am working on > another change and > > this is one > > > > of the problem I need to fix. I will let > you when I am > > done with my > > > > testing. > > > > > > > > John > > > > > > > > > > > > > > > > > > > > On 7/24/12 4:35 PM, Greg Barker wrote: > > > >> Thank you for the quick reply. Saw you > checked in some > > changes so I > > > >> checked out revision 526 and rebuilt. Now > when I try to > > compile my > > > >> program I am hitting the following errors: > > > >> > > > >> ./lib/libfastbit.so: undefined reference to > > `ibis::slice::clear()' > > > >> ./lib/libfastbit.so: undefined reference to > > > >> `ibis::slice::getSerialSize() const' > > > >> collect2: ld returned 1 exit status > > > >> > > > >> Do you know what the cause of this would be? > > > >> > > > >> Thank you, > > > >> Greg > > > >> > > > >> On Mon, Jul 23, 2012 at 8:03 PM, K. John Wu > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > > > >> <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>>> wrote: > > > >> > > > >> Hi, Greg, > > > >> > > > >> Thanks for report. The problem appears > to be due to a > > > silly attempt > > > >> to optimize that converts the > expression you > > mentioned into > > > a list of > > > >> equality comparisons. This will be > removed shortly. > > > >> > > > >> John > > > >> > > > >> > > > >> On 7/23/12 2:54 PM, Greg Barker wrote: > > > >> > Hello - > > > >> > > > > >> > I have a query that has an "in" > clause which contains a > > > large number > > > >> > of strings: > > > >> > > > > >> > select col_a, col_b where col_a in > ('value1', 'value2', > > > 'value3', > > > >> > 'value4', ...., 'valueN') > > > >> > > > > >> > When N is very large (thousands of > items) I am > > hitting stack > > > >> overflow. > > > >> > This appears to be caused by the > recursive nature of > > > verifyExpr in > > > >> > whereClause.cpp:552. Was wondering if > you had any > > advice > > > on how > > > >> to fix > > > >> > this. > > > >> > > > > >> > Thanks! > > > >> > Greg > > > >> > > > > >> > > > > >> > > _______________________________________________ > > > >> > FastBit-users mailing list > > > >> > [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[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
