Hi Jan, I made a checkout of the cvs modules and after compile buildtools successfully and when i tried to compile MonetDB: [jmartin@outsourcing1 MonetDB]$ ./bootstrap automake 1.9.6 is 1.7 or newer. Good. autoconf 2.59 is 2.57 or newer. Good. libtool 1.5.22 is 1.4 or newer. Good. Python 2.4.3 is 2.0.0 or newer. Good. Traceback (most recent call last): File "/home/jmartin/monetdbcvs/bin/autogen.py", line 29, in ? from autogen import am ImportError: No module named autogen please help. El lun, 07-04-2008 a las 13:14 +0200, Jan Rittinger escribió:
Hi Jorge,
I just extended the implementation of fn:number to cope with NaN values in equality predicates.
In case you have trouble avoiding the restriction you can try out the CVS head version (-- the nightly build will be available tomorrow). To make use of my changes you have to activate the (not yet standard) algebra code generation (using '\G' in your mclient).
Jan
On 04/07/2008 11:46 AM, Jorge Martín Cuervo wrote with possible deletions:
Thanks Jan,
I'll try to rewrite some parts of the xquery as you said.
best regards.
El lun, 07-04-2008 a las 11:36 +0200, Jan Rittinger escribió:
Hi Jorge,
we compile XQuery into relational algebra and afterwards into the MonetDB specific language MIL. The query plan (our correspondent for a stack trace) thus will not help you.
I would have suggested you a function like the following
declare function mynumber ($foo as xs:string*) as xs:double* { for $a in $foo return if ($a castable as xs:double) then number($a) else () };
but I just detected (to my astonishment) that we do not support the castable concept yet. The only solution I thus see is a filter that looks for strings starting with digits instead of checking for castable. (This is admittedly a very ugly adaption).
The other solution would be to look into the data and find a better filter based on path step predicates.
Jan
On 04/07/2008 11:27 AM, Jorge Martín Cuervo wrote with possible deletions:
Thanks Jan,
but can a active some debug info or similar to print the stack trace when a runtime error is triggered?
i think it could be very usefull. ;)
thanks again.
El lun, 07-04-2008 a las 11:11 +0200, Jan Rittinger escribió:
Hi Jorge,
your first error triggers a compile-time error. Here we know where the error appears. The second error on the other side is a runtime error (a cast failing because some strings cannot be converted to double) where we have no query information anymore.
Regards, Jan
P.S.: My best guess is that your query has a predicate with a comparison between a number and the result of a path step (like e.g., '/a/[b>3.14]') where not all resulting nodes can be cast to double (as e.g., in the following XML fragment '<a><b>42</b><b>pi</b></a>'). In this situations you might add calls to the built-in function fn:number() to modify the casting behavior (e.g., '/a/[number(b)>3.14]').
On 04/07/2008 10:41 AM, Jorge Martín Cuervo wrote with possible deletions:
Hi all, i have some error messages from mclient when i try to run an xquery.
First i've got:
ERROR = !type error: body of hr:fw() evaluates to `double | integer' which is not a subtype of `xs:double'
and i removed the return type from function, and later i've got:
ERROR = !ERROR: err:FORG0001: could not cast value from string to double.
is there any way to know where is the error (like the before message)?
thanks.
--
;-)
____________________________________
Jorge Martin Cuervo
Outsourcing Emarketplace
deFacto Powered by Standards
email