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]> 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]>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]> 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]>> 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]>>> 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]>>>> 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]>>> >>> > > >> > >>> > 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
