June 2007 - developers-list

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/semantics xquery_fo.c, XQuery_0-18, 1.129.2.1, 1.129.2.2
by Stefan Manegold 08 Jun '07

08 Jun '07

On Thu, Jun 07, 2007 at 08:01:52PM +0000, Sjoerd Mullender wrote: > Update of /cvsroot/monetdb/pathfinder/compiler/semantics > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv31053 > > Modified Files: > Tag: XQuery_0-18 > xquery_fo.c > Log Message: > Experiment: split up declaration of xquery_fo into smaller pieces in > multiple functions to see whether it then compiles with icc on Linux. Sjoerd, thanks for yoiur efforts! Unfortunately, it still does not help/work: /net/corona.ins.cwi.nl/export/scratch0/manegold/Monet/Testing/Stable/source/pathfinder/compiler/semantics/xquery_fo.c(1664): (col. 1)internal error: 0_0 Maybe, we should finally consider upgrading icc --- provided there is a newer (free) version available... Stefan > Index: xquery_fo.c > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/semantics/xquery_fo.c,v > retrieving revision 1.129.2.1 > retrieving revision 1.129.2.2 > diff -u -d -r1.129.2.1 -r1.129.2.2 > --- xquery_fo.c 7 Jun 2007 14:07:00 -0000 1.129.2.1 > +++ xquery_fo.c 7 Jun 2007 20:01:49 -0000 1.129.2.2 > @@ -97,8 +97,8 @@ > } > } > > -void > -PFfun_xquery_fo (void) > +static void > +PFfun_xquery_fo1 (void) > { > struct xquery_fo xquery_fo1[] = > /** > @@ -956,7 +956,15 @@ > .ret_ty = PFty_xs_double () } }, > .alg = PFbui_fn_floor_dbl } > , { .loc = 0 } > - }, xquery_fo2[] = { > + }; > + > + xquery_fo_initiaze(xquery_fo1); > +} > + > +static void > +PFfun_xquery_fo2 (void) > +{ > + struct xquery_fo xquery_fo2[] = { > /* fn:floor (integer?) as integer? */ > { .ns = PFns_fn, .loc = "floor", > .arity = 1, .sig_count = 1, .sigs = { { > @@ -1646,7 +1654,15 @@ > .ret_ty = PFty_opt (PFty_doc (PFty_xs_anyNode ())) } }, > .alg = PFbui_fn_doc } > , { .loc = 0 } > - }, xquery_fo3[] = { > + }; > + > + xquery_fo_initiaze(xquery_fo2); > +} > + > +static void > +PFfun_xquery_fo3 (void) > +{ > + struct xquery_fo xquery_fo3[] = { > /* fn:collection (string) as node* */ > { .ns = PFns_fn, .loc = "collection", > .arity = 1, .sig_count = 1, .sigs = { { > @@ -2241,11 +2257,17 @@ > , { .loc = 0 } > }; > > + xquery_fo_initiaze(xquery_fo3); > +} > + > +void > +PFfun_xquery_fo (void) > +{ > PFfun_env = PFenv (); > > - xquery_fo_initiaze(xquery_fo1); > - xquery_fo_initiaze(xquery_fo2); > - xquery_fo_initiaze(xquery_fo3); > + PFfun_xquery_fo1 (); > + PFfun_xquery_fo2 (); > + PFfun_xquery_fo3 (); > } > > /* vim:set shiftwidth=4 expandtab: */ > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

2 1

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/modules/pftijah serialize_pftijah.mx, XQuery_0-18, 1.49, 1.49.2.1
by Stefan Manegold 07 Jun '07

07 Jun '07

Jan, property checking is quite expensive, hence, you might want to do it for debugging purposes, only, e.g, when property checking is enabled in Mserver via --debug=8 / --debug=10. To do so, just replace "if ( 1 )" by "PROPDEBUG" (which is defined as "if (GDKdebug & PROPMASK)" in MonetDB/src/gdk/gdk.mx) Stefan On Thu, Jun 07, 2007 at 12:50:55PM +0000, Jan Flokstra wrote: > Update of /cvsroot/monetdb/pathfinder/modules/pftijah > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv12149 > > Modified Files: > Tag: XQuery_0-18 > serialize_pftijah.mx > Log Message: > - add a propcheck to our "C" generated ft-index BATs to see if they are correct > > > > Index: serialize_pftijah.mx > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/modules/pftijah/serialize_pftijah.mx,v > retrieving revision 1.49 > retrieving revision 1.49.2.1 > diff -u -d -r1.49 -r1.49.2.1 > --- serialize_pftijah.mx 1 Jun 2007 15:35:00 -0000 1.49 > +++ serialize_pftijah.mx 7 Jun 2007 12:50:49 -0000 1.49.2.1 > @@ -689,6 +689,16 @@ > BBPunfix(BBPcacheid(tjctx->b_collPre)); > BBPunfix(BBPcacheid(tjctx->b_collSize)); > BBPunfix(BBPcacheid(tjctx->b_collPfPre)); > + if ( 1 ) { > + BATpropcheck(tjctx->b_globalTerm,BATPROPS_ALL); > + BATpropcheck(tjctx->b_globalTag,BATPROPS_ALL); > + BATpropcheck(tjctx->b_docName,BATPROPS_ALL); > + BATpropcheck(tjctx->b_docFirstPre,BATPROPS_ALL); > + BATpropcheck(tjctx->b_collParam,BATPROPS_ALL); > + BATpropcheck(tjctx->b_collPre,BATPROPS_ALL); > + BATpropcheck(tjctx->b_collSize,BATPROPS_ALL); > + BATpropcheck(tjctx->b_collPfPre,BATPROPS_ALL); > + } > if ( tjctx->stemCtx->clear && !tjctx->stemCtx->clear(tjctx->stemCtx) ) > return GDK_FAIL; > free(tjctx); > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > > -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/modules/pftijah pftijah.mx, XQuery_0-18, 1.134.2.1, 1.134.2.2
by Stefan Manegold 07 Jun '07

07 Jun '07

Jan, IMHO, this changes is not correct. Though being of type BIT (which is physically a signed char, hence 8 bit wide), the ordered flags use all 8 bits, only the lowest one (1) indicates sortedness, the highest one (1<<7=128) indicates reverse sortedness, and the remaining ones are "mis-"used for radix clustering. Hence, checking for sortedness shoudl alwasy be done with BAT[ht]ordered(b)&1 --- regardless of the endianess, this should alwasy check for the lowest bit, now matter whether this is located left or right --- anyway, endianess is about byte orde, not about bit order, right?? Hence, if the your change does fix the Itanium problems, than the bug is IMHO caused somewhere else (wrong setting of the ordered flag?), and only appears here... Stefan On Thu, Jun 07, 2007 at 09:28:20AM +0000, Jan Flokstra wrote: > Update of /cvsroot/monetdb/pathfinder/modules/pftijah > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv29459 > > Modified Files: > Tag: XQuery_0-18 > pftijah.mx > Log Message: > - Try to fix Itanium bug [ 1732596 ] PFtijah tests fail on Itanium > Remove the bitwise AND in the check because it could be at the wrong side > of the word? > > > > Index: pftijah.mx > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/modules/pftijah/pftijah.mx,v > retrieving revision 1.134.2.1 > retrieving revision 1.134.2.2 > diff -u -d -r1.134.2.1 -r1.134.2.2 > --- pftijah.mx 4 Jun 2007 17:42:06 -0000 1.134.2.1 > +++ pftijah.mx 7 Jun 2007 09:28:18 -0000 1.134.2.2 > @@ -3745,8 +3745,10 @@ > /* --------------------------- checks ---------------------------------- */ > > BATcheck(tid, name); > - if (!(BATtordered(tid) & 1)) > + /* if (!(BATtordered(tid) & 1)) */ > + if ( !(BATtordered(tid) ) > { > + /* BUG#1732596 this test currently fails on Itanium */ > GDKerror("%s: index-bat must be ordered on tail.\n", name); > return GDK_FAIL; > } > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/runtime shredder.mx, XQuery_0-18, 1.126, 1.126.2.1
by Jens Teubner 07 Jun '07

07 Jun '07

Hi Jan F, thanks for looking into our shredder's entity handling. This has been bugging us for quite a while now. It feels a bit strange, though, that we really have to implement getEntity() ourselves. After all, this is exactly what I would expect to be handled automatically by an XML parsing library. I have just glanced briefly over the libxml2 documentation. And I saw that there is a replaceEntities field in libxml2's xmlParserCtxt struct. As usual, the documentation is very poor here, but this sounds to me like exactly what we need. Have you tried whether simply enabling this flag would handle entities automatically? (Sorry, I don't have the time to test this myself right now.) You find the documentation for xmlParserCtxt at http://xmlsoft.org/html/libxml-tree.html#xmlParserCtxt . Just my 2¢ (still Euro-Cents) Jens On Tue, Jun 05, 2007 at 07:30:50AM +0000, Jan Flokstra wrote: > Update of /cvsroot/monetdb/pathfinder/runtime > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv2405 > > Modified Files: > Tag: XQuery_0-18 > shredder.mx > Log Message: > - A first attempt at making ENTITIES work. After long searching and > trying the final solution was very simple. The libxml2 package already > maintains a hashtable with defined entities. The only thing missing was > the lookup function which it mysteriously does not use. > I implemented the "getEntity()" function in the xmlSAXHandler structure and > now simple ENTITIES defined in the internal subset work. > This solves bug#1185932 XML: Entities by Wouter Alink > > - Change error handling. I noticed for some time that there were no error > messages generated anymore on my system. The xmlSetGenericErrorFunc() does > not work on my machine. I added the "error()" function in the xmlSAXHandler > structure and now I get descriptive error messages again. This may screw up > some testset output but I think this is a big system improvement. > > > > Index: shredder.mx > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/runtime/shredder.mx,v > retrieving revision 1.126 > retrieving revision 1.126.2.1 > diff -u -d -r1.126 -r1.126.2.1 > --- shredder.mx 24 Apr 2007 15:04:42 -0000 1.126 > +++ shredder.mx 5 Jun 2007 07:30:46 -0000 1.126.2.1 > @@ -1103,6 +1103,35 @@ > stream_printf(GDKerr, "%s", buf); > } > > +static void > +shred_warning(void *ctx, > + const char *msg, ...) > +{ > + /* IMPORTANT this function may be called multiple times for one error > + * message so it is not possible to use GDKerror() here. > + * Instead, we "mis-use" the ctx pointer to remember whether a newline > + * has occured in the error message, and thus be able to prefix each > + *(line of an) error message with GDKERROR("!Error: "), which is > + * required to properly get the error message through the MAPI > + * protocol... > + */ > + va_list args; > + int *print_error_newline =(int*)ctx; > + int len = 0; > + char buf[PFSHRED_BUFLEN]; > + > + if (*print_error_newline) { > + len += snprintf(buf+len, PFSHRED_BUFLEN-len-1, GDKERROR); > + } > + > + va_start(args, msg); > + len += vsnprintf(buf+len, PFSHRED_BUFLEN-len-1, msg, args); > + va_end(args); > + > + *print_error_newline =(strchr(buf,(int)'\n') != NULL); > + stream_printf(GDKerr, "!WARNING: %s", buf); > +} > + > /** > * The shred_attribute_defAttributeDef() handles the DTD attribute definition callbacks > * in the from the header of the XML file. This is used for the ID/IDREF > @@ -1163,6 +1192,44 @@ > } > } > > +static xmlEntityPtr > +shred_getEntity(void *xmlCtx, const xmlChar *name) > +{ > + /* the shredder is now able to handle ENTITY's from the internal > + * subset. I do not really understand yet why this had to be done > + * here and why it was not handled automagically > + * The functions used are defined in $LIBXML2INCLUDES/entities.h > + */ > +#if 0 > + stream_printf(GDKerr,"shred_getEntity(ctx,\"%s\") CALLED\n",name); > +#endif > + xmlParserCtxtPtr ctx = ((shredCtxStruct*) xmlCtx)->xmlCtx; > + /* lookup the entity in the document entity hash table */ > + return xmlGetDocEntity(ctx->myDoc,name); > + /* QUESTION: xmlGetDtdEntity() and xmlGetParameterEntity() were also > + * possible, whats the diff between the doc/dtd versions, they both > + * seem to work. */ > +} > + > +#if 0 > +/* My first try at building an entity table but this one was not necessary > + * because the internal subset table was already build. > + */ > +static void > +shred_entityDecl(void *xmlCtx, > + const xmlChar *name, > + int type, > + const xmlChar *publicId, > + const xmlChar *systemId, > + xmlChar *content) > +{ > + xmlParserCtxtPtr ctx = ((shredCtxStruct*) xmlCtx)->xmlCtx; > + if ( ! xmlAddDtdEntity(ctx->myDoc,name,type,publicId,systemId,content) ) > + stream_printf(GDKerr,"shred_entityDecl(ctx,\"%s\") FAIL\n",name); > +} > +#endif > + > + > /* ==================================================================================== > * the shredder and its data structures > * - shredder_create() create all data structures > @@ -1183,14 +1250,14 @@ > , .characters = shred_characters > , .processingInstruction = shred_pi > , .comment = shred_comment > - , .error = 0 > + , .error = shred_error > , .cdataBlock = shred_cdata > , .internalSubset = 0 > , .isStandalone = 0 > , .hasInternalSubset = 0 > , .hasExternalSubset = 0 > , .resolveEntity = 0 > - , .getEntity = 0 > + , .getEntity = shred_getEntity > , .entityDecl = 0 > , .notationDecl = 0 > , .attributeDecl = shred_attribute_def > @@ -1199,7 +1266,7 @@ > , .setDocumentLocator = 0 > , .reference = 0 > , .ignorableWhitespace = 0 > - , .warning = 0 > + , .warning = shred_warning > , .fatalError = 0 > , .getParameterEntity = 0 > , .externalSubset = shred_external_subset > @@ -1229,6 +1296,10 @@ > char buf[XMLCHUNK+1]; > > /* reset libxml2 error handling */ > + /* note JF: this does not have any effect on SuSe9.3. No error messages > + * are printed. I assigned the 'error' field in the xmlSAXHandler and > + * this works fine. > + */ > xmlSetGenericErrorFunc((void*)&print_error_newline, shred_error); > > /* parse XML input(receive SAX events) */ > @@ -1237,7 +1308,30 @@ > } else if (buffer) { > xmlCtx = xmlCreateMemoryParserCtxt(buffer, shredCtx->fileSize); > } else { > - xmlCtx = xmlCreateURLParserCtxt(location, XML_PARSE_XINCLUDE|XML_PARSE_NOXINCNODE); > + /* Possible options for the second arg are: > + * XML_PARSE_RECOVER = recover on errors > + * XML_PARSE_NOENT = substitute entities > + * XML_PARSE_DTDLOAD = load the external subset > + * XML_PARSE_DTDATTR = default DTD attributes > + * XML_PARSE_DTDVALID = validate with the DTD > + * XML_PARSE_NOERROR = suppress error reports > + * XML_PARSE_NOWARNING = suppress warning reports > + * XML_PARSE_PEDANTIC = pedantic error reporting > + * XML_PARSE_NOBLANKS = remove blank nodes > + * XML_PARSE_SAX1 = use the SAX1 interface internally > + * XML_PARSE_XINCLUDE = Implement XInclude substitition > + * XML_PARSE_NONET = Forbid network access > + * XML_PARSE_NODICT = Do not reuse the context dictionnary > + * XML_PARSE_NSCLEAN = rm redundant namespaces declarations > + * XML_PARSE_NOCDATA = merge CDATA as text nodes > + * XML_PARSE_NOXINCNODE= do not generate XINCLUDE START/END nodes > + */ > + /* > + * TODO: how to prevent expansion of entities? > + */ > + xmlCtx = xmlCreateURLParserCtxt(location, > + XML_PARSE_XINCLUDE| > + XML_PARSE_NOXINCNODE); > } > if (!xmlCtx) { > GDKerror("shredder_parse: libxml2 could not initialize a parser.\n"); > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 >From /usr/src/linux/include/linux/kernel.h: #define STACK_MAGIC 0xdeadbeef

2 1

[Monetdb-developers] Release Branding?
by Stefan Manegold 05 Jun '07

05 Jun '07

Dear fellow developers, some time ago, we intorduced "nicknames" to be able to refer to our "mega-releases" (in particular MonetDB/XQuery, but in general all MonetDB related packages released together. Hence, what should be the name of this (final?) "mega-release"? (Future releases will preferably be release of individual packages such that a new release of a package work with the most recently released version of all related packages.) My suggestion: Starting the journey with (on) Valentijn('s day 2005), and after stop-overs at Mercury, Earth, Ceres, (being lost in Star Dust), and Venus, Pathfinder finally arrived at Mars (only to leave our own solar system hereafter to explore outer space...) Comments? Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

2 1

Re: [Monetdb-developers] [Monetdb-checkins] buildtools/conf MonetDB.m4, MonetDB_1-18, 1.16.2.2, 1.16.2.3
by Stefan Manegold 05 Jun '07

05 Jun '07

On Tue, Jun 05, 2007 at 09:24:10AM +0200, Fabian Groffen wrote: > On 05-06-2007 06:13:22 +0000, Stefan Manegold wrote: > > Update of /cvsroot/monetdb/buildtools/conf > > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv17106/conf > > > > Modified Files: > > Tag: MonetDB_1-18 > > MonetDB.m4 > > Log Message: > > > > Java 1.6 seems to be (partly) incompatible with Java 1.4 & 1.5; > > we do not support Java 1.6, yet. > > Stefan, > > Thanks for doing this. It was on my todo-list, but I ended up > forgetting about it every time. no problem. same holds/held for me, just happened to recall it "by accident", and took the "early bird's" opportunity ;-) Stefan > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Monetdb-checkins mailing list > Monetdb-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-checkins -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

Re: [Monetdb-developers] Data type of the text() nodes
by Peter Boncz 04 Jun '07

04 Jun '07

Hi Jennie + Jens, Jennie, the idea in XRPC is to put the burden of function resolution and type promotion at the client -- server does nothing, in order to make it easy to implement XRPC compliant web services in environments that lack any XPath/XQuery (type analysis) support, such as simple wrapper code. The client side (i.e. pf) already performs type promotion, otherwise the function call would have given the resolution error at client side. So, the only thing that needs to be done is *use* the types of the function signature when generating the XRPC request. ..Fix around line 1000 in xrpc_client.mx.. 1067 cur_kind = XTRACT_KIND(cmbn_cont_kind); 1068 1069 switch (cur_kind) { But, Jens, there is also static vs. dynamic typing issue here. Of course, dynamic types are often more specific than static types. An example that excploits this is: declare function isInt($ctx as item()* as xs:boolean { typeswitch($ctx) case xs:integer: return true() default: return false() } For this reason my proposed fix is to use the function signature type *only* if it is a subtype of the runtime type (= if it is more specific). While the above probably fixes Jennie's issue, I do think there is a problem in pathfinder with function parameter promotion. This can surface when the typeswitch() is used inside the function body. Basically, when types are promoted, the runtime representation should be forced to reflect this. AFAIK this is not done in mps -- maybe the new type annotation system (in progress) handles this? With such a system in place, the runtime type would already be xs:string and the hack I propose above would not be needed. As an aside, I also think that there is something wrong in pathfinder with type promotion in general comparisons. Specifically, while the spec says that in case of a comparision between untyped data and a numeric, the untyped should be cast to xs:double. Pathfinder seems to apply a direct cast to the specific numeric data type (e.g. xs:integer) instead. Example: <a t='1.1'/>/@t = 1 I stubled on this in my Friday exercise to implement selection pushdown (not yet finished). Peter ------------------------------ Message: 4 Date: Fri, 1 Jun 2007 17:14:46 +0200 From: Ying Zhang <Y.Zhang(a)cwi.nl> Subject: [Monetdb-developers] Data type of the text() nodes To: monetdb-developers(a)lists.sourceforge.net Message-ID: <20070601151446.GV11079(a)cwi.nl> Content-Type: text/plain; charset=us-ascii Hello, I'm having a problem with the data type of text() nodes in XRPC implementation. --------------------------- module function definition: --------------------------- module namespace foo = "xrpc-test-function"; declare function foo:q2($strs as xs:string*) as node()* { for $s in $strs return <bar>{$s}</bar> }; ----------- test query: ----------- import module namespace test = "xrpc-test-function" at "/ufs/zhang/max-nr-params/xrpc-mod.xq"; let $hello := <hello> <lang>en</lang> <lang>nl</lang> </hello> let $lang := $hello/lang/text() return execute at {"localhost"} {test:q2($lang)} ------------------------------------------------------------- I got the error "function could not be resolved" when I run the XRPC query above. The reason is that all items in the sequence $lang have the type U_A (xs:untypedAtomic), and they are marshalled in the XRPC req. msg as, for example: <xrpc:atomic-value xsi:type="xs:untypedAtomic">en</xrpc:atomic-value> At the server side, the values are unmarshalled and assigned the type U_A again. So far, the values are handled correctly, IMHO. But then problem happens, namely, when the server calls the function 'xquery_sig_match' (in pathfinder.mx), it concludes that xs:untypedAtomic is not a sub-type of xs:string, hence, the function signature can not be resolved. This error does not occur if the function 'q2' is called without XRPC. So, what is the trick of pathfinder to match the signature? Is xs:untypedAtomic just treated the same as xs:string? The easiest solution of my problem is to just marshall an xs:untypedAtomic as an xs:string, but if someone has better suggestions, I would like to know. Thanks a lot! Regards, Jennie ------------------------------ Message: 5 Date: Fri, 1 Jun 2007 17:27:03 +0200 From: Jens Teubner <jens.teubner(a)in.tum.de> Subject: Re: [Monetdb-developers] Data type of the text() nodes To: monetdb-developers(a)lists.sourceforge.net Message-ID: <20070601152703.GB8539(a)notekemper14.informatik.tu-muenchen.de> Content-Type: text/plain; charset=us-ascii On Fri, Jun 01, 2007 at 05:14:46PM +0200, Ying Zhang wrote: > [...] > > But then problem happens, namely, when the server calls the function > 'xquery_sig_match' (in pathfinder.mx), it concludes that > xs:untypedAtomic is not a sub-type of xs:string, hence, the function > signature can not be resolved. > > This error does not occur if the function 'q2' is called without XRPC. > So, what is the trick of pathfinder to match the signature? Is > xs:untypedAtomic just treated the same as xs:string? Hi Jennie, the keywords to look for in the Formal Semantics are "type promotion" and "function call". And there are the function conversion rules as implemented in core/fs.brg:function_conversion(). Sorry for my very brief answer, but these pointers should bring you quite far. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 I invented <Ctrl><Alt><Delete>, but Bill Gates made it famous. -- David Bradley, member of the original IBM PC design team ------------------------------ Message: 6 Date: Fri, 1 Jun 2007 21:00:27 +0200 From: Jens Teubner <jens.teubner(a)in.tum.de> Subject: Re: [Monetdb-developers] [MonetDB-users] XRPC problem: too many parameters To: Ying Zhang <Y.Zhang(a)cwi.nl> Cc: monetdb-developers(a)lists.sourceforge.net Message-ID: <20070601190027.GF8539(a)notekemper14.informatik.tu-muenchen.de> Content-Type: text/plain; charset=us-ascii On Fri, Jun 01, 2007 at 06:50:41PM +0200, Ying Zhang wrote: > [...] > > I forgot to say that you need to wrap "$gb-hit/Hit_gb/text()" into the > fn:data() function before those values can be passed to "test:q1". This > is a restriction of the current implementation of XRPC. > > The values you get by selecting the "text()" child node are of the type > "untypedAtomic". XRPC currently does not cast eash untypedAtomic to the > expected atomic type, hence, you need to add a fn:data() to do this. I > will add this cast later in XRPC's implementation. This sounds odd. Applied to (untyped) nodes, fn:data() returns xs:untypedAtomic. Only if a value is used in a function call, the items are cast to the respective atomic type ("function conversion rules"). (Actually, I just saw that fn:data() is not allowed at all on untyped nodes. Maybe this changed in the latest revisions of the specs.) Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Linus Torvalds is a lot like Bill Gates. Both are about the same height. -- USA Today ------------------------------ Message: 8 Date: Sat, 2 Jun 2007 22:14:44 +0200 From: Ying Zhang <Y.Zhang(a)cwi.nl> Subject: Re: [Monetdb-developers] [MonetDB-users] XRPC problem: too many parameters To: monetdb-developers(a)lists.sourceforge.net Message-ID: <20070602201444.GC11079(a)cwi.nl> Content-Type: text/plain; charset=us-ascii On Fri, Jun 01, 2007 at 09:00:27PM +0200, Jens Teubner wrote: > On Fri, Jun 01, 2007 at 06:50:41PM +0200, Ying Zhang wrote: > > > [...] > > > > I forgot to say that you need to wrap "$gb-hit/Hit_gb/text()" into the > > fn:data() function before those values can be passed to "test:q1". This > > is a restriction of the current implementation of XRPC. > > > > The values you get by selecting the "text()" child node are of the type > > "untypedAtomic". XRPC currently does not cast eash untypedAtomic to the > > expected atomic type, hence, you need to add a fn:data() to do this. I > > will add this cast later in XRPC's implementation. > > This sounds odd. Applied to (untyped) nodes, fn:data() returns > xs:untypedAtomic. Only if a value is used in a function call, the items > are cast to the respective atomic type ("function conversion rules"). > > (Actually, I just saw that fn:data() is not allowed at all on untyped > nodes. Maybe this changed in the latest revisions of the specs.) > > Jens Hi Jens, You are right about that fn:data() does not do what I need, namely take an untypedAtomic and return an atomic value in the right type. But according to the latest revision, I think fn:data() does allow untypedAtomic as its parameter: fn:data($arg as item()*) as xs:anyAtomicType* But I need to find another way to solve this problem. Jennie > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > Linus Torvalds is a lot like Bill Gates. Both are > about the same height. > -- USA Today

2 1

Re: [Monetdb-developers] xs:docmgmt in XQuery user defined functions?
by Peter Boncz 04 Jun '07

04 Jun '07

Hi Djoerd, All document management functions return the docmgt type, as a mechanism to ensure that such queries do not perform any document updates. For MonetDB, this separation is handy, as document management and XQUF updates rely on two different mechanisms (checkpointing vs WAL) and if queries would rely on both, it would be hard to make them atomic. Pathfinder supports the 'declare document management function' syntax extension (imilar to the xQUF notation 'declare updating function') to allow user-defined functions that perform document management. Peter

1 0

[Monetdb-developers] Feature freeze & new release branches
by Stefan Manegold 04 Jun '07

04 Jun '07

Dear all, as decided and announced last week, I'll "enforce" the feature freeze for the upcoming *.18 release today, Sunday June 3 2007 --- well, the origin plan was for Friday June 1 2007 but other obligations and lack of time forced my to post-pone this action by two days --- hopefully, SF will be less busy on a weekend... Hence, from now on, please do NOT checkin to ANY CVS modules releated to MonetDB until I'm done later today. I'll let you know, once I'm done and you can checkin, again. Thank you very much for your cooperation. Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 1

Re: [Monetdb-developers] [MonetDB-users] XRPC problem: too many parameters
by Jens Teubner 02 Jun '07

02 Jun '07

On Fri, Jun 01, 2007 at 06:50:41PM +0200, Ying Zhang wrote: > [...] > > I forgot to say that you need to wrap "$gb-hit/Hit_gb/text()" into the > fn:data() function before those values can be passed to "test:q1". This > is a restriction of the current implementation of XRPC. > > The values you get by selecting the "text()" child node are of the type > "untypedAtomic". XRPC currently does not cast eash untypedAtomic to the > expected atomic type, hence, you need to add a fn:data() to do this. I > will add this cast later in XRPC's implementation. This sounds odd. Applied to (untyped) nodes, fn:data() returns xs:untypedAtomic. Only if a value is used in a function call, the items are cast to the respective atomic type ("function conversion rules"). (Actually, I just saw that fn:data() is not allowed at all on untyped nodes. Maybe this changed in the latest revisions of the specs.) Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Linus Torvalds is a lot like Bill Gates. Both are about the same height. -- USA Today

2 1