I don't really understand the monetdb warning below, which I get when
running test cases for pf/tijah. it's actually nice that monetdb
performs all these BATpropchecks when running the test cases, but what's
actually the problem here? I printed the BAT and its info() now to check
myself, but can't
hej stefan,
thanks for the code clean-up... not only icc likes this ;-) , but one
gets blind for these things when changing the algorithm several times.
-henning
Stefan Manegold wrote:
> Update of /cvsroot/monetdb/pathfinder/modules/pftijah
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-ser
of course, we would like to be included in the binary packages. so we
thought about negative consequences this might have for the rest of you...
main point would be compilation on other machines. for the current
version this looks good now (thanks to stefan). so, we don't see
problems for this rele
hej roel, zijn die niet sowieso al gesorteerd?
tenminste moeten ze dat eigenlijk altijd zijn.
groet -henning
Roel van Os wrote:
> Update of /cvsroot/monetdb/pathfinder/modules/pftijah
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv12912
>
> Modified Files:
> Tag: XQuery_0-16
>
hej amsterdam,
what's the status of the release? or more important, when are we allowed
to do check-ins again?
and second question: which machine on the test web is actually running
icc? i remember we checked the test-web on friday and besides the rare
sun-os all systems looked pretty green on ou
roel, wat was hier eigenlijk aan de hand?
eigenlijk hoef je "left" toch niet nog een keer te sorteren? "left" is
toch altijd gesorteerd, of niet?
-henning
Roel van Os wrote:
> Update of /cvsroot/monetdb/pathfinder/modules/pftijah
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv12912
>
>
hej developers,
we have a debugging question...
we have an xquery which stops the Mserver with the following output:
MonetDB>!FATAL: BATpropcheck: BAT tmp_350(232) has inconsistent
descriptor 16384 (4)
*** glibc detected *** double free or corruption (!prev):
0x01488c10 ***
Aborted
14) |
> (((xx - yy) != BATcount(b)) << 15);
>
> if (zz) {
> GDKfatal("BATpropcheck: BAT %s(%d) has inconsistent
> descriptor %d (%o)\n", BATgetId(b), b->batCacheid, zz, zz);
>
>
&group_id=56967&atid=482468
>
> Stefan
>
>
> On Fri, Apr 20, 2007 at 07:19:39PM +0200, Stefan Manegold wrote:
>> On Fri, Apr 20, 2007 at 02:12:48PM +0200, Henning Rode wrote:
>>> hej stefan,
>>>
>>> thanks for the help. it was indeed check
d to test the correctness of the actual code.
> Hence, please treat it with the respective concentration and care.
>
>
> Thanks.
>
> Stefan
>
>
> On Wed, Sep 05, 2007 at 03:41:57PM +, Henning Rode wrote:
>> Update of /cvsroot/monetdb/pathfinder/modules/pftijah/Tests
&
hej monet-people,
i was a bit puzzled when using the batsize/batdsksize mil-commands on
our pf/tijah index BATs:
our pre_size table is also (void|int). however:
(dbl(batsize("tj_DFLT_FT_INDEX_size1")) /
count(bat("tj_DFLT_FT_INDEX_size1"))).print();
[ 5.1875055810700283 ]
since this seemed a ra
--- if you want/need to know why, you better ask him/her who
> allocated/created/filled the "tj_DFLT_FT_INDEX_size1" BAT ...
>
>
> On Mon, Oct 15, 2007 at 02:36:46PM +0200, Henning Rode wrote:
>> hej stefan,
>>
>> sorry, that i did not answer earlie
hej monetdb developers,
i tried to write a simple aggregation query:
let $cands := doc("x.xml")//c
for $eid in distinct-values($cands/@id)
return
however, executing the above query turns out to be rather difficult. i
always killed the process after waiting for more than half an hour
without get
ient -lxquery q.xq` or `pf [-M] q.xq | mclient -lmil`.)
>
> Could you please also try the algebra backend via
> `pf -A q.xq | mclient -lmil`
> and report the results/behaviour?
>
> Stefan
>
> On Thu, Oct 25, 2007 at 12:39:07PM +0200, Henning Rode wrote:
>> hej
hej,
one of the check-ins yesterday more or less "killed" pf/tijah. the
test-set is now completely red for our module.
since i also checked in one line of code yesterday, i tested already
whether it was the cause of the trouble, but undoing my check-in does
not solve anything. so, i suppose the
exactly, though i must admit that the error message in this case is far
from being helpful.
-henning
Jan Rittinger wrote:
> On 05/07/2008 10:54 AM, Lefteris wrote with possible deletions:
>
>> But here we are not talking about the algebra backend, but about MPS.
>>
>> >From what I saw all fai
.mx was incorrect and the proc ws_create() -> ws_create(0)
> was still needed.
>
> Jan
>
> On 05/07/2008 10:11 AM, Henning Rode wrote with possible deletions:
>> hej,
>>
>> one of the check-ins yesterday more or less "killed" pf/tijah. the
>> test
tefan Manegold wrote:
>> On Sun, Feb 01, 2009 at 06:28:32PM +0100, Sjoerd Mullender wrote:
>>> On 2009-02-01 18:12, Henning Rode wrote:
>>>> Update of /cvsroot/monetdb/pathfinder/modules/pftijah/tjc
>>>> In directory 23jxhf1.ch3.sourceforge.com:/tmp/cvs-serv21759
Stefan Manegold wrote:
>> Log Message:
>> after running the testset of INEX efficiency track, i found and fixed
>> several small bugs that caused queries to fail.
>>
>
> Would it be an option to consider adding these tests to the standard
> testset to be run (and checked) automatically every n
i just wanted to add here, that most tijah-users use the
--enable-bits=64 --enable-oid32
configuration. however, this is not a really big group still, so it
should be easy to tell them to re-index their collections.
-henning
On 14.04.2009, at 14:04, Peter Boncz wrote:
> Hi Sjoerd,
>
> Thanks fo
i just wanted to add here, that most tijah-users use the
--enable-bits=64 --enable-oid32
configuration. however, this is not a really big group still, so it
should be easy to tell them to re-index their collections.
-henning
Peter Boncz wrote:
> Hi Sjoerd,
>
> Thanks for the question. I wrote
right, Feb2010 would have been the better place.
but i does not harm PF/Tijah a lot. the dublicates are in the list for years
now, so i doesn't matter if it becomes May before they are really out.
-henning
Stefan Manegold wrote:
> On Fri, Jan 15, 2010 at 03:54:05PM +, Henning Ro
22 matches
Mail list logo
