- developers-list - monetdb.org

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/tests/W3C_use_cases/XQUF/R/Tests Q7x.milS, 1.2, 1.3 Q7x.stable.out, 1.2, 1.3
by Jan Rittinger 31 Oct '06

31 Oct '06

Stefan, your rewrite may return different results (at least without schema knowledge). If you have E1/E2[P] the predicate P is evaluated on E2 only. Your rewrite changes the binding to E1/E2 and is thus equivalent to (E1/E2)[P]. The correct rewrite thus would be doc("items.xml")/items/item_tuple[itemno=1002] -> doc(\"items.xml\")/items/(for $i in item_tuple where $i/itemno=1002 return $i) which would result in the same translation as without the for loop. On 10/30/2006 10:09 PM, Stefan Manegold wrote with possible deletions: > Update of /cvsroot/monetdb/pathfinder/tests/W3C_use_cases/XQUF/R/Tests > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv14959/XQUF/R/Tests > > Modified Files: > Q7x.milS Q7x.stable.out > Log Message: > > with a path expression E and a predicate P, > Pathfinder's derives the type of > E[P] > as "node", while this could be "element" as required by some functions; > replacing > E[P] > by > for $i in E where P return $i > yields an "element". > > Added althernative versions for all tests where E[P] triggers a type error > but for $i in E where P return $i works fine. > > > Index: Q7x.stable.out > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/tests/W3C_use_cases/XQUF/R/Tests/Q7x.stable.out,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -d -r1.2 -r1.3 > --- Q7x.stable.out 30 Oct 2006 20:54:19 -0000 1.2 > +++ Q7x.stable.out 30 Oct 2006 21:09:18 -0000 1.3 > @@ -15,7 +15,7 @@ > xquery("xml"," > do insert > <comment>This is a bargain !</comment> > -as last into exactly-one(doc(\"items.xml\")/items/item_tuple[itemno=1002]) > +as last into exactly-one(for $i in doc(\"items.xml\")/items/item_tuple where $i/itemno=1002 return $i) > ").printf(); > > xquery("xml","doc(\"items.xml\")").printf(); > > Index: Q7x.milS > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/tests/W3C_use_cases/XQUF/R/Tests/Q7x.milS,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -d -r1.2 -r1.3 > --- Q7x.milS 30 Oct 2006 20:54:19 -0000 1.2 > +++ Q7x.milS 30 Oct 2006 21:09:17 -0000 1.3 > @@ -4,7 +4,7 @@ > xquery("xml"," > do insert > <comment>This is a bargain !</comment> > -as last into exactly-one(doc(\"items.xml\")/items/item_tuple[itemno=1002]) > +as last into exactly-one(for $i in doc(\"items.xml\")/items/item_tuple where $i/itemno=1002 return $i) > ").printf(); > > xquery("xml","doc(\"items.xml\")").printf(); > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > -- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/

2 1

[Monetdb-developers] starting a new user...
by Romulo Goncalves 30 Oct '06

30 Oct '06

Dear developers, I created a user, schema and I set the new schema for the new user: CREATE SCHEMA "test" AUTHORIZATION "public"; CREATE USER "monet_test" WITH PASSWORD 'pass_test' NAME 'TEST USER' SCHEMA "sys"; ALTER USER "monet_test" SET SCHEMA "test"; Then I connect the new user with a mclient: [goncalve@amelia Dependencies]$ mclient -umonet_test -Ppass_test MAPI = monet_test@localhost:50000 ACTION= mapi_start_talking ERROR = !InvalidCredentialsException:checkCredentials:Invalid credentials for user 'monet_test' [goncalve@amelia Dependencies]$ What is the problem with the user creation? The authorization for the schema is public this means that any user can use the schema "test". I am right or wrong? I will appreciate some help. Best Regards, Romulo Goncalves

2 2

[Monetdb-developers] 'at'-hint URI for XRPC calls
by Ying Zhang 30 Oct '06

30 Oct '06

Hello Jens, An XRPC call needs to know the value of the 'at'-hint of its module, so that it can tell the XRPC receiver where to load the module file. The implementation of the previous XRPC syntax (import rpc-module) saves the 'at'-hint in 'apply.rpc_uri'. In the implementation of the current XRPC syntax (execute at...), this information is gone. I'm wondering if the struct PFfun_t or one of its member can be extended to include the value of the 'at'-hint. Regards, Jennie

1 1

[Monetdb-developers] XRPC Syntax
by Peter Boncz 29 Oct '06

29 Oct '06

Dear all, I know you don't probably want to see any more emails on this, but I will re- visit the proposed XRPC syntax once more. The following proposals have been made: (a) "execute at" SimpleExrp FunctionCall (in the paper) (b) "execute at" "{" SimpleExpr "}" "{" FunctionCall "}" (currently implemented) (c) "execute at" "{" SimpleExpr "}" FunctionCall (lighter variant) (d) "execute at" SimpleExpr "xquery" FunctionCall (XQueryD.1) (e) "execute at" SimpleExpr "function" FunctionCall (XQueryD.2) I will first try to summarize the positions on these proposals: - Jens: stresses the point that lexical analysis should be easy. Secondary, he values a connection with XQueryD, with preference for full query support (not only module function calls). Jens supports (b), (c) and (d). - Jennie: seems not to care about the exact syntax. Tis may be a ery wise position. - Torsten: prefers parentheses notation, to denote a lexical scope with special semantics (similar to element and attribute). Supports (b) and (c). - Peter: is rapidly progressing to a point not to care, but under interrogation will still confess to a preference for (a). Is this an interrogation?? Yes, yes, I will confess: As XQueryD is "dead" in the sense that it is not even in Galax where it was proposed, I do not feel inclined to adapt all of the syntax necessarily (we do adopt "execute at" in any case, so they can be happy with that). The XQueryD proposal requires quite a bit of analysis and transformation to correctly parse a query with some variables appearing without being defined, in the free-form xqueries they support. This is not required when viewing an RPC as a remote *function* call, such that the XQuery language support for function signatures can be leveraged to make parameters explicit. Then, for the user the simplest syntax for RPC is (a), at least in the sense that it is the shortest. Suppose we *do* view XRPC as an extension of XQueryD (I actually don't), or really a special case within it, as Jens says. Because free-format xqueries need extra implementation effort (parameter extraction) and a protocol extension (to send the query definition), and cannot benefit from pre- processing and a function cache (easily) we can and want to use a faster execution strategy for the specific (XRC) case of module function calls (i.e. optimized to fit into the function cache -- this saves a lot of latency, from 170msec to 35msec) . To aid this decision, syntax support can be given (i.e. using the keyword "function" instead of "xquery"). Also, with two different keywords, systems could support both functions and free-form, or any of the two. Therefore, if asked for my preference after (a), I would favor (e) over (d). But once again, I actually do not feel much about the need to be XQueryD consistent. Now Torsten's opinion is that when it is necessary to delimit the thing being RPC-ed, then parentheses may be the most logical delimiters. This then goes counter to the XQueryD proposal, which uses "xquery". His well-formulated argument then made me start doubting my second-best preference (e); maybe (b) is after all more logical. Still, it does not make me doubt about my first preference, (a). \Is explicit delimiting necessary, for an extension that does not build on XQueryD, and only has the ambition to call single XQuery functions remotely, in any case? I'd say no. What remain are Jens' reserves about (a) being possible/attractive in the scanner/parser. I can come up with the below short diff. Unless previous versions, this one works, and abides to the spirit of the scanner that refrains from using input()/unput() nor REJECT. When in operator mode, the scanner should not see a QName followed by a parenthesis, unless it is a builtin operator name (e.g. "x" eq ("y")), so QName- s were not allowed. In case of XRPC style (a), this is what happens when finishing the parse of the URI expression( e.g. execute at "x" fcn("y")). My modification addes a rule with lowest preference in the OPERATOR mode to accept a QName (lowest pref, so it was not recognized as a builtin operator), and then matches the '(' in a new more EXPRFCNCALL mode that serves just that purpose. Peter Index: scanner.l =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/scanner.l,v retrieving revision 1.40 diff -r1.40 scanner.l 136a137 > || YY_START == EXPRFCNCALL \ 343a345 > /* 25 EXPRFCNCALL */ 368a371 > %x EXPRFCNCALL 607,608c610,611 < "execute"{_}"at"{_}?"{" { pushState (OPERATOR); pushState (DEFAULT); < yield (execute_at_lbrace); } --- > "execute"{_}"at"{_}? { pushState (OPERATOR); pushState (DEFAULT); > yield (execute_at); } 776a780,787 > {QName} { gotoState (EXPRFCNCALL); > pflval.qname = extract_qname (yytext, 0); } > . { yield (invalid_character); } > } > > <EXPRFCNCALL>{ > {_}?"("/[^:] { gotoState (DEFAULT); > yield (QName_LParen); } Index: parser.y =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/parser.y,v retrieving revision 1.47 diff -r1.47 parser.y 353c353 < %token execute_at_lbrace "execute at {" --- > %token execute_at "execute at" 2766,2767c2766,2767 < XRPCCall : "execute at {" Expr "}" "{" FunctionCall "}" < { $$ = wire2 (p_xrpc, @$, $2, $5); } --- > XRPCCall : "execute at" Expr FunctionCall > { $$ = wire2 (p_xrpc, @$, $2, $3); }

2 1

Re: [Monetdb-developers] New serialize form of XRPC message
by Jan Rittinger 27 Oct '06

27 Oct '06

Hi Jennie, Your output looks pretty good. I would reuse as much as possible from the xml-typed mode. If you however have conflicts then I'd introduce new callbacks. In your case it seems sensible to introduce all the namespace declarations in some xrpc_serializeStart event that also prints the whole envelope tag. A xrpc_serializeStop event may then close this element. In addition you would need a new xrpc_seqStart and xrpc_seqEnd callback that uses a user-given sequence name and does not generate the namespace declarations. As you can see I proposed to introduce two new callbacks that have to be placed before/after the loop over the different iterations -- That change would be fine with me. It however requires to introduce dummy routines that have to be called for all modes except xrpc (the serializeFunStruct and its instances have to be modified -- see serialize*.mx and modules/...). What do the other think? Jan On 10/23/2006 05:32 PM, Ying Zhang wrote with possible deletions: > Hello Jan, > > With this e-mail, I would like to ask for your advice how I can > reuse/adjust the current serialization code of the "typed" mode to > support serializing the new XRPC response message. > > Maybe you have seen in our (Peter and I) XRPC paper for PLAN-X that we > have defined an XML schema for the XRPC request and response messages. > The schema definition file is avaible here: > http://monetdb.cwi.nl/XQuery/XRPC.xsd > > An XRPC response message now looks like this: > > <?xml version="1.0" encoding="utf-8"?> > <env:Envelope > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:env="http://www.w3.org/2003/05/soap-envelope" > xsi:schemaLocation="http://www.w3.org/2003/05/soap-envelope http://www.w3.org/2003/05/soap-envelope" > xmlns:xrpc="http://monetdb.cwi.nl/XQuery" > xsi:schemaLocation="http://monetdb.cwi.nl/XQuery http://monetdb.cwi.nl/XQuery/XRPC.xsd"> > <env:Body> > <xrpc:response xrpc:module="xrpcmodule" xrpc:method="test"> > > <xrpc:sequence> > <xrpc:document><a/></xrpc:document> > <xrpc:element><a/></xrpc:element> > </xrpc:sequence> > <xrpc:sequence> > <xrpc:attribute x="y"/> > <xrpc:text>z</xrpc:text> > </xrpc:sequence> > <xrpc:sequence> > <xrpc:processing-instruction>z</xrpc:processing-instruction> > <xrpc:comment></xrpc:comment> > <xrpc:atomic-value xsi:type="xs:integer">1</xrpc:atomic-value> > <xrpc:atomic-value xsi:type="xs:decimal">42.100000</xrpc:atomic-value> > <xrpc:atomic-value xsi:type="xs:string">bla</xrpc:atomic-value> > </xrpc:sequence> > > </xrpc:response> > </env:Body> > </env:Envelope> > > As you can see, the new form of XRPC response message is quite different > than the current form of the XRPC messages, but it is very similar to > the way the result of an xquery is serialized in the "typed" mode. > During the making of the new schema, we have actually consulted the > output of the "typed" mode to use the same type names, so that we can > reuse as much as possbile the code of the "typed" mode. > > The "xrpc:sequence" part is very similar to the "result:sequence" part > of the typed mode. In serialize_dflt.mx, the seriializeFunStruct-s of > "xml typed" and "xml soap" only differ in the following: > > struct serializeFunStruct struct serializeFunStruct > typed_xmlSerializeFun = { typed_xmlSerializeFun = { > "xml typed", "soap xml", > > typed_xml_seqStart, xml_seqStart, > null_complete_seqStart, xml_complete_seqStart, > typed_xml_seqEnd, xml_seqEnd, > typed_xml_seqItemStart, soap_xml_seqItemStart, > typed_xml_seqItemEnd, soap_xml_seqItemEnd, > null_seqItemSeparator soap_xml_seqItemSeparator > }; }; > > If we make two changes in the typed_* functions, all xml_* and soap_* > functions in "soap xml" can by replaced by the typed_* functions to > procude the new XRPC response messages. With these changes, we can even > get rid of the "soap" mode, and just use the "typed" mode to serialize > XRPC response messages. > > The changes I would need are the following: > > (i) instead of using the static prefix "result", use a dynamically > specified prefix, so that i.s.o. "result:sequence", "xrpc:sequence" can > be printed for XRPC response messages. Can we store the prefix in the > existing parameter XqueryCtx* ctx? Or do we need to add a new parameter > to the typed_* functions? > > This change is not _strictly_ necessary, since I can also use the prefix > "result" in the XRPC response messages, but using dynamically specified > prefixes looks nicer/cleaner to me. > > (ii) for XRPC response messages, I'd prefer to not have the namespace > definitions of "result" (or "xrpc"), "xs" and "xsi" in > <result:sequence>, because each XRPC response message can contain a > (large) number of sequences. With the NS definitions of "result", "xs" > and "xsi" included in every sequence tag is obviously wasting of > bandwidth. Do you have an idea how this change can be implemented > nicely? > > > I hope I have made my problems and ideas clear. Please ask me if it is > not so. > > Thanks in advance! > > > Regards, > > Jennie > -- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/

2 3

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/debug abssynprint.c, 1.25, 1.26 coreprint.c, 1.26, 1.27
by Ying Zhang 27 Oct '06

27 Oct '06

On Tue, Oct 24, 2006 at 03:20:03PM +0000, Jens Teubner wrote: > Update of /cvsroot/monetdb/pathfinder/compiler/debug > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv19355/compiler/debug > > Modified Files: > abssynprint.c coreprint.c > Log Message: > Parser support for the `execute at' syntax extension (XRPC). > > Pathfinder's parser now recognizes expressions of the kind > > "execute" "at" "{" Expr "}" "{" FunctionCall "}" Hi Jens, Would you please change the implementation of the syntax according to the discussion on the syntax? The final version (I hope:)) of the syntax should be: "execute at" Expr "xquery" FunctionCall Thanks! Jennie > > where the expression in the first pair of braces specifies an > URI where the function call given in the second pair should > be evaluated at. Note that, in order to avoid parser conflicts, > we did not directly use the syntax proposed in a recent paper > submission, but rather this one that adds the curly braces. > > The system will try hard to convert the expression given in > the first pair of braces into a string. > > An expression as shown above will lead to a Core tree situation > that uses the new node kind `xrpc': > > xrpc > / \ > URI FunctionCall > > It's now Jennie's task to support that in the back-end. I suppose the change in the syntax won't affect the structure of this node kind? > TODO: If *not* touched the code that is currently existing in > Pathfinder and uses the "old" `import rpc-module' syntax. > Jennie, will you rip out this old stuff, once you have implemented > back-end support for the new syntax? Yep, I will. Jennie > > > Index: coreprint.c > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/debug/coreprint.c,v > retrieving revision 1.26 > retrieving revision 1.27 > diff -u -d -r1.26 -r1.27 > --- coreprint.c 25 Sep 2006 11:11:36 -0000 1.26 > +++ coreprint.c 24 Oct 2006 15:20:01 -0000 1.27 > @@ -132,6 +132,9 @@ > , [c_recursion] = "recursion" > , [c_seed] = "seed" > > + /* Pathfinder extension: XRPC */ > + , [c_xrpc] = "xrpc" > + > }; > > /** Current node id */ > > Index: abssynprint.c > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/debug/abssynprint.c,v > retrieving revision 1.25 > retrieving revision 1.26 > diff -u -d -r1.25 -r1.26 > --- abssynprint.c 25 Sep 2006 11:11:33 -0000 1.25 > +++ abssynprint.c 24 Oct 2006 15:20:01 -0000 1.26 > @@ -181,6 +181,9 @@ > /* Pathfinder extension: recursion */ > , [p_recursion] = "recursion" > , [p_seed] = "seed" > + > + /* Pathfinder extension: XRPC */ > + , [p_xrpc] = "xrpc" > }; > > /** Names of XPath axes */ > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins

2 3

[Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

Hi Jennie, hi Peter, I am currently looking into the XRPC syntax. Primarily I wanted to give you feedback to what you wrote in your Plan-X submission. So you are defining the syntax to be XRPCCall ::= "execute" "at" URILiteral FunctionCall Lateron, however, you allow more than just a literal URI, but rather an XQuery expression. So `URILiteral' is definitely wrong here. Once you changed this to, say, ExprSingle, you end up with ambiguity in your parser. Consider execute at "foo" eq ("bar") (I couldn't think of a better example ad hoc.) What we have here is an ambiguity: we don't know whether `eq' is supposed to be a function call, or if it is the binary operator `eq', followed by another expression in parenthesis. So I will take the freedom to modify your syntax proposal and do it in a more XQuery-like style: "execute" "at" "{" Expr "}" "{" FunctionCall "}" This avoids the ambiguity and should make it rather easy to parse. ...already hacking... Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Time is money. Especially if you make clocks.

1 0

Re: [Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

Hi Peter, hi Jennie, On Tue, Oct 24, 2006 at 09:13:00PM +0200, Ying Zhang wrote: > I found the formal definition of XQueryD grammar (BTW. it's called > XQueryD, not DXQ. DXQ is something else.) in "A Framework for XML-Based > Integration": > > ExprSingle ::= "execute at" <URL> [ "xquery" { ExprSingle } | ... ] this syntax actually looks okay to me as well. The reason: XQuery is crafted in a way that it uses as few keywords as possible. To achieve that, the lexical analyzer (a) often recognizes patterns that are larger than a single word (matching "execute at" instead of "execute" removes the ambiguity with a child step searching for an `execute' element) and (b) switches parsing states depending on the symbols that the lexer sees. What we have here is that the lexical analyzer reads an expression. After reading an expression, it will *always* wait for an operator (e.g., an arithmetic operator, a sequence constructor, but also `as type', etc.). In this state it is safe to recognize a lot more keywords without making them ambiguous with, e.g., path steps. So if we throw in the `xquery' here, the state machine of the lexical analyzer should run fine again. `xquery' will be recognized as a keyword whenever an operator is expected, but not otherwise. Peter, Pathfinder's parser is strictly separated as it is supposed to be in a well-designed parser. There is a lexical analyzer, which is *independent* of the parser (done with bison in Pathfinder). Being unaware of any context information, our lexical analyzer thus cannot know that it currently is somewhere between the two components of an "execute at" clause. If you prefer the above syntax, I could implement that. It should be an easy fix. Just let me know. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 No scientist is ever right, they just can't be proved wrong at the time! -- Richard Feynman

1 0

Re: [Monetdb-developers] XRPC syntax
by Ying Zhang 27 Oct '06

27 Oct '06

Hi Peter, What is the reason that you want to avoid using the additional braces? I found the formal definition of XQueryD grammar (BTW. it's called XQueryD, not DXQ. DXQ is something else.) in "A Framework for XML-Based Integration": ExprSingle ::= "execute at" <URL> [ "xquery" { ExprSingle } | ... ] So they also use braces to surrond the piece of xquery query that will be executed remotely. This is similar with '{FunctionCall}'. And since Jens said that using extrax braces will make parsing easier, so I thought it won't hurt to have one more pair of braces to surround the destination expression. Jennie On Tue, Oct 24, 2006 at 08:47:48PM +0200, p.a.boncz(a)chello.nl wrote: > Hi Jens, > > I had missed this email. The ambiguity you identify is for operators, which by default are built-ins. Thus, technically there is no ambiguity. > > In this case, you would parse "x eq y" as an ExprSingle, and then you will actually give a parse error because of the missing function application. > > If it is really impossible to do (for some reason), I would propose the syntax: > > XRPCCall ::= "execute" "at" ExprSingle "function" FunctionCall > > which is analogous to DXQ: "execute" "at" ExprSingle "xquery" ExprSingle > > Peter > > > > > > van: Jens Teubner <jens.teubner(a)in.tum.de> > > datum: 2006/10/24 Tue PM 02:55:21 MEST > > aan: Ying Zhang <Y.Zhang(a)cwi.nl>, P.Boncz(a)cwi.nl > > onderwerp: XRPC syntax > > > > Hi Jennie, hi Peter, > > > > I am currently looking into the XRPC syntax. Primarily I wanted to give > > you feedback to what you wrote in your Plan-X submission. > > > > So you are defining the syntax to be > > > > XRPCCall ::= "execute" "at" URILiteral FunctionCall > > > > Lateron, however, you allow more than just a literal URI, but rather an > > XQuery expression. So `URILiteral' is definitely wrong here. > > > > Once you changed this to, say, ExprSingle, you end up with ambiguity in > > your parser. Consider > > > > execute at "foo" eq ("bar") > > > > (I couldn't think of a better example ad hoc.) What we have here is an > > ambiguity: we don't know whether `eq' is supposed to be a function call, > > or if it is the binary operator `eq', followed by another expression in > > parenthesis. > > > > So I will take the freedom to modify your syntax proposal and do it in a > > more XQuery-like style: > > > > "execute" "at" "{" Expr "}" "{" FunctionCall "}" > > > > This avoids the ambiguity and should make it rather easy to parse. > > > > ...already hacking... > > > > Jens > > > > -- > > Jens Teubner > > Technische Universitaet Muenchen, Department of Informatics > > D-85748 Garching, Germany > > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > > > Time is money. Especially if you make clocks. > > >

1 0

Re: [Monetdb-developers] XRPC syntax
by p.a.boncz＠chello.nl 27 Oct '06

27 Oct '06

Hi Jens, I had missed this email. The ambiguity you identify is for operators, which by default are built-ins. Thus, technically there is no ambiguity. In this case, you would parse "x eq y" as an ExprSingle, and then you will actually give a parse error because of the missing function application. If it is really impossible to do (for some reason), I would propose the syntax: XRPCCall ::= "execute" "at" ExprSingle "function" FunctionCall which is analogous to DXQ: "execute" "at" ExprSingle "xquery" ExprSingle Peter > > van: Jens Teubner <jens.teubner(a)in.tum.de> > datum: 2006/10/24 Tue PM 02:55:21 MEST > aan: Ying Zhang <Y.Zhang(a)cwi.nl>, P.Boncz(a)cwi.nl > onderwerp: XRPC syntax > > Hi Jennie, hi Peter, > > I am currently looking into the XRPC syntax. Primarily I wanted to give > you feedback to what you wrote in your Plan-X submission. > > So you are defining the syntax to be > > XRPCCall ::= "execute" "at" URILiteral FunctionCall > > Lateron, however, you allow more than just a literal URI, but rather an > XQuery expression. So `URILiteral' is definitely wrong here. > > Once you changed this to, say, ExprSingle, you end up with ambiguity in > your parser. Consider > > execute at "foo" eq ("bar") > > (I couldn't think of a better example ad hoc.) What we have here is an > ambiguity: we don't know whether `eq' is supposed to be a function call, > or if it is the binary operator `eq', followed by another expression in > parenthesis. > > So I will take the freedom to modify your syntax proposal and do it in a > more XQuery-like style: > > "execute" "at" "{" Expr "}" "{" FunctionCall "}" > > This avoids the ambiguity and should make it rather easy to parse. > > ...already hacking... > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > Time is money. Especially if you make clocks. >

1 0

Re: [Monetdb-developers] XRPC syntax
by p.a.boncz＠chello.nl 27 Oct '06

27 Oct '06

Hi Jens, To answer your opening question, this email exchange has brought us to the root of the issue, which I personally find very useful, because I like to understand what is happening to me when something is happening to me. After all, this was not really about the XRPC extension not being parsable. Rather, the small diff needed to introduce the proposed syntax does not suit your *coding* easthetics, apparently because you object to the use of REJECT in a scanner. Or something along those lines. I infer this from your qualification of my code as "lowering the quality of the Pathfinder parser". I can only assure you that "messing up the Pathfinder parser" was not my intent while writing that code. Given that the Pathfinder parser (and beyond) is mostly your brainchild, I can understand that you want to retain control over where it is heading. So if you block this proposal for reasons of taste, I will have to listen to you, even if I disagree or simply do not understand what the fuss is about (I myself care more if a language syntax is handy for a human user, rather than for a parser, which is operated by a machine without feelings). So, on to an alternative syntax. I will restrict myself to the alternatives that you find acceptable for some reason. For me the XQueryD syntax is not a holy thing, as it does not really have any installed base. It is not part of Galax, just was part of some prototype that never made it into a stable version. But I do like the 'xquery' variant better than the curly braces, plus we have indeed the argument that this is the same as something that was proposed before (even if that something has become irrelevant). So, thanks in advance for making that change.. Peter > > van: Jens Teubner <jens.teubner(a)in.tum.de> > datum: 2006/10/25 Wed PM 06:38:03 CEST > aan: p.a.boncz(a)chello.nl > cc: Ying Zhang <Y.Zhang(a)cwi.nl>, P.Boncz(a)cwi.nl > onderwerp: Re: Re: XRPC syntax > > On Wed, Oct 25, 2006 at 06:00:39PM +0200, p.a.boncz(a)chello.nl wrote: > > > Hi Jens, > > > > Well, you had me reading the flex manual there, after which I must > > still conclude that our modification is parsable. > > > > What I meant from the start is that one can match the operator > > keywords after which a "(" can legally occur (eq, etc) with preference > > over QName_LParam. See the below diff. > > > > There are also ways of doing that without REJECT, if your religion > > does not permit its use. > > e.g.: ("eq"|("eq"/{_}"(")) { gotoState (DEFAULT); yield (eq); } > > > > The MIL parser is a mess; but gladly its internals should play no role > > in this discussion. > > Hi Peter, > > I cannot see where this shall head. Why would we, under all > circumstances, try to mess up Pathfinder's parser? As far as I can see, > *all* the proposals made by other people do use some syntax that aids > parsing. The XQuery syntax itself built its way for good reason, and > both approaches we had are very much in the flavor of XQuery. I cannot > see why we would want to give that up. > > I *strongly* vote for using either of the following two options: > > -- execute at { Expr } { FunctionCall } > > -- execute at Expr xquery FunctionCall > > Both, in my opinion, are clean and in line with the remaining language. > From a parser point of view, we could leave out the *second* pair of > curly braces, but that would only make things inconsistent. > > Also, I cannot understand why you insist on introducing your very own > syntax for XRPC. There have been other proposals. In the spirit of > interoperability, experimentation, comparison, etc. I think the adaption > of existing syntax is a good idea. It would help increasing our > system's acceptance and visibility, I argue. > > (I brought the MIL parser into the discussion, because I thought that > would put you off any attempts to lower the quality of Pathfinder's > parser.) > > 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 >

1 0

Re: [Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

On Wed, Oct 25, 2006 at 06:00:39PM +0200, p.a.boncz(a)chello.nl wrote: > Hi Jens, > > Well, you had me reading the flex manual there, after which I must > still conclude that our modification is parsable. > > What I meant from the start is that one can match the operator > keywords after which a "(" can legally occur (eq, etc) with preference > over QName_LParam. See the below diff. > > There are also ways of doing that without REJECT, if your religion > does not permit its use. > e.g.: ("eq"|("eq"/{_}"(")) { gotoState (DEFAULT); yield (eq); } > > The MIL parser is a mess; but gladly its internals should play no role > in this discussion. Hi Peter, I cannot see where this shall head. Why would we, under all circumstances, try to mess up Pathfinder's parser? As far as I can see, *all* the proposals made by other people do use some syntax that aids parsing. The XQuery syntax itself built its way for good reason, and both approaches we had are very much in the flavor of XQuery. I cannot see why we would want to give that up. I *strongly* vote for using either of the following two options: -- execute at { Expr } { FunctionCall } -- execute at Expr xquery FunctionCall Both, in my opinion, are clean and in line with the remaining language. >From a parser point of view, we could leave out the *second* pair of curly braces, but that would only make things inconsistent. Also, I cannot understand why you insist on introducing your very own syntax for XRPC. There have been other proposals. In the spirit of interoperability, experimentation, comparison, etc. I think the adaption of existing syntax is a good idea. It would help increasing our system's acceptance and visibility, I argue. (I brought the MIL parser into the discussion, because I thought that would put you off any attempts to lower the quality of Pathfinder's parser.) 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

1 0

Re: [Monetdb-developers] XRPC syntax
by p.a.boncz＠chello.nl 27 Oct '06

27 Oct '06

Hi Jens, Well, you had me reading the flex manual there, after which I must still conclude that our modification is parsable. What I meant from the start is that one can match the operator keywords after which a "(" can legally occur (eq, etc) with preference over QName_LParam. See the below diff. There are also ways of doing that without REJECT, if your religion does not permit its use. e.g.: ("eq"|("eq"/{_}"(")) { gotoState (DEFAULT); yield (eq); } The MIL parser is a mess; but gladly its internals should play no role in this discussion. Peter Index: scanner.l =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/scanner.l,v retrieving revision 1.40 diff -r1.40 scanner.l 317c317 < %option noreject --- > %option reject 607,608c607,608 < "execute"{_}"at"{_}?"{" { pushState (OPERATOR); pushState (DEFAULT); < yield (execute_at_lbrace); } --- > "execute"{_}"at"{_}? { pushState (OPERATOR); pushState (DEFAULT); > yield (execute_at); } 651a652 > PFlog("<DEFAULT>"); 776a778,785 > {QName} { int c; > do c = input(); > while (c == 0x20 || c == 0x09 || c == 0x0d || c == 0x0a); > if (c != '(') REJECT; > gotoState (DEFAULT); > pflval.qname = extract_qname (yytext, 0); > yield (QName_LParen); > } > > van: Jens Teubner <jens.teubner(a)in.tum.de> > datum: 2006/10/25 Wed PM 04:46:51 CEST > aan: p.a.boncz(a)chello.nl > cc: Ying Zhang <Y.Zhang(a)cwi.nl>, P.Boncz(a)cwi.nl > onderwerp: Re: Re: XRPC syntax > > On Wed, Oct 25, 2006 at 03:41:44PM +0200, p.a.boncz(a)chello.nl wrote: > > > Hi Jens, > > > > Indeed you are right, I meant XQueryD. > > > > As I still do not grasp how the parsing problem manifests itself, I > > just applied the changes we desire to the parser/scanner myself (see > > below). As far as I can see, this works. The parser reports one more > > shift/reduce conflict in state 122 (it now has 3 conflicts instead of > > 2, and in total there are 17 instead of 16), which on my fiirst sight > > does not seem significant. > > 42 eq (42) > > This is quite precisely the problem I tried to describe. Trust me, > parsing XQuery is a lot trickier than MIL. (And even that you > implemented as simple as possible; think about operator priorities.) > > > Your characterization of XQuery as a language with little keywords, > > makes me appreciate our current syntactical proposal more than a > > solution with braces or keywords. If forced to choose between them, I > > would go for a keyword. In that case, i would not use "xquery" as this > > might put the XQueryD guys into trouble (they want a valid XQuery > > after that - we just a function call), but rather propose "function", > > i.e. execute at "foo" function bla(1). > > I'd actually use the same argument the other way round. Using the same > syntax as somebody else leaves us room for (maybe) supporting arbitrary > XQuery expressions at some point in time. In both, the "curly braces" > approach, as well as in the "keyword" approach we could, if needed, > easily open our parser to allow any expression. > > Regards, > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > Beware of bugs in the above code; > I have only proved it correct, not tried it. > -- Donald Knuth >

1 0

Re: [Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

On Wed, Oct 25, 2006 at 03:41:44PM +0200, p.a.boncz(a)chello.nl wrote: > Hi Jens, > > Indeed you are right, I meant XQueryD. > > As I still do not grasp how the parsing problem manifests itself, I > just applied the changes we desire to the parser/scanner myself (see > below). As far as I can see, this works. The parser reports one more > shift/reduce conflict in state 122 (it now has 3 conflicts instead of > 2, and in total there are 17 instead of 16), which on my fiirst sight > does not seem significant. 42 eq (42) This is quite precisely the problem I tried to describe. Trust me, parsing XQuery is a lot trickier than MIL. (And even that you implemented as simple as possible; think about operator priorities.) > Your characterization of XQuery as a language with little keywords, > makes me appreciate our current syntactical proposal more than a > solution with braces or keywords. If forced to choose between them, I > would go for a keyword. In that case, i would not use "xquery" as this > might put the XQueryD guys into trouble (they want a valid XQuery > after that - we just a function call), but rather propose "function", > i.e. execute at "foo" function bla(1). I'd actually use the same argument the other way round. Using the same syntax as somebody else leaves us room for (maybe) supporting arbitrary XQuery expressions at some point in time. In both, the "curly braces" approach, as well as in the "keyword" approach we could, if needed, easily open our parser to allow any expression. Regards, Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth

1 0

Re: [Monetdb-developers] XRPC syntax
by p.a.boncz＠chello.nl 27 Oct '06

27 Oct '06

Hi Jens, Indeed you are right, I meant XQueryD. As I still do not grasp how the parsing problem manifests itself, I just applied the changes we desire to the parser/scanner myself (see below). As far as I can see, this works. The parser reports one more shift/reduce conflict in state 122 (it now has 3 conflicts instead of 2, and in total there are 17 instead of 16), which on my fiirst sight does not seem significant. Your characterization of XQuery as a language with little keywords, makes me appreciate our current syntactical proposal more than a solution with braces or keywords. If forced to choose between them, I would go for a keyword. In that case, i would not use "xquery" as this might put the XQueryD guys into trouble (they want a valid XQuery after that - we just a function call), but rather propose "function", i.e. execute at "foo" function bla(1). Peter Index: parser.y =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/parser.y,v retrieving revision 1.47 diff -r1.47 parser.y 353c353 < %token execute_at_lbrace "execute at {" --- > %token execute_at "execute at" 2766,2767c2766,2767 < XRPCCall : "execute at {" Expr "}" "{" FunctionCall "}" < { $$ = wire2 (p_xrpc, @$, $2, $5); } --- > XRPCCall : "execute at" Expr FunctionCall > { $$ = wire2 (p_xrpc, @$, $2, $3); } Index: scanner.l =================================================================== RCS file: /cvsroot/monetdb/pathfinder/compiler/parser/scanner.l,v retrieving revision 1.40 diff -r1.40 scanner.l 607,608c607,608 < "execute"{_}"at"{_}?"{" { pushState (OPERATOR); pushState (DEFAULT); < yield (execute_at_lbrace); } --- > "execute"{_}"at"{_}? { pushState (OPERATOR); pushState (DEFAULT); > yield (execute_at); } 776a777,780 > {QName}{_}?"("/[^:] { gotoState (DEFAULT); > pflval.qname = extract_qname (yytext, 0); > yield (QName_LParen); > } > > van: Jens Teubner <jens.teubner(a)in.tum.de> > datum: 2006/10/25 Wed AM 11:28:53 CEST > aan: Ying Zhang <Y.Zhang(a)cwi.nl> > cc: p.a.boncz(a)chello.nl, P.Boncz(a)cwi.nl > onderwerp: Re: XRPC syntax > > Hi Peter, hi Jennie, > > On Tue, Oct 24, 2006 at 09:13:00PM +0200, Ying Zhang wrote: > > > I found the formal definition of XQueryD grammar (BTW. it's called > > XQueryD, not DXQ. DXQ is something else.) in "A Framework for XML-Based > > Integration": > > > > ExprSingle ::= "execute at" <URL> [ "xquery" { ExprSingle } | ... ] > > this syntax actually looks okay to me as well. > > The reason: XQuery is crafted in a way that it uses as few keywords as > possible. To achieve that, the lexical analyzer (a) often recognizes > patterns that are larger than a single word (matching "execute at" > instead of "execute" removes the ambiguity with a child step searching > for an `execute' element) and (b) switches parsing states depending on > the symbols that the lexer sees. > > What we have here is that the lexical analyzer reads an expression. > After reading an expression, it will *always* wait for an operator > (e.g., an arithmetic operator, a sequence constructor, but also `as > type', etc.). In this state it is safe to recognize a lot more keywords > without making them ambiguous with, e.g., path steps. So if we throw in > the `xquery' here, the state machine of the lexical analyzer should run > fine again. `xquery' will be recognized as a keyword whenever an > operator is expected, but not otherwise. > > Peter, Pathfinder's parser is strictly separated as it is supposed to be > in a well-designed parser. There is a lexical analyzer, which is > *independent* of the parser (done with bison in Pathfinder). Being > unaware of any context information, our lexical analyzer thus cannot > know that it currently is somewhere between the two components of an > "execute at" clause. > > If you prefer the above syntax, I could implement that. It should be an > easy fix. Just let me know. > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > No scientist is ever right, they just > can't be proved wrong at the time! > -- Richard Feynman >

1 0

Re: [Monetdb-developers] XRPC syntax
by p.a.boncz＠chello.nl 27 Oct '06

27 Oct '06

Hi Jens (& Jennie), Thanks for your efforts. As for the syntax, I must say I do not like the idea of the curly braces. Where does that come from? Maybe there is a parsing reason, but if possible, I would avoid them. AFAIK, the DXQ extension by Suciu which also introduces "execute at" did not have that restriction. On another note, during the various phases of query parsing and analisys, we introduced ugly hacks to add a special parameter if the function application was an rpc call. That ugly stuff can now be removed. thanks again, Peter > > van: Ying Zhang <Y.Zhang(a)cwi.nl> > datum: 2006/10/24 Tue PM 06:08:51 MEST > aan: Jens Teubner <jens.teubner(a)in.tum.de> > cc: P.Boncz(a)cwi.nl > onderwerp: Re: XRPC syntax > > On Tue, Oct 24, 2006 at 05:28:48PM +0200, Jens Teubner wrote: > > On Tue, Oct 24, 2006 at 04:58:30PM +0200, Ying Zhang wrote: > > > > > What is then the right definition of the grammar rule? > > > > > > XRPCCall ::= "execute" "at" "{" URILiteral "}" "{" FunctionCall "}" > > > > > > or > > > > > > XRPCCall ::= "execute" "at" "{" ExprSingle "}" "{" FunctionCall "}" > > > > > > (BTW, are the braces added correctly?) > > > > It's > > > > XRPCCall ::= "execute" "at" "{" Expr "}" "{" FunctionCall "}" > ^^^^ > shouldn't it be ExprSingle? Since we want only _one_ URI string here. > > > > > > (Although it shouldn't really matter in that situation.) > > > > > > I will have to think about how we can implement such a check most > > > > elegantly within Pathfinder. I'm wondering about its usefulness, > > > > though. I accept that we may want to restrict it to non-built-ins only. > > > > But is the import via a module a sensible restriction? i > > > > > > I think it does make sense to filter out XRPC calls to in-query UDFs. > > > If an in-query UDF is called with XRPC, the query just cannot be > > > executed, since we don't want to ship the function implementation in > > > XRPC request. So if such a query is not rejected by the compiler, it > > > will eventually be rejected by the XRPC sender. > > > > In my opinion, it is fine if the sender rejects such stupid queries. We > > will have to check different things there anyway, such as `Is there > > actually a remote XRPC system listening at the given URI?', `Does it > > support the functions that I'm trying to call there?', and so on. > > There's no way we can do such essential tests in the compiler. So why > > do some very hand-waving tests that won't be effective in practice, > > anyway? In my opinion, this is wasted effort (both, in terms of coding > > and in terms of CPU cycles). > > Thus checks don't belong to the compiler, I think. > > > > Maybe we should put even more restriction on the imported module, such > > > as we can require that the imported module should be available in a > > > location which is accessible via the HTTP protocol. This way, we know > > > it for sure that both the XRPC client and the server can access the > > > module definition file (provided there is not further authentication > > > restriction of accessing the file), and both the client and the server > > > access the *same* module definition file, so the argument types should > > > be the same (right?). > > > > You introduced so many conditionals here that I think it only > > strengthens my above point. > > :) > > I will think up other places to do such checks, if necessary. > > > > > > Support for the new syntax, by the way, is now in CVS. > > Thanks! > > > Jennie > > > > > Jens > > > > -- > > Jens Teubner > > Technische Universitaet Muenchen, Department of Informatics > > D-85748 Garching, Germany > > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > > > Be consistent. > > -- `perlstyle' man page >

1 0

Re: [Monetdb-developers] XRPC syntax
by Ying Zhang 27 Oct '06

27 Oct '06

On Tue, Oct 24, 2006 at 05:28:48PM +0200, Jens Teubner wrote: > On Tue, Oct 24, 2006 at 04:58:30PM +0200, Ying Zhang wrote: > > > What is then the right definition of the grammar rule? > > > > XRPCCall ::= "execute" "at" "{" URILiteral "}" "{" FunctionCall "}" > > > > or > > > > XRPCCall ::= "execute" "at" "{" ExprSingle "}" "{" FunctionCall "}" > > > > (BTW, are the braces added correctly?) > > It's > > XRPCCall ::= "execute" "at" "{" Expr "}" "{" FunctionCall "}" ^^^^ shouldn't it be ExprSingle? Since we want only _one_ URI string here. > > (Although it shouldn't really matter in that situation.) > > > > I will have to think about how we can implement such a check most > > > elegantly within Pathfinder. I'm wondering about its usefulness, > > > though. I accept that we may want to restrict it to non-built-ins only. > > > But is the import via a module a sensible restriction? i > > > > I think it does make sense to filter out XRPC calls to in-query UDFs. > > If an in-query UDF is called with XRPC, the query just cannot be > > executed, since we don't want to ship the function implementation in > > XRPC request. So if such a query is not rejected by the compiler, it > > will eventually be rejected by the XRPC sender. > > In my opinion, it is fine if the sender rejects such stupid queries. We > will have to check different things there anyway, such as `Is there > actually a remote XRPC system listening at the given URI?', `Does it > support the functions that I'm trying to call there?', and so on. > There's no way we can do such essential tests in the compiler. So why > do some very hand-waving tests that won't be effective in practice, > anyway? In my opinion, this is wasted effort (both, in terms of coding > and in terms of CPU cycles). Thus checks don't belong to the compiler, I think. > > Maybe we should put even more restriction on the imported module, such > > as we can require that the imported module should be available in a > > location which is accessible via the HTTP protocol. This way, we know > > it for sure that both the XRPC client and the server can access the > > module definition file (provided there is not further authentication > > restriction of accessing the file), and both the client and the server > > access the *same* module definition file, so the argument types should > > be the same (right?). > > You introduced so many conditionals here that I think it only > strengthens my above point. :) I will think up other places to do such checks, if necessary. > > Support for the new syntax, by the way, is now in CVS. Thanks! Jennie > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > Be consistent. > -- `perlstyle' man page

1 0

Re: [Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

On Tue, Oct 24, 2006 at 04:58:30PM +0200, Ying Zhang wrote: > What is then the right definition of the grammar rule? > > XRPCCall ::= "execute" "at" "{" URILiteral "}" "{" FunctionCall "}" > > or > > XRPCCall ::= "execute" "at" "{" ExprSingle "}" "{" FunctionCall "}" > > (BTW, are the braces added correctly?) It's XRPCCall ::= "execute" "at" "{" Expr "}" "{" FunctionCall "}" (Although it shouldn't really matter in that situation.) > > I will have to think about how we can implement such a check most > > elegantly within Pathfinder. I'm wondering about its usefulness, > > though. I accept that we may want to restrict it to non-built-ins only. > > But is the import via a module a sensible restriction? i > > I think it does make sense to filter out XRPC calls to in-query UDFs. > If an in-query UDF is called with XRPC, the query just cannot be > executed, since we don't want to ship the function implementation in > XRPC request. So if such a query is not rejected by the compiler, it > will eventually be rejected by the XRPC sender. In my opinion, it is fine if the sender rejects such stupid queries. We will have to check different things there anyway, such as `Is there actually a remote XRPC system listening at the given URI?', `Does it support the functions that I'm trying to call there?', and so on. There's no way we can do such essential tests in the compiler. So why do some very hand-waving tests that won't be effective in practice, anyway? In my opinion, this is wasted effort (both, in terms of coding and in terms of CPU cycles). > Maybe we should put even more restriction on the imported module, such > as we can require that the imported module should be available in a > location which is accessible via the HTTP protocol. This way, we know > it for sure that both the XRPC client and the server can access the > module definition file (provided there is not further authentication > restriction of accessing the file), and both the client and the server > access the *same* module definition file, so the argument types should > be the same (right?). You introduced so many conditionals here that I think it only strengthens my above point. Support for the new syntax, by the way, is now in CVS. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Be consistent. -- `perlstyle' man page

1 0

Re: [Monetdb-developers] XRPC syntax
by Ying Zhang 27 Oct '06

27 Oct '06

On Tue, Oct 24, 2006 at 04:00:48PM +0200, Jens Teubner wrote: > On Tue, Oct 24, 2006 at 03:40:16PM +0200, Ying Zhang wrote: > > > Our intention is to allow an XQuery expression here (after "at"), but it > > should be evaluated to a URILiteral. How can I correct this rule to > > express our intention? > > This is a typing thing, and I've already implemented that. Whatever the > expression after "at" evaluates to, we try to cast it into a string. > This is in line with how XQuery is defined elsewhere. > > You cannot express such a restriction in your grammar, though. This is > a pure typing thing. What is then the right definition of the grammar rule? XRPCCall ::= "execute" "at" "{" URILiteral "}" "{" FunctionCall "}" or XRPCCall ::= "execute" "at" "{" ExprSingle "}" "{" FunctionCall "}" (BTW, are the braces added correctly?) > > > With or without '{' and '}' doesn't matter for me:) So, if the braces > > make it easier for parsing, we should then just adjust the syntax > > definition. > > Done already. :-) > > > I'd like to mention that we need to check that the called function > > belongs to an imported module, thus it should not be a built-in function > > or a UDF which is in-line with the query. > > I will have to think about how we can implement such a check most > elegantly within Pathfinder. I'm wondering about its usefulness, > though. I accept that we may want to restrict it to non-built-ins only. > But is the import via a module a sensible restriction? i I think it does make sense to filter out XRPC calls to in-query UDFs. If an in-query UDF is called with XRPC, the query just cannot be executed, since we don't want to ship the function implementation in XRPC request. So if such a query is not rejected by the compiler, it will eventually be rejected by the XRPC sender. > I could easily > create some module with some function definition and import it. Still, > the respective function would not be available at the XRPC target > machine. I think we cannot really check whether a target machine will > actually implement a given function > (and if it does so with the same argument types). > So we will have a garbage in, garbage out situation > always. Does it then make sense to do this very special check at all? Maybe we should put even more restriction on the imported module, such as we can require that the imported module should be available in a location which is accessible via the HTTP protocol. This way, we know it for sure that both the XRPC client and the server can access the module definition file (provided there is not further authentication restriction of accessing the file), and both the client and the server access the *same* module definition file, so the argument types should be the same (right?). Is it difficult to implement this restriction? Jennie > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > SQL0437W Performance of this complex query may be sub-optimal. > Reason code: "3". SQLSTATE=01602 > -- IBM DB2 V7.1 Warning Message

1 0

Re: [Monetdb-developers] XRPC syntax
by Jens Teubner 27 Oct '06

27 Oct '06

On Tue, Oct 24, 2006 at 03:40:16PM +0200, Ying Zhang wrote: > Our intention is to allow an XQuery expression here (after "at"), but it > should be evaluated to a URILiteral. How can I correct this rule to > express our intention? This is a typing thing, and I've already implemented that. Whatever the expression after "at" evaluates to, we try to cast it into a string. This is in line with how XQuery is defined elsewhere. You cannot express such a restriction in your grammar, though. This is a pure typing thing. > With or without '{' and '}' doesn't matter for me:) So, if the braces > make it easier for parsing, we should then just adjust the syntax > definition. Done already. :-) > I'd like to mention that we need to check that the called function > belongs to an imported module, thus it should not be a built-in function > or a UDF which is in-line with the query. I will have to think about how we can implement such a check most elegantly within Pathfinder. I'm wondering about its usefulness, though. I accept that we may want to restrict it to non-built-ins only. But is the import via a module a sensible restriction? I could easily create some module with some function definition and import it. Still, the respective function would not be available at the XRPC target machine. I think we cannot really check whether a target machine will actually implement a given function (and if it does so with the same argument types). So we will have a garbage in, garbage out situation always. Does it then make sense to do this very special check at all? Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 SQL0437W Performance of this complex query may be sub-optimal. Reason code: "3". SQLSTATE=01602 -- IBM DB2 V7.1 Warning Message

1 0

Re: [Monetdb-developers] XRPC syntax
by Ying Zhang 27 Oct '06

27 Oct '06

Hi Jens, First of all, thanks for your help! On Tue, Oct 24, 2006 at 02:55:21PM +0200, Jens Teubner wrote: > Hi Jennie, hi Peter, > > I am currently looking into the XRPC syntax. Primarily I wanted to give > you feedback to what you wrote in your Plan-X submission. > > So you are defining the syntax to be > > XRPCCall ::= "execute" "at" URILiteral FunctionCall > > Lateron, however, you allow more than just a literal URI, but rather an > XQuery expression. So `URILiteral' is definitely wrong here. Our intention is to allow an XQuery expression here (after "at"), but it should be evaluated to a URILiteral. How can I correct this rule to express our intention? > > Once you changed this to, say, ExprSingle, you end up with ambiguity in > your parser. Consider > > execute at "foo" eq ("bar") > > (I couldn't think of a better example ad hoc.) What we have here is an > ambiguity: we don't know whether `eq' is supposed to be a function call, > or if it is the binary operator `eq', followed by another expression in > parenthesis. > > So I will take the freedom to modify your syntax proposal and do it in a > more XQuery-like style: > > "execute" "at" "{" Expr "}" "{" FunctionCall "}" > > This avoids the ambiguity and should make it rather easy to parse. With or without '{' and '}' doesn't matter for me:) So, if the braces make it easier for parsing, we should then just adjust the syntax definition. I'd like to mention that we need to check that the called function belongs to an imported module, thus it should not be a built-in function or a UDF which is in-line with the query. Regards, Jennie > > ...already hacking... > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > Time is money. Especially if you make clocks.

1 0

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/runtime pathfinder.mx, 1.255, 1.256 pf_support.mx, 1.163, 1.164
by Jan Rittinger 27 Oct '06

27 Oct '06

Hi Peter, your checkin broke the implementation of fn:id() (see the testweb for the tests in benchmarks/XPath and benchmarks/XPathMark). Jan On 10/26/2006 02:12 PM, Peter Boncz wrote with possible deletions: > Update of /cvsroot/monetdb/pathfinder/runtime > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv8300/runtime > > Modified Files: > pathfinder.mx pf_support.mx > Log Message: > fast NID node retriveal by NID > - moved support for id/idref node retrieval into pathfinder.mx > having this as an API function will allow us to provide this functionality > using indices later (i.e. be able to lock and isolte a hash index). > it also helps a port of this functionality to algebra. > > for the moment, there are no shared hash tables, and ID/IDREF queries > on updatable XML documents will be slowish (sequential scans needed) > the new NID access is a good alternative to look up nodes. > > - implemented in ID node retrieval support for string sthat are numbers, > these are interpreted as NIDs, not ID attributes. > > - implemented a new fn:nid(element()*) as xs:string* builtin function > that returns the NIDs of element nodes. > > - fixed some constant support things (mposjoin) > > > [...] -- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/

1 0

Re: [Monetdb-developers] Monetdb-developers Digest, Vol 5, Issue 19
by p.a.boncz＠chello.nl 26 Oct '06

26 Oct '06

Yes, a string return type. Hey, it is an identifier ("node identifier"), that sounds more like a string than an integer anyway. And you then you can do id(nid($elt)), i.e. these functions are each others inverse. > > van: monetdb-developers-request(a)lists.sourceforge.net > datum: 2006/10/26 Thu PM 09:22:27 CEST > aan: monetdb-developers(a)lists.sourceforge.net > onderwerp: Monetdb-developers Digest, Vol 5, Issue 19 > > Send Monetdb-developers mailing list submissions to > monetdb-developers(a)lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/monetdb-developers > or, via email, send a message with subject or body 'help' to > monetdb-developers-request(a)lists.sourceforge.net > > You can reach the person managing the list at > monetdb-developers-owner(a)lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Monetdb-developers digest..." > > > Today's Topics: > > 1. Re: [Monetdb-pf-checkins] pathfinder/compiler/semantics > xquery_fo.c, 1.83, 1.84 (Jan Rittinger) > 2. Upcoming changes in the type system affect existing code! > (Jens Teubner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 26 Oct 2006 17:19:24 +0200 > From: Jan Rittinger <rittinge(a)in.tum.de> > Subject: Re: [Monetdb-developers] [Monetdb-pf-checkins] > pathfinder/compiler/semantics xquery_fo.c, 1.83, 1.84 > To: monetdb-developers(a)lists.sourceforge.net > Message-ID: <4540D1FC.5050604(a)in.tum.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Do you really mean string as return type of fn:nid? > > On 10/26/2006 02:12 PM, Peter Boncz wrote with possible deletions: > > Update of /cvsroot/monetdb/pathfinder/compiler/semantics > > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv8300/compiler/semantics > > > > Modified Files: > > xquery_fo.c > > Log Message: > > fast NID node retriveal by NID > > - moved support for id/idref node retrieval into pathfinder.mx > > having this as an API function will allow us to provide this functionality > > using indices later (i.e. be able to lock and isolte a hash index). > > it also helps a port of this functionality to algebra. > > > > for the moment, there are no shared hash tables, and ID/IDREF queries > > on updatable XML documents will be slowish (sequential scans needed) > > the new NID access is a good alternative to look up nodes. > > > > - implemented in ID node retrieval support for string sthat are numbers, > > these are interpreted as NIDs, not ID attributes. > > > > - implemented a new fn:nid(element()*) as xs:string* builtin function > > that returns the NIDs of element nodes. > > > > - fixed some constant support things (mposjoin) > > > > > > > > Index: xquery_fo.c > > =================================================================== > > RCS file: /cvsroot/monetdb/pathfinder/compiler/semantics/xquery_fo.c,v > > retrieving revision 1.83 > > retrieving revision 1.84 > > diff -u -d -r1.83 -r1.84 > > --- xquery_fo.c 19 Oct 2006 19:32:27 -0000 1.83 > > +++ xquery_fo.c 26 Oct 2006 12:12:40 -0000 1.84 > > @@ -184,6 +184,11 @@ > > .par_ty = (PFty_t[]) { PFty_opt (PFty_xs_string ()) }, > > .ret_ty = PFty_opt (PFty_doc (PFty_xs_anyNode ())) } }, > > .alg = PFbui_fn_doc } > > + , /* fn:idref (xs:element) as integer */ > > + { .ns = PFns_fn, .loc = "nid", > > + .arity = 1, .sig_count = 1, .sigs = { { > > + .par_ty = (PFty_t[]) { PFty_xs_anyElement () }, > > + .ret_ty = PFty_xs_string () } } } > > , /* fn:id (string*) as element* */ > > { .ns = PFns_fn, .loc = "id", > > .arity = 1, .sig_count = 1, .sigs = { { > > > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Monetdb-pf-checkins mailing list > > Monetdb-pf-checkins(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > > > > -- > Jan Rittinger > Database Systems > Technische Universit?t M?nchen (Germany) > http://www-db.in.tum.de/~rittinge/ > > > > ------------------------------ > > Message: 2 > Date: Thu, 26 Oct 2006 16:43:14 +0200 > From: Jens Teubner <jens.teubner(a)in.tum.de> > Subject: [Monetdb-developers] Upcoming changes in the type system > affect existing code! > To: monetdb-developers(a)lists.sourceforge.net > Message-ID: > <20061026144314.GD11690(a)notekemper14.informatik.tu-muenchen.de> > Content-Type: text/plain; charset=us-ascii > > Pathfinder folks, > > I am currently busy rewriting Pathfinder's type system. In the > short-term view, this rewrite will bring us a much cleaner and > more consistent representation of types, and I'm quite confident > that there will be less bugs in the new code; I have actually > found quite a few in the existing code while doing the rewrite. > > Most importantly, however, on a longer term view, my rewrites > pave the ground to implement also *dynamic* typing in Pathfinder > in an elegant and standards-compliant manner. > > The rewrite will also change the internal representation of types > in Pathfinder. Most of the current built-in primitive types will > become *named* types, in line with the XQuery specs. Most > importantly, this makes Pathfinder highly flexible and easily > extendible with respect to types. > > Unfortunately, there's a bunch of code flying around in the > project that inspects the (current) internal type representation > in a deprecated manner. My changes *will* break such code. This > mainly affects code that looks into the enum field PFty_t.type, a > field that is not (and has never been) supposed to be inspected > by code outside types.c and subtyping.c. milprint_summer.c in > particular is full of such references. ONCE I'M DONE WITH MY > REWRITES, SUCH CODE *WILL* BREAK. > > MY NEXT CHECKIN WILL TAG AFFECTED CODE IN MILPRINT_SUMMER.C WITH > #ifdef'S. WHOEVER FEELS RESPONSIBLE FOR THIS ABUSE OF THE > CURRENT TYPE REPRESENTATION OR WANTS TO RESCUE THE CODE IN > milprint_summer.c FROM DYING CAN USE THESE #ifdef'S TO FIND THE > APPROPRIATE PLACES AND FIX THE RESPECTIVE CODE. I WILL *NOT* FIX > THE AFFECTED CODE MYSELF. > > The "official" way to inspect Pathfinder's types is to use the > functions provided by types.c and subtyping.c. The subtype check > PFty_subtype() is the function that allows most of the checks > against types that one ever needs. Additional helpers can be > PFty_prime() (which normalizes a structured type to have the form > `t1 | t2 | t3 | ...') or PFty_quantifier() (determining the > quantifier, `0', `1', `?', `+', or `*', of a given type). > > The test whether a type t is the type `xs:string' may, e.g., > implemented by testing > > PFty_subtype (t, PFty_xs_string ()). > > (Some care has to be taken, though, that this is a *subtype* > relationship. Often, this is what you actually need. If you > want to test for type *equivalence*, use PFty_equality(), which > applies the subtype test in both directions.) > > Quantifiers are usually tested with a subtype test against a > regular expression over the `item' type. > > PFty_subtype (t, PFty_item ()), > > e.g., tests whether the quantifier of t is exactly one. > > You may want to look into other pieces of our code, e.g., > core2alg.brg, to see how PFty_subtype() and others can be used to > test types. Just watch out for invocations of PFty_subtype(). > > If you need any further assistance regarding types, just contact > me. > > Jens > > -- > Jens Teubner > Technische Universitaet Muenchen, Department of Informatics > D-85748 Garching, Germany > Tel: +49 89 289-17259 Fax: +49 89 289-17263 > > Unix is user friendly - it's just picky about it's friends. > > > > ------------------------------ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > ------------------------------ > > _______________________________________________ > Monetdb-developers mailing list > Monetdb-developers(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-developers > > > End of Monetdb-developers Digest, Vol 5, Issue 19 > ************************************************* >

1 0

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/semantics xquery_fo.c, 1.83, 1.84
by Jan Rittinger 26 Oct '06

26 Oct '06

Do you really mean string as return type of fn:nid? On 10/26/2006 02:12 PM, Peter Boncz wrote with possible deletions: > Update of /cvsroot/monetdb/pathfinder/compiler/semantics > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv8300/compiler/semantics > > Modified Files: > xquery_fo.c > Log Message: > fast NID node retriveal by NID > - moved support for id/idref node retrieval into pathfinder.mx > having this as an API function will allow us to provide this functionality > using indices later (i.e. be able to lock and isolte a hash index). > it also helps a port of this functionality to algebra. > > for the moment, there are no shared hash tables, and ID/IDREF queries > on updatable XML documents will be slowish (sequential scans needed) > the new NID access is a good alternative to look up nodes. > > - implemented in ID node retrieval support for string sthat are numbers, > these are interpreted as NIDs, not ID attributes. > > - implemented a new fn:nid(element()*) as xs:string* builtin function > that returns the NIDs of element nodes. > > - fixed some constant support things (mposjoin) > > > > Index: xquery_fo.c > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/semantics/xquery_fo.c,v > retrieving revision 1.83 > retrieving revision 1.84 > diff -u -d -r1.83 -r1.84 > --- xquery_fo.c 19 Oct 2006 19:32:27 -0000 1.83 > +++ xquery_fo.c 26 Oct 2006 12:12:40 -0000 1.84 > @@ -184,6 +184,11 @@ > .par_ty = (PFty_t[]) { PFty_opt (PFty_xs_string ()) }, > .ret_ty = PFty_opt (PFty_doc (PFty_xs_anyNode ())) } }, > .alg = PFbui_fn_doc } > + , /* fn:idref (xs:element) as integer */ > + { .ns = PFns_fn, .loc = "nid", > + .arity = 1, .sig_count = 1, .sigs = { { > + .par_ty = (PFty_t[]) { PFty_xs_anyElement () }, > + .ret_ty = PFty_xs_string () } } } > , /* fn:id (string*) as element* */ > { .ns = PFns_fn, .loc = "id", > .arity = 1, .sig_count = 1, .sigs = { { > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > -- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/

1 0

[Monetdb-developers] Upcoming changes in the type system affect existing code!
by Jens Teubner 26 Oct '06

26 Oct '06

Pathfinder folks, I am currently busy rewriting Pathfinder's type system. In the short-term view, this rewrite will bring us a much cleaner and more consistent representation of types, and I'm quite confident that there will be less bugs in the new code; I have actually found quite a few in the existing code while doing the rewrite. Most importantly, however, on a longer term view, my rewrites pave the ground to implement also *dynamic* typing in Pathfinder in an elegant and standards-compliant manner. The rewrite will also change the internal representation of types in Pathfinder. Most of the current built-in primitive types will become *named* types, in line with the XQuery specs. Most importantly, this makes Pathfinder highly flexible and easily extendible with respect to types. Unfortunately, there's a bunch of code flying around in the project that inspects the (current) internal type representation in a deprecated manner. My changes *will* break such code. This mainly affects code that looks into the enum field PFty_t.type, a field that is not (and has never been) supposed to be inspected by code outside types.c and subtyping.c. milprint_summer.c in particular is full of such references. ONCE I'M DONE WITH MY REWRITES, SUCH CODE *WILL* BREAK. MY NEXT CHECKIN WILL TAG AFFECTED CODE IN MILPRINT_SUMMER.C WITH #ifdef'S. WHOEVER FEELS RESPONSIBLE FOR THIS ABUSE OF THE CURRENT TYPE REPRESENTATION OR WANTS TO RESCUE THE CODE IN milprint_summer.c FROM DYING CAN USE THESE #ifdef'S TO FIND THE APPROPRIATE PLACES AND FIX THE RESPECTIVE CODE. I WILL *NOT* FIX THE AFFECTED CODE MYSELF. The "official" way to inspect Pathfinder's types is to use the functions provided by types.c and subtyping.c. The subtype check PFty_subtype() is the function that allows most of the checks against types that one ever needs. Additional helpers can be PFty_prime() (which normalizes a structured type to have the form `t1 | t2 | t3 | ...') or PFty_quantifier() (determining the quantifier, `0', `1', `?', `+', or `*', of a given type). The test whether a type t is the type `xs:string' may, e.g., implemented by testing PFty_subtype (t, PFty_xs_string ()). (Some care has to be taken, though, that this is a *subtype* relationship. Often, this is what you actually need. If you want to test for type *equivalence*, use PFty_equality(), which applies the subtype test in both directions.) Quantifiers are usually tested with a subtype test against a regular expression over the `item' type. PFty_subtype (t, PFty_item ()), e.g., tests whether the quantifier of t is exactly one. You may want to look into other pieces of our code, e.g., core2alg.brg, to see how PFty_subtype() and others can be used to test types. Just watch out for invocations of PFty_subtype(). If you need any further assistance regarding types, just contact me. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Unix is user friendly - it's just picky about it's friends.

1 0

[Monetdb-developers] mclient does not close its session.
by Romulo Goncalves 25 Oct '06

25 Oct '06

Dear developers, I start a mserver5, I load the sql module, and I start a sql client with sql.start() in the mserver prompt. In a new shell I start an mclient and I load a sql file to create a user and a schema within one transaction: mclient < create_user.sql After to run this command line the client never closes its session. I check the mserver system tables and the user and the schema were created. This is the file loaded in mclient: START TRANSACTION; CREATE USER "skyserver" WITH PASSWORD 'skyserver' NAME 'SkyServer' SCHEMA "sys";CREATE SCHEMA "skyserver" AUTHORIZATION "skyserver"; ALTER USER "skyserver" SET SCHEMA "skyserver"; COMMIT; Any idea? Regards, Romulo

2 1

[Monetdb-developers] [SQL] Header line change, support for warnings/info
by Fabian Groffen 24 Oct '06

24 Oct '06

I have a prepared a change for SQL's meta-data headers to use a different symbol than the widely accepted hash (#) used for comments in MonetDB. Instead, the percentage sign (%) is used to indicate a structured meta-data header. This change allows JDBC to be strict in its parsing, while it also supports comments/info/warnings over the protocol. Mapi has also been patched to support this. An additional advantage of this change is that meta-data no longer is considered a comment by Mtest; as such changes in this meta-data (which usually upset or change the behaviour of JDBC) are immediately visible, even though there is no JDBC test available. In the changes implemented one or multiple comment lines can follow after a regular Response, just before the prompt or next start of header. I changed the signatures of the functions that create the Responses such that they can take an extra string argument "w" (to comply with Niels' coding style) which represents a warning message. This string may contain newlines, in which case the string is properly send as multiple comment lines over the stream. Before I do this massive checkin (lots of mapproves in SQL) I prefer to get a go/no-go first. In case of a no-go, I will check in my changes on a branch.

2 2

Re: [Monetdb-developers] [Monetdb-checkins] buildtools/mel mel.mx, 1.11, 1.12
by Stefan Manegold 24 Oct '06

24 Oct '06

Niels, all our testing machines have flex 2.5.4, except the Gentoo machine (pegatoo) and the Debian machine (core-1); both use flex 2.5.33 (default on Gentoo, from /soft on Debian where 2.5.31 is default) --- and now fail to compile buildtools (mel) with " if g++ -DHAVE_CONFIG_H -I. -I/var/tmp/monet.GNU.32.32.d.14085/buildtools/mel -I. -g -MT mel.yy.o -MD -MP -MF ".deps/mel.yy.Tpo" -c -o mel.yy.o mel.yy.cc; \ then mv -f ".deps/mel.yy.Tpo" ".deps/mel.yy.Po"; else rm -f ".deps/mel.yy.Tpo"; exit 1; fi mel.ll:21: error: redefinition of ‘int yylineno’ lex.yy.c:346: error: ‘int yylineno’ previously defined here make[1]: *** [mel.yy.o] Error 1 " (cf. http://monetdb.cwi.nl/testing/projects/monetdb/Current/buildtools/.GNU.64.6… http://monetdb.cwi.nl/testing/projects/monetdb/Current/buildtools/.GNU.32.3… ) Did you check with flex 2.5.33 on some other machine? Which one? And in combination with which bison? I recall that there was a problem with an undefined yylineno when using flex 2.5.33 & bison 2.3 on openSUSE 10.2 *Alpha* (as reported by Riham), but was not able to reproduce it on our machines with flex 2.5.33 and bison 2.2 (gentoo) or bison 1.875d (debian). Stefan On Mon, Oct 23, 2006 at 07:16:26PM +0000, Niels Nes wrote: > Update of /cvsroot/monetdb/buildtools/mel > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv24999/mel > > Modified Files: > mel.mx > Log Message: > only flex 2.5.5 to 2.5.31 define yylineno (well we are I think only sure > about 2.5.31). <= 2.5.4 and >= 2.5.33 surely don't define yylineno. > > > > Index: mel.mx > =================================================================== > RCS file: /cvsroot/monetdb/buildtools/mel/mel.mx,v > retrieving revision 1.11 > retrieving revision 1.12 > diff -u -d -r1.11 -r1.12 > --- mel.mx 29 Aug 2006 10:38:43 -0000 1.11 > +++ mel.mx 23 Oct 2006 19:16:24 -0000 1.12 > @@ -506,7 +506,7 @@ > extern yystype yylval; > > #ifdef FLEX_SCANNER > -#if !defined(YY_FLEX_SUBMINOR_VERSION) || YY_FLEX_SUBMINOR_VERSION < 5 > +#if !defined(YY_FLEX_SUBMINOR_VERSION) || YY_FLEX_SUBMINOR_VERSION < 5 || YY_FLEX_SUBMINOR_VERSION > 31 > /* flex 2.5.31 declares yylineno. I don't know which other versions > do as well. */ > int yylineno; > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > 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 |

3 4

[Monetdb-developers] Signed/unsigned and NULL
by Fabian Groffen 24 Oct '06

24 Oct '06

I just figured that the following yields in a signed/unsigned warning: 1 void myfunc(char *s) { 2 if (s != NULL) { 3 ... 4 } 5 } The error occurs on line 2. I cannot find the definition of NULL, but I suspect it is defined like: #define NULL 0 Obviously 0 is signed while s (pointer) is not. Maybe we should use #define NULL (char*)0 instead?

3 4

Re: [Monetdb-developers] [Monetdb-sql-checkins] sql/src/common sql_types.mx, 1.72, 1.73
by Martin Kersten 22 Oct '06

22 Oct '06

first measurement Q13 drops to 3.98 sec (and 4.84 in second run) It was 2.17

1 0

[Monetdb-developers] sql_logdir -> logdir -> {sql,xquery}_logdir
by Fabian Groffen 21 Oct '06

21 Oct '06

Hi all, I probably missed something, but after the recent commits some questions popped up: - why sql_logdir -> logdir? - why was this solution not a good idea wich led to a revert and addition of xquery_logdir? Not that I don't agree, but I think it's good to know at least why/what is the problem.

3 2

Re: [Monetdb-developers] strings
by Martin Kersten 20 Oct '06

20 Oct '06

Martin, (et al) Thanks for your comments (Martin's repeated below). For the moment, I settled for a function that ensures no reading beyond the zero byte. The previous proposal did that. It still process two bytes per iteration, though: @- Hash Function The string hash function is a very simple hash function that xors and rotates all characters together. It is optimized to process 2 characters at a time (adding 16-bits to the hash value each iteration). @h #define GDK_STRHASH(x,y) { \ str _c = (str) (x); \ for((y)=0; _c[0] && _c[1]; _s+=2) { \ (y) = ((y) << 5) ^ ((y) >> 7) ^ ((_c[0] << 8) | _c[1]);\ } \ (y) ^= _c[0]; \ } Shared BAT heaps using views could be done. We could modify the view mechanism to allow a VIEW to have its own BUN heap, but still share a heap from a parent. This would allow still only a single parent, though. Touching the view code, however, is quite delicate matter. The suggestion for elimination of all doubles *always* I find not desirable. This policy is what caused crashes I had to go fix in the data center of ABN AMRO. Think of unique string keys -- even if we could dynamically tune the hash table size (we don't) as the BAT grows to avoid long collision lists, we would waste a lot of memory and gain nothing. The current adaptive approach is extremely robust against any distribution thrown at it: - on small bats, the overhead of the (mostly) useless hash table is limited (4KB) - on bats with a 'small' (L2 cachable) heap, the current "working" (=double-eliminating) hash table has just about the right size (256KB) such that things work nice when they can. Out-of-cache hash tables are never nice. - on bats with too many unique values we still profit from local correlations thanks to the repeated flushing. Such distributions would if fully double eliminated, need a (robust!) dynamic allocation scheme, plus a *lot* of memory to keep all the unique values. Not worth it. Thus we have a data structure that requires *no* a-priori distribution knowledge, introduces a limited maximal amount of storage overhead, and reduces storage maximally (given the low resource budget), in the best case achieving full double elimination that can be exploited with ELIMDOUBLES(h). I agree it could be cleaner to remove the hash table fully, and rely on explicit application-driven double elimination. But, as described, this mechanism never hurts us (much), and I guess that for many many use cases, of which we are not even aware now, it actually is delivering us a lot of gain, just because it is pervasively applied. I do not fully grasp your suggestion for hash functions that are distribution-dependent; especially how they would work incrementally, when values are added to a BAT over time. In that case, the distribution would change continually, and thus the hash function.. Peter -----Original Message----- From: Martin Kersten [mailto:Martin.Kersten@cwi.nl] Sent: Friday, October 20, 2006 5:15 PM To: Peter Boncz Cc: Niels Nes; Martin Kersten; Stefan Manegold; Sjoerd Mullender Subject: strings Peter, Niels and I were discussing the snippet shown in the attachment two days ago. The snippet is interesting for several reasons. The most important one is that the cost of this string join comes from inserting 800K strings, *not* the str hash join itself. (observed with callgrind) Amongst others, it triggered (again) the wish to have more control at the BAT level to deal with strings values. For example, it would be nice to know that *all* doubles are eliminated (not only per chunk). In combination with a fast 'uniqueCount' it could make some operations a lot faster. Alternatively, it would be nice if you could refer into the heap of another BAT, e.g. by marking a column as 'shared heap' and re-using the BATview scheme in the target to protect it. (In the 19.sql case, we actually should have dropped the string in the semijoin operation. Calling for either a new gdk operation or a better optimization step.) Wat betreft je voorstel. Ik zou zoeken in de volgende richting. De hash wordt in belangrijke mate bepaald door de statistische kans dat je hetzelfde patroon tegenkomt. Tevens weten we dat in de praktijk het gebruik van characters (en character combinaties) zipfian gedistribueerd is. Dit kan je gebruiken door in de header of de string heap een encoding tabel op te nemen die ervoor zorgt dat nieuwe encoding meer/minder effect heeft op de hash functie. Voorbeeld laat alle veel voorkomende characters weg en neem altijd N minder voorkomende characters. Of gebruik alternatieve bit patronen die de hash Deze codering zou je zelfs als apparte optimalizatie stap op de BAT kunnen loslaten. De default is gebaseerd op een eenvoudige tekst analyse. Verder kan de hash table (nu 1K best wat groter)

1 0

[Monetdb-developers] Compiling buildtools..
by Romulo Goncalves 20 Oct '06

20 Oct '06

Dear developers, I tried three times more and now everything works. It is strange such error. I continue to interest in reason for such error. Best Regards, Romulo Goncalves

2 2

[Monetdb-developers] Compiling buildtools.
by Romulo Goncalves 20 Oct '06

20 Oct '06

I update my buildtools,bootstraap, configure, make and I got this error: /ufs/goncalve/scratch/MonetDB/buildtools/build/_MX/Mx -x C /ufs/goncalve/MonetDB/buildtools/mel/object.mx /ufs/goncalve/MonetDB/buildtools/mel/object.mx: ./object.cc - created if g++ -DHAVE_CONFIG_H -I. -I/ufs/goncalve/MonetDB/buildtools/mel -I. -g -MT object.o -MD -MP -MF ".deps/object.Tpo" -c -o object.o object.cc; \ then mv -f ".deps/object.Tpo" ".deps/object.Po"; else rm -f ".deps/object.Tpo"; exit 1; fi g++: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See <URL:http://bugzilla.redhat.com/bugzilla> for instructions. make[2]: *** [object.o] Error 1 make[2]: Leaving directory `/net/amelia/export/scratch1/goncalve/MonetDB/buildtools/build/_MEL' make[1]: *** [all] Error 2 make[1]: Leaving directory `/net/amelia/export/scratch1/goncalve/MonetDB/buildtools/build/_MEL' make: *** [all] Error 2 [goncalve@amelia scripts]$ Any idea? Regards, Romulo

2 1

[Monetdb-developers] Planning the next MonetDB release
by Stefan Manegold 15 Oct '06

15 Oct '06

Dear all, with the recent deadlines passed and the next(?) one (SIGMOD) five weeks ahead, it might be a good time to assess the current status of developments around MonetDB to make more concrete plans for the next release. I guess, we all agree that the next release should be *the* MonetDB/XQuery Update release, i.e., providing an implementation of the W3C XQuery Update Facility (http://www.w3.org/TR/xqupdate/) for MonetDB/XQuery. Hence, the major focus is obviously on finishing this implementation. See details below under "XQuery Updates". Concerning MQX/PF, there are three more subjects/areas where we need to see to which extend they should be officially announced with the release (and hence, need to be "finished" before the release): - algebra path (TUM: JanR, Jens) - recursions (TUM: JanR, Jens) - XRpc (CWI: Jennie, Peter) Further, the 64-bit Windows port of MQX (i.e., pathfinder) is still open. Concerning MonetDB in general, we need to see to which extend we want/need to improve the compilation process before the release: - clean-up configure scripts - clean-up usage of *-config.h include files - "meta scripts" to simplify the cvs checkout/update and build process Additionally, Niels & Fabian probably also have a todo list for MonetDB/SQL. Finally, all parts require some thorough testing --- especially all newly added features, in particular the XQuery update & transaction features and the new multi-document support --- simply using it (like with the recently added (multi-doc) benchmark tests) is a good start... Also, there are 50(!) open bug reports, and for many (most?) bugs that have been filed or closed since 01.01.2006, no test script has been provided, yet, to monitor their status. Lots of work to do... As said, this is to trigger an assessment of the current state and a planning for the release, hence, please feel free to comment and add your points. I suggest to discuss this in (or after) "MADAM" tomorrow and in the PF skype conference on Tuesday. Stefan XQuery Updates ============== As far as I'm aware, the major missing features are transaction support, mainly logging & recovery. Undoubtedly, this is a CWI task. Apart from that, we need to finish/extend the implementation of document management within MonetDB/XQuery --- both in MIL & XQuery. My vision is that we provide comparable (if not equal) functionality in both MIL & XQuery, providing functions beyond the XQuery standard where necessary. The envisaged functionally should cover the following: - access a single document by name (or URI) XQ!: fn:doc($uri as xs:string?) as document-node()? Done. - access all documents in a collection XQ!: fn:collection($arg as xs:string?) as node()* ToDo! - shred a single document into a new "singleton" collection: MIL: shred_doc(str URI [,str doc-name [,str col-name]] [,lng freeSlotsPerPage]) : void (defaults: doc-name = URI, col-name = doc-name?doc-name:URI, freeSlotsPerPage = 0 (i.e., read-only)) Done. XQ!: fn:doc($uri as xs:string?) as document-node()? (implies doc-name = URI, col-name = URI, freeSlotsPerPage = 0 (i.e., read-only)) Done. - shred a set of documents into a single new collection: MIL: shred_doc(BAT[void,str] URI [,BAT[void,str] doc-name [,str col-name]] [,lng freeSlotsPerPage]) : void (defaults: doc-name = URI, col-name = doc-name?first-doc-name:first-URI, freeSlotsPerPage = 0 (i.e., read-only)) ToDo! XQ!: loop-lifted fn:doc($uri as xs:string?) as document-node()? (implies doc-name = URI, col-name = URI, freeSlotsPerPage = 0 (i.e., read-only)) Done. XQ?: fn:doc($uri as xs:string*) as document-node()? (implies doc-name = URI, col-name = first-URI, freeSlotsPerPage = 0 (i.e., read-only)) ToDo? - shred a set of documents into a set of new collections: MIL: shred_doc(BAT[void,str] URI [,BAT[void,str] doc-name [,BAT[void,str] col-name]] [,BAT[void,lng] freeSlotsPerPage]) : void (defaults: doc-name = URI, col-name = doc-name?doc-name:URI, freeSlotsPerPage = 0 (i.e., read-only)) (constraint: freeSlotsPerPage must be identical for all documents within a collection) Done. XQ?: loop-lifted fn:doc($uri as xs:string*) as document-node()? (implies doc-name = URI, col-name = first-URI, freeSlotsPerPage = 0 (i.e., read-only)) ToDo? - shred a single document and add it to an existing collection: MIL: add_doc(str URI, str col-name [,str doc-name] [,lng freeSlotsPerPage]) : void (defaults: doc-name = URI, freeSlotsPerPage = 0 (i.e., read-only)) ToDo! XQ?: fn:add_doc($uri as xs:string, $coll as xs:string) as document-node()? (implies doc-name = URI, freeSlotsPerPage = 0 (i.e., read-only)) ToDo! - shred a set of documents and add it to a single existing collection: MIL: add_doc(BAT[void,str] URI, str col-name [,BAT[void,str] doc-name] [,lng freeSlotsPerPage]) : void (defaults: doc-name = URI, freeSlotsPerPage = 0 (i.e., read-only)) ToDo! XQ?: loop-lifted fn:add_doc($uri as xs:string, $coll as xs:string) as document-node()? (implies doc-name = URI, freeSlotsPerPage = 0 (i.e., read-only)) ToDo! XQ?: fn:add_doc($uri as xs:string*, $coll as xs:string) as document-node()? (implies doc-name = first-URI, freeSlotsPerPage = 0 (i.e., read-only)) ToDo! - shred a set of documents and add it to a set of existing collections: MIL: add_doc(BAT[void,str] URI, BAT[void,str] col-name [,BAT[void,str] doc-name] [,BAT[void,lng] freeSlotsPerPage]) : void (defaults: doc-name = URI, freeSlotsPerPage = 0 (i.e., read-only)) (constraint: freeSlotsPerPage must be identical for all documents within a collection) ToDo! XQ?: fn:add_doc($uri as xs:string*, $coll as xs:string*) as document-node()? (implies doc-name = URI, freeSlotsPerPage = 0 (i.e., read-only)) ToDo! - delete a single document by name (and the whole collection, if this was the last document in that collection) MIL: delete_doc(str doc-name) : void Done. XQ?: fn:del_doc($uri as xs:string) as ??? ToDo! - dito for a set of documents? - delete a collection MIL: delete_col(str col-name) : void ToDo! XQ?: fn:del_col($col as xs:string) as ??? ToDo! - dito for a set of collections? - delete all cached/persistent documents MIL: delete_all_docs(bit cachedOnly) : void Done. XQ?: fn:del_all_docs($cachedOnly as xs:boolean) as ??? ToDo! - view all explicitly shredded and/or cached documents and collections (at least their names, maybe more info) in the database/cache, a la "xmlcache_print()" & "xmldb_print()" - view/list all documents (names) in a collection - manage cache rules Anything more? -- | 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

[Monetdb-developers] shredding loop-lifted fn:doc() into one collection
by Stefan Manegold 15 Oct '06

15 Oct '06

Peter, our fix of Friday night to shred all documents of a loop-lifted fn:doc() call into one single collection (as opposed to creating one collection per document) --- not checked in, yet; see attached "pathfinder.mx.LLdoc.PATCH." for details --- seems to work fine (at least correct; speed/performance needs to be analyzed in detail) for file-URLs, i.e., documents that get indeed cached persistently). However, for non-file URLs (i.e., document that do get cached and hence stay trnasient), it did/does not work, basically as the docuemnts are shredded into the "transient" collection, and are (hence?) not assigned unique document IDs --- the document do not end up in the doc_* BATs. A HACK(?) to use the (unified) temporary document-/collection-ID for all documents (see attached "pathfinder.mx.LLdoc.FIX.") seems to work --- however, I have no idea, whether this is what was indended... More "live" on Monday. 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 0

[Monetdb-developers] Problems with SQL module...
by Romulo Goncalves 12 Oct '06

12 Oct '06

Dear all, I founded some problems in SQL module. Maybe they are not problems just a misunderstood. To see the problems in your computer just start a mserver5, load sql module, and sql.start(); Then start a mclient -lsql. First Problem: Execute this two queries in the mclient: CREATE FUNCTION zero(id int) RETURNS int BEGIN IF id > 0 THEN RETURN 1; ELSE RETURN 0; END IF; END; CREATE FUNCTION TEST() RETURNS BOOLEAN BEGIN DECLARE x int; SET x = zero(1); IF x > 0 THEN RETURN TRUE; ELSE RETURN FALSE; END IF; END; UNTIL now you should not find any problems. Lets see the first problem: In the mclient execute: SELECT test(); I got this error: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1098918240 (LWP 14589)] 0x00002aaaaaaba2c1 in idcmp (n=0x2aaab485227b "destroy", m=0x0) at /ufs/goncalve/MonetDB/MonetDB5/monet5/src/mal/mal_type.mx:251 251 if (* n == * m) (gdb) up #1 0x00002aaab483ab94 in isUpdated (mb=0xf59548, pc=9) at /ufs/goncalve/MonetDB/MonetDB5/monet5/src/optimizer/opt_support.mx:885 885 if (idcmp("destroy", getFunctionId(q)) = = 0) (gdb) up #2 0x00002aaab483f287 in OPTcommonTermsImplementation (mb=0xf59548, stk=0x0, pci=0x0) at /ufs/goncalve/MonetDB/MonetDB5/monet5/src/optimizer/opt_commonTerms.mx:17 6 176 if (hasSameSignature(p, q) && (gdb) up #3 0x00002aaab483f718 in OPTcommonTerms (mb=0xf59548, stk=0x0, p=0x0) at /ufs/goncalve/MonetDB/MonetDB5/monet5/src/optimizer/opt_commonTerms.mx:24 9 Line number 249 out of range; /ufs/goncalve/MonetDB/MonetDB5/monet5/src/optimize r/opt_commonTerms.mx has 220 lines. (gdb) up #4 0x00002aaab4efb73a in addQueryToCache (c=0x503a10) at /ufs/goncalve/MonetDB/SQL/sql/src/backends/monet5/sql_optimizer.mx:434 434 OPTcommonTerms(mb,0,0); /* common terms */ (gdb) up #5 0x00002aaab4efa84e in backend_create_func (be=0x10e1218, f=0x10e80b8) at /ufs/goncalve/MonetDB/SQL/sql/src/backends/monet5/sql_gencode.mx:1938 1938 addQueryToCache(c); If you want all the details, run your mserver with gdb (I know that you know the procedures for debugging). ;) Second problem: If I restart the mclient and restart the mserver: The mclient can see the functions in the table sys.functions, but the client started in the server by sql.start() does see the functions created. Third problem: Just execute the following query: select * from functions where name like 'hash'; Why they are so many rows with the same information for the function hash? Fourth problem: Just create the following function: CREATE FUNCTION niels(id_val int) RETURNS TABLE (id int) BEGIN DECLARE TABLE roro(id int); RETURN TABLE (SELECT id from functions where id = id_val order by id); END; I will try to correct this bugs, but until there I will appreciate some help. This problems are delaying the translation of Skyserver functions and also the my implementation of Dependency Control table. Best Regards, Romulo Goncalves

3 2

[Monetdb-developers] re-organizing PF/MXQ tests
by Stefan Manegold 12 Oct '06

12 Oct '06

Dear all, before adding another ~80 tests (all 4 flavors of the XBench benchmark suite) to the current pathfinder test set of 1384 tests, I'd like to propose a re-organization/re-structuring of the pathfinder test set. With all tests enabled, testing takes almost 30 minutes --- with an optimized 64-bit binary with 32-bit OIDs on my Athlon64 X2 3800+ (2GHz) with 2GB RAM. A quick analysis clusters the tests in 5 categories: 1) compiler ("pf" only) tests 2) tests for features provided by the MXQ runtime 3) tests for additional/optional modules (PFtijah) 4) tests derived from bug reports, use cases, etc. 5) benchmark tests Currently, the respective tests reside in the follwoing directory trees: 1) compiler// 2) runtime// 3) modules// 4) tests// 5) tests// This allows to conveniently run each category individually (e.g., `Mtest -r compiler/`), except from the "tests/" tree, which contains two categories: 4 & 5. I propose to replace 5) tests// by 5) benchmarks// i.e., add "benchmarks/" and move all benchmark tests from tests// to benchmarks//, basically: mv tests/{MBench,X007,XBench,XMach-1,XMark,XPath,XPathMark} benchmarks/ Additionally, I'd suggest to also move the tests/XRpc/xmark_queries to benchmarks/XMark/XRpc Open question: should we then also move tests/Music to benchmarks/Music ? Votes? Well, as you might imagine, I'v everything ready here for checkin ;-) Hence, unless there are complains or different suggestions by Saturday (Oct 14 2006) morning, I'll apply above changes during the weekend. Kind regards, 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 0

[Monetdb-developers] [Monetdb-sql-checkins] Problems with SQL installation.
by Stefan Manegold 10 Oct '06

10 Oct '06

Romulo, this should have been either filed as a bug report or sent to Monetdb-developers(a)lists.sourceforge.net. On Tue, Oct 10, 2006 at 05:19:32PM +0200, Romulo Goncalves wrote: > Dear SQL developers, > > I checked out the buildtools and I installed it. > > > I checked out MonetDB4 v4.13.1 and I install with this configure: > configure --prefix=/ufs/goncalve/scratch/MonetDB/monetdb4 --enable-debug > --enable-bits=64 At this point: is /ufs/goncalve/scratch/MonetDB/monetdb4/bin in your PATH? > I checked out MonetDB5 version v4.99.19 and I installed it with the > following configure: > configure --prefix=/ufs/goncalve/scratch/MonetDB/monetdb5 --enable-debug > --enable-bits=64 > > > Then I checked out SQL module and I installed it with the following > configure: At this point: is /ufs/goncalve/scratch/MonetDB/monetdb5/bin in your PATH? > configure --prefix=/ufs/goncalve/scratch/MonetDB/monetdb5/ > --enable-debug --enable-bits=64 > > > For all the installations the directories were removed and the > bootstraap was executed. > > The error that I got in the installation of SQL is: > > ve/scratch/MonetDB/monetdb4/lib/libstream.so -lpthread -m64 -Wl,-soname > -Wl,lib _sql.so.0 -o .libs/lib_sql.so.0.0.0 > /usr/bin/ld: cannot find -loptimizer > collect2: ld returned 1 exit status > make[7]: *** [lib_sql.la] Error 1 > make[7]: Leaving directory > `/net/amelia/export/scratch1/goncalve/SQL/sql/build/s rc/backends/monet5' > > > This problem started after the following update: > > [Monetdb-sql-checkins] sql/src/backends/monet5 Makefile.ag, 1.30, 1.31 > > Update of /cvsroot/monetdb/sql/src/backends/monet5 > In directory > sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv6378/src/backends/monet5 > > Modified Files: > Makefile.ag > Log Message: > Added some libraries that are used by the module. did you re-compiler Monet5 & SQL from scratch (bootstrap; configure; make; make install) after this update? > Could you tell me where I am wrong? > > Best regards, > Romulo Goncalves 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 |

3 4

[Monetdb-developers] Linking against a library
by Wouter Scherphof 09 Oct '06

09 Oct '06

Hi, My first module (called "geom"), created from "template", compiles (on Windows XP with the "native tools") and the hello() function works. Now I want to use some functions of a certain library (the GEOS<http://geos.refractions.net>C API). I'm fairly new to C, so probably I'm doing something obvious wrong. What I have is a header file "geos_c.h<http://geos.refractions.net/ro/doxygen_docs/html/geos__c_8h-source.html>" and a DLL "geos_c_fw.dll" (I chose to use a prebuilt DLL for now, since I didn't manage to build the GEOS library as well :-(.) I put those in the NT directory. In my geom.mx, I added: *#include* <geos_c.h>* **int* testGeos( ){* * initGEOS(*NULL*,*NULL*);* * finishGEOS();* ** return* GDK_SUCCEED;* *} Now, when I run "nmake NEED_MX=1", I get: (...) cl -GF -W3 -wd4273 -wd4102 -MD -nologo -Zi -Ox -I. -I.\.. "-IC:\Pthreads\include" -I.\..\..\src "-IC:\monetdb\MonetDB\NT\include" "-IC:\monetd b\MonetDB\NT\include\common" "-IC:\monetdb\MonetDB\NT\include\gdk" "-IC:\monetdb\MonetDB\NT\include\monet" "-IC:\monetdb\MonetDB\NT\include\plain" "-I C:\monetdb\MonetDB\NT\include\mapi" -DNDEBUG -DLIBGEOM -DCOMPILE_DL_GEOM -Fo"geom.obj" -c "geom.c" geom.c cl -GF -W3 -wd4273 -wd4102 -MD -nologo -Zi -Ox -I. -I.\.. "-IC:\Pthreads\include" -I.\..\..\src "-IC:\monetdb\MonetDB\NT\include" "-IC:\monetd b\MonetDB\NT\include\common" "-IC:\monetdb\MonetDB\NT\include\gdk" "-IC:\monetdb\MonetDB\NT\include\monet" "-IC:\monetdb\MonetDB\NT\include\plain" "-I C:\monetdb\MonetDB\NT\include\mapi" -DNDEBUG -LD -Felib_geom.dll geom.glue.obj geom.obj /link "/LIBPATH:C:\monetdb\MonetDB\NT\lib" "/LIBPATH:C:\monet db\MonetDB\NT\lib\MonetDB" libbat.lib libmonet.lib Creating library lib_geom.lib and object lib_geom.exp geom.obj : error LNK2019: unresolved external symbol _finishGEOS referenced in function _testGeos geom.obj : error LNK2019: unresolved external symbol _initGEOS referenced in function _testGeos lib_geom.dll : fatal error LNK1120: 2 unresolved externals So the compilation of geom.c succeeds, but the linking of lib_geom.dll fails. Apperently, the geos_c_fw.dll is not found. I tried putting it in one of the /LIBPATH, but that doesn't help. How can I make this work? Best regards, Wouter Scherphof. Utrecht Professional School, The Netherlands.

2 1

[Monetdb-developers] Crash leaves me unable to start mserver
by Joseph.Baird＠cox.com 09 Oct '06

09 Oct '06

After loading several million records via odbc, the server is suddenly unresponsive but can be restarted. When using jdbc, the server crashes, again after several million records, but cannot be restarted. Performance and usability are impressive with a million records or so but I cannot seem to load more than that without consistent problems. Is there any way to make the server - and ideally the database - usable again? Thank you in advance, Joe Baird

2 1

Re: [Monetdb-developers] Monetdb-developers Digest, Vol 5, Issue 6
by p.a.boncz 06 Oct '06

06 Oct '06

Hi all, > In PROC rpc_client() (runtime/xrpc.mx), I had changed > ws_addcoll(ws, ... > to > ws_opencoll(ws_id(ws), ... it should we ws_opencoll(wsid, ...) You have that, because in the query context we always have both variable 'ws' and 'wsid'. ws_id(ws) should be called once, it asks for a unique oid. The combination of (id,int(ws)) is squeezed into a lng, and that is wsid. As for doc_tbl(), what would work is to change its parameter to wsid; one can always get the ws with ws := ws_bat(wsid), this is done now in numerous places in pf_support.mx. Your conclusions (1), (2) and (3) are all correct. But, Jan's suggestion to store the wsid inside the ws can also work. However, I deem it very awkward to introduce a new BAT in the ws just to retain a number. Other suggestions are to rename the ws-bat to some unique key, and then we can use that name as transaction key (=wsid). We would change the wsid type then from lng to str. Another idea is to set the head-seqbase of the ws-bat to an oid. I think the ws is accessed with fetch() only, which disregards any seqbase. Note that internally in pathfinder.mx there are a number of functions that just pass around an artificial wsid, and in fact a ws does not exist at all (this is the MIL document management interface e.g. shred_doc), so a number of (internal) functions in pathfinder.mx will have to stay using a wsid in their signature. They do not need a ws-bat. But the exported functions ws_opencoll and ws_opendoc could indeed just use a ws as they did before. I will not have time for this until next week, so if anyone feels like adventurous, he may try. Peter -- | 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 | ------------------------------ Message: 2 Date: Fri, 6 Oct 2006 12:43:21 +0200 From: Stefan Manegold <Stefan.Manegold(a)cwi.nl> Subject: Re: [Monetdb-developers] The new "ws-API", Algebra & XRpc (& PFtijah) To: Monetdb-developers(a)lists.sourceforge.net Message-ID: <20061006104321.GA2821(a)corona.ins.cwi.nl> Content-Type: text/plain; charset=us-ascii On Thu, Oct 05, 2006 at 11:03:09AM +0200, Stefan Manegold wrote: > Dear Peter, dear fellow PF & MXQ developers, [...] > In cases of XRpc & Algebra, there are still places were wsid := ws_id(ws) is > IMHO called in the wrong location: > > XRpc: > In PROC rpc_client() (runtime/xrpc.mx), I had changed > ws_addcoll(ws, ... > to > ws_opencoll(ws_id(ws), ... > While this seems to worg for now with read-only documents (i.e., in the > absense of updates and concurrency), it is IMHO incorrect in general. > Rather, rpc_client should receive wsid as argument instead of ws; > if necessary, ws can then be derived via ws := ws_bat(wsid). I just changed the signatures of doLoopLiftedRPC() & rpc_client() to receive lng wsid instead of BAT ws, BAT ws is the locally derived via ws := ws_bat(wsid); All XRpc tests seem to work fine. 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 | ------------------------------ Message: 3 Date: Fri, 06 Oct 2006 14:39:19 +0200 From: Jan Rittinger <rittinge(a)in.tum.de> Subject: Re: [Monetdb-developers] The new "ws-API", Algebra & XRpc (& PFtijah) To: Monetdb-developers(a)lists.sourceforge.net Message-ID: <45264E77.3060201(a)in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed If this wsid is a concept that is strictly necessary for the update support (and nobody except me thinks that this bit shifting might be not the nicest solution) we could also think about getting rid of the ws and replacing it with the wsid. I just do not like the fact that there are two variables underway that have some side effects on each other. So a fourth proposal (d) would be to replace the occurrences of ws by wsid. This would mean that *all* document accesses would have to include another indirection (even all path steps). On 10/05/2006 11:03 AM, Stefan Manegold wrote with possible deletions: > Dear Peter, dear fellow PF & MXQ developers, > > I'm not sure, whether I do understand the new "ws-API" correctly, and would > be grateful if someone of you could enlighten me. > > First, here's how far I get so far (please correct me if/where I'm wrong!), > followed by concrete open questions. > > For transaction support, Peter introduced a new wsid that uniquely > identifies (a reference to?) a ws, which is required for conflict detection > (as far as I understand). > > A wsid is to be generated from/for a ws by calling wsid := ws_id(ws); > however, this generated a new unique id each time is called (two calls on > the same ws yield two different ids, right?), hence, wsid := ws_id(ws) > should immediately follow ws := ws_create() . > > For the inverse, there is ws := ws_bat(wsid) that return the ws identified > by wsid; obviously, this function yield the same result each time it's > called with the same wsid. > > Since some functionality required to to the wsid instead of "only" the ws, > Peter had changes the signatures/API of some runtime PROCs. As far as I see > right now, these are mainly (only?) > ws_doc(ws, ... -> ws_opendoc(wsid, ... > ws_addcoll(ws, ... -> ws_opencoll(wsid, ... > ws_destroy(int(ws)) -> ws_destroy(wsid) > > I finished these changes by simply running the folloing one-liners: > > find * -type f | xargs grep -l 'var ws := ws_create();' | xargs perl -i -p -e 's|(var ws := ws_create;)|$1 var wsid := ws_id(ws);|' > find * -type f | xargs grep -l 'ws_doc(ws,' | xargs perl -i -p -e 's|ws_doc$ws,|ws_opendoc(wsid,|' > find * -type f | xargs grep -l 'ws_destroy(int(ws))' | xargs perl -i -p -e 's|ws_destroy\(int\(ws$\)|ws_destroy(wsid)|' > find * -type f | xargs grep -l 'ws_addcoll(ws,' | xargs perl -i -p -e 's|ws_addcoll\(ws,|ws_opencoll(wsid,|' > find * -type f | xargs grep -l 'ws_addcoll' | xargs perl -i -p -e 's|ws_addcoll|ws_opencoll|' > > > While this seemed to have been enough to fix all .milS tests and (most of) > the milprint_summer functionallity, there are two open issues left: > the Algebra version, XRpc & PFtijah. > > To be honest, I haven't looked at PFtijah, yet; some help by the respective > experst would be appreciated. > > > In cases of XRpc & Algebra, there are still places were wsid := ws_id(ws) is > IMHO called in the wrong location: > > XRpc: > In PROC rpc_client() (runtime/xrpc.mx), I had changed > ws_addcoll(ws, ... > to > ws_opencoll(ws_id(ws), ... > While this seems to worg for now with read-only documents (i.e., in the > absense of updates and concurrency), it is IMHO incorrect in general. > Rather, rpc_client should receive wsid as argument instead of ws; > if necessary, ws can then be derived via ws := ws_bat(wsid). > > Algebra: > in PROC doc_tbl() (runtime/pf_support.mx), I had changed > var r := ws_doc(ws, item); > into > var wsid := ws_id(ws); > var r := ws_opendoc(wsid, item); > Same story as above. > However, doc_tbl return ws also in its result BAT-of-BATs, as far as I > understand mainly for "canonical API" reasons. > Obviously, it is not possible to replace BAT ws by lng wsid, here... > > > Leaving the latter problem aside for the moment, the following could (have) > work(ed) as a general rule, and we should check and change the codebase > accordingly: > > 1) wsid := ws_id(ws) must only be called immediately after ws := ws_create() > > 2) all functions/PROCs that recursively (i.e., including all transitively > called functions/PROCs) require wsid instead of or inaddition to ws should > be modified in that the receive wsid instead of ws as an argument; > ws can then locally be derived via ws := ws_bat(wsid) if/where necessary. > > 3) all functions/PROCs that recursively (i.e., including all transitively > called functions/PROCs) "never" (at least not yet) require wsid, but are > fine with ws can stay unchanged, i.e., getting (only) ws as argument. > Obviously, wherever these functions need to maintain a signature/API > aligned with those that fall under point 2) above, we should also change > these functions as described above with 2). > > > As indicated above, this does not work for doc_tbl and its companion PROCs > in runtime/pf_support.mx that make-up the interface between the Algebra > version of the compiler and the runtime. > I assume the respective canonical API could be changed in that the > respective PROC get wsid instead of (or in addition to?) ws as arguments. > However, we cannot easily change the API to return wsid (lng) instead of ws > (BAT) in the result BAT-of-BATs. Here, I see three solutions --- the last > one actually comes from JanR: > > a) Is ws/wsid indeed required in the result? > If not, we could simply discard it. > > b) Wrap wsid temprarly into a ("fake") [void,lng] BAT containing only one > (nil,wsid) BUN. > (Ugly!) > > c) (JanR) Put the wsid inside ws --- basically as a ("fake") BAT [void,lng]. > Kind of the "encapsulated" solution --- not only for the algebra-runtime > interface! > Consequently, we should have ws_create() call ws_id(ws) internally and > stored the result in ws (this could save the seemingly "redundant" > ws := ws_create(); wsid := ws_id(ws); sequence), and all (most, except at > least ws_destroy()) signatures/API could be kept / re-unified to pass > (only) ws (now including wsid) instead of wsid as argument. > > There seems to be one problem, so, if I understand Peter's comment > correctly: > " > - ws-IDs are now lng-s (combination of *unique* ID and bat-ID) such IDs > are meaningful also after the query is done (and ws-bat deallocated). > ^1^1^1^1^1^1^1^1^1^1^1^1^1^1 ^2^2^2^2^2^2^2^2^2^2^2 > this is needed for trans mgmt. > All meta-bats witha ws-id field now hold lng instead of int. > " > > In other words, (^2) wsid needs to be available also if ws is gone. > I'm not sure, though, whether is has to be available in the global wsid > variable (i.e., inside/during the query), or (only) in some meta-bats > outside (and hence after) the query (-context) (as suggested by ^1). > > > Peter, > > could you please enlighten me/us, here? > > > In case "only" (^1) is required, the "encapsulated" solution seems indeed > to be suitable for all code. > Otherwise, is would at least be a local solution for the algebra-runtime > interface (in case (a) & (b0 are no option), but bears the burden of > maintaining consistency between the global wsid variable and the wsid stored > inside the ws. > > > I hope, this email and any reactions to it help to clearify the current > situation, rather than to blur it even more ... > > Stefan > > -- Jan Rittinger Database Systems Technische Universit?t M?nchen (Germany) http://www-db.in.tum.de/~rittinge/ ------------------------------ Message: 4 Date: Fri, 6 Oct 2006 15:08:00 +0200 From: Stefan Manegold <Stefan.Manegold(a)cwi.nl> Subject: Re: [Monetdb-developers] The new "ws-API", Algebra & XRpc (& PFtijah) To: Jan Rittinger <rittinge(a)in.tum.de> Cc: Monetdb-developers(a)lists.sourceforge.net Message-ID: <20061006130800.GB5598(a)corona.ins.cwi.nl> Content-Type: text/plain; charset=us-ascii On Fri, Oct 06, 2006 at 02:39:19PM +0200, Jan Rittinger wrote: > If this wsid is a concept that is strictly necessary for the update > support (and nobody except me thinks that this bit shifting might be not > the nicest solution) we could also think about getting rid of the ws and > replacing it with the wsid. I just do not like the fact that there are > two variables underway that have some side effects on each other. To be honest, I'm still in the process of analyzing trying to understand, what all the flavors, pros, cons, and ideas behind having/using wsid are; hence, I cannot tell, whether it is "strictly necessary" or not. As far as I understand so far, the basic idea behind the "bit shifting" is merely to store both the id of (and hence reference to) BAT ws as well as a unique identifier --- that is still valid after a query/transaction (and hence cannot simply be the ws BAT id, which might be re-used for a subsequent query/transaction) --- in one single atomic value. Further, I agree, that having two related variables that need to be kept in sync and treated accordingly is not very handy for maintenance --- my guess is, that the current situation resulted from lack of time and fear to implement (something like) your (d) proposal; which I agree is "nicer" & "cleaner", but requires quite a lot of possibly error-prone code changes --- nevertheless, I might give it a try during the weekend ... Stefan > So a fourth proposal (d) would be to replace the occurrences of ws by > wsid. This would mean that *all* document accesses would have to include > another indirection (even all path steps). -- | 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 | ------------------------------ Message: 5 Date: Fri, 6 Oct 2006 15:42:02 +0200 From: Stefan Manegold <Stefan.Manegold(a)cwi.nl> Subject: Re: [Monetdb-developers] The new "ws-API", Algebra & XRpc (& PFtijah) To: Monetdb-developers(a)lists.sourceforge.net Cc: Jan Rittinger <rittinge(a)in.tum.de> Message-ID: <20061006134202.GA6958(a)corona.ins.cwi.nl> Content-Type: text/plain; charset=us-ascii On Fri, Oct 06, 2006 at 03:08:00PM +0200, Stefan Manegold wrote: > On Fri, Oct 06, 2006 at 02:39:19PM +0200, Jan Rittinger wrote: > > If this wsid is a concept that is strictly necessary for the update > > support (and nobody except me thinks that this bit shifting might be not > > the nicest solution) we could also think about getting rid of the ws and > > replacing it with the wsid. I just do not like the fact that there are > > two variables underway that have some side effects on each other. > > To be honest, I'm still in the process of analyzing trying to understand, > what all the flavors, pros, cons, and ideas behind having/using wsid are; > hence, I cannot tell, whether it is "strictly necessary" or not. > > As far as I understand so far, the basic idea behind the "bit shifting" is > merely to store both the id of (and hence reference to) BAT ws as well as a > unique identifier --- that is still valid after a query/transaction (and hence > cannot simply be the ws BAT id, which might be re-used for a subsequent > query/transaction) --- in one single atomic value. > > Further, I agree, that having two related variables that need to be kept in > sync and treated accordingly is not very handy for maintenance --- my guess > is, that the current situation resulted from lack of time and fear to > implement (something like) your (d) proposal; which I agree is "nicer" & > "cleaner", but requires quite a lot of possibly error-prone code changes --- > nevertheless, I might give it a try during the weekend ... > > Stefan > > > So a fourth proposal (d) would be to replace the occurrences of ws by > > wsid. This would mean that *all* document accesses would have to include > > another indirection (even all path steps). Well, I just realize that this actually only helps to save us from having function interfaces that expect/use either ws or wsid or both --- it does not help to get rid of the global ws variable: to exist throught the whole query, the ws BAT must either be a global variable or be persistent --- the latter is not possible, since ws is a BAT-of-BATs, and those cannot be persistent... ... I just recall, that we have something like "session" BATs --- I'll check whether that's an option (any help/hint is of course welcome ...) 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 | ------------------------------ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ------------------------------ _______________________________________________ Monetdb-developers mailing list Monetdb-developers(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers End of Monetdb-developers Digest, Vol 5, Issue 6 ************************************************

2 3

[Monetdb-developers] The new "ws-API", Algebra & XRpc (& PFtijah)
by Stefan Manegold 06 Oct '06

06 Oct '06

Dear Peter, dear fellow PF & MXQ developers, I'm not sure, whether I do understand the new "ws-API" correctly, and would be grateful if someone of you could enlighten me. First, here's how far I get so far (please correct me if/where I'm wrong!), followed by concrete open questions. For transaction support, Peter introduced a new wsid that uniquely identifies (a reference to?) a ws, which is required for conflict detection (as far as I understand). A wsid is to be generated from/for a ws by calling wsid := ws_id(ws); however, this generated a new unique id each time is called (two calls on the same ws yield two different ids, right?), hence, wsid := ws_id(ws) should immediately follow ws := ws_create() . For the inverse, there is ws := ws_bat(wsid) that return the ws identified by wsid; obviously, this function yield the same result each time it's called with the same wsid. Since some functionality required to to the wsid instead of "only" the ws, Peter had changes the signatures/API of some runtime PROCs. As far as I see right now, these are mainly (only?) ws_doc(ws, ... -> ws_opendoc(wsid, ... ws_addcoll(ws, ... -> ws_opencoll(wsid, ... ws_destroy(int(ws)) -> ws_destroy(wsid) I finished these changes by simply running the folloing one-liners: find * -type f | xargs grep -l 'var ws := ws_create();' | xargs perl -i -p -e 's|(var ws := ws_create;)|$1 var wsid := ws_id(ws);|' find * -type f | xargs grep -l 'ws_doc(ws,' | xargs perl -i -p -e 's|ws_doc$ws,|ws_opendoc(wsid,|' find * -type f | xargs grep -l 'ws_destroy(int(ws))' | xargs perl -i -p -e 's|ws_destroy\(int\(ws$\)|ws_destroy(wsid)|' find * -type f | xargs grep -l 'ws_addcoll(ws,' | xargs perl -i -p -e 's|ws_addcoll\(ws,|ws_opencoll(wsid,|' find * -type f | xargs grep -l 'ws_addcoll' | xargs perl -i -p -e 's|ws_addcoll|ws_opencoll|' While this seemed to have been enough to fix all .milS tests and (most of) the milprint_summer functionallity, there are two open issues left: the Algebra version, XRpc & PFtijah. To be honest, I haven't looked at PFtijah, yet; some help by the respective experst would be appreciated. In cases of XRpc & Algebra, there are still places were wsid := ws_id(ws) is IMHO called in the wrong location: XRpc: In PROC rpc_client() (runtime/xrpc.mx), I had changed ws_addcoll(ws, ... to ws_opencoll(ws_id(ws), ... While this seems to worg for now with read-only documents (i.e., in the absense of updates and concurrency), it is IMHO incorrect in general. Rather, rpc_client should receive wsid as argument instead of ws; if necessary, ws can then be derived via ws := ws_bat(wsid). Algebra: in PROC doc_tbl() (runtime/pf_support.mx), I had changed var r := ws_doc(ws, item); into var wsid := ws_id(ws); var r := ws_opendoc(wsid, item); Same story as above. However, doc_tbl return ws also in its result BAT-of-BATs, as far as I understand mainly for "canonical API" reasons. Obviously, it is not possible to replace BAT ws by lng wsid, here... Leaving the latter problem aside for the moment, the following could (have) work(ed) as a general rule, and we should check and change the codebase accordingly: 1) wsid := ws_id(ws) must only be called immediately after ws := ws_create() 2) all functions/PROCs that recursively (i.e., including all transitively called functions/PROCs) require wsid instead of or inaddition to ws should be modified in that the receive wsid instead of ws as an argument; ws can then locally be derived via ws := ws_bat(wsid) if/where necessary. 3) all functions/PROCs that recursively (i.e., including all transitively called functions/PROCs) "never" (at least not yet) require wsid, but are fine with ws can stay unchanged, i.e., getting (only) ws as argument. Obviously, wherever these functions need to maintain a signature/API aligned with those that fall under point 2) above, we should also change these functions as described above with 2). As indicated above, this does not work for doc_tbl and its companion PROCs in runtime/pf_support.mx that make-up the interface between the Algebra version of the compiler and the runtime. I assume the respective canonical API could be changed in that the respective PROC get wsid instead of (or in addition to?) ws as arguments. However, we cannot easily change the API to return wsid (lng) instead of ws (BAT) in the result BAT-of-BATs. Here, I see three solutions --- the last one actually comes from JanR: a) Is ws/wsid indeed required in the result? If not, we could simply discard it. b) Wrap wsid temprarly into a ("fake") [void,lng] BAT containing only one (nil,wsid) BUN. (Ugly!) c) (JanR) Put the wsid inside ws --- basically as a ("fake") BAT [void,lng]. Kind of the "encapsulated" solution --- not only for the algebra-runtime interface! Consequently, we should have ws_create() call ws_id(ws) internally and stored the result in ws (this could save the seemingly "redundant" ws := ws_create(); wsid := ws_id(ws); sequence), and all (most, except at least ws_destroy()) signatures/API could be kept / re-unified to pass (only) ws (now including wsid) instead of wsid as argument. There seems to be one problem, so, if I understand Peter's comment correctly: " - ws-IDs are now lng-s (combination of *unique* ID and bat-ID) such IDs are meaningful also after the query is done (and ws-bat deallocated). ^1^1^1^1^1^1^1^1^1^1^1^1^1^1 ^2^2^2^2^2^2^2^2^2^2^2 this is needed for trans mgmt. All meta-bats witha ws-id field now hold lng instead of int. " In other words, (^2) wsid needs to be available also if ws is gone. I'm not sure, though, whether is has to be available in the global wsid variable (i.e., inside/during the query), or (only) in some meta-bats outside (and hence after) the query (-context) (as suggested by ^1). Peter, could you please enlighten me/us, here? In case "only" (^1) is required, the "encapsulated" solution seems indeed to be suitable for all code. Otherwise, is would at least be a local solution for the algebra-runtime interface (in case (a) & (b0 are no option), but bears the burden of maintaining consistency between the global wsid variable and the wsid stored inside the ws. I hope, this email and any reactions to it help to clearify the current situation, rather than to blur it even more ... 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 4

[Monetdb-developers] bolts damaged
by server RTz 04 Oct '06

04 Oct '06

attack applies contact area ordinary wrenches Kroc. HSW Fact Day: paintball markers Foresters Boards Blogs Segments SNAP High Candy Spiked same Guarana fuels amazing BAWLS drink Brown customers saying... Copyright Rights Reserved Statement Company Music.com Reviews Videos support. Resources Getting v. Edition. In earlier releases used similar OS v. Edition. In earlier releases used similar date: Copyright Rights Reserved Statement Company Music.com Reviews Videos InNew User Connect S.com Market Forums Boards Blogs Segments SNAP Next Gaming PRO SAP Oracle Music Palm BREW Cross iMode Windows UIQ Knowledge Known Issues FAQs Tips eUpdate archive Platforms Military Physical drives. gigs Ionut Ambrosie winners meet Monitor home Travel Consumer Products Bawls Mints High Candy

1 0

[Monetdb-developers] Error compiling MEL w/ flex 2.5.33 & bison 2.3
by Stefan Manegold 03 Oct '06

03 Oct '06

On Mon, Oct 02, 2006 at 12:47:39PM +0200, Niels Nes wrote: > On Mon, Oct 02, 2006 at 12:32:22PM +0200, Riham wrote: > > Hi, > > > > I am a new PhD student at the University of Twente. I am working with > > Dr. Maurice van Keulen on Optimizing Pathfinder queries. I was > > installing Monet on my new linux system and I got the following error: > > > > =========================================================================== > > kader@netloosewi840:~/home/MonetDB_XQuery_CVS/build/buildtools> make > > cd > > ""/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/../../src/buildtools"/autogen" > > && python setup.py build > > running build > > running build_py > > running build_scripts > > cd _MX && make MAKE=make all > > make[1]: Entering directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MX' > > make all-am > > make[2]: Entering directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MX' > > make[2]: Nothing to be done for `all-am'. > > make[2]: Leaving directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MX' > > make[1]: Leaving directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MX' > > cd _MEL && make MAKE=make all > > make[1]: Entering directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL' > > make all-am > > make[2]: Entering directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL' > > g++ -g -o mel any_arg.o atom_arg.o atom.o atomops.o bat_arg.o > > builtin.o command.o debug.o depend.o dependency.o epilogue.o FileInfo.o > > glue.o html.o iterator.o link.o ListIterator.o mel.o mel.tab.o mel.yy.o > > mil.o module.o object.o operator.o ops.o prelude.o proto.o symbol.o > > symtable.o type_arg.o use.o var_arg.o > > mel.tab.o: In function `semerror()': > > /local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.yy:471: > > undefined reference to `yylineno' > > /local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.yy:472: > > undefined reference to `yylineno' > > mel.tab.o: In function `yyparse()': > > /local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.yy:59: > > undefined reference to `yylineno' > > /local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.yy:67: > > undefined reference to `yylineno' > > /local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.yy:131: > > undefined reference to `yylineno' > > mel.yy.o:/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL/mel.ll:253: > > more undefined references to `yylineno' follow > > collect2: ld returned 1 exit status > > make[2]: *** [mel] Error 1 > > make[2]: Leaving directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL' > > make[1]: *** [all] Error 2 > > make[1]: Leaving directory > > `/local/kader/home/MonetDB_XQuery_CVS/build/buildtools/_MEL' > > make: *** [all] Error 2 > > =========================================================================== > > > > The flex and bison versions I have are 2.5.33 and 2.3 respectively. > > I was advised by Jan Flokstra to report the error to you. I hope you > > have sufficient information to know the origin of the problem, if not > > please let me know. > > > > Thank you for your help, > > Riham Abdel Kader. > > As of flex 2.5.31 the yylineno was defined by flex. Normaly we define > it our selfs. > > You could try to patch the following line from mel.mx > > #if !defined(YY_FLEX_SUBMINOR_VERSION) || YY_FLEX_SUBMINOR_VERSION < 5 > /* flex 2.5.31 declares yylineno. I don't know which other versions > do as well. */ > int yylineno; > #endif > > Simply removed the #if/#endif should work. A better solution is to know > which range between 2.5.6 and 2.5.31/32 have a yylineno defined. And > fix the second part of the #ifdef. > > Niels Niels, Riham, I haven't analysed the problem any further, yet, but I think it might also be related to bison 2.3 or the combination of bison 2.3 and flex 2.5.33. In out nightly testing pool (cf., http://monetdb.cwi.nl/Development/TestWeb/) we use flex 2.5.4 & flex 2.5.33 and bison 1.875, 2.0, 2.1, 2.2, and everything works fine. We don't use bison 2.3, yet ... Riham, which linux distribution (name & version) are you using? Does Niels' patch work for you? 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 |

4 11

Re: [Monetdb-developers] Monetdb-developers Digest, Vol 4, Issue 13
by p.a.boncz 26 Sep '06

26 Sep '06

Hi Jens, I read your recursion proposal, but I do not really understand the need or goal for such a syntax extension: - is't the default XQuery function recursion more powerful? - why not confine oneself to have an *internal* algebraic closure operator, if that is such a useful abstraction? Nor do I understand the need for the focus on nodes and set fixpoint semantics. If the result expression is a sequence of nodes you may define this to be duplicate-free and in document order, but it is less obvious why atomic sequences should be treated like that. Order is a first-class citizen in XQuery, and atomic types are also first-class. And what about element construction? Isn't it obvious given the recursive nature of XML that people may want to build XML documents with recursion -- so the choice to union all results always is limiting. I can imagine that *some* XQuery recursion patterns could be translated to this fixpoint operator. Tail recursion is the big "success story" here (given your node-union fixpoint semantics it will actually only be possible in rare cases). However, given the fact that XQuery has for-loops, it is quite unlikely in the first place that in the real world people will use tail-recursion for iteration (this may distinguish XQuery from "purer" functional languages). I conclude that this extension per-se does not help in translating recursion in XQuery for the algebra backend at all (nor is it its goal), rather places a second recursive vehicle beside it. I am completely puzzled to hear such proposals from the usually XQuery-standard-respecting community in Garching. Finally, what exactly is "hacky" about the milprint_summer recursion approach? Maybe you mean with "hacky" that it does not try to eliminate recursion, and thus only works if the target language offers recursion. The reality is that only trivial recursion patterns can be eliminated, so this limitation will apply always. And you may forget, that a lot of recursion in milprint_summer *is* eliminated, as all calls inside a for-loop are reduced to one thanks to "loop-lifting" (maybe we could even "sell" this idea in the FP community). So actually it surely is not as primitive/hacky as the implementation of recursion in say Galax. Defining myself as an engineer, I am aware of the limitations of my knowledge and understanding of such formal issues. ready to be educated.. Peter -----Original Message----- From: monetdb-developers-bounces(a)lists.sourceforge.net [mailto:monetdb-developers-bounces@lists.sourceforge.net] On Behalf Of monetdb-developers-request(a)lists.sourceforge.net Sent: Saturday, September 23, 2006 12:14 AM To: monetdb-developers(a)lists.sourceforge.net Subject: Monetdb-developers Digest, Vol 4, Issue 13 Send Monetdb-developers mailing list submissions to monetdb-developers(a)lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/monetdb-developers or, via email, send a message with subject or body 'help' to monetdb-developers-request(a)lists.sourceforge.net You can reach the person managing the list at monetdb-developers-owner(a)lists.sourceforge.net When replying, please edit your Subject line so it is more specific than "Re: Contents of Monetdb-developers digest..." Today's Topics: 1. Upcoming feature: Recursion in Pathfinder (algebra) (Jens Teubner) 2. configure & *_config.h include files (Stefan Manegold) 3. Re: configure & *_config.h include files (Stefan Manegold) 4. Error with the Java Client (Jim Foley) 5. Re: Error with the Java Client (Fabian Groffen) ---------------------------------------------------------------------- Message: 1 Date: Fri, 22 Sep 2006 14:11:03 +0200 From: Jens Teubner <jens.teubner(a)in.tum.de> Subject: [Monetdb-developers] Upcoming feature: Recursion in Pathfinder (algebra) To: monetdb-developers(a)lists.sourceforge.net Cc: Loredana Afanasiev <lafanasi(a)science.uva.nl> Message-ID: <20060922121103.GF11762(a)notekemper14.informatik.tu-muenchen.de> Content-Type: text/plain; charset=us-ascii Hi all, this is to keep you informed what we are currently working on in Munich. Pathfinder's purely relational approach so far cannot handle *recursion* in XQuery expression in a sensible way (recursion in the W3C XQuery language is possible by means of user-defined recursive function). The milprint_summer branch includes some hacky implementation (with help of MIL PROCs) that provides recursion nevertheless. Together with people from UVA (Loredana Afanasiev in particular), we are currently working on support for recursion in an algebraic manner. A generic handling of recursion seems quite difficult. The W3C XQuery language syntax does not pose any restrictions on the style of recursion that can be described. The common approaches to deal with recursion in relational systems, in contrast, cannot cope with all these variants of recursion. A second problem is that the kind of recursion used in a given query (e.g., tail recursion) used in a given query seems quite tricky to infer (and a consistent treatment of this case in the algebraic compiler adds another challenge). Hence, we decided to go for a limited recursion feature in Pathfinder first. We may later on try to add a more generic handling. We are currently implementing a *syntax extension* to Pathfinder that allows to describe a limited notion of recursion. The new construct with $var seeded by expr1 recurse expr2 will have the following semantics: 1. expr1 is evaluated once and then used as a seed to initiate the recursion. $var is bound to the result of expr1 in the first recursion step. 2. Then, expr2 is evaluated over and over. Variable $var is visible in expr2 and for each recursion step will be bound to the union of all items (nodes) obtained in the previous recursion steps. (The results of all recursion steps are collected into the overall result using set semantics.) 3. Recursion terminates if a recursion step does not contribute any new items (nodes) to the overall result (i.e., we reached a fixpoint). (Remark: There still is some discussion if (for performance reasons) each recursion step should only observe the *new* items obtained in the previous recursion step, or whether the entire result set collected so far should be observable in expr2.) The `union' semantics of this new recursion construct implies that we can do recursion only on *nodes*, not on atomic values. This quite directly matches the requirements of the UVA group (and others) that are looking for a "transitive closure" operator. Note that the above syntax extension that we are about to introduce does not interfere with any existing constructs. So our changes will not affect any (existing) valid XQuery expression. Motivation: There is a high demand for transitive closure functionality in the group at UVA (i.e., Loredana and others), but also in other research groups (as I was told). Transitive closure is, e.g., a vital component of an XPath dialect known as "Regular XPath". Regards from Garching Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Software is like sex: It's better when it's free -- Linus B. Torvalds

3 4

[Monetdb-developers] Compilation warnings MonetDB/SQL
by Fabian Groffen 25 Sep '06

25 Sep '06

For what it is worth, here is a list of warnings produced when compiling MonetDB/SQL. MonetDB itself appears to be mostly warning free. Making and installing MonetDB/SQL in /ufs/fabian/scratch/vtmp/build-current-monetdb-pegasus.ins.cwi.nl/sql /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx: In function 'table_delete': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx:223: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx: In function 'table_check': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_table.mx:266: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'schema_get_table': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:1177: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_kc': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4069: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_key': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4084: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_ic': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4113: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_idx': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4128: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_tc': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4151: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_trigger': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4165: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_column': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4187: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_table': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4240: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sys_drop_func': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4264: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4265: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sql_trans_drop_schema': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4413: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sql_trans_alter_null': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4717: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx: In function 'sql_trans_alter_default': /ufs/fabian/scratch/monetdb/current/sql/src/storage/bat/bat_store.mx:4741: warning: comparison between signed and unsigned sql_parser.y:404.8-12: warning: symbol CHECK redeclared sql_parser.y:408.16-23: warning: symbol DISTINCT redeclared sql_parser.y:410.41-46: warning: symbol HAVING redeclared conflicts: 21 shift/reduce, 44 reduce/reduce sql_parser.y:404.8-12: warning: symbol CHECK redeclared sql_parser.y:408.16-23: warning: symbol DISTINCT redeclared sql_parser.y:410.41-46: warning: symbol HAVING redeclared conflicts: 21 shift/reduce, 44 reduce/reduce /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_select.mx: In function 'sql_binop': /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_select.mx:924: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_scan.mx: In function 'scanner_string': /ufs/fabian/scratch/monetdb/current/sql/src/server/sql_scan.mx:562: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/server/rel_select.mx: In function 'rel_binop': /ufs/fabian/scratch/monetdb/current/sql/src/server/rel_select.mx:2878: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'mvc_dump_1': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:252: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'mvc_dump_2': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:269: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'dump_1': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:286: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'dump_2': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:303: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'dump_3': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:322: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx: In function 'backend_dumpstmt_': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:371: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:377: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:392: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:407: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:417: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:427: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:821: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:834: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:850: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:856: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:873: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:876: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:924: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:946: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:966: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:972: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:975: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1032: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1042: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1081: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1149: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1151: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1153: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1155: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1157: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1160: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1260: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1283: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1301: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1303: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1351: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_gencode.mx:1416: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_result.mx: In function 'convert2str': /ufs/fabian/scratch/monetdb/current/sql/src/backends/monet4/sql_result.mx:564: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/ODBCConvert.c: In function 'ODBCFetch': /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/ODBCConvert.c:1133: warning: signed and unsigned type in conditional expression /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/ODBCConvert.c:1418: warning: signed and unsigned type in conditional expression /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/SQLConnect.c: In function 'SQLConnect_': /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/SQLConnect.c:93: warning: comparison between signed and unsigned /ufs/fabian/scratch/monetdb/current/sql/src/odbc/driver/SQLConnect.c:111: warning: comparison between signed and unsigned

2 2

Re: [Monetdb-developers] Error with the Java Client
by Jim Foley 24 Sep '06

24 Sep '06

> Date: Sat, 23 Sep 2006 09:56:44 +0200 > From: Fabian Groffen <Fabian.Groffen(a)cwi.nl> > Subject: Re: [Monetdb-developers] Error with the Java Client > To: monetdb-developers(a)lists.sourceforge.net > Message-ID: <20060923075643.GB21350(a)cwi.nl> > Content-Type: text/plain; charset=utf8 > > On 22-09-2006 23:44:20 -0400, Jim Foley wrote: > > Fabian, > > > > I can accept that my transaction is invalid and there is no way to > > tell what the state of tables/object is but I cannot except that a > > fatal java exception is what is expected. I would expect a > java error > > stating that the state of the database is unknown and > please roll back > > the last transaction. > > > > Am I expecting too much from open software? > > No, I just never tried doing this. I just fixed this in CVS, thanks. Thank you, Fabian. I will download the new code and try it out. Hopefully once I get to know the code better I will be able to help you out with some of these problem. Jim

1 0

Re: [Monetdb-developers] Error with the Java Client
by Jim Foley 23 Sep '06

23 Sep '06

Fabian, I can accept that my transaction is invalid and there is no way to tell what the state of tables/object is but I cannot except that a fatal java exception is what is expected. I would expect a java error stating that the state of the database is unknown and please roll back the last transaction. Am I expecting too much from open software? Jim > Message: 5 > Date: Fri, 22 Sep 2006 16:57:03 +0200 > From: Fabian Groffen <Fabian.Groffen(a)cwi.nl> > Subject: Re: [Monetdb-developers] Error with the Java Client > > Hi Jim, > > On 22-09-2006 10:47:13 -0400, Jim Foley wrote: > > voc-> start transaction; > > Operation successful > > > > auto commit mode: off > > voc-> select * from tables; > > Error: SELECT: no such table 'tables' > > Your transaction died here ... > > > voc-> > > voc-> create table test > > voc=> (id int, jimnum decimal(38,2)); > > Error: current transaction is aborted (please ROLLBACK) > > ... hence the error message you need to rollback > > > voc-> \d > > A fatal exception occurred: java.sql.SQLException: current > transaction > > is aborted (please ROLLBACK) > > This might be a bit hefty, but in fact is expected behaviour, > since your transaction has been invalidated, so it is unknown > what tables/objects there should be at this moment. > > > > ------------------------------ >

2 1

[Monetdb-developers] Error with the Java Client
by Jim Foley 22 Sep '06

22 Sep '06

I am doing some testing with MonetDB and the java client. I have a repeatable error that I am not sure if it is a but or the way I am using the tool. I have an Oracle background so it could be me. Java client connection on Windows 2000 Professional to MonetDB on openSuSe 10.1 using SQL. Thanks for your help. Jim Foley C:\MonetDB Client>java -jar jdbcclient-1.4.jar -h 192.168.1.101 -d demo -u voc password: Welcome to the MonetDB interactive JDBC terminal! Database: MonetDB 4.13.1 Driver: MonetDB Native Driver 1.4 (Dilate 20060918) Type \q to quit, \h for a list of available commands auto commit mode: on voc-> \d voc-> start transaction; Operation successful auto commit mode: off voc-> select * from tables; Error: SELECT: no such table 'tables' voc-> voc-> create table test voc=> (id int, jimnum decimal(38,2)); Error: current transaction is aborted (please ROLLBACK) voc-> \d A fatal exception occurred: java.sql.SQLException: current transaction is aborted (please ROLLBACK) java.sql.SQLException: current transaction is aborted (please ROLLBACK) at nl.cwi.monetdb.jdbc.MonetConnection$ResponseList.executeQuery(MonetConne ction.java:2292) at nl.cwi.monetdb.jdbc.MonetConnection$ResponseList.processQuery(MonetConne ction.java:2045) at nl.cwi.monetdb.jdbc.MonetStatement.internalExecute(MonetStatement.java:3 57) at nl.cwi.monetdb.jdbc.MonetStatement.execute(MonetStatement.java:326) at nl.cwi.monetdb.jdbc.MonetStatement.executeQuery(MonetStatement.java:390) at nl.cwi.monetdb.client.JdbcClient.processInteractive(JdbcClient.java:646) at nl.cwi.monetdb.client.JdbcClient.main(JdbcClient.java:476) C:\MonetDB Client>

2 1

[Monetdb-developers] Upcoming feature: Recursion in Pathfinder (algebra)
by Jens Teubner 22 Sep '06

22 Sep '06

Hi all, this is to keep you informed what we are currently working on in Munich. Pathfinder's purely relational approach so far cannot handle *recursion* in XQuery expression in a sensible way (recursion in the W3C XQuery language is possible by means of user-defined recursive function). The milprint_summer branch includes some hacky implementation (with help of MIL PROCs) that provides recursion nevertheless. Together with people from UVA (Loredana Afanasiev in particular), we are currently working on support for recursion in an algebraic manner. A generic handling of recursion seems quite difficult. The W3C XQuery language syntax does not pose any restrictions on the style of recursion that can be described. The common approaches to deal with recursion in relational systems, in contrast, cannot cope with all these variants of recursion. A second problem is that the kind of recursion used in a given query (e.g., tail recursion) used in a given query seems quite tricky to infer (and a consistent treatment of this case in the algebraic compiler adds another challenge). Hence, we decided to go for a limited recursion feature in Pathfinder first. We may later on try to add a more generic handling. We are currently implementing a *syntax extension* to Pathfinder that allows to describe a limited notion of recursion. The new construct with $var seeded by expr1 recurse expr2 will have the following semantics: 1. expr1 is evaluated once and then used as a seed to initiate the recursion. $var is bound to the result of expr1 in the first recursion step. 2. Then, expr2 is evaluated over and over. Variable $var is visible in expr2 and for each recursion step will be bound to the union of all items (nodes) obtained in the previous recursion steps. (The results of all recursion steps are collected into the overall result using set semantics.) 3. Recursion terminates if a recursion step does not contribute any new items (nodes) to the overall result (i.e., we reached a fixpoint). (Remark: There still is some discussion if (for performance reasons) each recursion step should only observe the *new* items obtained in the previous recursion step, or whether the entire result set collected so far should be observable in expr2.) The `union' semantics of this new recursion construct implies that we can do recursion only on *nodes*, not on atomic values. This quite directly matches the requirements of the UVA group (and others) that are looking for a "transitive closure" operator. Note that the above syntax extension that we are about to introduce does not interfere with any existing constructs. So our changes will not affect any (existing) valid XQuery expression. Motivation: There is a high demand for transitive closure functionality in the group at UVA (i.e., Loredana and others), but also in other research groups (as I was told). Transitive closure is, e.g., a vital component of an XPath dialect known as "Regular XPath". Regards from Garching Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Software is like sex: It's better when it's free -- Linus B. Torvalds

1 0

[Monetdb-developers] MT_sleep_ns()?
by Jens Teubner 21 Sep '06

21 Sep '06

Hi all, in shredder.mx there is a call to MT_sleep_ns(). This came with the "new_update" merger. I cannot find, however, any definition of this function. The only thing I can find is MT_sleep_ms() in gdk_posix.mx. Is this a typo? If so, could anybody fix this? This seems to break compilation on Cygwin (at least as reported by our student). Regards Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 This email was written with 100% recycled electrons.

2 1

[Monetdb-developers] PF: back-merging the "new_updates" branch into the HEAD
by Stefan Manegold 20 Sep '06

20 Sep '06

Dear Pathfinder developers, you might have noticed, that Peter checked in the initial "raw" version of his new revised extended XML/XQuery update implementation into a "new_updates" branch of the pathfinder repository last Monday (Sep 11 2006). Since then, we spent a week on consolidating the code with respect to compilation and testing --- at least on our major development platform Fedora Core 4. We had decided to use a branch, first, so that the consolidation phase would not interfere with other development going on on the development trunk (HEAD). With most of the issues solved, we're now down to only 26 out of 1282 tests failing; see http://monetdb.cwi.nl/testing/projects/monetdb/new_updates.35/ for details. We consider this stable "enough" to merge the "new_updates" branch back into the development trunk (HEAD) A.S.A.P., i.e., preferably tomorrow, in order to (1) avoid further double-lane development and the resulting synchronization overhead/problems, (2) put the new code under the surveillance of automatic *multi-platform* testing, and (3) give more of us the opportunity to test the new code both as such and in combination with their own extensions. In particular, the following parts need to be tested (more) intensively - algebra version: the test-web XMark tests work fine, more hasn't been tested, yet - StandOff: known to fail, code requires adaption to comply with (new) update schema - Tijah: not tested at all, mainly because no tests are available in CVS, yet - the new document management features: hardly (if at all) tested, yet, tests need to be added Unless there are any severe objections by 2 pm (CEST) tomorrow (Tue, Sep 19 2006), we will perform the back-merge. Thank you very much for your cooperation. Kind regards, 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 3

Re: [Monetdb-developers] Monetdb-developers Digest, Vol 4, Issue 7
by Jim Foley 18 Sep '06

18 Sep '06

>------------------------------ > >Message: 2 >Date: Sat, 16 Sep 2006 08:37:24 +0200 >From: Fabian Groffen <Fabian.Groffen(a)cwi.nl> >Subject: Re: [Monetdb-developers] Compiled ok under openSUSE 10.1 (32 bit) but some errors in the tests > >Hi Jim, > >Thanks for your interest in MonetDB/SQL. > >On 15-09-2006 19:09:10 -0400, Jim Foley wrote: >> I freed up a linux server and got MonetDB 4.12.0 and the SQL client to >> compile and run under openSUSE 10.1 with a AMD 3800 64 bit processor. >> It seems to work fine but I am getting some errors on the test for >> both the DB and the SQL client. I understand from the archives that >> some errors are normal. Is there a list of errors on each platform? I >> can just copy off the test results before I compile it with as a 64 >> bit app and compare the results but I would prefer to clean up the >> errors if I can under the 32 bit app before I try it under 64 bits. I >> have a DBA background and I could just be being anal. ;-) >If you want to be sure, post the names of the tests failing. We don't have a list of failing tests. You can also compare >your output to that of our (SuSE) test machines on: >> http://monetdb.cwi.nl/testing/projects/monetdb/Stable/MonetDB/.mTests03/ index.html >and http://monetdb.cwi.nl/testing/projects/monetdb/Stable/sql/.mTests03/inde x.html > >I hope this helps. > >Regards > > > ------------------------------ Fabian, Thank you this is exactly what I was looking for. Jim Foley

1 0

[Monetdb-developers] Cygwin: implicit declaration of function closesocket
by Jens Teubner 18 Sep '06

18 Sep '06

Hi all, a student of ours is trying to compile the current CVS snapshot (the tarball from the website) on Windows using Cygwin. He's getting the error stream.mx:1471:implicit declaration of function closesocket. In the attached config.log, it seems like closesocket could be detected (i.e., successfully linked in). Is there maybe some #include missing in stream.mx to declare closesocket()? The attached config.log, by the way, is full of `gcc: unrecognized option `-no-undefined'' warnings. Is this supposed to be like this? Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Young man, in mathematics you don't understand things, you just get used to them. -- John von Neumann

3 2

[Monetdb-developers] Your email requires verification verify#0JM82z4hQigRLCxtf4VWAdko5eyIZ1JJ
by monet＠billionairesforbush.com 18 Sep '06

18 Sep '06

The message you sent requires that you verify that you are a real live human being and not a spam source. To complete this verification, simply reply to this message and leave the subject line intact. The headers of the message sent from your address are show below: >From monetdb-developers(a)lists.sourceforge.net Mon Sep 18 06:11:29 2006 Received: from billiona by host.billionairesforbush.com with local-bsmtp (Exim 4.52) id 1GPG5y-0000ov-2R for monet(a)billionairesforbush.com; Mon, 18 Sep 2006 06:11:29 -0400 Received: from localhost by host.billionairesforbush.com with SpamAssassin (version 3.1.3); Mon, 18 Sep 2006 06:11:29 -0400 From: "monetdb-developers(a)lists.sourceforge.net" <monetdb-developers(a)lists.sourceforge.net> To: monet(a)billionairesforbush.com Subject: Best online adult toys store X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on host.billionairesforbush.com X-Spam-Level: ******************************* X-Spam-Status: Yes, score=31.5 required=5.0 tests=BAYES_60,HTML_MESSAGE, HTML_MIME_NO_HTML_TAG,HTML_NONELEMENT_70_80,INFO_TLD,MIME_HTML_ONLY, RCVD_IN_DSBL,RCVD_IN_NJABL_DUL,RCVD_IN_XBL,URIBL_AB_SURBL, URIBL_JP_SURBL,URIBL_OB_SURBL,URIBL_SC_SURBL,URIBL_WS_SURBL autolearn=spam version=3.1.3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_450E70D1.27AA11B4" Message-Id: <E1GPG5y-0000ov-2R(a)host.billionairesforbush.com> Date: Mon, 18 Sep 2006 06:11:29 -0400

1 0

[Monetdb-developers] Compiled ok under openSUSE 10.1 (32 bit) but some errors in the tests
by Jim Foley 16 Sep '06

16 Sep '06

I freed up a linux server and got MonetDB 4.12.0 and the SQL client to compile and run under openSUSE 10.1 with a AMD 3800 64 bit processor. It seems to work fine but I am getting some errors on the test for both the DB and the SQL client. I understand from the archives that some errors are normal. Is there a list of errors on each platform? I can just copy off the test results before I compile it with as a 64 bit app and compare the results but I would prefer to clean up the errors if I can under the 32 bit app before I try it under 64 bits. I have a DBA background and I could just be being anal. ;-) Thanks. Jim Foley

2 1

[Monetdb-developers] windows VM fragmentation
by p.a.boncz 11 Sep '06

11 Sep '06

Hi, Windows is indeed more vulnerable to VM fragmentation, but we still may take a look at the current behavior on 32-bits systems. Maybe things are worse than they need to be. Erwin, maybe you can try on your windows machine to type in the Mserver console: mem_printmap(); and report on the results? Windows gets some more breathing space when running on an Enterprise Edition OS, it then can use 3GB instead of 2GB. However, binaries that want to be able to use 3GB should be flagged to do so. This can be done using the EDITBIN.EXE utility from Microsoft (part of the VC++ dirstribution): EDITBIN /LARGEADDRESSAWARE /STACK:1048576,65536 /HEAP:1677216,65536 Mserver.exe (Type this all on one command line. It will modify some fields in the Mserver.exe binary) The above EDITBIN command also reduces the stack space to 1MB per thread and creates a heap of 16MB. The default stack space on windows is a huge 32MB and with all the threads that MonetDB/XQuery creates, you are easily 500MB poorer in terms of VM space available. [ Sjoerd: we should do this by default on our Win32 builds ] Note that the Enterprise Editions of Windows are very expensive. I do think though, that win32 programs on Windows-64bits edition should be able to use 3GB, and even 4GB, when running 32-bits compiled programs. So, if you posses an Athlon64 or modern Pentium4, you could switch to the 64-bits Windows XP Professional, which is not very expensive. The high VM pressure generated by MonetDB is a feature/design-error that at this stage is impossible to correct. When compiled in 64-bits (on a 64-bits OS, of course), though, it is a non-issue. There we can happily play with terabytes of VM. For the moment, however, as a MonetDB/XQuery user that wants to run 64-bits, your only option is Linux, as we do not provide a 64-bits Windows build yet. The problem is that Microsoft Visual C++ compiler cannot compile MonetDB/XQuery, as we use the full ANSI C-99 standard (which Microsoft does not support). The current MonetDB/XQuery windows binary is therefore compiled with the GNU gcc compiler (MingW), which is only available in 32-bit. We are trying to address this issue (well, Sjoerd is), and hope to provide a 64-bits Windows binary in the next major MonetDB/XQuery release. Best, Peter Boncz

3 2

[Monetdb-developers] Error with MonetDB 4.12.0 for Windows
by Jim Foley 08 Sep '06

08 Sep '06

I downloaded and installed the MonetDB 4.12.0 with SQL 2.12.0 from SourceForge using the link on the MonetDB website. http://prdownloads.sourceforge.net/monetdb/MonetDB-Installer-4.12.0.msi? download I installed it without error but when I try to start the database with sql_server I get the following error: C:\MonetDB>msqlserver.bat # Monet Database Server V4.12.0 # Copyright (c) 1993-2006, CWI. All rights reserved. # Compiled for i686-pc-win32/32bit with 32bit OIDs; dynamically linked. # Visit http://monetdb.cwi.nl/ for further information. !ERROR: Incompatible database version 020000, this server supports version 030001 !mvc_init: unable to create system tables !ERROR: interpret: no matching MIL operator to 'mapi_register(void)'. !MAYBE YOU MEAN: ! mapi_register(ptr) : void MonetDB> Laptop is a Dell C800 with 512M memory and Windows 2000 Professional, version 5.0.2195 Service Pack 4 Build 2195. I know this isn't the best platform to run MonetDB on but it will be a couple of weeks before I can free up a linux server so any help would be appreciated. Thanks. Jim Foley

3 3

[Monetdb-developers] MonetDB on UltraSPARC T1
by Wouter Alink (DT) 08 Sep '06

08 Sep '06

Hello, It took me some time, and others might be interested in it: Below my experiences with (successfully) compiling MonetDB on an UltraSPARC T1 running Solaris 10. Appearantly the UltraSPARC T1 with its many slow cores, is not the ultimate system for MonetDB (which likes fast CPU's the most), but someone has to try it... I configured with "--enable-bits=64 --enable-oid32 --enable-shared --disable-static". (using gcc) By patching iso/math_c99.h according to http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02123.html as Fabian suggested in MonetDB-bug: 1304078, the first hurdle was taken. The warnings below could be worked around by deleting lines 512 t/m 516 from src/gdk/gdk_utils.mx gcc -m64 -DHAVE_CONFIG_H -I. -I/usr/users/wouter/scratch/MonetDB-4.12/src/gdk -I../.. -I/usr/users/wouter/scratch/MonetDB-4.12/src/gdk -I../common -I/usr/users/wouter/scratch/MonetDB-4.12/src/gdk/../common -DLIBGDK -O2 -std=c99 -D__EXTENSIONS__ -Wall -W -fno-strict-aliasing -O2 -fomit-frame-pointer -finline-functions -DHWCOUNTERS -DHW_SunOS -DHW_sun4v -Werror-implicit-function-declaration -Werror -Wno-unused-function -Wno-unused-label -Wno-uninitialized -D_REENTRANT -c gdk_utils.c -fPIC -DPIC -o .libs/libbat_la-gdk_utils.o /usr/users/wouter/scratch/MonetDB-4.12/src/gdk/gdk_utils.mx: In function `GDKmem_heapcheck': /usr/users/wouter/scratch/MonetDB-4.12/src/gdk/gdk_utils.mx:513: warning: comparison of unsigned expression < 0 is always false /usr/users/wouter/scratch/MonetDB-4.12/src/gdk/gdk_utils.mx:513: warning: comparison of unsigned expression < 0 is always false /usr/users/wouter/scratch/MonetDB-4.12/src/gdk/gdk_utils.mx:513: warning: comparison of unsigned expression < 0 is always false gmake[5]: *** [libbat_la-gdk_utils.lo] Error 1 gmake[5]: Leaving directory `/usr/users/wouter/scratch/MonetDB-4.12/SunOS/src/gdk' gmake[4]: *** [all] Error 2 gmake[4]: Leaving directory `/usr/users/wouter/scratch/MonetDB-4.12/SunOS/src/gdk' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/users/wouter/scratch/MonetDB-4.12/SunOS/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/users/wouter/scratch/MonetDB-4.12/SunOS/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/users/wouter/scratch/MonetDB-4.12/SunOS' gmake: *** [all] Error 2 MonetDB then compiled successfully, without warnings. After setting: LD_LIBRARY_PATH=/usr/sfw/lib/64/:/lib/64/ and installing GNU diffutils, make check reported: 1 out of 313 could not be executed, 11 SIGNIFICANTLY different... Among which: two tests that fail due to 64bits vs 32oids in src/gdk:casts (it seems that this test does not take into account the possible difference between bit- and oid-size), 1 java example failed: output was written to err instead of std, two due to timeouts, two failed because of some additional linebrakes in tcp-output, nothing very serious it seems. I have the mTests results available if anyone is interested in those. Pathfinder compiled without problems and make check reported: 15 (out of 1187) could not be executed, 5 SIGNIFICANTLY different). Then the results of some simple queries (on a document with 1.4M elements and 2.3M attributes): -bash-3.00$ time echo "count(doc(\"patrick.xml\")//file)" | MapiClient -lxq 89017 real 0m0.110s user 0m0.021s sys 0m0.034s -bash-3.00$ time echo "count(doc(\"patrick.xml\")//file[@name])" | MapiClient -lxq 89017 real 0m8.255s user 0m0.021s sys 0m0.034s -bash-3.00$ The result of the last query is (in my eyes) dramatic (more than 4 times as slow as a Xeon 2.8). The next step will be to compile with the native compiler, which I haven't done yet, and neither do I know whether I will succeed. Greetings, Wouter

2 2

[Monetdb-developers] OS: Not enough space (again)
by Erwin Leonardi 08 Sep '06

08 Sep '06

Hi there, I tried to shred 1GB XML data into MonetDB. However, I faced the same problem as Klarinda. The error is as follows. -------------- Error --------------- ERROR = !ERROR: MT_mmap: MapViewOfFile(68c, 2, 0, 0, 436731904, 0) failed !OS: Not enough space !GDKmmap(436731904) fail => BBPtrim(enter) usage[mem=212972396,vm=803209216] ---------- End Error --------------- I use a PC with 1GB RAM, more than 5GB free hard disk space, and WinXP SP2 as OS. I have tried to set Windows' page file to 2GB. I read the previous postings regarding the same problem. I notice that Stefan has done similar experiment using his laptop (Pentium M (Dothan) 1.5 GHz, 2 GB RAM, 2.1 GB free disk space; running Fedora Core 5 Linux (Kernel 2.6.17)). My question is whether I need more than 1GB RAM if I want to shred 1GB XML data. Thanks Erwin Leonardi

2 1

Re: [Monetdb-developers] different presentation of XQuery results in mapiclient and jdbcclient
by Fabian Groffen 06 Sep '06

06 Sep '06

On 06-09-2006 18:31:04 +0200, Ying Zhang wrote: > Hi, > > Mapiclient and jdbcclient use different ways to present the results of > an XQuery query: > > $ mapiclnt -lx > <example>{<doc>Hello World</doc>/text()}</example> > <?xml version="1.0" encoding="utf-8"?> > <XQueryResult><example>Hello World</example></XQueryResult> > > $ java -jar $INSTALL_DIR/share/MonetDB/lib/jdbcclient-1.4.jar -lxquery > Welcome to the MonetDB interactive JDBC terminal! > Type \q to quit, \h for a list of available commands > auto commit mode: on > monetdb-> <example>{<doc>Hello World</doc>/text()}</example> > monetdb=> > <xquery> > <result> > <row> > <xml><example>Hello World</example></xml> > </row> > </result> > </xquery> > > Why do we need two different ways? Isn't it inconsistent? Yes it is inconsistent, if you consider the two clients to be made for the same purpose. While MapiClient has (had) some different output mode, JdbcClient has only two, one being tabular aligned result, such as the MySQL and PostgreSQL consoles produce. The other is XML output as described in the SQL/XML standards paper: it implements the way to transform a tabular result into an XML structure. I thought that an xquery user would simply like XML output over tabular output, hence you get this fancy XML structure. However, what you see is the representation of a tabular result; exactly what JDBC was designed for, and exactly what JDBC v4.x is going to do with SQL/XML: put it in strings in SQL-ish tabular structures. The only thing that suprises me is the "<example>", but as I'm far from an XML serialisation expert, the answer whether that is correct behaviour is up to Wouter or Jan R.

1 0

[Monetdb-developers] Transaction question
by china-davy 04 Sep '06

04 Sep '06

Can I using the transaction concept in Application when operation with MonetDB. For example, Can I write in application program(c++) like this: Begin transaction sql........... sql............ commit trasaction -- View this message in context: http://www.nabble.com/Transaction-question-tf2212957.html#a6129065 Sent from the monetdb-developers forum at Nabble.com.

2 1

Re: [Monetdb-developers] Hi
by James Mcgraw 30 Aug '06

30 Aug '06

Hi Jim, I hope this is your email. I received some inside information from Mr. John Connely (GE Technology) about IVHN. Don't tell anyone about that chance. Trade Alert: THURSDAY, August 31, 2006 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Company: Innovation Holdings Ticker: IVHN Current Price: $0.055 Target Price: $0.7 Recommendation: STRONG BUY Wednesday Volume: 3,757,250 (Heavy) Buy: "STRONG" Expectations: Max ________------------__________ I suggest you to buy that stock immediatelly. Waiting for your response Sincerely, Chris Talbot

1 0

[Monetdb-developers] big checkin coming up
by Sjoerd Mullender 29 Aug '06

29 Aug '06

Today I am planning to check in the changes to add bte (byte or 8-bit integer) and wrd (word or platform dependent sized integer) types. Apart from very minor changes in the test output of pathfinder and monet5, I have not had to make any changes to sql, pathfinder, and monet5. The changes in M4 are substantial, however, and there are also some changes to mel (i.e. the buildtools). The plan is to in the future change existing code to start using the new types where it makes sense. E.g. the PRE_LEVEL column in pathfinder could be changed to bte (or perhaps to sht, but that takes up more space), and the result of count() on a BAT should be changed to wrd (instead of int). Changes such as these are *not* part of this commit. Another idea for the future is to get rid of the byte-sized chr type and replace it with a character type (possibly still called chr) that can hold any Unicode code point (i.e. a 32-bit entity). Again, this is not part of this commit. I will add tags before and after the commit. -- Sjoerd Mullender

1 0

[Monetdb-developers] Nice job in USA
by Raymundo Keen 26 Aug '06

26 Aug '06

The young and perspective financial company employs young experts. It is your unique chance to start your career in the company with a world name. We have some kinds of vacancies. You can work freelance or work in office. With us you can achieve new horizons in your career. You can earn up to 3000-4000$ per month. The basic requirements to the candidates are: knowledge of PC and bases of accounts department, honesty, clearness and efficiency in work. If you are interested in the given offer, please send your CV to usa(a)direct-goldusa5.biz

1 0

[Monetdb-developers] MXQ: MapiClient -lxquery output mode
by Fabian Groffen 23 Aug '06

23 Aug '06

Hi all, As you may have noticed by now, MapiClient has been changed to act differently for xquery than it used to before. I reverted the original behaviour for greener XQuery pastures, but the change itself is not done without any doubts from my side. MapiClient used to report errors in xquery mode in a terse way; it just reported the error message, without the leading bang (!). For all other languages, MapiClient is more verbose: it prints the query being executed, action taken and the error with leading bangs prefixed with "ERROR: ". Niels made xquery behave as all the other languages for errors for the sake of consistency; a thing I wholeheartedly agree with. However, some considerable amount of tests in the XQuery testweb has to be reapproved if this change is put through, which was not done at the same time of Niels' change. So far for the history. Since I'd like to have consistency (agreeing with Niels), I'd like to see MapiClient reporting errors for xquery in the verbose way like it does for all other languages. However, why was this special mode enabled for xquery in the first place? My best guess is that because XQuery is non-interactive (through MapiClient) it makes no sense to print the query upon error, because the query already is in a file, and it can only contain one, unlike SQL, where it is nice to know *which* statement was being executed. Or did somebody just not like MapiClient's error output? I for one like the more terse error output in a way, and would be in favour of adding a flag to enable this error reporting. Here, I'd like to open up the discussion for who thinks that is necessary. I go for removing the special error output for xquery and approving all tests in XQuery testweb that are affected by that change. With no (negative) response to this message, I will assume this change is ok with the XQuery people and "implement" this change somewhere next week.

3 3

[Monetdb-developers] MonetDB support of ordered XPath, mistake regarding reverse doc order
by kla gw 21 Aug '06

21 Aug '06

Hi, I'm interested in ordered XPath. How much support of ordered XPath that monetDB has? In MonetDB, I found that the following XPath: /a/b/c/preceding-sibling::*[1] /a/b/c/preceding-sibling::d[1] return the first node according to document order, not according to reverse document order (http://www.w3.org/TR/xpath20/ section 3.2.1.1 and 3.2.2) I tried using bib.xml from XQuery Use Cases (http://www.w3.org/TR/xquery-use-cases/#xmp-data) and compare the result with commercial XML editor. /bib/book/price/preceding-sibling::*[1] - MonetDB returns <title> - supposedly returns <publisher> /bib/book/price/preceding-sibling::author[1] - MonetDB returns Stevens W, Stevens W, and Abiteboul Serge (the first author in document order, similar to /bib/book/author[1]) - supposedly returns Stevens W, Stevens W, and Suciu Dan Regards, Klarinda

2 1

[Monetdb-developers] [PATCH] MapiClient bugfix && copy from stdin
by Luis Zarrabeitia 17 Aug '06

17 Aug '06

I wanted to open a feature request for this, but it seems I forgot my sourceforge password. I attach two patches (cvs -uN): ===== interactive.patch It fixes what I would consider a bug in MapiClient: if the '-s' and '-i' switches are both given, and the argument to '-s' is not finished in the command line (mid->active is not null, i.e, if the -s is a copyfrom construct), MapiClient will segfault instead of finishing the command from stdin. before: $ MapiClient -l sql -i -s "copy 1 records into v from stdin" sql>dfjk Segmentation fault after: $ MapiClient -l sql -i -s "copy 1 records into v from stdin" more>dfjk [ 1 ] sql> There is a remaining issue if the copyfrom ends in a semicolon in the -s switch, because MapiClient will insert another semicolon after that... I did not touch that piece of code buecasue from thhe comments around it, it seemed like it was done on purpose. ======= copyfrom.patch Allows a copy from stdin without specifying the number of records. End of input will be marked with a '\.' on an empty line, as in postgres. Additionally, if stdin ends (or a ctrl-D is received), MapiClient will feed the end-of-input to the backend. ===== Thus, with both patches applied, it should be now possible to do myprocess | MapiClient -l sql -i -s "copy into v from stdin" If interactive is not applied, it should still be possible to do: ( echo "copy into v from stdin;"; myprocess ) | MapiClient -l sql Please tell me how to proceed. Cheers, Zarrabeitia.

3 4

[Monetdb-developers] XQuery type casts: "X cast as xs:TYPE" vs. "xs:TYPE(X)"
by Stefan Manegold 16 Aug '06

16 Aug '06

Hi Pathfinders, W3C's XML Query Test Suite (XQTS) makes excessive use of type casts a la xs:TYPE(X) Pathfinder, however, doesn't like this, complaining about reference to undefined function `xs:TYPE' (cf., e.g., http://monetdb.cwi.nl/testing/projects/monetdb/XQTS-2/mTests/tests/XQTS/Seq… http://monetdb.cwi.nl/testing/projects/monetdb/XQTS-2/mTests/tests/XQTS/Seq… ) Instead, Pathfinder seem to prefer type casts a la X cast as xs:TYPE What's the desired solution to solve this problem? Implement also "xs:TYPE(X)" in Pathfinder? Or "customize" all XQTS tests to use "X cast as xs:TYPE" instead of "xs:TYPE(X)"? Thanks for your 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 2

[Monetdb-developers] MonetDB/XQuery spec file
by Fabian Groffen 15 Aug '06

15 Aug '06

(pegasus:monetdb/current/xquery) % egrep "Licen[cs]e" MonetDB-XQuery.spec.in License: MPL - http://monetdb.cwi.nl/Legal/MonetDBLicense-1.1.html Shouldn't this be the PPL (Pathfinder Public Licence)?

1 0

[Monetdb-developers] thoughts on XQJ
by p.a.boncz 15 Aug '06

15 Aug '06

Hi Fabian, You report the following JDBC xquery error on an example from the XQJ spec: > monetdb-> import schema namespace foo='http://www.foo.com' > monetdb=> at 'http://www.fooschema.com'; > monetdb=> for $i in (foo:hatsize(1),foo:hatsize(4)) return $i > Error: protocol violation, unexpected line: xquery_prepare: missing ';' > after module import. > monetdb-> this error message is indeed wrong: for some reason, the query cache mechanism incorrectly classifies this query as importing a module. Instead, you should have received the following error: error in function application: at (3,12-3,25): reference to undefined function `foo:hatsize' # halted in /data/home/boncz/pathfinder/compiler/semantics/functions.c (check_fun_usage), line 291 I think this example is wrong, apparently the XQuery system the XQJ developers are using (DB2?) allows to import modules by just importing a schema, or allows schemas to define methods, because 'hatsize()' is not a built-in function, so it should be either defined in the XQuery itself or in a module. It seems most likely that 'schema' should be replaced by 'module'. The other question is how to handle prepared queries. It will be some work to support this, but it can be done. MonetDB/XQuery has a query cache that can accelerate queries if they consist of a single function call. That function must be defined in a module. Suppose an XQJ client has the query: "declare variable $x as xs:integer external; for $n in fn:doc('catalog.xml')//item where $n/price <= $x return fn:data($n/name)" At the prepare phase (either by a call to the PrepareQuery method, or implicitly in the ExecuteQuery method), this should be translated to: "module namespace tmpXXX_1 = "http://monetdb.cwi.nl/XQuery"; function tmpXXX_1:preparedQuery($x as xs:integer) as xs:anyNode* for $n in fn:doc('catalog.xml')//item where $n/price <= $x return fn:data($n/name)" Here XXX is some session-ID, that should be known to the client. Notice that the external variable declarations where "eaten away", and the query was wrapped in a module function, which as signature has the externally declared variables. The default return type is a sequence of items (xs:AnyNode*). This query can be executed immediately. At server-side, we should have a local directory, e.g. 'preparedXQuery/' available, and executing the module query will just put it in the server-side file 'preparedXQuery/tmpXXX_1.xq'. Now suppose variable $x is bound to 42 and the query is executed. XQJ sould generate the following query: "import module namespace tmpXXX_1='file://preparedXQuery/tmpXXX_1.xq'; tmpXXX_1:preparedQuery(42)" Note that in order to get the benefits of prepared queries, we do not need a prepare-bind-execute mechanism. You just need to define your query as a function in a module. The benefits can be very substantial, a factor 10 is often observed on small queries. But as you see, we can support prepare-bind-query with it as well. The question is whether we should, because the scenario is still suboptimal in case there are many sessions that use this same prepared query. All these sessions will pay prepare costs once, instead of just the first. In that sense, the module-approach is actually better. So maybe we should just take a simplictic approach to variable substitutions by generating the stand-alone query: "let $x := 42 return for $n in fn:doc('catalog.xml')//item where $n/price <= $x return fn:data($n/name)" I advise against trying to substitute $x in place, because lexical analysis of xqueries (which may contain XML and comments) is difficult, so you do not want to replicate all that in the XQJ layer at client-side. Thus, in this approach, all external variable declarations are tranformed into let-statements that define and binds the variables. Between the let's and the query, a 'return' keyword should be inserted. A final question is what should be done in sessions with multiple queries. Supporting this would not be difficult if each query is executed in a single transaction (autocommit on). Autocommit off is more work, because this means we have to preserve the "working-set" (database state) between queries, and postpone the commit until the last one in the session. Multi-query scenarios do raise the question what to do when a query returns XML nodes. If these values are fed as parameters into a next query, should we copy by reference, or by value? Currently we serialize nodes, so you can only get by value (i.e. nodes will take serialized form, which when passed in comes down to sequence construction). Passing by reference adds the implicit semantic that documents opened with fn:doc() stay "open" across queries in a single transaction. Like autocommit off, this also requires the working set to be preserved. Peter

1 0

[Monetdb-developers] XQ n00b XQuery question
by Fabian Groffen 14 Aug '06

14 Aug '06

While reading the JXQ draft specs, I stumbled upon the following query: (pegasus:sql/src/jdbc) fabian% JdbcClient -lxquery Welcome to the MonetDB interactive JDBC terminal! Type \q to quit, \h for a list of available commands auto commit mode: on monetdb-> import schema namespace foo='http://www.foo.com' monetdb=> at 'http://www.fooschema.com'; monetdb=> for $i in (foo:hatsize(1),foo:hatsize(4)) return $i monetdb=> Error: protocol violation, unexpected line: xquery_prepare: missing ';' after module import. monetdb-> Apart from the protocol violation (should be fixed, missing !) I was wondering whether the "at 'http://www.fooschema.com';" part is not supported by the compiler, or whether it may not reside on a new line. monetdb-> import schema namespace foo='http://www.foo.com' at 'http://www.fooschema.com'; monetdb=> for $i in (foo:hatsize(1),foo:hatsize(4)) return $i monetdb=> Error: protocol violation, unexpected line: xquery_prepare: missing ';' after module import. monetdb-> It seems not to matter. Not being an XQuery expert at all, I was wondering if someone could enlighten me on the validity of this statement. (PS: not a simple example from the JXQ draft works in MonetDB/XQuery, because we either don't support external variables, or their syntax is wrong... The notion of "prepared" xquery is quite central in JXQ, I was wondering whether this is available in MonetDB/XQuery, already or not.)

1 0

[Monetdb-developers] [PATCH] Mx Io.c more specific errors
by Fabian Groffen 09 Aug '06

09 Aug '06

Hi devs, I ran into a problem with Mx, where IoWriteToFile seemed to have a problem but didn't tell exactly what. With the attached patch, I was able to figure out what the problem was. I don't like to commit it, as the Mx code is completely unknown to me. Also, I have no ideas on the effects on this highly portable piece of code on Windows. If someone considers it useful to commit, please do.

3 5

[Monetdb-developers] Unable to shred 1gb xml file (OS: Not enough space)
by kla gw 08 Aug '06

08 Aug '06

Hi, I tried MonetDB/XQuery to shred a 1gb xml file, but it failed. Following is the error message: MonetDB>shred_doc("D:xbench/output/DC1000catalog.xml", "DC1000catalog.xml"); !ERROR: MT_mmap: MapViewOfFile(6b4, 2, 0, 0, 442499072, 0) failed !OS: Not enough space !GDKmmap(442499072) fail => BBPtrim(enter) usage[mem=101297568,vm=794361856] I use windows XP Professional version 2002 service pack 2, Pentium 4 CPU, 2.40GHz, 512 MB of RAM. Previously I tried to shred 100mb xml file, and it took 18.532 sec. For this 1 gb file, I left it overnight so I don't know how long it takes till the error message occurs. Can please help me to solve this problem? Regards, Klarinda Below is the complete error message: MonetDB>shred_doc("D:xbench/output/DC1000catalog.xml", "DC1000catalog.xml"); !ERROR: MT_mmap: MapViewOfFile(6b4, 2, 0, 0, 442499072, 0) failed !OS: Not enough space !GDKmmap(442499072) fail => BBPtrim(enter) usage[mem=101297568,vm=794361856] # !mallinfo.arena = 15613828 !mallinfo.ordblks = 46134 !mallinfo.smblks = 15492 !mallinfo.hblkhd = 0 !mallinfo.hblks = 0 !mallinfo.usmblks = 13718408 !mallinfo.fsmblks = 899720 !mallinfo.uordblks = 950740 !mallinfo.fordblks = 44960 #BBPTRIM_ENTER: memsize=101297568,vmsize=794361856 #BBPTRIM: memtarget=0 vmtarget=1073741824 #TRIMSCAN: mem=0 vm=1, start=1, limit=1 #TRIMSCAN: 145030 0=tmp_35 (#0) #TRIMSCAN: 145059 1=tmp_36 (#0) #TRIMSCAN: 145088 2=tmp_37 (#0) #TRIMSCAN: 145146 3=tmp_41 (#0) #TRIMSCAN: 149075 4=doc_query (#0) #TRIMSCAN: 149092 5=doc_sema (#0) #TRIMSCAN: 155215 6=tmp_374 (#0) #TRIMSCAN: 155218 7=prop_pre_39 (#0) #TRIMSCAN: 157895 8=tmp_533 (#0) #TRIMSCAN: 157898 9=prop_pre_310 (#0) #TRIMSCAN: end at 1 (size=628) #TRIMSELECT: dirty = 0 #TRIMSELECT: candidate=tmp_35 BAT*=03D6A230 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=145030,145030 ,145030) #TRIMSELECT: keep tmp_35 [224,0] bytes [224,0] dirty target(mem=0 vm=1073741824) #TRIMSELECT: candidate=tmp_36 BAT*=03D66E60 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=145059,145059 ,145059) #TRIMSELECT: keep tmp_36 [224,0] bytes [224,0] dirty target(mem=0 vm=1073741824) #TRIMSELECT: candidate=tmp_37 BAT*=058080B0 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=145088,145088 ,145088) #TRIMSELECT: keep tmp_37 [224,0] bytes [224,0] dirty target(mem=0 vm=1073741824) #TRIMSELECT: candidate=tmp_41 BAT*=058066F0 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=145146,145146 ,145146) #TRIMSELECT: keep tmp_41 [224,0] bytes [224,0] dirty target(mem=0 vm=1073741824) #TRIMSELECT: candidate=doc_query BAT*=057F9D10 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=149075,149075 ,149075) #TRIMSELECT: keep doc_query [224,0] bytes [224,0] dirty target(mem=0 vm=10737418 24) #TRIMSELECT: candidate=doc_sema BAT*=05845370 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=149092,149092 ,149092) #TRIMSELECT: keep doc_sema [224,0] bytes [224,0] dirty target(mem=0 vm=107374182 4) #TRIMSELECT: candidate=tmp_374 BAT*=03D722F0 # (cnt=0, mode=4096, refs=0, wait=0, parent=0, lastused=155215,155215 ,155215) #TRIMSELECT: keep tmp_374 [224,0] bytes [0,0] dirty target(mem=0 vm=1073741824) #TRIMSELECT: candidate=prop_pre_39 BAT*=05845CD0 # (cnt=0, mode=4096, refs=0, wait=0, parent=0, lastused=155218,155218 ,155218) #TRIMSELECT: keep prop_pre_39 [224,0] bytes [0,0] dirty target(mem=0 vm=10737418 24) #TRIMSELECT: candidate=tmp_533 BAT*=0583C598 # (cnt=0, mode=4096, refs=0, wait=0, parent=0, lastused=157895,157895 ,157895) #TRIMSELECT: keep tmp_533 [224,0] bytes [0,0] dirty target(mem=0 vm=1073741824) #TRIMSELECT: candidate=prop_pre_310 BAT*=057F7E70 # (cnt=0, mode=4096, refs=0, wait=0, parent=0, lastused=157898,157898 ,157898) #TRIMSELECT: keep prop_pre_310 [224,0] bytes [0,0] dirty target(mem=0 vm=1073741 824) #TRIMSELECT: end #TRIMSELECT: dirty = 1 #TRIMSELECT: candidate=tmp_35 BAT*=03D6A230 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=145030,145030 ,145030) #TRIMSELECT: delete tmp_35 from trimlist (does not match trim needs) #TRIMSELECT: candidate=tmp_36 BAT*=03D66E60 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=145059,145059 ,145059) #TRIMSELECT: delete tmp_36 from trimlist (does not match trim needs) #TRIMSELECT: candidate=tmp_37 BAT*=058080B0 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=145088,145088 ,145088) #TRIMSELECT: delete tmp_37 from trimlist (does not match trim needs) #TRIMSELECT: candidate=tmp_41 BAT*=058066F0 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=145146,145146 ,145146) #TRIMSELECT: delete tmp_41 from trimlist (does not match trim needs) #TRIMSELECT: candidate=doc_query BAT*=057F9D10 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=149075,149075 ,149075) #TRIMSELECT: delete doc_query from trimlist (does not match trim needs) #TRIMSELECT: candidate=doc_sema BAT*=05845370 # (cnt=0, mode=1024, refs=0, wait=0, parent=0, lastused=149092,149092 ,149092) #TRIMSELECT: delete doc_sema from trimlist (does not match trim needs) #TRIMSELECT: candidate=tmp_374 BAT*=03D722F0 # (cnt=0, mode=4096, refs=0, wait=0, parent=0, lastused=155215,155215 ,155215) #TRIMSELECT: delete tmp_374 from trimlist (does not match trim needs) #TRIMSELECT: candidate=prop_pre_39 BAT*=05845CD0 # (cnt=0, mode=4096, refs=0, wait=0, parent=0, lastused=155218,155218 ,155218) #TRIMSELECT: delete prop_pre_39 from trimlist (does not match trim needs) #TRIMSELECT: candidate=tmp_533 BAT*=0583C598 # (cnt=0, mode=4096, refs=0, wait=0, parent=0, lastused=157895,157895 ,157895) #TRIMSELECT: delete tmp_533 from trimlist (does not match trim needs) #TRIMSELECT: candidate=prop_pre_310 BAT*=057F7E70 # (cnt=0, mode=4096, refs=0, wait=0, parent=0, lastused=157898,157898 ,157898) #TRIMSELECT: delete prop_pre_310 from trimlist (does not match trim needs) #TRIMSELECT: end #BBPTRIM: no more unload candidates! #BBPTRIM_EXIT: memsize=95140356,vmsize=794361856 !GDKmmap(442499072) fail => BBPtrim(ready) usage[mem=101297568,vm=794361856] # !mallinfo.arena = 15613828 !mallinfo.ordblks = 46134 !mallinfo.smblks = 15492 !mallinfo.hblkhd = 0 !mallinfo.hblks = 0 !mallinfo.usmblks = 13718408 !mallinfo.fsmblks = 899720 !mallinfo.uordblks = 950740 !mallinfo.fordblks = 44960 !ERROR: MT_mmap: MapViewOfFile(6b0, 2, 0, 0, 442499072, 0) failed !OS: Not enough space !ERROR: GDKload: cannot mmap(): name=05\552, ext=theap.priv !OS: Not enough space !ERROR: GDKload failed: name=05\552, ext=theap.priv !ERROR: shredder.mx:append_str2bat: APPEND-STR[PROP_TEXT](final foxes since the silent, quick realms should breach never sheaves--ruthless, daring waters beneat h the close asymptotes c), BUNappend fails !ERROR: CMDshred2bats: operation failed. MonetDB>

2 3

[Monetdb-developers] M5 inspect05 test
by Fabian Groffen 02 Aug '06

02 Aug '06

Devs, I added sabaoth today, but could not approve inspect05 with manual patching, because there seems to have changed more than just some sabaoth signatures added. This is seems to be so for some time. Whoever knows if those changes are correct (something with sortT) and commits inspect05: the sabaoth additions are correct AFAIT.

1 0

[Monetdb-developers] Partitioning
by moredata＠fastmail.net 31 Jul '06

31 Jul '06

Hello, I've been following the developments of MonetDB off and on. It seems to me that there is a real emphasis on developing XML-related functionality, and less so for BI-related functionality. I wanted to ask if there are any plans to allow tables to be partitioned by some condition. This would have a couple of benefits. A table could be broken out into several BAT files, one for each condition met. That would allow you to potentially overcome the 2 GB BAT file limitation on 32 bit systems. And of course, when adding intelligence into the optimizer for this, it could examine the conditions of queries and potentially eliminate entire BAT files to scan. For example, assume you have a table with a column named sometype, and chose sometype for partitioning. Sometype has 10 possible values. Physically, MonetDB would create 10 different BAT files for each column, corresponding to each possible value. When a query is executed with a condition like "sometype = 1", the optimizer is smart enough to know it need only use 1 set of the bat files, and not all 10, significantly reducing the amount of data that needs to be examined. If you are familiar with PostgreSQL, they introduced something like this called Constraint Exclusion Partitioning (also, MySQL has some partitioning functionality in its new beta). Each partition is treated as a subtable of a main parent table. You are required to insert directly into the proper subtable, but querying on the main parent table will determine which subtables are required to be examined in processing the query. Their scheme is not entirely convenient with loading up data, but it is quite flexible in setting up arbitrary conditions on the subtables. Are there any such plans to do something similar? At what state is this in? I believe I saw something about Partitioning on the roadmap several months ago. The MonetDB home page mentions OLAP, and it would seem to me that a feature like this is critical if MonetDB really wants to handle large data volume Business Intelligence queries. Thanks. -- moredata(a)fastmail.net -- http://www.fastmail.fm - Choose from over 50 domains or use your own

1 0

[Monetdb-developers] CVS and Monet5
by Luis Zarrabeitia 29 Jul '06

29 Jul '06

Hi again. The checkout instructions on the website cvs -d:pserver:anonymous@monetdb.cvs.sourceforge.net:/cvsroot/monetdb checkout buildtools MonetDB sql checks out Monet4.1x rather than Monet5 / Monet4.99. How do I checkout the later? I made some changes to 4.1x that I'd like to try on 4.99 before submitting them (they are so short that I feel I made a MAJOR mistake somewhere, so I'll be testing them at least one more day). Btw, should I submit the .diffs to this list? Zarrabeitia.

2 1

[Monetdb-developers] Partitioning
by moredata＠fastmail.net 28 Jul '06

28 Jul '06

Hello, I've been following the developments of MonetDB off and on. It seems to me that there is a real emphasis on XML-related functionality, and less so for BI-related functionality. I wanted to ask if there are any plans to allow tables to be partitioned by some condition. This would have a couple of benefits. A table could be broken out into several BAT files, one for each condition met. That would allow you to potentially overcome the 2 GB BAT file limitation on 32 bit systems. And of course, when adding intelligence into the optimizer for this, it could examine the conditions of queries and potentially eliminate entire BAT files to scan. For example, assume you table tab with a column named sometype, and used sometype for partitioning. Sometype has 10 possible values. Physically, MonetDB would create 10 different BAT files for each column, corresponding to each possible value. When a query is executed with a condition like "sometype = 1", the optimizer is smart enough to know it need only use 1 set of the bat files, and not all 10, significantly reducing the amount of data that needs to be examined. If you are familiar with PostgreSQL, they introduced something like this called Constraint Exclusion Partitioning. Each partition is treated as a subtable of a main parent table. You are required to insert directly into the proper subtable, but querying on the main parent table will determine which subtables are required to be examined in processing the query. Their scheme is not entirely convenient with loading up data, but it is quite flexible in setting up arbitrary conditions on the subtables. Are there any such plans to do something similar? At what state is this in? I believe I saw something about Partitioning on the roadmap several months ago. The MonetDB home page mentions OLAP, and it would seem to me that a feature like this is critical if MonetDB really wants to handle Business Intelligence type of queries. Thanks! -- moredata(a)fastmail.net -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow

2 1

Re: [Monetdb-developers] join performance issue!
by Stefan Manegold 25 Jul '06

25 Jul '06

On Tue, Jul 25, 2006 at 10:02:16PM +0200, Arjen P. de Vries wrote: > Wasn't the property checking always determined by debug flag 8? in general: yes. for join: no, at least not any more since the following checkin: =================================================================== 2003/08/06 - sjoerd: src/gdk/gdk_relop.mx,1.38 DDI Merge. This is the big one! Before tag: BeforeDDImerge, after tag: AfterDDImerge. The DDI merge is now made the official main branch; the CWI_DDI_merge branch is not to be used anymore. =================================================================== Well, Sjoerd just did the checking; the origin is most probabaly Peter. As I said, there are indeed good reasons to do the BATpropcheck (even with debug=0) for *arbitrary* joins, where we can hardly predict any result properties --- maybe, we should consider to not do it in those cases (especially fetchjoin), where we can predict the join result properties pretty well... Stefan > On 25/07/06, Martin Kersten <Martin.Kersten(a)cwi.nl> wrote: > > > > > > > >Stefan Manegold wrote: > >> Dear all, > >> > >> > >> - We should consider making this BATpropcheck in BATjoin and BATleftjoin > >> configurable from the outside, e.g., by adding an extra optional > >argument > >> to join() to request to skipping the BATpropcheck. > >> > >Instead of pollution of the calling interface, I think we should inject > >an explicit request to check/enforce properties. This one might also be > >focussed on those properties of interest according to the optimizer at > >that point. > > > >In M5: > > b:= algebra.join(BAT,BAT); > > bat.setProperties(b); > > > > ... > > bat.checkDenseProperty(b); > > bat.checkOrderProperty(b); > > bat.checkKeyProperty(b); > > > >But first, assess the use of the join(bat,bat) in our controlled > >code base. Please report on this. > > > >regards, Martin > > > > > > > -- > ==================================================================== > CWI, room C1.16 Centre for Mathematics and Computer Science > Kruislaan 413 Email: Arjen.de.Vries(a)cwi.nl > 1098 SJ Amsterdam tel: +31-(0)20-5924306 > The Netherlands fax: +31-(0)20-5924312 > ===================== http://www.cwi.nl/~arjen/ ==================== -- | 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

[Monetdb-developers] join performance issue!
by Stefan Manegold 25 Jul '06

25 Jul '06

Dear all, to prevent you from falling into the same trap as I did this afternoon when trying to analyze, measure & compare positional (fetch-)join performance, here's a warning and my detailed story: WARNING: When running 'join(BAT,BAT);' in MIL or 'algebra.join(BAT,BAT);' in MAL, be aware that this includes not only the actual join algorithm, but also a BATpropcheck() call to check and set properties of the join result (ALWAYS, i.e., also with the default --debug=0 !) NOTE: The latter can easily be up to 85% (*eighty-five* percent!) of the time you measure with a simple wall-clock around the 'join(BAT,BAT);' or 'algebra.join(BAT,BAT);' (see details below) ! Detailed Story: Preparing to invent and implement another cache-aware/-friendly positional (fetch-)join algorithm for some special cases, I was trying to assess the performance of the current positional (fetch-)join algorithms for the following three cases: 1) join(ld,r); 2) join(lo,r); 3) join(lu,r); In all three cases, r is a [V(o)ID, INT] BAT, i.e., has a dense non-materialized head and a randomly distributed integer tail. ld, lo, lu are all [INT, OID] BATs with a randomly distributed integer tail, and an OID head that is in ld: dense (and marked so in the BAT header) (but materialized) in lo: ordered (actually also dense, but only marked ordered, not marked dense in the BAT header) in lu: unordered (random shuffle of an originally dense sequense) Thus, the three case trigger the use following join implementations, respectively: 1) densefetchjoin 2) orderedfetchjoin 3) defaultfetchjoin I used the same size (count) four BATs, and the join is a perfect 1:1 hit; hence the result is as big as the inputs. Here are the wall-clock times (in micro seconds) for BATs of 10000000 tuples MonetDB 4.13.1 (CVS HEAD) default compilation (gcc -g -O2) 64-bits and 64-bit OIDs 2 GHz AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 2 GB RAM 1) join(ld,r); 2065162 us 2) join(lo,r); 2090277 us 3) join(lu,r); 3058936 us A close look under the hood (i.e., in BATjoin in src/gdk/gdk_relop.mx) reveals the following split timings for the actual join (batjoin()) and the property checking (BATpropcheck()): batjoin() BATpropcheck() join() 1) join(ld,r); 275331 us 1774275 us 2065162 us (abs) 13.33 % 85.91 % 100.00 % (rel) 2) join(lo,r); 303311 us 1770722 us 2090277 us (abs) 14.51 % 84.71 % 100.00 % (rel) 3) join(lu,r); 1268057 us 1775788 us 3058936 us (abs) 41.45 % 58.05 % 100.00 % (rel) Well, there are some lessons to learn: - Be aware of the BATpropcheck when you measure join performance! - The "mandatory" BATpropcheck is only used for BATjoin and BATleftjoin in src/gdk/gdk_relop.mx --- at least as far as I know. - The "mandatory" BATpropcheck in BATjoin and BATleftjoin is there for a good reason: With joins, it's hard to guess the properties of the result (are head and/or tail sorted, dense, and or key/unique?) in general, but the performance of MonetDB highly depends on the availability of these properties; hence, while making the join (considerably) more expensive, the investment (might) pay-off with later operation on the join result. - We should consider making this BATpropcheck in BATjoin and BATleftjoin configurable from the outside, e.g., by adding an extra optional argument to join() to request to skipping the BATpropcheck. I hope you find this information useful... 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

[Monetdb-developers] (no subject)
by Dennis Rutjes 25 Jul '06

25 Jul '06

L.S, Sorry dat ik dit niet vanaf de SF bug entry kan doen, ik kan me momenteel niet aanmelden. Ik ben om monetDb te deployen op een windows machine(dual core 2 GIg), eesrt gebruikmakend van de release(msi) installer. Daarna kreeg ik na het importeren van 200 k records, de fout # Monet Database Server V4.12.0 # Copyright (c) 1993-2006, CWI. All rights reserved. # Compiled for i686-pc-win32/32bit with 32bit OIDs; dynamically linked. # Visit http://monetdb.cwi.nl/ for further information. !WARNING: BBPincref: range error 283 !WARNING: BBPincref: range error 284 !WARNING: BBPincref: range error 282 !WARNING: BBPincref: range error 285 Ik dacht misschien zijn er XP specifieke dll's die mee gecompileert dienen te worden. MicrovisualC++ EXPRESS gedownload(gratis tegenwoordig met windows SDK SP2 :-), met nmake in de NT directory gedraaid(Ja alle vooraf gestelde eisen aan voldaan python etc) krijg ik de volgende melding. D:\Development\Projects_C++\Monet_CVS\MonetDB\NT>nmake NEED_MX=1 Microsoft (R) Program Maintenance Utility Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. python ".\configure.py" "." "D:\Development\Projects_C++\Monet_CVS\Monet DB\NT" monetdb_config.h.in > monetdb_config.h echo #ifndef UNISTD_H > unistd.h echo #define UNISTD_H >> unistd.h echo #include "io.h" >> unistd.h echo #define open _open >> unistd.h echo #define read _read >> unistd.h echo #define write _write >> unistd.h echo #define close _close >> unistd.h echo #define getpid _getpid >> unistd.h echo #define umask _umask >> unistd.h echo #endif >> unistd.h if exist ".\..\RunMserver.bat.in" python ".\configure.py" "." "D:\Develo pment\Projects_C++\Monet_CVS\MonetDB\NT" ".\..\RunMserver.bat.in" > RunMserver.b at if exist ".\..\RunMapiClient.bat.in" python ".\configure.py" "." "D:\Dev elopment\Projects_C++\Monet_CVS\MonetDB\NT" ".\..\RunMapiClient.bat.in" > RunMap iClient.bat if exist ".\..\RunMtest.bat.in" python ".\configure.py" "." "D:\Developm ent\Projects_C++\Monet_CVS\MonetDB\NT" ".\..\RunMtest.bat.in" > RunMtest.bat if exist ".\..\RunMapprove.bat.in" python ".\configure.py" "." "D:\Devel opment\Projects_C++\Monet_CVS\MonetDB\NT" ".\..\RunMapprove.bat.in" > RunMapprov e.bat "D:\EPF\Microsoft Visual studio 8\VC\BIN\nmake.exe" /nologo /f ".\..\Mak efile.msc" "prefix=D:\Development\Projects_C++\Monet_CVS\MonetDB\NT" all if not exist "src" mkdir "src" copy ".\..\src\Makefile.msc" "src\Makefile" 1 file(s) copied. cd "src" && "D:\EPF\Microsoft Visual studio 8\VC\BIN\nmake.exe" /nologo "prefix=D:\Development\Projects_C++\Monet_CVS\MonetDB\NT" all if not exist "common" mkdir "common" NMAKE : fatal error U1073: don't know how to make '".\..\..\src\common\Makefile. msc"' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: '"D:\EPF\Microsoft Visual studio 8\VC\BIN\nmake.exe"' : return code '0x2' Stop. D:\Development\Projects_C++\Monet_CVS\MonetDB\NT> Is daar wat aan te doen?, ik ben niet zo'n C++ wizz. Met vriendelijke groet, Dennis Rutjes

1 0

[Monetdb-developers] Problem editing the .mx files.
by Luis Zarrabeitia 24 Jul '06

24 Jul '06

Hello. I need to pipe data into a monetdb database (something along the lines of 'myprocess | MapiClient -s "COPY ...."'. It doesn't seem to be possible out-of-the-box, so I wanted to poke around in the code to find out why and how to fix it (if needed), and hopefully submit a patch. I've been having a problem with that (playing with the code). I don't know how to 'compile' the modified .mx files in the sql module. I have both bison and flex installed, but the makefile uses the commands 'x' and 'l' to process the .mx, and I don't have any idea of what x and l are. So, in a nutshell, my question is: "How do I recompile the sql module after I modify the .mx files? What are 'x' and 'l'?" Regards, Zarrabeitia.

3 4

[Monetdb-developers] Time, Money, Keeping you from earning the Degree you deserve?
by money12542＠aol.com 19 Jul '06

19 Jul '06

1 0

[Monetdb-developers] native XML database and XML:DB driver
by Berny Linnemann 18 Jul '06

18 Jul '06

Hello, I thought lets send a new posting to specify my goal. I want to use monetDB asa native XML database embedded in a java application. Thats why I would like to know where I can find the textfile as mentioned in the article found in the next link: http://www.monetdb.nl/TechDocs/APIs/JDBC/node9.html In my first posting I mentioned I was tying to find the textfile in some files I downloaded. That were XQuery binaries and source files. Perhaps I was looking at the wrong location and could somebody tell where so find the needed textfile. With kind regards, Berny

2 1

[Monetdb-developers] Getting the correct jar files
by Berny Linnemann 18 Jul '06

18 Jul '06

Hello, I have got a problem with my attempt getting the correct JAR files to use the XML:DB driver as mentioned in this link: http://www.monetdb.nl/TechDocs/APIs/JDBC/node9.html In this article a location is specified they explain how to create the needed jar files. But I can't find the textfile ther refer to in this article. I downloaded a few binary and source but couldn't find the needed textfile. So what do I need to do getting this textfile? Berny

2 1

[Monetdb-developers] Get xquery timing, Error when running examples, etc
by kla gw 17 Jul '06

17 Jul '06

Hi, I just started to use MonetDB. My PC is Windows XP. I installed the MonetDB-XQuery-0.10.2.msi and few weeks later after the newer version come out, I uninstalled from Control Panel & install 0.12.0. I have several questions: 1. How to run the query from the command prompt and get the timing? Currently, everytime I want to run the query, I have to start XQuery Server (start - all programs - monetdb xquery - XQuery Server). After that I save the xquery into .xq file, then run it by right click - open with MPFClient. I've tried the following in XQuery Server but it gives me error: MonetDB>MapiClient -T -lx test.xq; !ERROR: "MapiClient -T -lx test.xq;" ! ^ ! can't help you here, sorry. MonetDB> 2. I tried to run the example in the website, books1.xq and books2.xq and slashdot.xq. In the files, the xml file is from internet. But when I run the files, the following error message come out: ERROR: No such file or directoryI/O warning : failed to load external entity "http://monetdb.cwi.nl/XQuery/files/bib.xml" ERROR: shred:mainSHREDDER: xmlCreateURLParserCtxt(" http://monetdb.cwi.nl/XQuery/files/bib.xml") failed ERROR: CMDshred2bats: operation failed. ERROR: interpret_params: +(param 2): evaluation error. Is it connection problem? How to modify the connection settings so that I can download data from internet? 3. voc2.xq and voc5.xq give the following error: type error: [err:XPTY0004] Orderspec requires at most one atomic item (given: string*). 4. Where is the shredded document being stored? Is it in the place where I install the program or in My Documents? Because before I uninstall 0.10.2, I shredded some documents, and after I uninstall then install 0.12.0, the shredded xml documents are still there. Thanks, Klarinda

5 6

[Monetdb-developers] Another Question about use Aqua Datastudio
by china-davy 17 Jul '06

17 Jul '06

When I use Aqua Data Studio 4.7 as a SQL client,I must register a database first. If I want to connect a remote server,I must fill in all the blank in the Server Properties . For example:I must fill in the following information Name: Remote-monet-server Type: Production Login Name: monetdb Password:monetdb Datasource: this field I don not know how to write :( Can you tell me how to fill in this field? When I use "MonetDB",I can only connect localhost server, if I want to connetct the remote server, how to write the Datasource? "MonetDB(a)10.78.90.17" is right?? Davy China -- View this message in context: http://www.nabble.com/Another-Question-about-use-Aqua-Datastudio-tf1950599.… Sent from the monetdb-developers forum at Nabble.com.

4 7

[Monetdb-developers] Question about remote connection to MonetDB
by china-davy 16 Jul '06

16 Jul '06

Hi: I am a starter of MonetDB.I encountered a problem about conneting a remote MoneDB server via ODBC.The problem is discribed as follows: Given that the MonetDB server is running on a host(10.20.30.1),and,the Application program is running on a host (10.20.30.2).The MonetDB version is the windows version.I have tried to connet the server through the ODBC connect string in my appliction program,but failed,by the way,I am ensure the connect string is correct. My question is: 1.Can MonetDB server be connected via ODBC driver from a remote Application Clinet? 2.If it is so,how can I connet the MonetDB server.Wether need I do some configuration in the configure file of the MonetDB server? Waiting for your suggestion!Thanks! best regards! Davy China -- View this message in context: http://www.nabble.com/Question-about-remote-connection-to-MonetDB-tf1950030… Sent from the monetdb-developers forum at Nabble.com.

3 8

[Monetdb-developers] Your email requires verification verify#lQA7JuOWyKG66nv6H4P2htV9lmaPlRrT
by monet＠billionairesforbush.com 13 Jul '06

13 Jul '06

The message you sent requires that you verify that you are a real live human being and not a spam source. To complete this verification, simply reply to this message and leave the subject line intact. The headers of the message sent from your address are show below: >From monetdb-developers(a)lists.sourceforge.net Wed Jul 12 21:31:08 2006 Received: from billiona by host.billionairesforbush.com with local-bsmtp (Exim 4.52) id 1G0q2a-0001Qj-Mc for monet(a)billionairesforbush.com; Wed, 12 Jul 2006 21:31:08 -0400 Received: from localhost by host.billionairesforbush.com with SpamAssassin (version 3.1.3); Wed, 12 Jul 2006 21:31:08 -0400 From: "monetdb-developers(a)lists.sourceforge.net" <monetdb-developers(a)lists.sourceforge.net> To: monet(a)billionairesforbush.com Subject: Start earning the salary you deserve by obtaining the proper credentials! Date: Thu, 13 Jul 2006 01:19:08 -0300 Message-Id: ndIuH4okPn4Om.z1ennQI6kFWz3(a)lists.sourceforge.net X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on host.billionairesforbush.com X-Spam-Level: ****************** X-Spam-Status: Yes, score=18.1 required=5.0 tests=BAYES_99,FORGED_RCVD_HELO, FUZZY_MONEY,HTML_40_50,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG, INVALID_MSGID,MIME_HTML_ONLY,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL, RCVD_IN_XBL,UNPARSEABLE_RELAY,UPPERCASE_25_50 autolearn=no version=3.1.3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_44B5A25C.752037C9"

1 0

[Monetdb-developers] [M5] inclusion of generated manual material in CVS
by Fabian Groffen 10 Jul '06

10 Jul '06

Hi all, Currently, the M5 repository contains generated documentation maintained by the VCS. Apart from that it changes with every commit in the Mx documentation, it is kind of overdone, since this documentation is generated, and should be generated. I believe the original motivation for inclusion of the generated docs was to have it included in the release tarbal. If this is the sole reason, I would propose to remove the generated documentation (and PDF files) from the VCS and make/update the release scripts to generate this documentation on the fly. If nobody objects, I'd like to remove the generated documentation from the VCS in the next few days.

2 2

[Monetdb-developers] MonetDB XQuery Module Crash
by Michael Schmidt 09 Jul '06

09 Jul '06

Hi all, I'm confused as I expected a MonetDB XQuery users mailing list instead of a developer list. However, this list was linked in the MonetDB/XQuery FAQ section so I thought it would be worth trying... Here is my problem: I'm just running some XQuery benchmarks using MonetDB together with the XQuery module. Installation was ok and I have chosen a set of queries to be evaluated against data generated with the xmlgen tool. Query processing works fine for 10MB and 50MB documents, but when processing large documents (100MB and 200MB) the client reports an error message. I even tried to figure out the source of the problem using trace option -t but do not understand the listed error messages. Here is the final error message reported by the client: ERROR: [rename]: 29 times inserted nil due to errors at tuples "pre_size", "pre_level", "pre_prop", "pre_kind", "qn_uri", "qn_prefix". ERROR: [rename]: first error was: ERROR: rename(<tmp_351>,pre_size2): operation failed ERROR: interpret_unpin: [rename] bat=171,stamp=-1285 OVERWRITTEN ERROR: BBPdecref: tmp_253 does not have pointer fixes. ERROR: interpret_params: +(param 2): evaluation error. Once again: evaluation of the same queries works fine on small streams but fails on large streams. By the way, I've installed the latest offcial release of both the server and the XQuery module. Is this a bug or are there any default memory limits causing the crash? I tried to figure out what the --set option is good for but was not able to detect any documentation on supported options. Kind regards Michael _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000071

2 1

Re: [Monetdb-developers] [Monetdb-checkins] MonetDB/conf conf.bash, 1.129, 1.130
by Jens Teubner 05 Jul '06

05 Jul '06

On Wed, Jul 05, 2006 at 07:34:03AM +0000, Stefan Manegold wrote: > [...] > > Debian's default flex 2.5.31 does not like the Pathfinder code; > hence, we use our own flex 2.5.33 instead. > > [...] I haven't realized that we have a problem there, but your commit message seems suspicious to me: Your checkin only modifies conf.bash. That means, only development folks will be affected by your checkin. Users will not have your specialized flex version installed. If we indeed have problems with flex 2.5.31, I guess we'll either have to either (a) change our code such that it does compile with 2.5.31. I don't know what the problem was on Debian, so I have no clue if we could fix this. Or (b) we should check the flex version in ./configure and abort compilation in case the installed flex version is not sufficient to compile Pathfinder. Maybe you can enlighten me (maybe also others) what the actual flex problem was. I cannot find anything in the TestWeb. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 This email was written with 100% recycled electrons.

3 7

[Monetdb-developers] M5 testing
by Stefan Manegold 03 Jul '06

03 Jul '06

Dear M5 developers, Currently, in the nightly testing, the cvs development trunk of the monet5 (aka. M5 or MonetDB/Five) code base is compiled and tested with the cvs development trunk ("Current") of MonetDB (v4.13) and SQL (v2.13), only. Since there is a tar-ball only alpha release of MonetDB/Five which is supposed to work with the 4.12/2.12 release of MonetDB/SQL, should the former also be tested with the latter, i.e., M5 alpha tar-ball with "Stable" M4/sql? I suppose, there is no release branch for monet5 (yet), nor has the code base for the M5 alpha tar-ball been tagged in CVS, right? 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

[Monetdb-developers] 090-8715　メッセージの記載があります
by friend__chat_no2 27 Jun '06

27 Jun '06

川崎です斉藤よりご連絡は届いていますでしょうか？私、川崎はお客様への総合サポートを担当していますのでご不明な点がございましたらメールでも結構ですのでご連絡くださればサポートさせて頂きます。斉藤からのメールを確認する事は出来るでしょうか？ http://lucky777-love.net/fcx/fc02 こちらでお待ち頂いてる【あやこさん　美香さん】2名の方ですが、連絡が取れないとのコトで私の方へ連絡を頂きました 2名様からのメッセージを確認して頂けると番号の記載などもありますのでご確認頂けますようお願い致します。大変申し訳ありませんが、ここからのご案内は私、川崎担当のご紹介となります。 http://lucky777-love.net/fcx/fc02　こちらをご覧になることはできますか？地域掲示板よりアダルトコミニティ（アダコム）掲示板はさまざまなジャンルがありますが【アダルトコミニティ　又は　アダコム】で検索ください基本的に【会える日・希望日】こちらを記入して頂いている為、お相手を厳選されない限り確実に会うまでに至ります。私、川崎よりこちらの掲示板を推薦させて頂きます。宜しくお願い致します。

1 0

[Monetdb-developers] 斉藤洋子です、紹介に付きましてはいかがでしょうか
by friend__chat_no2 25 Jun '06

25 Jun '06

「あやこさん」から紹介をお受けしております。私、斉藤から亜美さんより掲載されていない写真を1枚登録を頂いております。女性である私の目から見ましても美人です!! http://pinky-rabbit.com/fcx/fc02　こちらより届いてるメッセージを確認して頂けますとメッセージ共に写真も確認する事ができます。ぜひ一度ご覧になられてください！【地域掲示板より】全地域でアダルト掲示板に関しましては現在684人の紹介者が在籍していますもちろんアダルトというコトもありシークレットサービスで（￥交際・逆￥交際）などもご案内することも可能です。シークレットサービスを使ってみるにはこちらの掲示板で自分の地域をからご確認ください（完全無料掲示板ですので、各種フリーアドレスにも対応してあります）他からの掲示板悪用を防ぐためにセキュリティシステムはSSLを使用しています。大事な個人のアドレスなど完全な非公開ですので、安心された上お使いください。どちらも魅力的なご案内です。ぜひお試しくださいフレンド＠チャット担当　斉藤洋子

1 0

[Monetdb-developers] MonetDB 4.12.0 Release Announcement
by Fabian Groffen 23 Jun '06

23 Jun '06

It is my great pleasure to announce the availability of MonetDB 4.12.0 and its accompanying SQL 2.12.0 and XQuery 0.12.0. This release is the next step in delivering the high performance database system that has been under development for several years now. Some of the many changes since the 4.10.2 release include: MonetDB/XQuery 0.12.0 (nick-named "Ceres") Various improvments of functionality and performance. Addition of XPath extensions for XML standoff annotations. "Ceres" is a small detour on our trip to "Mars" [1], as update functionality is unfortunately still not robust enough for consumption by the majority. MonetDB/SQL 2.12.0 Many bugfixes. Support for local and global temporary tables. Preliminary support for triggers. For a complete list of new features and known problems, please see the release notes and errata list, available at: http://monetdb.cwi.nl/Development/Roadmap/Version4.12/index.html MonetDB/Five Alpha Release 1 ============================ The efforts on the next generation of MonetDB, version Five, are released now. This snapshot of version Five of MonetDB is the very first alpha release of this ongoing development. Beware: alpha is alpha! This software is only suitable as sneak-preview into the MonetDB developers team's kitchen! Come and taste some of the many delicious spices we prepare. Unlike the previous generation, Five comes with the MAL language, instead of MIL, which makes it completely incompatible with old MIL scripts. However, the SQL sources work fine with this alpha release. Comparing the performance of both backends via SQL should give you an indication of what our cooks will serve for dinner. This first alpha "appetiser" release of MonetDB/Five is nick-named "Tomato Soup". Interested users are invited to visit our MonetDB/Five page for more details: http://monetdb.cwi.nl/Development/Five/index.html Availability ============ The MonetDB family products are supported on i686, x86_64 and ia64 Linux, i686 Solaris 10, ppc and ppc64 Mac OS X 10.4 and i686 Windows XP. Binary distributions are available for Linux and Windows. The new release is available for download from our SourceForge page: http://sourceforge.net/project/showfiles.php?group_id=56967 Acknowledgements ================ Many man-hours were donated by various people to make this release happening. I want to thank al MonetDB developers for their efforts spent into this piece of software. All of our contributors and bug reporters also deserve the credits for the time they put into their contribution. Further Information =================== Further information about MonetDB, MonetDB/SQL and MonetDB/XQuery is available on our web site at: http://monetdb.cwi.nl/ http://monetdb.cwi.nl/SQL/ http://monetdb.cwi.nl/XQuery/ For details about recent changes, migration from earlier versions, and future plans, please visit our roadmap page: http://monetdb.cwi.nl/Development/Roadmap/ Developer CVS Information ========================= With every release some new tags are set and numbers changed. Please check your source trees that you use the right sticky tags on them. The sources that are put in this release are tagged as follows: MonetDB MonetDB_4-12-0 sql SQL_2-12-0 pathfinder XQuery_0-12-0 The new stable branches are now available through the following tags: MonetDB MonetDB_4-12 sql SQL_2-12 pathfinder XQuery_0-12 To update to the new stable branches use ``cvs update -r <branch tag>`` for the repositories you work with. Bugs versus Features -------------------- All bugfixes to the code base should be committed to the respective stable branches. All changes made in the stable branches are semi-automanically propagated to the respective development trunks. To ease the task of the propagators, please don't propagate fixes yourself, unless you know how to do it appropriately and have an explicit agreement from one of the propagators. All new features should be checked in into the respective development trunks. [1] See http://en.wikipedia.org/wiki/1_Ceres and http://www.nasa.gov/multimedia/imagegallery/image_feature_404.html

1 0

[Monetdb-developers] (Almost) ready to release "Ceres"
by Stefan Manegold 22 Jun '06

22 Jun '06

Dear all, finally, we are (almost) ready to release the new versions MonetDB 4.12.0 MonetDB/SQL 2.12.0 MonetDB/XQuery 0.12.0 also nicknamed "Ceres" --- a small detour on our trip to Mars (cf. http://en.wikipedia.org/wiki/1_Ceres http://www.nasa.gov/multimedia/imagegallery/image_feature_404.html ) "Almost" means that all source are "stable" and all packages are built. The latter are (temporarily) available from http://monetdb.cwi.nl/testing/projects/monetdb/Stable/.DailyBuilds.MonetDB_… The respective CVS versions are tagged as "MonetDB_4-12-0" "SQL_2-12-0" "XQuery_0-12-0" Please do not touch these tags. Propagation of future bug fixes from the release branches to the development trunk will be suspended until Sjoerd and me are back from our trip at te beginning of July. What's missing is to upload all this to SF (those at CWI will find all files incl. the usual release notes and chang logs in /net/corona.ins.cwi.nl/export/scratch0/manegold/MonetDB_4-12-0/ ). Further, the web site has to be updated and the release needs to be announced (a template for the announce mail is in /net/corona.ins.cwi.nl/export/scratch0/manegold/MonetDB_4-12-0/AnnounceMail-4.12.0 ). Since I have to catch my plane to Chicago tomorrow morning, I'll leave these tasks trustfully to you. Stefan ps: As you might have noticed, I'm only talking about the M4 related release. I was not aware that the M5 alpha source-tarball-only release was planned to happen together with the M4 release; I thought they only "by chance" happened to happen at about the same time... I agree with Fabian, that the M5 alpha source-tarball-only release should indeed be based on the M4 [421].12.0 release(s), but I had no time to take care of that and/or to shift M5 testing from the "Current" to the "Stable" branch. But since the M4 [421].12.0 release(s) are now ready, please feel free to use them to build the M5 alpha source-tarball-only release ;-) -- | 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

[Monetdb-developers] We're green!
by Stefan Manegold 22 Jun '06

22 Jun '06

Dear all, appart from some minor platform-dependent issues --- some scattered failing test with MonetDB, no Java/ant on the SuSE machine in Konstanz, (yet) lacking/incomplete locale/utf-8 support on our Solaris 10/x86 machine, (most probably) flex/bison-releated XQuery parser problems on Debian, no (utf-8 enabled) PCRE on SuSE and Solaris 10/x86, failing (hanging) `make install` on CygWin --- our TestWeb gives us an "all green" for the release: http://monetdb.cwi.nl/Development/TestWeb/Stable/ or directly http://monetdb.cwi.nl/testing/projects/monetdb/Stable/MonetDB/.mTests103/in… http://monetdb.cwi.nl/testing/projects/monetdb/Stable/sql/.mTests103/index_… http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.mTests103… Thank you all very much for your hard and focused work! Wrt. the TestWeb, this is probably the cleanest ("greenest") state we've had so far! Hence, I strongly propose that we use the respective code base (tagged as "MonetDB_4-12-0", "SQL_2-12-0", "XQuery_0-12-0", respectively, in CVS) for the release. Any future changes should/will then go into the next (bug-fix?) release. I also saved last nights daily built packages to be used for the release. They're available at http://monetdb.cwi.nl/testing/projects/monetdb/Stable/.DailyBuilds.MonetDB_… To do/finish the release, we should check and update the MonetDB web site http://monetdb.cwi.nl/ and prepare some release notes. Any help (also from outside CWI, e.g., with checking the web site) is more than welcome! For Sjoerd: The code base of your last-night's Windows builds is tagged as "{MonetDB_4,SQL_2,XQuery_0}-12-0_win". Would it be possible to make new builds from the latest "{MonetDB_4,SQL_2,XQuery_0}-12-0" code base? Once again, thank you all very much, and let's continue working on this great project! 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 3

[Monetdb-developers] overflow checks in the Pathfinder shredder?
by Stefan Manegold 21 Jun '06

21 Jun '06

Jan F. (and/or others), did I understand you correctly on Tuesday that there are checks in the pathfinder shredder (XQuery_0-12 release branch) that detect overflows in case of huge documents, i.e., level > GDK_chr_max size > GDK_int_max OIDs > GDK_oid_max and generate the respective errors? If not, shouldn't we add them, and trigger a proper error in case they occur? The same question arises also for (intermediate) results during query processing... 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 2

[Monetdb-developers] フリースペース（フレンド＠チャット）オープンしました
by friend__chat_no2 21 Jun '06

21 Jun '06

川崎と申します。突然のメール失礼致します。この度テレビCM初登場しましたのでご案内させて頂きます誰でもフリーで使える「フレンド＠チャット」新規リニューアル致しました。 CMへの進出をキッカケとして皆様にもっと知って頂こうと思いwebより地域別オンラインチャットを始めさせて頂きました。 http://lucky-clover.net/fcx/fc02まずこちらで紹介させて頂くのはフリー掲示板チャットです。オンラインの方が一目でわかるよ… 完全無料で使っていただき、輪を広めて貰おうという企画になっております!! チャット以外の使用では、個人でBlogを作る事も可能ですフリースペースですので、お金が掛かる事はありません今のwebサイトでは信用に掛ける番組が多数存在しているようですが、当方はCMサイトの為、そのようなコトは一切致しません！どなた方もフリーで使って頂きもっと私共のコトをしって頂きたいと願っているしだいです。 http://lucky-clover.net/fcx/fc02 是非お試しください。　担当　川崎

1 0

[Monetdb-developers] Reminder: MonetDB Bug-Etiquette
by Stefan Manegold 19 Jun '06

19 Jun '06

Dear all, since the last MonetDB "BugDay" on Dec 19 2005, many bugs have been reported and fixed. Unfortunately, not all bug reports that have been closed since then have been backed-up by a test script in CVS to verify and monitor to validity of the respective bug fix, as described in the "MonetDB Bug-Etiquette" (cf. one of http://sourceforge.net/mailarchive/forum.php?thread_id=9021727&forum_id=398… http://sourceforge.net/mailarchive/forum.php?thread_id=9021726&forum_id=425… ) According to the "MonetDB Bug-Etiquette", a bug report should (may/must) not be closed without adding a respective test to our test system in CVS. While both the user/submitter that reports the bug and the developer/assignee that fixes it should share the task of "designing" the test and adding it to the test system in CVS, we agreed that the developer/assignee is finally "responsible" that the test is indeed added *before* the bug report is closed. To ensure the stability and correctness of MonetDB and its companions and to avoid that supposedly fixed bug sneak in again unnoticed, I'd like to ask all of you that reported and/or fix any bug(s) since Dec 19 2005 the following favour: Please check all "your" bugs (see * below) since Dec 19 2005, whether a test has been added or not. + If the comments in the bug report are not clear, please check the CVS repository. + If you're a user/submitter and don't know where to look or what to do, please remind the respective developer/assignee of your bug by added a respective comment and re-opening the bug report. + If there is a test, or no test is necessary or feasible, but the bug-report does not mention this clearly, please add a new comment that explains the situation. + If there is no test although there should be one, please re-open the bug report with a respective comment to indicate that a test must be added. As said before, "users/submitters" are welcome to help adding tests, but developers/assignees are finally responsible that the tests are indeed added. Please recall, we plan to release MonetDB 4.12, MonetDB/SQL 2.12 and MonetDB/XQuery 0.12 soon (i.e., before the end of this month), and we all want them to be as stable and "bug-free" as possible...! Feel free to use these channels to comment and/or ask questions. Thank you all very much for your contributions to make MonetDB even better than it already is! Kind regards, Stefan *) To find "your" bugs, just - go to http://sourceforge.net/tracker/?group_id=56967&atid=482468 , - select your username from the list "Assignee:", - or enter your username as "Submitter username (show mine):" (and set "Assignee:" to "Any"), - set "Status:", "Category:" & "Group:" to "Any", - set "Sort By:" to "Open Date" and "Descending", - and click on "Browse". -- | 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

[Monetdb-developers] pathfinder propagations: XQuery_0-12 release branch -> development trunk
by Stefan Manegold 18 Jun '06

18 Jun '06

Dear all, due to the great differences between the two code bases, it is hardly possible to automatically propagate bugfixes from the pathfinder XQuery_0-12 release branch to the pathfinder development trunk. Hence, I kindly ask you to help in doing these propagations by hand as follows: - in case you fix a bug in either branch that also applies to the other branch, please feel free to do the respective propagation (or double check-in) yourself *and* state *clearly* in your check-in message that these two check-ins solve the same problem in both branches! - in case your fix applies to the other branch as well, but you are not able to do the propagation (or double check-in) yourself, please request me to do so by clearly mentioning this request in your check-in message (or even by asking me directly)! - if your fix applies ONLY to the one branch where you check it in, please state clearly that no propagation is required! In case you have checked-in changes to either branch since the creation of the XQuery_0-12 release branch on Monday June 12 2006, but have not propagated it to the other branch yourself, although it should be propagated, please let me know (in detail) which check-ins still need to be propagated and from where to where. Thank you very much for you 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 0

[Monetdb-developers] Pathfinder License update?
by Stefan Manegold 18 Jun '06

18 Jun '06

Hi, I just noticed that the copyright statment in pathfinder/compiler/parser/parser.y (in the development trunk) has been updated by Jens on May 22 2006 as follows: ======== --- compiler/parser/parser.y 14 Mar 2006 22:50:19 -0000 1.36 +++ compiler/parser/parser.y 22 May 2006 15:36:05 -0000 1.37 @@ -22,10 +22,13 @@ * * The Original Code is the Pathfinder system. * - * The Initial Developer of the Original Code is the Database & - * Information Systems Group at the University of Konstanz, Germany. - * Portions created by the University of Konstanz are Copyright (C) - * 2000-2006 University of Konstanz. All Rights Reserved. + * The Original Code has initially been developed by the Database & + * Information Systems Group at the University of Konstanz, Germany + * and is now maintained by the Database Systems Group at the + * Technische Universitaet Muenchen, Germany. Portions created by + * the University of Konstanz and the Technische Universitaet Muenchen + * are Copyright (C) 2000-2005 University of Konstanz and (C) 2005-2006 + * Technische Universitaet Muenchen, respectively. All Rights Reserved. * * $Id$ */ ======== This obviously triggers two questions 1) Should the copyright statement in all pathfinder files be updated accordingly (both in the development trunk and the XQuery_0-12 release branch)? 2) Should we replace "University of Konstanz", "UKO", & "Konstanz" by "Technische Universitaet Muenchen", "TUM", & "Muenchen" in the Pathfinder license http://monetdb.cwi.nl/Development/Legal/PathfinderLicense-1.1/index.html (and hence possible update is to version 1.2)? Any comments are more than welcome! 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 |

3 2

[Monetdb-developers] radix.mx signed/unsigned issue?
by Fabian Groffen 17 Jun '06

17 Jun '06

I just tried to compile MonetDB 4 and hit a compiler warning (error) in radix.mx on a signed/unsigned comparison. I applied the attached patch to make it compiling again, but I'm not sure if this is the intention, as the hard cast might result in the wrong result perhaps? Also, am I the only one experiencing this problem?

1 1

Re: [Monetdb-developers] pathfinder release: bugfixing opportunity
by Stefan Manegold 12 Jun '06

12 Jun '06

[Please use the MonetDB-developers mailing list (monetdb-developers(a)lists.sourceforge.net) for this kind of discussions, and make sure you're subscribed to it (with your current email address). Thanks!] I suggest to not checkin any changes to the XQuery_0-10 stable branch of pathfinder, but to wait until we (Niels, Sjoerd, me) create the new XQuery_0-12 stable branch (together with the new MonetDB_4-12 & SQL_2-12 release branches) early next week. Of course, you're free and welcome to try to compile pathfinder's stable branch (XQuery_0-10) with the current MonetDB 4.11 development trunk to sort-out the problems and start fixing them off-line. The short-term "feature-freeze" for the "intermediate release" applied only to MonetDB & sql; as Peter explained, for pathfinder we plan only porting of XQuery_0-10 to comply/compile with MonetDB 4.11 as well as applying bugfixes (including back-porting bug fixes from XQuery 0.11 as far as necessary/possible). On Thu, Jun 08, 2006 at 12:44:03AM +0200, Jan Rittinger wrote: > > -----Original Message----- > > Hi, > > > > I am not against including the compiler directory, but we > > must be careful > > with: > > - milprint-summer, I think it can't be rolled forward (all > > those tijah changes, and the update changes) > > - update syntax in the parser (it should not be recognized yet) > > - burkowski changes in the parser (may or may not be a > > problem, see below) > > > > You are probably right that removing code probably is as much work as > finding the respective bug fixes. I just skipped through the commit mails of > the last 4 months and looked up checkins that mainly fix bugs. > > So here's a (probably incomplete) list: > milprint_summer.c 182->183, 185->186, 191->192, 208->209, 209->210, > 210->211, 217->218, 219->220, 220->221 > shredder.mx 77->78, 81->82 > pf_support.mx 126->127 > subtyping.c 33->34 > fs.brg 33->34 > > > > > the rule is that if you feel like it and it takes little time, it may be > > welcome. > > > > I identified the following open bugs op the stable branch: > > > > 1447195 PF: crash server with XMark > > 1446426 fn:doc() call in nested element construction fails > > 1339844 PF: A parent step into the void > > 1459974 XQuery: parent-step into all > > 1491723 wrong position numbering in sequence after predicate and: 1410662 PF: tests tests/XQuery/Tests/typing[12].xq fail 1365379 PF: "stable order by" 1351516 PF: attribute after non-attribute content 1207048 XQuery: crashtest those that are "not (yet?) fixable" should be close with the proper comment/explanation. Stefan > > > > will try to compile pathfinder tomorrow and look into these issues. feel > > free to claim ony of these bugs.. > > > > I also identified the following closed bugs on the stable > > branch. They appeared to have been applied only to the HEAD, > > so I backported them to the Stable. This must still be checked: > > > > 1490847 problem with functions in xquery > > QUESTION TO JAN RITTINGER: was this really the small > > change mentioned in the bug report? I applied it. > > it's in the above patch list > > > 1454407 Mserver does not close XQuery sockets > > QUESTION TO NIELS NES: the patch in the bug report was ok? I applied it. > > > > this one I don't know what to do with: > > > > 1463558 wrong result when passing nodelist to function > > QUESTION TO JAN RITTINGER: what was the bug-fix here? > > it's in the above patch list > > > > > QUESTION TO WOUTER: I reported two problems with select-narrow. Can we roll > > forward pf_burk as it is now to the stable, and get those fixes as well as > > the rename? > > > > As the release date is near (I think Niels aims for less than two weeks), > > please treat this with urgency, or do not treat this at all.. > > > > best, > > > > Peter > > > > > > Two bugs that might pop up if we roll forward the MonetDB head (with > > batcache) to Stable pathfinder: > > > > 1499969 PF: tests/XQuery/Tests/typeswitch[34].xq: property errors > > 1499962 PF: XMark Q10: "HASHremove: Assertion `0' failed." > > > > > > > > -----Original Message----- > > From: Jan Rittinger [mailto:rittinge@in.tum.de] > > Sent: 07 June 2006 23:46 > > To: 'Peter Boncz'; wouter(a)holmes.nl; 'Torsten Grust'; 'Jens Teubner'; > > 'Jan Flokstra'; 'Maurice Van Keulen'; 'Wouter Alink' > > Cc: 'Sjoerd Mullender'; 'Stefan Manegold'; Niels.Nes(a)cwi.nl > > Subject: RE: pathfinder release: bugfixing opportunity > > > > > > I have no problem postponing the pf release. > > > > However I think that I (and also others) fixed quite a number of 'important' > > pathfinder bugs. In addition some small but very useful extensions sneaked > > into the code (e.g. we now support all kinds of typeswitches). It would be a > > pitty to ignore them in the coming release. > > > > Is it perhaps possible to include the compiler directory (with small > > adjustments to align it with pf runtime and MonetDB), but leave out changes > > of the runtime? > > > > Jan > > > > > -----Original Message----- > > > From: Peter Boncz [mailto:boncz@cwi.nl] > > > Sent: Wednesday, June 07, 2006 9:41 PM > > > To: wouter(a)holmes.nl; Torsten Grust; Jens Teubner; Jan > > > Rittinger; Jan Flokstra; Maurice Van Keulen; Wouter Alink > > > Cc: Sjoerd Mullender; Stefan Manegold; niels(a)cwi.nl > > > Subject: pathfinder release: bugfixing opportunity > > > > > > Hi, > > > > > > Today we had a MonetDB meeting about the release. We decided > > > to have a release now, but without Pathfinder. > > > > > > For the Pathfinder release with updates, multi-documents and > > > soap the realistic time-frame becomes *september* (well, > > > maybe maybe august), but there will be a feature freeze > > > around SIGMOD (june 25). We anticipate a long testing and > > > debugging stage. Sorry, but this is reality. No SIGMOD release. > > > > > > As MonetDB/SQL and the alpha Monet5 do not want to wait any > > > longer just to roll through the accumulated new features and > > > fixes, there is also an imminent release. As we release > > > always all components to keep compatability and the test web > > > easily manageble in a single Stable an single Current branch, > > > the new release will include the *stable* branch of pathfinder. > > > > > > There will be a (very) small porting effort to make > > > stable-pathfinder work on head-monet. However, one of the > > > tasks ahead for a pathfinder release anyway is bug-fixing. > > > Thus, we can take this opportunity to identify quick-win bugs > > > in pathfinder and release those. We can also look at the bugs > > > fixed in pathfinder in the past period, and ask ourselfves > > > whether rollling them through is useful and little work. > > > > > > I guess the freeze for the direct release is only within > > > days, and I recommend you all not to spend much time on it. > > > At least the new pathfinder will contain the BATuselect fix > > > in the serialization (admittedly not as fast as Jan R.'s > > > current implementation but still better than before). > > > > > > As the experiences with it have been positive, I propose this > > > time to build pathfinder with burkowski enabled. Thus we can > > > point the guy who wants windows with burkowski (and other > > > like him) to the new binary release. Note that the > > > functionality is by default still disabled; you need to set a > > > configuration switch to yes to turn it on. > > > > > > Peter > > > > > > -- | 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 3

Re: [Monetdb-developers] pathfinder release: bugfixing opportunity
by Wouter Alink (DT) 08 Jun '06

08 Jun '06

Forgot to answer my question: The problem with the stack that was too small has been fixed. The StandOff-joins now increase the stack-size whenever it grows out-of-bound. The StandOff-axes in the stable branch still have two bugs to fix that I know of: - sorting of the final result (with multiple iters, the result is not sorted at the moment). The current work-around is adding a self-step directly after the StandOff-step. - David Ahn mentioned another bug, when nesting 3 for-loops, each using the select-narrow-axis the output is garbage, but I don't know whether this bug is related to the sorting, or perhaps to another part of MonetDB/XQuery. Still have to figure this out. Greetings, Wouter >-----Original Message----- >From: Stefan Manegold [mailto:Stefan.Manegold@cwi.nl] >Sent: Thursday, June 08, 2006 9:42 AM >To: monetdb-developers(a)lists.sourceforge.net >Cc: Wouter Alink (DT); 'Jan Flokstra'; 'Maurice Van Keulen' >Subject: Re: pathfinder release: bugfixing opportunity > > >[Please use the MonetDB-developers mailing list > (monetdb-developers(a)lists.sourceforge.net) for this kind of >discussions, and make sure you're subscribed to it (with your >current email address). Thanks!] > > >I suggest to not checkin any changes to the XQuery_0-10 stable >branch of pathfinder, but to wait until we (Niels, Sjoerd, me) >create the new >XQuery_0-12 stable branch (together with the new MonetDB_4-12 >& SQL_2-12 release branches) early next week. >Of course, you're free and welcome to try to compile >pathfinder's stable branch (XQuery_0-10) with the current >MonetDB 4.11 development trunk to sort-out the problems and >start fixing them off-line. > >The short-term "feature-freeze" for the "intermediate release" >applied only to MonetDB & sql; as Peter explained, for >pathfinder we plan only porting of XQuery_0-10 to >comply/compile with MonetDB 4.11 as well as applying bugfixes >(including back-porting bug fixes from XQuery 0.11 as far as >necessary/possible). > > >On Thu, Jun 08, 2006 at 12:44:03AM +0200, Jan Rittinger wrote: >> > -----Original Message----- >> > Hi, >> > >> > I am not against including the compiler directory, but we must be >> > careful >> > with: >> > - milprint-summer, I think it can't be rolled forward (all those >> > tijah changes, and the update changes) >> > - update syntax in the parser (it should not be recognized yet) >> > - burkowski changes in the parser (may or may not be a >problem, see >> > below) >> > >> >> You are probably right that removing code probably is as >much work as >> finding the respective bug fixes. I just skipped through the commit >> mails of the last 4 months and looked up checkins that >mainly fix bugs. >> >> So here's a (probably incomplete) list: >> milprint_summer.c 182->183, 185->186, 191->192, 208->209, 209->210, >> 210->211, 217->218, 219->220, 220->221 >> shredder.mx 77->78, 81->82 >> pf_support.mx 126->127 >> subtyping.c 33->34 >> fs.brg 33->34 >> >> > >> > the rule is that if you feel like it and it takes little time, it >> > may be welcome. >> > >> > I identified the following open bugs op the stable branch: >> > >> > 1447195 PF: crash server with XMark >> > 1446426 fn:doc() call in nested element construction fails >> > 1339844 PF: A parent step into the void >> > 1459974 XQuery: parent-step into all >> > 1491723 wrong position numbering in sequence after predicate > >and: > >1410662 PF: tests tests/XQuery/Tests/typing[12].xq fail >1365379 PF: "stable order by" >1351516 PF: attribute after non-attribute content >1207048 XQuery: crashtest > >those that are "not (yet?) fixable" should be close with the >proper comment/explanation. > >Stefan > > >> > >> > will try to compile pathfinder tomorrow and look into >these issues. >> > feel free to claim ony of these bugs.. >> > >> > I also identified the following closed bugs on the stable branch. >> > They appeared to have been applied only to the HEAD, so I >backported >> > them to the Stable. This must still be checked: >> > >> > 1490847 problem with functions in xquery >> > QUESTION TO JAN RITTINGER: was this really the small change >> > mentioned in the bug report? I applied it. >> >> it's in the above patch list >> >> > 1454407 Mserver does not close XQuery sockets >> > QUESTION TO NIELS NES: the patch in the bug report >was ok? I applied it. >> > >> > this one I don't know what to do with: >> > >> > 1463558 wrong result when passing nodelist to function >> > QUESTION TO JAN RITTINGER: what was the bug-fix here? >> >> it's in the above patch list >> >> > >> > QUESTION TO WOUTER: I reported two problems with >select-narrow. Can >> > we roll forward pf_burk as it is now to the stable, and get those >> > fixes as well as the rename? >> > >> > As the release date is near (I think Niels aims for less than two >> > weeks), please treat this with urgency, or do not treat >this at all.. >> > >> > best, >> > >> > Peter >> > >> > >> > Two bugs that might pop up if we roll forward the MonetDB >head (with >> > batcache) to Stable pathfinder: >> > >> > 1499969 PF: tests/XQuery/Tests/typeswitch[34].xq: property errors >> > 1499962 PF: XMark Q10: "HASHremove: Assertion `0' failed." >> > >> > >> > >> > -----Original Message----- >> > From: Jan Rittinger [mailto:rittinge@in.tum.de] >> > Sent: 07 June 2006 23:46 >> > To: 'Peter Boncz'; wouter(a)holmes.nl; 'Torsten Grust'; 'Jens >> > Teubner'; 'Jan Flokstra'; 'Maurice Van Keulen'; 'Wouter Alink' >> > Cc: 'Sjoerd Mullender'; 'Stefan Manegold'; Niels.Nes(a)cwi.nl >> > Subject: RE: pathfinder release: bugfixing opportunity >> > >> > >> > I have no problem postponing the pf release. >> > >> > However I think that I (and also others) fixed quite a >number of 'important' >> > pathfinder bugs. In addition some small but very useful extensions >> > sneaked into the code (e.g. we now support all kinds of >> > typeswitches). It would be a pitty to ignore them in the >coming release. >> > >> > Is it perhaps possible to include the compiler directory >(with small >> > adjustments to align it with pf runtime and MonetDB), but >leave out >> > changes of the runtime? >> > >> > Jan >> > >> > > -----Original Message----- >> > > From: Peter Boncz [mailto:boncz@cwi.nl] >> > > Sent: Wednesday, June 07, 2006 9:41 PM >> > > To: wouter(a)holmes.nl; Torsten Grust; Jens Teubner; Jan >Rittinger; >> > > Jan Flokstra; Maurice Van Keulen; Wouter Alink >> > > Cc: Sjoerd Mullender; Stefan Manegold; niels(a)cwi.nl >> > > Subject: pathfinder release: bugfixing opportunity >> > > >> > > Hi, >> > > >> > > Today we had a MonetDB meeting about the release. We decided to >> > > have a release now, but without Pathfinder. >> > > >> > > For the Pathfinder release with updates, multi-documents >and soap >> > > the realistic time-frame becomes *september* (well, maybe maybe >> > > august), but there will be a feature freeze around SIGMOD (june >> > > 25). We anticipate a long testing and debugging stage. >Sorry, but >> > > this is reality. No SIGMOD release. >> > > >> > > As MonetDB/SQL and the alpha Monet5 do not want to wait >any longer >> > > just to roll through the accumulated new features and >fixes, there >> > > is also an imminent release. As we release always all components >> > > to keep compatability and the test web easily manageble in a >> > > single Stable an single Current branch, the new release will >> > > include the *stable* branch of pathfinder. >> > > >> > > There will be a (very) small porting effort to make >> > > stable-pathfinder work on head-monet. However, one of the tasks >> > > ahead for a pathfinder release anyway is bug-fixing. >> > > Thus, we can take this opportunity to identify quick-win bugs in >> > > pathfinder and release those. We can also look at the bugs fixed >> > > in pathfinder in the past period, and ask ourselfves whether >> > > rollling them through is useful and little work. >> > > >> > > I guess the freeze for the direct release is only within >days, and >> > > I recommend you all not to spend much time on it. >> > > At least the new pathfinder will contain the BATuselect >fix in the >> > > serialization (admittedly not as fast as Jan R.'s current >> > > implementation but still better than before). >> > > >> > > As the experiences with it have been positive, I propose >this time >> > > to build pathfinder with burkowski enabled. Thus we can >point the >> > > guy who wants windows with burkowski (and other like him) to the >> > > new binary release. Note that the functionality is by default >> > > still disabled; you need to set a configuration switch to yes to >> > > turn it on. >> > > >> > > Peter >> > > >> > > > >-- >| 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

[Monetdb-developers] pathfinder release: bugfixing opportunity
by Peter Boncz 07 Jun '06

07 Jun '06

LS, Today we had a MonetDB meeting about the release. We decided to have a release now, but without Pathfinder. For the Pathfinder release with updates, multi-documents and soap the realistic time-frame becomes *september* (well, maybe maybe august), but there will be a feature freeze around SIGMOD (june 25). We anticipate a long testing and debugging stage. Sorry, but this is reality. No SIGMOD release. As MonetDB/SQL and the alpha Monet5 do not want to wait any longer just to roll through the accumulated new features and fixes, there is also an imminent release. As we release always all components to keep compatability and the test web easily manageble in a single Stable an single Current branch, the new release will include the *stable* branch of pathfinder. There will be a (very) small porting effort to make stable-pathfinder work on head-monet. However, one of the tasks ahead for a pathfinder release anyway is bug-fixing. Thus, we can take this opportunity to identify quick-win bugs in pathfinder and release those. We can also look at the bugs fixed in pathfinder in the past period, and ask ourselfves whether rollling them through is useful and little work. I guess the freeze for the direct release is only within days, and I recommend you all not to spend much time on it. At least the new pathfinder will contain the BATuselect fix in the serialization (admittedly not as fast as Jan R.'s current implementation but still better than before). As the experiences with it have been positive, I propose this time to build pathfinder with burkowski enabled. Thus we can point the guy who wants windows with burkowski (and other like him) to the new binary release. Note that the functionality is by default still disabled; you need to set a configuration switch to yes to turn it on. Peter

1 0

[Monetdb-developers] MonetDB release meeting
by Niels Nes 07 Jun '06

07 Jun '06

MonetDB developers On wednessday morning (june 7) from 10:00 till 12:00 we will have another MonetDB meeting. Reason we missed our target freeze date and therefor will miss the release date of end of june. So we should reset those dates, assess the tasks at hand and possibly resuffle some of the work. Niels -- Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes(a)cwi.nl

8 15

[Monetdb-developers] feature freeze
by Peter Boncz 05 Jun '06

05 Jun '06

Niels, Feature freeze? One little problem: none of the XQuery targets is met (updates, soap, multi-document). So what do you (or you talk about "we") want to release? In my opinion - but correct me if I'm wrong - the goal of the release is the new XQuery version that brings updates. Thus I am against a feature freeze on monday. Creating the branch now will just create propagation overhead. It will take al least another 3 weeks until the basic features will be implemented, after that we have to go into a testing and packaging period still. Of course one should try to impose limits and milestones. Or even scrap goals if the milestones are never made. But in this case there is clear progress being made. Peter

2 1

[Monetdb-developers] monetdb feature freeze
by Niels Nes 02 Jun '06

02 Jun '06

MonetDB developers As you probably all know last thursday june 1 was the planned feature freeze date. Because of many reasons we didn't directly create the seperate cvs branches to really enforce the freeze. But we are serious, so we are about create these branches soon. Current planning is to create these on tuesday morning. Afcouse during the branch creation its better not to checkin changes. Therefor I hope everybody cleans up its checkout versions and checks in those changes which should end up in the to be released version before monday evening. The version of monday night (amsterdam time) marks, which features will be in the release. Niels Nes -- Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes(a)cwi.nl

1 0

[Monetdb-developers] Gebruik MonetDB, Python 2.3, WinXP
by drs Slinger Jansen 31 May '06

31 May '06

Hoi hoi, ik probeer al wat uurtjes Monet aan te spreken vanuit Python onder Windows XP, maar het lukt me niet erg. Ik heb de MSI gebruikt, en daarom mis ik de Mapi. Kan ik deze alsnog bouwen/installeren? En is dat uberhaupt wat ik wil? Ik ben ondertussen een pywin32 rijker. Ik wil Monetdb gebruiken vanuit een webservice met hoog volume verkeer (jaja, op een XP server, ik weet het). Kan ik eventueel even langs lopen? Slinger Jansen

2 1

[Monetdb-developers] compiler warnings
by Sjoerd Mullender 29 May '06

29 May '06

With the latest compiler on Fedora Core 5 I get these warnings when compiling mapi.java (see attached file warnings1.txt). And when compiling the jdbc tests I get the warnings in warnings2.txt. Finally, when compiling the jdbc examples I get the warnings in warnings3.txt. Should something be done about these? -- Sjoerd Mullender /usr/bin/ant -f /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/build.xml -Dbuilddir=/home/sjoerd/src/devel/MonetDB/Linux/src/mapi/clients/java -Djardir=/home/sjoerd/src/devel/MonetDB/Linux/src/mapi/clients/java jar_mapi Buildfile: /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/build.xml prepare: compile_mapi: [echo] Compiling Java Mapi [javac] Compiling 3 source files to /home/sjoerd/src/devel/MonetDB/Linux/src/mapi/clients/java [javac] ---------- [javac] 1. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 145) [javac] private int languageId= LANG_MAL; [javac] ^^^^^^^^^^ [javac] The field Mapi.languageId is never read locally [javac] ---------- [javac] ---------- [javac] 2. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 148) [javac] private boolean everything = false; [javac] ^^^^^^^^^^ [javac] The field Mapi.everything is never read locally [javac] ---------- [javac] ---------- [javac] 3. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 152) [javac] private boolean eos = false; [javac] ^^^ [javac] The field Mapi.eos is never read locally [javac] ---------- [javac] ---------- [javac] 4. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 169) [javac] private int minfields= 0; [javac] ^^^^^^^^^ [javac] The field Mapi.minfields is never read locally [javac] ---------- [javac] ---------- [javac] 5. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 188) [javac] private String hostname( String monetport ){ [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The method hostname(String) from the type Mapi is never used locally [javac] ---------- [javac] ---------- [javac] 6. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 194) [javac] private int portnr( String monetport ){ [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The method portnr(String) from the type Mapi is never used locally [javac] ---------- [javac] ---------- [javac] 7. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 588) [javac] private void storeBind(){ [javac] ^^^^^^^^^^^ [javac] The method storeBind() from the type Mapi is never used locally [javac] ---------- [javac] ---------- [javac] 8. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1007) [javac] String left,right; [javac] ^^^^ [javac] The local variable left is never read [javac] ---------- [javac] ---------- [javac] 9. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1007) [javac] String left,right; [javac] ^^^^^ [javac] The local variable right is never read [javac] ---------- [javac] ---------- [javac] 10. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1306) [javac] int i, sr=rownr; [javac] ^^ [javac] The local variable sr is never read [javac] ---------- [javac] ---------- [javac] 11. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1413) [javac] int n=0; [javac] ^ [javac] The local variable n is never read [javac] ---------- [javac] ---------- [javac] 12. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1414) [javac] int len= 0; [javac] ^^^ [javac] The local variable len is never read [javac] ---------- [javac] ---------- [javac] 13. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1415) [javac] String s=""; [javac] ^ [javac] The local variable s is never read [javac] ---------- [javac] ---------- [javac] 14. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1486) [javac] private void keepProp(String name, String colname){ [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The method keepProp(String, String) from the type Mapi is never used locally [javac] ---------- [javac] ---------- [javac] 15. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1509) [javac] String s= columns[i].columnname= fetchField(i); [javac] ^ [javac] The local variable s is never read [javac] ---------- [javac] ---------- [javac] 16. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1591) [javac] private int unquoteInternal(char msg[], int first) [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The method unquoteInternal(char[], int) from the type Mapi is never used locally [javac] ---------- [javac] ---------- [javac] 17. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1690) [javac] int size= msg.length(); [javac] ^^^^ [javac] The local variable size is never read [javac] ---------- [javac] ---------- [javac] 18. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1749) [javac] private void dumpLine(int i){ [javac] ^^^^^^^^^^^^^^^ [javac] The method dumpLine(int) from the type Mapi.RowCache is never used locally [javac] ---------- [javac] ---------- [javac] 19. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/Mapi.java [javac] (at line 1754) [javac] private void dumpCacheStatus(){ [javac] ^^^^^^^^^^^^^^^^^ [javac] The method dumpCacheStatus() from the type Mapi.RowCache is never used locally [javac] ---------- [javac] ---------- [javac] 20. WARNING in /home/sjoerd/src/devel/MonetDB/src/mapi/clients/java/mapi/MapiException.java [javac] (at line 28) [javac] class MapiException extends Exception { [javac] ^^^^^^^^^^^^^ [javac] The serializable class MapiException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] 20 problems (20 warnings) jar_mapi: [jar] Building jar: /home/sjoerd/src/devel/MonetDB/Linux/src/mapi/clients/java/mapi.jar BUILD SUCCESSFUL Total time: 7 seconds /usr/bin/ant -f /home/sjoerd/src/devel/sql/src/jdbc/tests/build.xml -Dbuilddir=/home/sjoerd/src/devel/sql/Linux/src/jdbc/tests -Djardir=/home/sjoerd/src/devel/sql/Linux/src/jdbc/tests compile Buildfile: /home/sjoerd/src/devel/sql/src/jdbc/tests/build.xml prepare: compile: [echo] Compiling JDBC tests [javac] Compiling 13 source files to /home/sjoerd/src/devel/sql/Linux/src/jdbc/tests [javac] ---------- [javac] 1. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/tests/Test_Csavepoints.java [javac] (at line 50) [javac] Savepoint sp1 = con.setSavepoint(); [javac] ^^^ [javac] The local variable sp1 is never read [javac] ---------- [javac] ---------- [javac] 2. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/tests/Test_PStypes.java [javac] (at line 27) [javac] ResultSet rs = null; [javac] ^^ [javac] The local variable rs is never read [javac] ---------- [javac] 2 problems (2 warnings) BUILD SUCCESSFUL Total time: 7 seconds /usr/bin/ant -f /home/sjoerd/src/devel/sql/src/jdbc/build.xml -Dbuilddir=/home/sjoerd/src/devel/sql/Linux/src/jdbc -Djardir=/home/sjoerd/src/devel/sql/Linux/src/jdbc jar_jdbcclient Buildfile: /home/sjoerd/src/devel/sql/src/jdbc/build.xml prepare: [mkdir] Created dir: /home/sjoerd/src/devel/sql/Linux/src/jdbc/example [echo] Debug is true, optimise is true driver: compile_jdbc: [echo] Compiling JDBC driver [javac] Compiling 11 source files to /home/sjoerd/src/devel/sql/Linux/src/jdbc [javac] ---------- [javac] 1. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetConnection.java [javac] (at line 59) [javac] private final int port; [javac] ^^^^ [javac] The field MonetConnection.port is never read locally [javac] ---------- [javac] ---------- [javac] 2. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetConnection.java [javac] (at line 1515) [javac] private final String getValue(char[] chrLine, int start, int stop) { [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The method getValue(char[], int, int) from the type MonetConnection.ResultSetResponse is never used locally [javac] ---------- [javac] ---------- [javac] 3. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetConnection.java [javac] (at line 2090) [javac] int lastState = linetype; [javac] ^^^^^^^^^ [javac] The local variable lastState is never read [javac] ---------- [javac] ---------- [javac] 4. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetConnection.java [javac] (at line 2175) [javac] int columncount = parseNumber(soh); [javac] ^^^^^^^^^^^ [javac] The local variable columncount is never read [javac] ---------- [javac] ---------- [javac] 5. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetDatabaseMetaData.java [javac] (at line 1402) [javac] private static String dq(String in) { [javac] ^^^^^^^^^^^^^ [javac] The method dq(String) from the type MonetDatabaseMetaData is never used locally [javac] ---------- [javac] ---------- [javac] 6. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetSavepoint.java [javac] (at line 139) [javac] private static synchronized int getHighestId() { [javac] ^^^^^^^^^^^^^^ [javac] The method getHighestId() from the type MonetSavepoint is never used locally [javac] ---------- [javac] ---------- [javac] 7. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetSocketBlockMode.java [javac] (at line 24) [javac] import java.util.*; [javac] ^^^^^^^^^ [javac] The import java.util is never used [javac] ---------- [javac] ---------- [javac] 8. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/util/MonetRedirectException.java [javac] (at line 23) [javac] public class MonetRedirectException extends Exception { [javac] ^^^^^^^^^^^^^^^^^^^^^^ [javac] The serializable class MonetRedirectException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] 8 problems (8 warnings) jar_jdbc: [jar] Building jar: /home/sjoerd/src/devel/sql/Linux/src/jdbc/monetdb-1.4-jdbc.jar compile_client: [echo] Compiling Clients [javac] Compiling 7 source files to /home/sjoerd/src/devel/sql/Linux/src/jdbc [javac] ---------- [javac] 1. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/client/util/Exporter.java [javac] (at line 23) [javac] import java.util.*; [javac] ^^^^^^^^^ [javac] The import java.util is never used [javac] ---------- [javac] ---------- [javac] 2. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/client/util/OptionsException.java [javac] (at line 21) [javac] public class OptionsException extends Exception { [javac] ^^^^^^^^^^^^^^^^ [javac] The serializable class OptionsException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 3. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/client/util/PasswordField.java [javac] (at line 43) [javac] int i; [javac] ^ [javac] The local variable i is never read [javac] ---------- [javac] ---------- [javac] 4. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetConnection.java [javac] (at line 59) [javac] private final int port; [javac] ^^^^ [javac] The field MonetConnection.port is never read locally [javac] ---------- [javac] ---------- [javac] 5. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetConnection.java [javac] (at line 1515) [javac] private final String getValue(char[] chrLine, int start, int stop) { [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [javac] The method getValue(char[], int, int) from the type MonetConnection.ResultSetResponse is never used locally [javac] ---------- [javac] ---------- [javac] 6. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetConnection.java [javac] (at line 2090) [javac] int lastState = linetype; [javac] ^^^^^^^^^ [javac] The local variable lastState is never read [javac] ---------- [javac] ---------- [javac] 7. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetConnection.java [javac] (at line 2175) [javac] int columncount = parseNumber(soh); [javac] ^^^^^^^^^^^ [javac] The local variable columncount is never read [javac] ---------- [javac] ---------- [javac] 8. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetSocketBlockMode.java [javac] (at line 24) [javac] import java.util.*; [javac] ^^^^^^^^^ [javac] The import java.util is never used [javac] ---------- [javac] ---------- [javac] 9. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/util/MonetRedirectException.java [javac] (at line 23) [javac] public class MonetRedirectException extends Exception { [javac] ^^^^^^^^^^^^^^^^^^^^^^ [javac] The serializable class MonetRedirectException does not declare a static final serialVersionUID field of type long [javac] ---------- [javac] ---------- [javac] 10. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetDatabaseMetaData.java [javac] (at line 1402) [javac] private static String dq(String in) { [javac] ^^^^^^^^^^^^^ [javac] The method dq(String) from the type MonetDatabaseMetaData is never used locally [javac] ---------- [javac] ---------- [javac] 11. WARNING in /home/sjoerd/src/devel/sql/src/jdbc/nl/cwi/monetdb/jdbc/MonetSavepoint.java [javac] (at line 139) [javac] private static synchronized int getHighestId() { [javac] ^^^^^^^^^^^^^^ [javac] The method getHighestId() from the type MonetSavepoint is never used locally [javac] ---------- [javac] 11 problems (11 warnings) jar_jdbcclient: [echo] Building JDBC + JdbcClient convenience jar [unjar] Expanding: /home/sjoerd/src/devel/sql/Linux/src/jdbc/monetdb-1.4-jdbc.jar into /home/sjoerd/src/devel/sql/Linux/src/jdbc [jar] Building jar: /home/sjoerd/src/devel/sql/Linux/src/jdbc/jdbcclient-1.4.jar BUILD SUCCESSFUL Total time: 16 seconds

2 1

[Monetdb-developers] a little unicode fix in MapiClient.py
by Max 23 May '06

23 May '06

Steps to reproduce problem: 1. MonetDB-4.10.2, Python 2.3.4, Gentoo Linux 2005.0, LANG=ru_RU.KOI8-R 2. Start monetdb mil server 3. Start MapiClient.py 4. Type following command: vars(); 5. Script fails with the following output: #MapiClient (python) connected to localhost:50000 as max > vars(); Traceback (most recent call last): File "/usr/bin/MapiClient.py", line 77, in ? main(sys.argv) File "/usr/bin/MapiClient.py", line 60, in main res = s.cmd(line) File "/usr/share/MonetDB/python/Mapi.py", line 116, in cmd return self.result() File "/usr/share/MonetDB/python/Mapi.py", line 67, in result while buffer[-len(self.prompt1):] != self.prompt1 and \ UnicodeDecodeError: 'ascii' codec can't decode byte 0x81 in position 0: ordinal not in range(128) Possible patch: --- MonetDB-4.10.2/src/mapi/clients/python/MapiClient.py.in 2006-01-20 23:36:49.000000000 +0700 +++ MonetDB-4.10.2/src/mapi/clients/python/MapiClient.py.in.fixed 2006-05-14 15:15:19.000000000 +0800 @@ -57,7 +57,7 @@ sys.stdout.write(s.prompt) line = fi.readline() while line and line != "quit;\n": - res = s.cmd(line) + res = s.cmd(line).encode('utf-8') print res sys.stdout.write(s.prompt.encode('utf-8')) line = fi.readline()

3 2

[Monetdb-developers] Mserver crash during data import
by Peter Roozemaal 20 May '06

20 May '06

During database import Mserver crashes on my Gentoo (64 bit) Linux Athlon64 machine. After the crash the Monet database is so corrupted that recovery fails. I have appended gdb output of the server session; additional information, input data and scripts are available upon request. Greetings, Peter. ===== gdb `which Mserver` GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run monetdb-startup.mil Starting program: /usr/bin/Mserver monetdb-startup.mil (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 21057)] !WARNING: GDKlockHome: created directory /var/lib/MonetDB/dbfarm/default/ !WARNING: GDKlockHome: ignoring empty or invalid .gdk_lock. !WARNING: BBPdir: initializing BBP. [New Thread 32769 (LWP 21060)] [New Thread 16386 (LWP 21061)] # Monet Database Server V4.10.2 # Copyright (c) 1993-2006, CWI. All rights reserved. # Compiled for x86_64-pc-linux-gnu/64bit with 64bit OIDs; dynamically linked. # Visit http://monetdb.cwi.nl/ for further information. [New Thread 32771 (LWP 21063)] [New Thread 49156 (LWP 21064)] [New Thread 65541 (LWP 21065)] [New Thread 81926 (LWP 21066)] [New Thread 98311 (LWP 21067)] [New Thread 114696 (LWP 21068)] [New Thread 131081 (LWP 21069)] [New Thread 147466 (LWP 21070)] [New Thread 163851 (LWP 21071)] [New Thread 180236 (LWP 21072)] [New Thread 196621 (LWP 21073)] [New Thread 213006 (LWP 21074)] [New Thread 229391 (LWP 21075)] [New Thread 245776 (LWP 21076)] [New Thread 262161 (LWP 21077)] [New Thread 278546 (LWP 21078)] [New Thread 294931 (LWP 21079)] [New Thread 311316 (LWP 21080)] [New Thread 327701 (LWP 21081)] [New Thread 344086 (LWP 21082)] [New Thread 360471 (LWP 21083)] [New Thread 376856 (LWP 21084)] [New Thread 393241 (LWP 21085)] [New Thread 409626 (LWP 21086)] [New Thread 426011 (LWP 21087)] [New Thread 442396 (LWP 21088)] [New Thread 458781 (LWP 21089)] [New Thread 475166 (LWP 21090)] [New Thread 491551 (LWP 21091)] [New Thread 507936 (LWP 21092)] [New Thread 524321 (LWP 21093)] [New Thread 540706 (LWP 21094)] [New Thread 557091 (LWP 21095)] [New Thread 573476 (LWP 21096)] [New Thread 589861 (LWP 21101)] [Thread 147466 (LWP 21070) exited] [New Thread 606218 (LWP 21117)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 426011 (LWP 21087)] 0x00002aaaab9aa2c8 in GDKreallocmax () from /usr/lib/libbat.so.0 (gdb) where #0 0x00002aaaab9aa2c8 in GDKreallocmax () from /usr/lib/libbat.so.0 #1 0x00002aaaab9530f3 in HEAPextend () from /usr/lib/libbat.so.0 #2 0x00002aaaab9e6989 in BATextend () from /usr/lib/libbat.so.0 #3 0x00002aaaab91c1b2 in BATappend () from /usr/lib/libbat.so.0 #4 0x00002aaaaafcfdbf in BATappend_wrap () from /usr/lib64/MonetDB/lib_bat.so.0 #5 0x00002aaaaafccf83 in BATappend_wrap_unpack1034987346 () from /usr/lib64/MonetDB/lib_bat.so.0 #6 0x00002aaaaabdc39b in interpret () from /usr/lib/libmonet.so.0 #7 0x00002aaaaabe47ef in interpret_seqblock () from /usr/lib/libmonet.so.0 #8 0x00002aaaaabdbcb1 in interpret () from /usr/lib/libmonet.so.0 #9 0x00002aaaaabdd071 in interpret () from /usr/lib/libmonet.so.0 #10 0x00002aaaaabe47ef in interpret_seqblock () from /usr/lib/libmonet.so.0 #11 0x00002aaaaabdbcb1 in interpret () from /usr/lib/libmonet.so.0 #12 0x00002aaaaabe47ef in interpret_seqblock () from /usr/lib/libmonet.so.0 #13 0x00002aaaaabdbcb1 in interpret () from /usr/lib/libmonet.so.0 #14 0x00002aaaaabdbb69 in interpret () from /usr/lib/libmonet.so.0 #15 0x00002aaaaabe47ef in interpret_seqblock () from /usr/lib/libmonet.so.0 #16 0x00002aaaaabdbcb1 in interpret () from /usr/lib/libmonet.so.0 #17 0x00002aaaaabe7a99 in handleRequest () from /usr/lib/libmonet.so.0 #18 0x00002aaaaabe80c9 in doRequest () from /usr/lib/libmonet.so.0 #19 0x00002aaaaac2593a in monetInterpreter () from /usr/lib/libmonet.so.0 #20 0x00002aaaac013c09 in pthread_start_thread () from /lib/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #21 0x00002aaaac013cb3 in pthread_start_thread_event () from /lib/libpthread.so.0 #22 0x00002aaaac5840a3 in clone () from /lib/libc.so.6 #23 0x0000000000000000 in ?? () (gdb) c Continuing. Program terminated with signal SIGKILL, Killed. The program no longer exists. (gdb) q

1 0

[Monetdb-developers] [noreply@sourceforge.net: [Bug 1490591] SSH host key change (new fingerprint)]
by Fabian Groffen 19 May '06

19 May '06

Hi all, FYI: ----- Forwarded message from "SourceForge.net" <noreply(a)sourceforge.net> ----- From: "SourceForge.net" <noreply(a)sourceforge.net> To: noreply(a)sourceforge.net Subject: [Bug 1490591] SSH host key change (new fingerprint) Date: Fri, 19 May 2006 00:47:32 -0700 url: https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1490591&group_… burley changed: What | Value ---------------+--------------------------------- AssignedTo | David Burley (burley) Status | Closed --- Comment from David Burley (burley) 2006-05-19 03:47 --- Greetings, Per the site status page: ( 2006-05-17 12:04:02 - Project CVS Service ) As of 2006-05-17 at 12:00 Pacific we synchronized the SSH keys on all of the CVS hosts. This will cause SSH key mismatch errors for most projects. Please reconfirm the new SSH key against site doc G04 (https://www.sourceforge.net/docs/G04) and then accept the new key, if it matches per normal procedure. We apologize for the inconvenience, but this should be a one-time event and make future CVS infrastructure changes more seamless. Thank you, David Burley Quality of Service Analyst, SourceForge.net ----- End forwarded message -----

1 0

[Monetdb-developers] semantics of aggregation operations
by S.Idreos＠cwi.nl 18 May '06

18 May '06

Hi all, I would like to open a discussion on the semantics of operations. I just noticed for example that the sum operation will return nil if one or more of the BUNs in the BAT is nil. That is probably not the semantics that someone would expect, i.e., I would like to see the actual result by ignoring the nils. Given the current semantics the code that SQL generates has to first remove nils (with a select operation) and then apply the sum operation on a BAT. That costs more time and also results in one more intermediate result. What about updating the sum implementation to ignore nils? How much would affect that the various projects on top of MonetDB? Regards, Stratos

4 3

[Monetdb-developers] multiplex string-add returns empty BAT
by Peter Roozemaal 18 May '06

18 May '06

I am using monetdb 4.10.2 on an AMD64 Gentoo Linux system (the Gentoo ebuild). I suspect there's a bug in the handling of the multiplex string-add: The following mil code: var xxx := "aap noot mies".split(" "); (xxx [+] xxx).print(); prints an empty BAT: #-----------------# # h t # name # void str # type #-----------------# where I expected: [ nil, "aapaap" ] [ nil, "nootnoot" ] [ nil, "miesmies" ] It looks like every invocation of the string [+] gives an empty result. Greetings, Peter Roozemaal.

3 3

[Monetdb-developers] New vs. Existing Update Syntax
by Jens Teubner 18 May '06

18 May '06

Hi MonetDB/XQuery folks, I'm in the midst of implementing the support for the "official" XQuery Update Facility syntax. So far it looks like the current code is pretty good in line with the W3C draft. The update operations in the draft are very similar to the update functions we currently have. A few questions, however, appeared when implementing the new syntax: -- It seems to me like we do not (yet) have a rename() function that only changes the tag name of a given element, attribute, or processing-instruction node. -- It is not clear to me how our current insert-...() functions handle attributes in the new node list. The W3C draft provides separate upd:insertAttributes ($element, $attlist) and upd:insertBefore ($element, $nodelist) functions (and similar). The translation from the surface syntax to the update operations then takes care of invoking the right functions. Unfortunately, this translation (the split-up of attributes and the rest in particular) is non-trivial in XQuery Core. So we could--in line with the current implementation of element construction--push this treatment of attributes into the back-end. Any comments on this? How does the current code deal with attributes in the arguments of insert-...()? So far for now, Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 XQuery processing at the speed of light: MonetDB/XQuery http://www.monetdb-xquery.org/ http://www.pathfinder-xquery.org/

2 3

[Monetdb-developers] MonetDB website problem
by Fabian Groffen 18 May '06

18 May '06

http://monetdb.cwi.nl/TechDocs/APIs/Mapi/C/index.html Could someone *PLEASE* fix this? kthx.

1 0

[Monetdb-developers] New serialization routine
by Jan Rittinger 16 May '06

16 May '06

In the current version serialization takes 10 seconds for a 10 MB file (http://www-db.in.tum.de/~rittinge/files/mixed.xml) which contains only slightly more nodes (517448) then the auction xml file of the same size (472681). The difference however is the number of attribute nodes which is much higher in mixed.xml (517447 vs. 38266). While the serialization of doc("auction10MB.xml") takes 2.72 seconds, doc("mixed.xml") requires 10.34 seconds!! Removing the attributes in mixed.xml (by deleting all entries from the attr_own bat) speeds up the serialization to complete in 4.6 seconds. Some more calculations reveal that for the auction file we are able to serialize 187 nodes/sec (nodes = elements+textnodes+attributes) while for mixed.xml the serialization function (with and without attributes) was only able to generate about 100 nodes/sec. In all 3 cases the serialization seems way to slow... (at least for me). As in principle the serialization is only a dump of the tables (even in table order) and other approaches are really faster we should be able to come up with an appropriate fast serialization routine. I see at least three possibilities to increase the performance: * serialize.mx uses about 50 function calls until one node without attributes is serialized * serialize.mx does collect the nodes using random access with a lot of indirections * serialize.mx uses stream_printf which is probably slower than a fixed size print routine like stream_write. In the following two weeks (before the feature freeze) I will try to come up with a new prototypical print routine that should handle the serialization more efficiently. This prototype will be a proof of concept and probably will fall back to current routine whenever some conditions are not fulfilled (e.g. wrong serialization type or multiple namespaces). Let's see wether we can get a faster serialization routine for the average query result! I will probably need help for some gdk internals, changes introduced by the update facility (e.g. indirections), and for understanding parts of the current serialize.mx. I hope for your support :-) More information on the new serialization routine will be available at the pathfinder wiki. Cheers, Jan -- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/

2 1

[Monetdb-developers] Bug in MonetDBv4.10.2
by Bart Scheers 11 May '06

11 May '06

Beste lezer, Ik gebruik monetdb v 4.10.2 met de bijbehorende jdbc driver. Na het creëren van een tabel met kolom van type 'double' kan ik via een PreparedStatement geen setDouble(d) aanroepen. Ik krijg de foutmelding: SQLException Message: wrong argument for prepared statement (expected double instead of decimal) en het is toch echt een double (te zien via SQL front end met \d). Als ik de DBMetaData ophaal (ik dacht slim te zijn door hiet het DATA_TYPE op te halen) krijg ik een error: SQLException: syntax error, unexpected IDENT in: "select "sqlname" as "TYPE_NAME", cast(case "sqlname" when 'timetz' then 92 when 'table' then 2003 when 'blob' then 2004 when 'bigint' then -5 when 'time' then 92 when 'varchar' then 12 when 'clob' then 2005 when 'int' then 4 when 'timestamptz' then 93 when 'date' then 91 when 'sec_interval' then -5 when 'boolean' then 16 when 'decimal' then 3 when 'double' then 8 when 'char' then 1 when 'month_interval' then 4 when 'oid' then 1111 when 'smallint' then 5 when 'timestamp' then 93 when 'real' then 7 else 1111 end as smallint) as "DATA_TYPE", "digits" as "PRECISION", cast(case when "systemname" = 'str' then cast('\' AS char) ELSE cast(NULL AS char) END) AS "LITERAL_PREFIX", cast(CASE WHEN "systemname" = 'str" Haakje of kwootje verkeerd? Al met al betekent het dat ik dan geen PreparedStatement kan uitvoeren, wat het wel sneller zou maken. Is dit bekend bij jullie? Groeten Bart Scheers

2 1

Re: Re: [Monetdb-developers] MapiClient connet problem
by Fabian Groffen 10 May '06

10 May '06

Hi, I seems that the mil support is not started by default. You can do this by typing on the server prompt: mapi_start(); After this command MapiClient should work. Beware that mil mode (the default) does not allow you to easily express XQuery queries; instead use the -lxquery flag. I don't know how this is done in the Windows version, but unfortunately MapiClient can't do an interactive session with xquery, so you have to give the file you want to execute as argument. If someone using Windows knows how this can be done the best way, please fill me in. Regards On 10-05-2006 18:34:35 +0800, zhangxin525 wrote: > Hi, > Thanks for your reply! > > First, sorry for my careless. I did not give you an exact copy of the error message. > The exact error message is : > > !ERROR mapi_reconnect: connect: error 10061 > MAPI = anonymous@localhost:50000 > ACTION= mapi_reconnect > ERROR = Setup connection failed > > > I start the MonetDB/XQuery server, the message of the server windows: > > # Monet Database Server V4.10.2 > # Copyright (c) 1993-2006, CWI. All rights reserved. > # Compiled for i386-pc-mingw32/32bit with 32bit OIDs; dynamically linked. > # Visit http://monetdb.cwi.nl/ for further information. > MonetDB> > > I think the server is correct. > Other, when I install MonetDB/XQuery, I chose the user for everynoe. > > Thanks for your patient help again. > > > > > zhangxin525 > 2006-05-10 > > > > 发件人： Fabian Groffen > 发送时间： 2006-05-10 16:40:59 > 收件人： zhangxin525 > 抄送： monetdb-developers > 主题： Re: [Monetdb-developers] MapiClient connet problem > > Hi, > > Thanks for your interest in MonetDB/XQuery. > > On 10-05-2006 16:08:26 +0800, zhangxin525 wrote: > > Hello! > > > > I install MonetDB/XQuery in WindowsXP, and I have start the XUery Server, but when I start MapiClient through command, always get the message: > > > > !ERROR mapi_reconnect: connect: > > MAPI = anonymous@localhost:5000 > > Is this an exact copy of the error message? In case it is, there is a 0 > missing here, the port should be 50000 not 5000. I think you can change > that somewhere in the .bat script that's called from the start menu. > > Maybe this is just a copy/paste error, so if this is not the problem, > can you copy and paste what's in the MonetDB/XQuery server window? > > Regards

1 0

[Monetdb-developers] MapiClient connet problem
by zhangxin525 10 May '06

10 May '06

Hello! I install MonetDB/XQuery in WindowsXP, and I have start the XUery Server, but when I start MapiClient through command, always get the message: !ERROR mapi_reconnect: connect: MAPI = anonymous@localhost:5000 ACTION= mapi_reconnect ERROR = Setup connection failed why? and how to solve it? Thank you very much! zhangxin525 2006-05-10

2 1

[Monetdb-developers] MapiClient connet problem
by zhangxin525 10 May '06

10 May '06

Hello! I install MonetDB/XQuery in WindowsXP, and I have start the XUery Server, but when I start MapiClient through command, always get the message: !ERROR mapi_reconnect: connect: error 10061 MAPI = anonymous@localhost:50000 ACTION= mapi_reconnect ERROR = Setup connection failed why? and how to solve it? Thank you very much! zhangxin525 2006-05-10

1 0

[Monetdb-developers] hashing algorithms usage in MonetDB/Five
by Fabian Groffen 29 Apr '06

29 Apr '06

Hi all, FYI Sourceforge isn't really cooperating, but I implemented MD5 and SHA1 hash algorithms support during challenge response in MAPI. I extended the JDBC driver to be able to use SHA1 or MD5 next to plain (crypt is not easily available in Java). I will check in my changes as soon as 1) SourceForge lets me, and 2) My physical state + location lets me I also added a little option to JdbcClient to force usage of a specified hash algorithm, using -Xhash. I conducted a little experiment to see the effect of connecting with a hash or plain. The results for my system is as follows: (I ran every call 10 times and took the average) % time java -jar jars/jdbcclient-1.4.jar -Xhash SHA1 < /dev/null real 0.29 % time java -jar jars/jdbcclient-1.4.jar -Xhash MD5 < /dev/null real 0.29 % time java -jar jars/jdbcclient-1.4.jar -Xhash plain < /dev/null real 0.23 The precision of time is seconds here, so the difference in time (or the cost of both hash implementations) is 0.06 seconds. This includes the time for the server to do the same of course. All in all, not really shocking IMHO. Please note that the JdbcClient does a lot of other stuff like querying the database for its version number and such. When not doing that the time will be probably lower. Also, the wallclock time does also include the full JVM startup. The C implementation of the hashes might be more efficient, I can only tell something useful about that once MapiClient will also support hash algorithms.

2 4

[Monetdb-developers] OpenSSL default detection
by Fabian Groffen 28 Apr '06

28 Apr '06

In conf/monet.m4 openssl detection is currently set to default to "no". Since I want to make use of the SHA1 and MD5 hashes from openssl and think that this should be enabled by default, I was wondering if there are objections agains setting "have_openssl=auto", such that auto-detection is done, and OpenSSL will be used whenever available. If I see no objections within a few days, I will assume it is ok to make this change to conf/monet.m4.

1 0

[Monetdb-developers] meeting notes
by Niels Nes 28 Apr '06

28 Apr '06

MonetDB developers Today another MonetDB Meeting was held at the CWI. In this meeting we decided to aim for another MonetDB{SQL/XQuery} release on June 25. To reach this goal we are going for a Feature freeze (ie the usual release candidates and release branch) on June 1. So if you have any (well tested) interesting features too add please commit them before June 1. The we are aiming for an Release with many new features. See http://monetdb.cwi.nl/Development/Roadmap/index.html for full details. Among these features are hopefully 'Xquery updates' and 'SQL triggers'. Before this MonetDB 4 release we are going for an alpha release via a 'tarball' of the MonetDB 5 development on May 05. This will be the first public release of the MonetDB 5 code base. Niels Nes

4 5

[Monetdb-developers] Re: AquaStudio en Windows versie
by Martin Kersten 28 Apr '06

28 Apr '06

Fabian wrote: > http://www.apple.com/downloads/macosx/development_tools/dbvisualizer.html > Ok, downloading requires your credentials to be left behind and some hints what to fill in where. Could you copy the doc/Assets/AquaDataStudio.texi file and enumerate the steps. Then I will try to re-do them following the documentation.

3 5

[Monetdb-developers] Re: m 5 documentation
by Martin Kersten 27 Apr '06

27 Apr '06

Niels, The documentation for M5 is self-contained. The overlapping pieces (e.g. HowToInstall's) are hand synchronized. The GDK and module layers are not touched. I will go through the Website and identify pieces to be shared. The latest draft versions are available at: http://www.cwi.nl/~mk/MonetDB http://www.cwi.nl/~mk/manual.pdf Comments on its structure and content are highly appreciated. Niels Nes wrote: > Martin > > Hoe gaan we de documentatie van M5 mergen met de MonetDB4,SQL,Xquery docs? > > Niels >

1 0

[Monetdb-developers] New logos
by Niels Nes 27 Apr '06

27 Apr '06

MonetDB developers Today the MonetDB website got its new logos. This of cause is just improves the way the site looks. So if you have improvements for the content we are pleased too add it. Niels Nes -- Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes(a)cwi.nl

4 4

[Monetdb-developers] MonetDB seems not to list FreeBSD as a supported platform
by jau＠iki.fi 17 Apr '06

17 Apr '06

Hello, As the subject says MonetDB web site does not list FreeBSD as a supported platform for MonetDB. Neither was I able to find MonetDB in the FreeBSD ports tree (/usr/ports/databases). Is there some portability issue which prevents that or is it only due to lack of time and/or resources? Cheers, // jau .--- ..- -.- -.- .- .- .-.-.- ..- -.- -.- --- -. . -. / Jukka A. Ukkonen, Oxit Ltd, Finland /__ M.Sc. (sw-eng & cs) (Phone) +358-500-606-671 / Internet: Jukka.Ukkonen(a)Oxit.Fi (Home) +358-9-6215-280 / Internet: jau(a)iki.fi v .--- .- ..- ...-.- .. -.- .. .-.-.- ..-. .. + + + + My opinions are mine and mine alone, not my employers. + + + +

4 5

[Monetdb-developers] Re: Monetdb-developers digest, Vol 1 #133 - 1 msg
by p.a.boncz＠chello.nl 06 Apr '06

06 Apr '06

No, if we can migrate the history.. > > van: monetdb-developers-request(a)lists.sourceforge.net > datum: 2006/04/06 do AM 05:29:55 CEST > aan: monetdb-developers(a)lists.sourceforge.net > onderwerp: Monetdb-developers digest, Vol 1 #133 - 1 msg > > Send Monetdb-developers mailing list submissions to > monetdb-developers(a)lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/monetdb-developers > or, via email, send a message with subject or body 'help' to > monetdb-developers-request(a)lists.sourceforge.net > > You can reach the person managing the list at > monetdb-developers-admin(a)lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Monetdb-developers digest..." > > > Today's Topics: > > 1. Re: cvs problems continue (Niels Nes) > > --__--__-- > > Message: 1 > Date: Wed, 5 Apr 2006 17:16:25 +0200 > From: Niels Nes <Niels.Nes(a)cwi.nl> > To: Niels Nes <Niels.Nes(a)cwi.nl>, monetdb-developers(a)lists.sourceforge.net > Subject: Re: [Monetdb-developers] cvs problems continue > > > MonetDB developers > > Seems switching to another 'sourceforge' like service isn't an option. > So we should try to get the best out of sourceforge. Reading their > remarks and some of the subversion documentation, it seems a good idea > to move to subversion. Does anybody have objections ? > > Niels > > > -- > > Niels Nes, Centre for Mathematics and Computer Science (CWI) > Kruislaan 413, 1098 SJ Amsterdam, The Netherlands > room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 > url: http://www.cwi.nl/~niels e-mail: Niels.Nes(a)cwi.nl > > > > --__--__-- > > _______________________________________________ > Monetdb-developers mailing list > Monetdb-developers(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-developers > > > End of Monetdb-developers Digest >

4 3

[Monetdb-developers] cvs problems continue
by Niels Nes 06 Apr '06

06 Apr '06

MonetDB developers Sourceforge cvs has serious problems (my guess is their raid system is broken and no spare is available). This (again) raises the question if sourceforge is the appropriate place for our cvs repository. Does anybody have better experiences with other sites like sourceforge? Niels Nes -- Niels Nes, Centre for Mathematics and Computer Science (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands room C0.02, phone ++31 20 592-4098, fax ++31 20 592-4312 url: http://www.cwi.nl/~niels e-mail: Niels.Nes(a)cwi.nl

3 4

Re: [Monetdb-developers] adding documents to Monetdb
by Swati Tata 16 Mar '06

16 Mar '06

Thank you everyone for your responses. I am working on a project on persistant storage of XML documents. Where I have simultaneously query multiple XML documents that are persistantly stored (but not cached) in a database like monetdb. I do all the querying using JDBC. I was wondering if there is any way that I can storage the XMLdocuments through my program rather than explicitly storing them using the shred_doc() before the execution of the program. Once again Thank you all. Swati -----Original Message----- From: Stefan Manegold <Stefan.Manegold(a)cwi.nl> To: Swati Tata <swtata(a)uky.edu>, monetdb-developers(a)lists.sourceforge.net Date: Thu, 16 Mar 2006 11:04:46 +0100 Subject: Re: [Monetdb-developers] adding documents to Monetdb Fabian, Jens, thanks you very much for providing Swati (and all other readers of this list) with the detailed information. Swati (and others), here's the "missing" bit: > o Upon each access to a cached document, MonetDB will try to figure out > if the document has changed since caching it. In particular, it > verifies file size and timestamp for documents in the local > filesystem. (I don't know, actually, what the caching system does > for documents from the network.) ======== # Monet Database Server V4.10.3 # Copyright (c) 1993-2006, CWI. All rights reserved. # Compiled for x86_64-redhat-linux-gnu/64bit with 64bit OIDs; dynamically linked. # Visit http://monetdb.cwi.nl/ for further information. MonetDB>module(pathfinder); MonetDB>sigs("pathfinder"); #---------------------------------------------------------# # signature # name # str # type #---------------------------------------------------------# [ "delete_all_docs(bit) : void" ] [ "delete_doc(str) : void" ] [ "pfstart(bit, lng) : void" ] [ "shred_doc(str, str) : void" ] [ "xmlcache_add_rule(str, any) : void" ] [ "xmlcache_del_rule(str) : void" ] [ "xmlcache_print() : void" ] [ "xmlcache_print_rules() : void" ] [ "xmldb_print() : void" ] [ "xquery(mode str, xquery str, is_url bit) : str " ] [ "xquery_server(Stream in, Stream out) : void " ] [ "xquery_start_query_cache(lng) : ptr" ] MonetDB>help("xmlcache_add_rule"); PROC: xmlcache_add_rule(str, lng) : void no text available PROC: xmlcache_add_rule(str, any) : void MODULE: pathfinder COMPILED: by boncz on May 2005 DESCRIPTION: add a new URI lifetime rule. The XML document cache keeps indexed copies of documents that where recently used in the fn:doc(URI) xquery function. The size of the cache is controlled using the 'xquery_cacheMB' setting in the 'MonetDB.conf' file. For file URIs, the cache looks at the last-modification-time of the file on disk to guarantee that the cached document is still up-to-date for answering queries from. For other URIs, *lifetime rules* determine how long documents can stay in the cache. Each lifetime rule consists of a URI prefix and the registered seconds of lifetime. The rule with longest prefix that matches an URI counts. Specifying a lifetime of 'int(nil)' seconds means that the URI will *not* be cached at all. This is also the default if no prefix matches an URI. The name of a cached document is the same as its location (URI). For explicitly shredded documents (with 'shred_doc(location,name)'), the name is an 'alias' and may differ from the URI. Explicitly shredded documents fall outside the XML document cache; documents are only removed at explicit user request (with 'delete_doc(name)'). MonetDB> ======== Cheers, 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 | --------------------------------------------- Swati Tata Research Assistant Advanced Genetic Technology Center (AGTC) University of Kentucky Room# 222 Plant Science Building, 1405 Veterans Drive Lexington, KY 40546-0312 Ph: (859)257-7445 x80740 Email: swtata(a)uky.edu

1 0

[Monetdb-developers] adding documents to Monetdb
by Swati Tata 16 Mar '06

16 Mar '06

Hello Everyone, Is it possible to load the XML documents to MonetDb using a java application? I have been using Shred_doc() from the command line to load the documents. Is there any other method using JDBC. Thank you, Swati --------------------------------------------- Swati Tata Research Assistant Advanced Genetic Technology Center (AGTC) University of Kentucky Room# 222 Plant Science Building, 1405 Veterans Drive Lexington, KY 40546-0312 Ph: (859)257-7445 x80740 Email: swtata(a)uky.edu

4 4

[Monetdb-developers] MonetDb Install Question
by joe baird 27 Feb '06

27 Feb '06

Hi - I'm stumped before even evaluating MonetDb for a forest growth and yield model validation. Where can libmutils be found. Thank you in advance for your help. Joe Baird

3 2

[Monetdb-developers] 沢井です
by information 09 Feb '06

09 Feb '06

$BFMA3$N%a!<%k$G?=$7Lu$4$6$$$^$;$s!#;d$O%;%l%V6f3ZIt$H$$$&A49qE83+$N#3#0Be0J>e$N4{:'<T$,=8$^$k!"%3%_%e%K%F%#$rE}3g$7$F$$$kBt0f9%H~$H?=$7$^$9!#4JC1$K@bL@$$$?$7$^$9$H!"?M:J$N=w@-$,0&?M$rC5$9%3%_%e%K%F%#$G$9!#$=$N$h$&$J4X78$K6=L#$N$"$kCK@-$O%3%A%i$^$G%"%/%;%9$7$F2<$5$$(B $B%3%A%i!!(Bhttp://awg.webchu.com/casanova/?1934$B!!$G%;%l(B $B%V6f3ZIt$H8!:w$7$F$b$i$($l$P=w@-$N4i<L??IU$-$N%W%m%U%#!<%k$HO"Mm@h$r8+$k;v$,$G$-$^$9!#$*BT$A$7$F$*$j$^$9!#(B ///////////////////////////////// $B%a!<%kITMW$NJ}$O$3$A$i$K%a!<%k$r"-(B concept3_net(a)yahoo.ca

1 0

[Monetdb-developers] SQL/JDBC: autocommit state
by Andrei Martsinchyk 30 Jan '06

30 Jan '06

Hi All, I have almost filed a bug, but noticed [ 1394298 ] SQL: auto commit state is not changed correctly on commit<https://sourceforge.net/tracker/index.php?func=detail&aid=1394298&group_id=…> so I decided to discuss the problem here first. My JDBC-based application stopped working with MonetDB 4.10.0/sql 2.10.0, while it works OK with Postgres backend and it used to work with MonetDB 4.9.3/sql 2.9.3. It output "commit does not allowed in autocommit mode" exceptions. However, I am sure that application handles transaction itself, that is setAutoCommit(false) is called immediately after connection is established and the connections are never return to autocommit mode. I investigated and found out that connection is switched to autocommit mode after commit() is called. I think server should not switch to autocommit mode after java.sql.Connection.commit() or java.sql.Connection.rollback(). Though this is not explicitly defined by JDBC specs, as far as I know all JDBC drivers work in this way, so it is standard de-facto. Therefore I suggest to revert the change. -- Best regards, Andrei Martsinchyk mailto:andrei.martsinchyk@gmail.com

2 1

[Monetdb-developers] ☆らぶともメール☆のご案内 -28
by info＠bananalove.info 27 Jan '06

27 Jan '06

$B:#(B10$BBe!A(B30$BBe$N=w@-$KBg?M5$$J$N$,!V$i$V$H$b%a!<%k!W$G$9!#(B $BK\5$$J=w$N;R$,B?$$$N$G!"??LLL\$J5$;}$A$G;22C$7$F$/$@$5$$!#(B $B:#$J$i!o(B5000$BJ,$N%]%$%s%H$,L5NA$G$9!#(B $B$40FFb@h"-(B http://bananalove.info/lvtm/ $BG[?.ITMW$NJ}$O%3%A%i$^$G(B refusal(a)ok.kz

1 0

[Monetdb-developers] Update and verify your information
by Scotiabank 26 Jan '06

26 Jan '06

1 0

[Monetdb-developers] SQL:2003 OLAP/windowing functions?
by Andrew Piskorski 25 Jan '06

25 Jan '06

Hello, I believe MonetDB/SQL does not currently support the SQL:2003 OLAP (aka, windowing) functions. Do you have any plans to add such support, or thoughts on how to do so? Coul this support be added via MIL, and if so how difficult do you think that would be? E.g., is it something that a dedicated end-user/devloper might plausibly attempt, or would it require deep knowledge of and hacking on the MonetDB core itself? These windowing functions were added as an amendement to the SQL:1999 spec, and SQL:2003 includes that, I think as features T611, "Elementrary OLAP functions" and T612, "Advanced OLAP functions". Apparently Fred Zemke of Oracle was the author of those SQL specs, and IBM also supported it, so the SQL:2003 syntax and behavior is probably identical to what Oracle and DB2 already have. PostgreSQL 8.0 doesn't yet support it, and I don't know if/when they plan to. Oracle calls this their "analytic" SQL functions, and has had it starting in 8i with improvements in 9i. I've used it extensively on Oracle, and although its syntax seems kind of klunky and non-intuitive, the functionality is EXTREMELY useful. Here are a bunch of links about the SQL OLAP/windowing functions: http://www.wintercorp.com/rwintercolumns/SQL_99snewolapfunctions.html http://www.ncb.ernet.in/education/modules/dbms/SQL99/OLAP-99-154r2.pdf http://www.wiscorp.com/sql/SQL2003Features.pdf http://troels.arvin.dk/db/rdbms/#select-limit-offset http://www.postgresql.org/docs/8.0/interactive/features.html http://en.wikipedia.org/wiki/SQL http://www.sigmod.org/sigmod/record/issues/0403/E.JimAndrew-standard.pdf http://www.oracle.com/oramag/oracle/01-jul/o41industry.html And here are a few more examples of using it. "lead" and "lag" are just the beginning, there is more. I find "dense_rank" particularly useful: http://www.mail-archive.com/sqlite-users@sqlite.org/msg08223.html http://www.mail-archive.com/sqlite-users@sqlite.org/msg10855.html -- Andrew Piskorski <atp(a)piskorski.com> http://www.piskorski.com/

2 1

[Monetdb-developers] FYI: only Fedore Core RPMs for upcoming MonetDB 4.10 release
by Stefan Manegold 22 Jan '06

22 Jan '06

Dear all, I just wanted to let you now that the only binary RPMs we will provide with the upcoming MonetDB 4.10 release will be made on Fedora Core 4 systems. On all other machines that we currently use with RPM-bases systems (SuSE, SLES & RHEL), too many tools are missing to build a full-fledged source distribution and/or all RPMs. We might consider having these machines upgraded *after* the initial release. 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

[Monetdb-developers] Feature Freeze!
by Stefan Manegold 21 Jan '06

21 Jan '06

Dear all, to ensure smooth processing in the final stages before we will release MonetDB 4.10 (hopefully on Monday), I now declare a Feature Freeze i.e., as of now, no more checkin sare allowed to *development trunks* of any the MonetDB related repositories on SF (buildtools, MonetDB, sql, pathfinder), unless they are bug fixes! I plan to fork-off the new release branches later tonight or tomorrow. I let you know, once I'm done with that. *Only then*, you may again check-in new features to the *development trunks*; *all* bugfixes must then go to the new release branches. Thanks you very much for your cooperation. Regards, Stefan ps: Your well come to take your share of the following tasks: 1) Take care of all open bugs and fix them: https://sourceforge.net/tracker/index.php?func=browse&group_id=56967&atid=4… 2) Re-check all bug reports that are set to "pending" and add proper test scripts for them: https://sourceforge.net/tracker/index.php?func=browse&group_id=56967&atid=4… If you do so, please let me know! Thanks in advance! -- | 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

Fwd: * Re: * [Monetdb-developers] MonetDB on FreeBSD?
by Arnoud Vermeer 20 Jan '06

20 Jan '06

Hi, I've included the full alarm.glue.c in the following url: http://www.freshway.biz/files/MonetDB-alarm.glue.c.txt I hope it helps. Thanks, Arnoud

3 9

Re: * [Monetdb-developers] MonetDB on FreeBSD?
by Stefan Manegold 20 Jan '06

20 Jan '06

> > > configure: WARNING: sys/file.h: present but cannot be compiled > > > configure: WARNING: sys/file.h: check for missing prerequisite > > headers? > > > configure: WARNING: sys/file.h: see the Autoconf documentation > > > configure: WARNING: sys/file.h: section "Present But Cannot Be > > Compiled" > > > > > > configure: WARNING: sys/file.h: proceeding with the preprocessor's > > result > > > configure: WARNING: sys/file.h: in the future, the compiler will take > > > precedence > > > configure: WARNING: ## ------------------------------------------ ## > > > > > configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## > > > configure: WARNING: ## ------------------------------------------ ## > > > > are these the only error messages you get from configure? > > yes, I've seen them before at other compiles to. Does compile most of the > time, inspite of the error. yes. I actually don't think that these are the reason for the errors you get. first was, that MonetDB requires GNU make instead of BSD make. That's solved. > The gmake fails: > standard ./configure (same output as in earlier posted version) > gmake > gmake.txt > gmake console output > gmake_console.txt > > Adding --enable-bits=64 to the ./configure doesn't change the output. > > http://www.freshway.biz/files/MonetDB-gmake.txt > http://www.freshway.biz/files/MonetDB-gmake_console.txt > > Any ideas? not really. I'm a bit scared by all the "overriding commands for target" messages, but the real problems seems to be this: ======= In file included from stream.mx:264: /usr/include/netinet/ip.h:49: error: syntax error before "u_int" /usr/include/netinet/ip.h:148: error: syntax error before "u_char" /usr/include/netinet/ip.h:200: error: syntax error before "u_char" stream.mx: In function ocket_open': stream.mx:1198: error: P_TOS' undeclared (first use in this function) stream.mx:1198: error: (Each undeclared identifier is reported only once stream.mx:1198: error: for each function it appears in.) gmake[4]: *** [libstream_la-stream.lo] Error 1 gmake[3]: *** [all] Error 2 gmake[2]: *** [all-recursive] Error 1 gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2 ======== I recall that there were some changes/fixes related to FreeBSD, which might not be in the release tarball ("MonetDB-4.8.2.tar.gz"). But we are about to release MonetDB 4.10 on Monday; hence, could you download the latest release candidate "MonetDB-4.9.3.tar.gz" from http://monetdb.cwi.nl/testing/projects/monetdb/Current/.DailyBuilds./Source… and check whether this works (better)? Stefan > Greetings, > > Arnoud Vermeer > FreshWay Innovations -- | 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 on FreeBSD?
by Stefan Manegold 19 Jan '06

19 Jan '06

Arnoud, which version of gcc are you using? `gcc --version` Stefan On Thu, Jan 19, 2006 at 10:57:58PM +0100, Arnoud Vermeer wrote: > Hi Stefan, > > In the new version, I've got a new error. The gmake command lasts longer > though, so I guess the previous problem was fixed in the newer version. > > This is the current error I get at a standard ./configure && gmake > > /bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. > -I../../.. -I. -I../../common -I../../gdk -I../../monet -DLIBALARM > -g -O2 -std=c99 -Wall -W -fno-strict-aliasing > -Werror-implicit-function-declaration -Werror -Wno-unused-function > -Wno-unused-label -D_REENTRANT -c -o lib_alarm_la-alarm.glue.lo `test -f ' > alarm.glue.c' || echo './'`alarm.glue.c > gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I. -I../../common -I../../gdk > -I../../monet -DLIBALARM -g -O2 -std=c99 -Wall -W -fno-strict-aliasing > -Werror-implicit-function-declaration -Werror -Wno-unused-function > -Wno-unused-label -D_REENTRANT -c alarm.glue.c -fPIC -DPIC -o > .libs/lib_alarm_la-alarm.glue.o > alarm.glue.c: In function `CMDctime_unpack559103634': > alarm.glue.c:185: warning: assignment discards qualifiers from pointer > target type > gmake[4]: *** [lib_alarm_la-alarm.glue.lo] Error 1 > gmake[4]: Leaving directory `/usr/home/funzoneq/MonetDB-4.9.3 > /src/modules/plain' > gmake[3]: *** [check] Error 2 > gmake[3]: Leaving directory `/usr/home/funzoneq/MonetDB-4.9.3 > /src/modules/plain' > gmake[2]: *** [check-recursive] Error 1 > gmake[2]: Leaving directory `/usr/home/funzoneq/MonetDB-4.9.3/src/modules' > gmake[1]: *** [check-recursive] Error 1 > gmake[1]: Leaving directory `/usr/home/funzoneq/MonetDB-4.9.3/src' > gmake: *** [check-recursive] Error 1 > > I also get a lot of overrides from rpm.mk, but that doesn't concern me that > much hence FreeBSD doesn't know rpm's. It seems the new error is located in > alarm.glue.c. > Although I have had a small bit of experience with C++ programming (first > year student Information Sciences at Windesheim College, Zwolle, The > Netherlands), I don't have a clue what the error means. > > Do you have any clue? > > Thanks, > > Arnoud Vermeer > > On 1/19/06, Stefan Manegold <Stefan.Manegold(a)cwi.nl> wrote: > > > > > > > configure: WARNING: sys/file.h: present but cannot be compiled > > > > > configure: WARNING: sys/file.h: check for missing prerequisite > > > > headers? > > > > > configure: WARNING: sys/file.h: see the Autoconf documentation > > > > > configure: WARNING: sys/file.h: section "Present But Cannot Be > > > > Compiled" > > > > > > > > > > configure: WARNING: sys/file.h: proceeding with the preprocessor's > > > > result > > > > > configure: WARNING: sys/file.h: in the future, the compiler will > > take > > > > > precedence > > > > > configure: WARNING: ## > > ------------------------------------------ ## > > > > > > > > > configure: WARNING: ## Report this to the AC_PACKAGE_NAME > > lists. ## > > > > > configure: WARNING: ## > > ------------------------------------------ ## > > > > > > > > are these the only error messages you get from configure? > > > > > > yes, I've seen them before at other compiles to. Does compile most of > > the > > > time, inspite of the error. > > > > yes. I actually don't think that these are the reason for the errors you > > get. > > > > first was, that MonetDB requires GNU make instead of BSD make. That's > > solved. > > > > > The gmake fails: > > > standard ./configure (same output as in earlier posted version) > > > gmake > gmake.txt > > > gmake console output > gmake_console.txt > > > > > > Adding --enable-bits=64 to the ./configure doesn't change the output. > > > > > > http://www.freshway.biz/files/MonetDB-gmake.txt > > > http://www.freshway.biz/files/MonetDB-gmake_console.txt > > > > > > Any ideas? > > > > not really. > > > > I'm a bit scared by all the "overriding commands for target" messages, but > > the real problems seems to be this: > > ======= > > In file included from stream.mx:264: > > /usr/include/netinet/ip.h:49: error: syntax error before "u_int" > > /usr/include/netinet/ip.h:148: error: syntax error before "u_char" > > /usr/include/netinet/ip.h:200: error: syntax error before "u_char" > > stream.mx: In function ocket_open': > > stream.mx:1198: error: P_TOS' undeclared (first use in this function) > > stream.mx:1198: error: (Each undeclared identifier is reported only once > > stream.mx:1198: error: for each function it appears in.) > > gmake[4]: *** [libstream_la-stream.lo] Error 1 > > gmake[3]: *** [all] Error 2 > > gmake[2]: *** [all-recursive] Error 1 > > gmake[1]: *** [all-recursive] Error 1 > > gmake: *** [all] Error 2 > > ======== > > > > I recall that there were some changes/fixes related to FreeBSD, which > > might > > not be in the release tarball ("MonetDB-4.8.2.tar.gz"). > > > > But we are about to release MonetDB 4.10 on Monday; > > hence, could you download the latest release candidate " > > MonetDB-4.9.3.tar.gz" > > from > > http://monetdb.cwi.nl/testing/projects/monetdb/Current/.DailyBuilds./Source… > > and check whether this works (better)? > > > > Stefan > > > > > Greetings, > > > > > > Arnoud Vermeer > > > FreshWay Innovations > > > > -- > > | 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 | > > -- | 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

[Monetdb-developers] MonetDB on FreeBSD?
by Arnoud Vermeer 19 Jan '06

19 Jan '06

Hello, I'm trying to compile MonetDB on FreeBSD 5.4. The machine is a dell single xeon EMT64 3.0 ghz with 2 gb of memory. The ./configure works just fine. I've included the output in configure.txt It does however put out the following text: configure: WARNING: sys/file.h: present but cannot be compiled configure: WARNING: sys/file.h: check for missing prerequisite headers? configure: WARNING: sys/file.h: see the Autoconf documentation configure: WARNING: sys/file.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/file.h: proceeding with the preprocessor's result configure: WARNING: sys/file.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------ ## configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## configure: WARNING: ## ------------------------------------------ ## When I try to run make, it returns the following error: "Makefile", line 981: Could not find ./*.mk "Makefile", line 982: Could not find ./*.mk make: fatal errors encountered -- cannot continue It is these two lines in the Makefile: include $(top_srcdir)/*.mk include $(top_builddir)/*.mk when I ls src/* I get no *.mk just: Makefile Makefile.am <http://makefile.am/> Makefile.msc gdk mel monet tools Makefile.ag <http://makefile.ag/> Makefile.in <http://makefile.in/> common mapi modules testing utils Includes: http://www.freshway.biz/files/MonetDB-configure.txt http://www.freshway.biz/files/MonetDB-makefile.txt Can anybody help me further along? Kind regards, Arnoud Vermeer FreshWay Innovations The Netherlands

3 4

Re: [Monetdb-developers] RFC: Upcoming release of MonetDB 4.10: Burkowski Code
by Stefan Manegold 19 Jan '06

19 Jan '06

On Tue, Jan 17, 2006 at 10:47:33PM +0100, Martin Kersten wrote: > > > Wouter Alink wrote: > >My opinion, for what it is worth... > > >I would like to ask to leave the code in, because it (probably) would not > >harm anybody, and I would be happy. > But are you planning to stick to the stable release then? or > do you switch to the development head directly? > Does your users work with that stuff from the release? > > I think that it can be removed from the release and stay > in the development branch. This would make you happy and > does not distract outsiders to use it too early. Exactly that was my proposal: leave the Burkowski code in the development runk, but keep it out of the release. Since the release will not be configure with `--enable-burk` (most; see * below) of the respective code will not be compiled and the features will not be usable with the (binary) release, anyway. Moreover, if I understand the comments of Jan & Jens (separate mail discussion between Wouter, Jens, Jan & me) correctly, the current burK implementation/integration does cause some significant(?) performance penalty in the burG generated code, which will harm the performance of XQuery translation significantly(?). Hence, unless Wouter has some clients that need to use the release with Burkowski features (i.e., self-compiled from the sources), I make a strong point to keep the Burkowski code out of the release --- the next release (then with Burkowski code) will (must ;-)) be ready within 2 months from now. (*) "Even" for the development trunk, I'd suggest to try an use the macro BURKOWSKI (and an AC_CONDITIONAL that we should add), that is/are set with the --enable-burk configure switch, to remove ALL Burkowski related code from the compilation; i.e., (if possible) also the declarative parts in compiler/algebra/core2alg.brg, compiler/core/coreopt.brg, compiler/core/simplify.brg, compiler/semantics/typecheck.brg, as well as the changes in compiler/parser/parser.y, compiler/parser/scanner.l, & runtime/pathfinder.mx. In fact, Jan & Jens suggest to even reduce the changes in (at least) compiler/algebra/core2alg.brg to a minimum. Maybe, Jan & Jens can help with the *.brg file (also optimizing the indices), I could help with runtime/pathfinder.mx, and the AC_CONDITIONAL to avoid compilation of pf_burk unless configure with --enable-burk. If we agree on keeping Burk out of the release, we have almost tow month to implement these improvements in the development trunk ;-) Kind Regards, Stefan ps: the release must be ready by Sunday Jan 22, 23:59:59, hence a quick reply is appreciated; sorry for the hurry, but "external constraints" forced us on short notice to finish the release a few days earlier than planned ... -- | 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 2

[Monetdb-developers] RFC: Upcoming release of MonetDB 4.10
by Stefan Manegold 17 Jan '06

17 Jan '06

Dear Developers, Enclosed you find the draft cover letter for the upcoming MonetDB release. Please provide any comments that from your perspective are relevant to mention. In preparing the distribution content we have finally decided not to include anything of the Xupdate functionality, SOAP, or other XML modules. The primary reason is that implementation and validation of these components have not reached a point were we are confident of their stability. These issues will be moved forward to the next release planned for March 2006 when the system will be presented at EDBT. Nevertheless, we can be proud of the progress made. Especially interaction with the server using a large number of small SQL update queries has been boosted to the point where we are in the same arena as MySQL and PostgreSQL using JDBC connectivity. The code freeze date is Friday, Jan 13 2006. We plan to release MonetDB v4.10 on Tuesday, Jan 24 2006. Regards, The MonetDB Development Team ------------------- Cover release 4.10 ---------- The MonetDB release 4.10 marks the end of a period where much attention was given to improving the performance of simple SQL applications. These improvements came from careful analysis of student programs and participating in the "c't" Magazine's database contest featuring the DVDstore benchmark. It led to re-consideration of MAPI -- the communication protocol -- aiming for less overhead and complex structures to be parsed. To facilitate this, JDBC has been largely be rewritten at core level to streamline the communication flow even more. Not only JDBC has benefited from the changes made, all MAPI driven communication has been sped up. A second Perl library has been prepared, which more directly uses the MAPI library. It has been registered at the official Perl archive for distribution (ICAN). ODBC has been upgraded to support server side prepared statements like JDBC. More meta-data is now available for columns in JDBC. MonetDB/SQL has been extended with SQL:03's sequences support. This allows for identity columns, serials (PostgreSQL) or auto_increments (MySQL) in MonetDB. A complete rewrite of the catalog and transaction handling removed the overhead encountered in small interactions. The SQL transaction scheme is based on three BATs (stable,inserts,deletes) which are merged at the end of a transaction. MonetDB/XQuery performance has been boosted using query/result caching and a rewrite of the code to manage the internal representation of MIL programs. Further, MonetDB/XQuery no also supports XQuery module definitions. XQuery is currently actively used in large scale applications and is stable. The MonetDB software base has been split to ease source distribution. The tools to prepare the source compilation (Mx), source code generators (MEL, Burg) and makefile generators (autogen) are assembled in the buildtools package. They are not needed to recompile source code distributed. ! TODO: ! Actually make the latter work. ! For now also the source distributions (still) require the buildtools package. In the kernel area we have added the 'constant' module. It provides functions to work with BATs whose tail consist of a constant value. During this period we have solved numerous bugs reported by our users. In addition we organized 3 bug testing days to encapsulate the problems reported into scripts that became part of our nightly testing scheme. Several smaller performance improvements have been made to the inner core of the server. One semantic error has been the cause of confusion. Bats with signature [void,void] are now allowed. A final clean-up of the respective semantic is currently being implemented; a detailed description of the changes will follow soon. Lack of manpower, expiring access to external machines, ceasing system maintenance and decrepit hardware forced us to stop nightly testing on IBM AIX, SGI IRIX and Sun Solaris. Thus, all active support for these (aging) platforms had to be suspended, too, but could easily be revived on request, once we (re-)gain access to such systems. Higher on our wishlist are more modern systems, especially 64-bit Windows and 64-bit Mac OS X. We welcome any donation in this area: access to respective systems, hardware, and/or (especially in case of the pending 64-bit Windows port of MonetDB) development-expertise and -time. The next release of MonetDB version 4 is scheduled for March 2006. By that time we also plan to release the alpha version of the next generation of MonetDB, version 5. Regards, The MonetDB Development Team -- | 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 |

5 12

[Monetdb-developers] CVS sql tree
by Fabian Groffen 23 Dec '05

23 Dec '05

Hi all, Unfortunately I seem to have broken SF's CVS system somehow. I tried to approve a test, but got in a 'hang' situation, which I killed after an hour of waiting. This didn't release some lockfile on the server, hence: | cvs diff: [17:27:03] waiting for mr-meltdown's lock in | /cvsroot/monetdb/sql/src/test/BugTracker/Tests Regardless how long I wait, it keeps spitting out this message. I made sure no connections are open with the SourceForge CVS server from my side (e.g. ps ax | grep sf.net) so I guess somehow I managed to melt down the system there causing a stale lockfile. If anyone knows how to resolve it, please speak up or fix it. I'm affraid one of the regular SF downtimes will not solve this stale lock thing.

2 3

[Monetdb-developers] what should happen when appending to a nil bat?
by Sjoerd Mullender 21 Dec '05

21 Dec '05

Consider this scenario: mil>var a := new(oid,void).insert(0@0,nil); mil>a.print(); #-----------------# # h t # name # oid void # type #-----------------# [ 0@0, nil ] mil>var b := new(oid,oid).insert(0@0,1@0); mil>b.print(); #-----------------# # h t # name # oid oid # type #-----------------# [ 0@0, 1@0 ] mil>a.append(b); mil>a.print(); The question is, what should the result be? As I see it, there are two possibilities: #-----------------# # h t # name # oid void # type #-----------------# [ 0@0, nil ] [ 1@0, nil ] or #-----------------# # h t # name # oid oid # type #-----------------# [ 0@0, nil ] [ 1@0, 1@0 ] The former keeps the nil tail (the tail of a was void without seqbase and stays that way), whereas the latter materializes the tail so that the tail value of b gets inserted. Opinions? -- Sjoerd Mullender

6 7

[Monetdb-developers] 2nd MonetDB-Bug-Day: Wed, Nov 9 2005 (next week)
by Stefan Manegold 20 Dec '05

20 Dec '05

(some of you might already have see this one coming; cf. http://www.cwi.nl/htbin/cwwwi/agenda?datum=2005_11+dag=09 ;-)) Dear all, given the success of the 1st MonetDB-Bug-Day on Oct 06 2005, 8 participants managed to check 347 of the then 721 bug reports, added 97 new test scripts, re-opened some bugs that still/again fail and filed 9 new bug reports; see https://sourceforge.net/mailarchive/forum.php?thread_id=8403629&forum_id=39… for details, there will by a 2nd MonetDB-Bug-Day to (hopefully) check the remaining 347 bug reports (plus those filed since Oct 06 2005), and produce proper test scripts for our automatic Nightly Multi-Platform Regression Test System (aka "TestWeb"; cf. http://monetdb.cwi.nl/Development/TestWeb/) When: Wednesday, Nov 9, 2005, "all day" (or as much time as you can spent) Where: Mainly at CWI, but you're also welcome to join "virtually" working from home or any other place in the world; for those who (again) want to turn the Bug-Day into a Bug-"Party", I reserved our meeting room (C0,01) from 8:00 - 23:00 --- you need to bring your own "equipment" though ... Who: Primarily everyone who is in touch with MonetDB, and/or one of its companions/front ends (SQL, XQuery, etc.), has rights to check-in to the MonetDB CVS repository on SourceForge, and is reasonably familiar with "Mtest.py" (cf. http://monetdb.cwi.nl/monet/src/testing/README) What: I will prepare a list of all bugs that have no test script, yet, and chop this in chunks, and assign each chunk to one participant so that [s]he can check them, and prepare the respective test scripts. More detailed instructions can be found at https://sourceforge.net/mailarchive/forum.php?thread_id=8403629&forum_id=39… and/or will follow before next Wednesday. Note: Though any help is appreciated, no one is "obliged" to help. Especially, there is no need to spent the whole day (though nine will complain if you do ;-)), anyone can join-in and leave whenever [s]he wants. For those of you participating at CWI, there will be free snacks and soft-drinks during the day (for the time you're "active"; as long as supplies lasts). Furthermore, there will be "real" drinks at the end of the Bug-Day (for participants, only; as long as supplies lasts; (maximum) amount per person will be proportional to the number of test scripts added). I hope to see especially (though not only) participants that I haven't seen on the 1st MonetDB-Bug-Day ;-) Once again thank you very much for your cooperation! CU next Wednesday, Stefan ps: Testing & the TestWeb are not (only?) my "toys"; it's "serious business", and helps all of you to (1) get a stable and reliable MonetDB, (2) monitor when your own bug reports get fixed, and (3) prevent the bugs you once thankfully detected, reported and/or fixed from occurring again! -- | 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 |

8 53

[Monetdb-developers] MONET-PHP
by Goker Burak Cetin 19 Dec '05

19 Dec '05

Dear All, I am planning to use monetdb for my thesis. But I have a problem with PHP module. I'll be glad if somebody supply me a solution. I'm using gentoo... And compiling monetdb on that distribution produces debug version of PHP module. Because my PHP compiled with "no-debug" ... those two do not want to work together :) I even changed ebuild script and added "--no-debug" string. But could't be able to get no-debug version of PHP mapi client module. And I couldn't find anywhere that make.standalone script that told in README file.. Would anybody advise please ... Thanks in Advance. And Regards. -- -------------------------------------------------------- Goker Burak Cetin System Administration Istanbul Technical University Center for Satellite Communications & Remote Sensing 34469 Maslak Istanbul TURKEY TEL: +90 212 285 68 13 FAX: +90 212 285 71 67 http://www.cscrs.itu.edu.tr/goker goker(a)cscrs.itu.edu.tr --------------------------------------------------------

2 1

[Monetdb-developers] JDBC/MonetDB performance test
by Fabian Groffen 18 Dec '05

18 Dec '05

Inspired by a student's preliminary test program, I conducted a -- at first quite innocent -- experiment to see how 'fast' MonetDB is and it's upcoming major release; MonetDB/Five. The conducted experiment mainly consists of inserting 8000, 19200 and 152800 tuples into three tables respectively. There are no constraints in use, as such it is quite 'dumb', but aggressive inserting. This inserting of values was done in three different ways: 1) using plain INSERT INTO statements (DBTestI) 2) using INSERT INTO statements batched by the JDBC driver (DBTest) [1] 3) using PreparedStatements to insert the date (DBTestP) I timed the wall-clock times of PostgreSQL 8.0.3 (PG8), MySQL 4.0.25 with InnoDB (My4), MonetDB 4.8.2 (M4) and todays CVS version of MonetDB/Five (M5). The JDBC drivers used for PostgreSQL and MySQL were the latest stable versions available, for MonetDB the released version and a progressive/experimental version were tested. This is marked with an 's' for the stable released version and 'p' for the progressive version. The databases run on a Dual Athlon MP 1600+ with 1GB of main-memory running Gentoo Linux with a 2.6.12 kernel (pegatoo). Two series of tests were performed; a local and remote version. In the local variant both the client application (with JDBC driver) and database server run on the same machine (as mentioned before). In the remote variant the client is on a different machine that is hardware wise equal to the machine that runs the database (crux). Both machines are directly connected to each other. The results follow in the table below: PG8 My4 M4s M4p M5s M5p JDBC local - DBTestI 37s 27s 90s 86s 62s 60s - DBTest 19s 27s 60s 59s 46s 46s - DBTestP 14s 27s 63s 64s 59s 60s JDBC remote - DBTestI 49s 37s 84s 85s 62s 62s - DBTest 19s 37s 57s 58s 43s 43s - DBTestP 14s 37s 66s 62s 53s 53s JDBC remote [2] - DBTestI 197s 168s >1201s >1545s - DBTest 67s 168s 76s 77s 61s 63s - DBTestP 68s 168s 75s 77s 66s 70s The results are somewhat 'confusing'. [1] Note: the program was not called DBTestB because it was submitted by the students under this name. [2] To simulate a slow link, we used an ssh tunnel to the database server as connection link, instead of a direct connection

2 4

[Monetdb-developers] JDBC liberation: use ant instead of make
by Fabian Groffen 12 Dec '05

12 Dec '05

Hi list, Tonight's testweb reveals that not a single JDBC test has run, due to incorrect packaging of the driver. I have always disliked the was the driver was built and packaged, but I think this time again, it is proven that `make` is too ancient for Java, or at least too clumpsy to deal with it. This is not only my personal opinion. That is, long ago other people already found out that make doesn't work that well with Java environments[1]. Although I understand the need to keep it 'simple'[2], I personally feel that fixing the current setup again to make it work is just another hack. From the very start of JDBC development, I used `ant`[1] to build the driver. Ant is, unlike make, a build tool geared towards Java projects, and the ant build scripts[3] that are currently in CVS have a much better understanding of the various files than make does. Just to name a few: - ant has multiple build targets for JDBC, XML:DB, MCL, etc. - ant date stamps each build - ant generates documentation when required - ant understands Java - ant builds jar files much more flexible. I am strongly in favour of using ant in the future to build Java related files. That is, let configure detect if ant is available or not, when Java is available. If not, don't build, or complain. I think most of our test platforms (especially since Sun and IRIX are RIP) have ant available (even Darwin has it!), as such availability of the build tools shouldn't be an issue. On a side note, testing Java on many platforms isn't that interesting, since the JVM itself has been tested on all platforms Sun supports. For JDBC, currently only endianness, timezone and charset are important. Since Darwin is both different-endian as well as in another timezone and using another charset by default, it is the only machine that really is interesting from a testing perspective, next to a windows machine and a linux machine in our neigbourhood. [1] http://ant.apache.org/ [2] that is, using tools known to those who deal with it [3] ant's build scripts are XML files called build.xml

2 2

[Monetdb-developers] RFC: New Integer Atoms: byte & word
by Stefan Manegold 08 Dec '05

08 Dec '05

Dear MonetDB developers, I'm almost done with the first steps of adding two new integer atoms to MonetDB: a) a tiny (8-bit) integer. b) a machine-word sized integer that grows with the system, i.e., 32-bit on 32-bit systems and 64-bit on 64-bit systems. (a) is supposed to replace "chr" wherever "chr" is not used as a character type, but as a (tiny) 1-byte integer. (b) is supposed to be the MIL pendant of the C type "var_t" and can/should be used, e.g., for BUN counts of BATs which are limited to 32-bit on 32-bit systems, but can grow to 64-bit on 64-bit systems. For now, I chose the following names, sticking to the 3-letter "design", and picking combinations that do not yet exist in the code base: a) "bte" (read "byte") b) "wrd" (read "word") In a first checking (hopefully sometime next week), I will only add these new atoms (and add the proper functionality & new signatures where necessary), but not change any existing MIL proc/command signatures. In a second check-in (maybe also already next week?), I plan to change (at least) the signature(s) of "count(BAT[any,any]) : int" & "count(int) : lng" to a single "count(BAT[any,any]) : wrd". Maybe, I/we should later also consider to replace "chr" by "bte" in the enum module. Well, so far so good. I would be grateful, if you could comment on these plans. Especially, I'd like to hear, whether there are better(?) suggestions for the names "bte" & "wrd". Further, did I miss any places, where we should/must use "bte" iso. "chr" and/or "wrd" iso. "int"/"lng"? Thank you very much in advance! 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 |

7 8

[Monetdb-developers] DgF LS- L 0 LITA NOW is out !!! with 4 in1 q5Y
by Best Offer 08 Dec '05

08 Dec '05

Hello Monetdb-developers, At this time we can offer a small update at our system - LS-L0 LITA and LITTLE CUTIES! Studio and our little stars are proud to present their new project. You can now compare this one with our other sites, judge the level of professionalism and exposure of subject, with have never been so high! Starign from over 4,000 HQ pics, the project features sets made in the studio, as well as on the side of nature. http://carsick.offer4in1.com/6/?lining Our great and unique offer: for each subscribtion You get access to another three sites from our portal for 31 days... without any additional payments! Simply subscribe, select and use! MSGID: 0AzYTtO3nHUzOQMaccabeusRvnmvY6El7MHuH

1 0

[Monetdb-developers] Re: PFTIJAH CVS branch for Pathfinder
by Stefan Manegold 06 Dec '05

06 Dec '05

Jan, Henning, according to the TestWeb, there seem to be quite some compilation problems with the lastest version of Pathfinder; hence, CVS HEAD version of Friday Dec 02 2005 (now tagged as "XQuery_TIJAH_root") to create a branch called "XQuery_TIJAH". Please let me/us know, in case there are any problems and/or once you want/need to start propagating changes from the main trunk to the XQuery_TIJAH branch. Also let me/us know, one you want/need to start automatic nightly testing of the XQuery_TIJAH branch. Regards, Stefan ps: I cc´ed the MonetDB-developers list, since more people (i.e., those maintaining and/or developing for any module in the MonetDB CVS repository on SF) might be interested in what's going on with the Pathfinder CVS repository; and monetdb-developers(a)lists.sourceforge.net is the proper communication channel that should be used more actively... On Tue, Dec 06, 2005 at 11:59:57AM +0100, Jan Flokstra wrote: > Hi Stefan, > > Thanks for your response. Our answers to your questions are: > > (1) We could have a branch from the current HEAD. It looks this works properly > at this moment. And we would indeed like it A.S.A.P. beacause Jan is goiing > to Mauritania for 3 weeks december 17th and he would like to have the > software ready for Hennig to experiment. > > (2) We are not planning to propagate from the pftijah branch to the main > branch. I think we could use the existing scripts to propagate the changes > from the main branch to the pftijah branch. The only real overlap are a > couple of command declarations in "pathfinder.mx", all other stuff will be in > new .mx files. In the end we would like to change the serialization.mx stuff > because this will be used extensively. But we can change it in the main trunk > and propagate it to 'pftijah' > > (3) Jan F? We could create the branch and worry about the other stuff when he > returns 10 januari! > > Regards, Jan & Hennig. > > > On Tuesday 06 December 2005 11:15, Stefan Manegold wrote: > > Hi Jan, Hi Henning, > > > > first of all, sorry for the late reply --- I had been quite busy recently > > --- only now (on short holidays in Germany ;-)) I found some time to write > > a proper reply ... > > > > Well, in principle creating a branch for 'pftijah' is no problem at all. > > However, given the experiences I/we have with especially the update branch, > > we should make very clear, (1) when/of which version of the main trunk the > > branch is created, (2) how/when to propagate changes from the main trunk to > > the pftijah branch (preferably not from the pftijah branch to the main > > trunk, i.e. ALL BUG fixes that also apply to the main trunk MUST be checked > > in to the main branch (as well)), and (3) who is responsible for > > maintaining the pftijah branch, propagating changes/bug-fixes from the main > > trunk to the pftijah branch and testing(!) the pftijah branch. > > > > About (1): > > I guess, you prefer ASAP, hence waiting for the release that we plan for > > end of January is no option, right? > > This in turn means that all changes of the update branch, which will be > > merged into the main trunk before the release (I guess just after new > > year), then also have to be merged into the pftijah branch... > > > > About (2) & (3): > > Well, I have some experiences and script for the propagation which I'm more > > than willing to share with who ever becomes the maintainer of the pftijah > > branch --- surely not me ;-) > > > > Let me know, what you think about this ... > > > > Greetings from --- well, doesn't matter ;-) > > > > Stefan > > > > On Fri, Dec 02, 2005 at 09:03:27AM +0100, Jan Flokstra wrote: > > > Hi Stefan, > > > > > > I'm going to start working on the possible integration of Tijah and > > > Pathfinder. The idea at this moment is to create a Tijah index on > > > Pathfinder documents. Then we will implement a nexi() function in > > > Pathfinder which will do the query on this Tijah index and will return > > > Pathfinder nodes which can be processed by Pathfinder. > > > I tried to set up a separate module for this called 'pftijah' but this > > > failed beacause at this moment I need to be very close to Pathfinder. > > > There will be quite a lot of people on this problem so we need a CVS > > > repository. So we would like to have a special Pathfinder branch called > > > 'PFTIJAH' from where we could do our experiments and distribute them. > > > This branch could be a branch from the current HEAD or from an older > > > stable version, whatever you consider the best solution. > > > Is it possible that you or somebody else creates such a branch for us??? > > > > > > Regards, Jan Flokstra & Hennig Rode. > -- | 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

[Monetdb-developers] Re: PFTIJAH CVS branch for Pathfinder
by Stefan Manegold 06 Dec '05

06 Dec '05

Hi Jan, Hi Henning, first of all, sorry for the late reply --- I had been quite busy recently --- only now (on short holidays in Germany ;-)) I found some time to write a proper reply ... Well, in principle creating a branch for 'pftijah' is no problem at all. However, given the experiences I/we have with especially the update branch, we should make very clear, (1) when/of which version of the main trunk the branch is created, (2) how/when to propagate changes from the main trunk to the pftijah branch (preferably not from the pftijah branch to the main trunk, i.e. ALL BUG fixes that also apply to the main trunk MUST be checked in to the main branch (as well)), and (3) who is responsible for maintaining the pftijah branch, propagating changes/bug-fixes from the main trunk to the pftijah branch and testing(!) the pftijah branch. About (1): I guess, you prefer ASAP, hence waiting for the release that we plan for end of January is no option, right? This in turn means that all changes of the update branch, which will be merged into the main trunk before the release (I guess just after new year), then also have to be merged into the pftijah branch... About (2) & (3): Well, I have some experiences and script for the propagation which I'm more than willing to share with who ever becomes the maintainer of the pftijah branch --- surely not me ;-) Let me know, what you think about this ... Greetings from --- well, doesn't matter ;-) Stefan On Fri, Dec 02, 2005 at 09:03:27AM +0100, Jan Flokstra wrote: > Hi Stefan, > > I'm going to start working on the possible integration of Tijah and > Pathfinder. The idea at this moment is to create a Tijah index on Pathfinder > documents. Then we will implement a nexi() function in Pathfinder which will > do the query on this Tijah index and will return Pathfinder nodes which can > be processed by Pathfinder. > I tried to set up a separate module for this called 'pftijah' but this failed > beacause at this moment I need to be very close to Pathfinder. There will be > quite a lot of people on this problem so we need a CVS repository. So we > would like to have a special Pathfinder branch called 'PFTIJAH' from where we > could do our experiments and distribute them. This branch could be a branch > from the current HEAD or from an older stable version, whatever you consider > the best solution. > Is it possible that you or somebody else creates such a branch for us??? > > Regards, Jan Flokstra & Hennig Rode. -- | 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

[Monetdb-developers] エッチなお姉さんは好きですか？
by info＠movr.info 05 Dec '05

05 Dec '05

$B!zL5NA$GM7$\$&!z%U%j!<%"%I%l%9$G4JC1EPO?(B!! $BEPO?!&G/2qHq!"40A4L5NA(B $B$7$+$b!"#1K|1_J,$NL5NA%]%$%s%HIU$-!#(B $B#S#M!"%;%U%l$O$b$A$m$s$N$3$H!"!{!{$J4X78$^$G%G%-%A%c%&(B(^o^) $BN/$^$C$FMh$?$i%3%3$GC5$7$F$M!*(B $B!!"-"-"-"-"-"-"-"-(B http://lo1.info/stg/ $BCk4V$O?M:J$GCf=P$7!"Lk$O(BOL$B$GCf=P$7!"@8%(%C%A$7$?$$$J$i:#$9$0!z(B $BL5NAEPO?!"#1K|1_J,L5NA!#(B $B!!"-"-"-"-"-"-"-"-(B http://lo1.info/stg/ Moon Star Casino $B$G%+%8%N%2!<%`$r$7$F!"L5NA$G(B$100$B$r<u$1<h$m$&!*(B http://hey2.info/casino/ $B:#8e5qH]$7$?$$J}$O(B haishin_kaijo(a)yahoo.co.jp $B$X(B

1 0

[Monetdb-developers] MonetDB Bug-Etiquette
by Stefan Manegold 24 Nov '05

24 Nov '05

Dear MonetDB-users and -developers, bug reports and especially test script play a crucial role with maintaining and improving the stability and correct functioning of MonetDB. However, adding test scripts "a posteriori" as we did recently during the two "MonetDB-Bug-Days" (a third one is still to come before the end of this year!) is a very tedious and time-consuming task, especially since who ever is adding a test script first needs to get familiar with the details of the very bug report. Since both the user who submits a bug report and the developer(s) who take(s) care of fixing a bug are by definition very familiar with the details of a bug report, it seems more than obvious that they should share the task of adding a test script to the CVS repository while dealing with the respective bug, i.e., *before* closing the bug report. Ideally, the user/submitter provides the query or script that triggers the bug as well as the expected/correct output with his/her bug report. In case the user/submitter has CVS check-in privileges, he/she could add the test script to the CVS repository him-/herself. Otherwise, the developer/assignee should add the user's test script to the CVS repository. The test script helps both the developer/assignee and the user/submitter to monitor the status of the bug by running "Mtest[.py]" (cf., http://monetdb.cwi.nl/monet/src/testing/README) or by checking the TestWeb (http://monetdb.cwi.nl/Development/TestWeb/) To coordinate this procedure, I made a first draft for a "MonetDB Bug Etiquette", which you find attached to this mail. I'd be very pleased, if you could comment on this. Thank you all very much for your contribution to make MonetDB even better than it already is! Kind regards, 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 |

4 10

[Monetdb-developers] SQL: Snodgrass' examples
by Steffen Goeldner 21 Nov '05

21 Nov '05

Attached is a SQL script with a collection of examples from 'Developing time-oriented database applications in SQL', chapter 3. <http://www.cs.arizona.edu/people/rts/tdbbook.pdf> I find this book very useful because the SQL standard is a very dry read. I changed a few errata, which are already confirmed by Mr. Snodgrass. It would give me great pleasure if the examples are of any use for you (e.g. as test script, quick reference, todo list ;-) Steffen /* Examples from Developing time-oriented database applications in SQL Richard T. Snodgrass ISBN 1-55860-436-7 Morgan Kaufmann Publishers <http://www.cs.arizona.edu/people/rts/tdbbook.pdf> Chapter 3: Instants and Intervals ---------------------------------------------------------------------- Boolean results should be true! ROLLBACK: expected error (not always thrown by MonetDB) rollback: MonetDB error */ SELECT DATE '1997-01-12'; SELECT TIME '11:35:29'; SELECT TIME '00:00:00'; SELECT TIME '11:08:27-07:00'; SELECT TIME '11:08:27.123456-07:00'; SELECT TIMESTAMP '1997-01-15 11:35:29.123456'; SELECT TIMESTAMP '1997-01-15 11:35:29.123456-07:00'; SELECT INTERVAL '3' YEAR; SELECT INTERVAL '7' MONTH; SELECT INTERVAL '3-7' YEAR TO MONTH; SELECT INTERVAL -'3-7' YEAR TO MONTH; SELECT INTERVAL +'0-0' YEAR TO MONTH; SELECT INTERVAL -'0-0' YEAR TO MONTH; SELECT INTERVAL '1 23:45:12' DAY TO SECOND; SELECT INTERVAL '0-0' YEAR TO MONTH = INTERVAL +'0-0' YEAR TO MONTH; SELECT INTERVAL '0-0' YEAR TO MONTH = INTERVAL -'0-0' YEAR TO MONTH; SELECT INTERVAL '3-4' YEAR TO MONTH = INTERVAL +'3-4' YEAR TO MONTH; SELECT INTERVAL '3-4' YEAR TO MONTH = INTERVAL '+3-4' YEAR TO MONTH; SELECT INTERVAL '3-4' YEAR TO MONTH = INTERVAL +'+3-4' YEAR TO MONTH; SELECT INTERVAL '3-4' YEAR TO MONTH = INTERVAL -'-3-4' YEAR TO MONTH; SELECT INTERVAL '3-4' YEAR TO MONTH = INTERVAL '3-4' YEAR TO MONTH; SELECT INTERVAL '3-7' YEAR TO MONTH = INTERVAL '43' MONTH; SELECT INTERVAL '3-7' YEAR TO MONTH = INTERVAL '23' DAY; -- incomparable ROLLBACK; -- `< ', ` < = ', `> ', `>= ', and`<> SELECT DATE '1996-02-24' + INTERVAL '7' DAY = DATE '1996-03-02'; SELECT DATE '1996-02-24' + INTERVAL '12:30' HOUR TO MINUTE; -- disallowed ROLLBACK; SELECT DATE '1996-02-24' + INTERVAL '2 12' DAY TO HOUR; -- disallowed ROLLBACK; SELECT INTERVAL '7' DAY + DATE '1996-02-24' = DATE '1996-03-02'; SELECT DATE '1996-03-02' - INTERVAL '7' DAY = DATE '1996-02-24'; SELECT TIMESTAMP '1996-02-24 12:34:56' AT LOCAL; -- MST: TIMESTAMP '1996-02-24 19:34:56' rollback; SELECT TIMESTAMP '1996-02-24 12:34:56+02:00' AT LOCAL; -- (MET DST) MST: TIMESTAMP '1996-02-24 03:34:56' rollback; SELECT TIMESTAMP '1996-02-24 12:34:56' AT TIME ZONE INTERVAL '-7:00' HOUR TO MINUTE = TIMESTAMP '1996-02-24 19:34:56'; rollback; SELECT CURRENT_DATE; SELECT CURRENT_TIME; SELECT CURRENT_TIMESTAMP; -- simultaneously SELECT CAST('1996-02-24' AS DATE) = DATE '1996-02-24'; SELECT CAST('12:34:56' AS TIME) = TIME '12:34:56'; SELECT CAST(TIME '12:34:56' AS TIMESTAMP WITH TIME ZONE) = TIMESTAMP '1997-07-23 12:34:56-07:00'; rollback; SELECT CAST( TIME '12:34:56.123' AS TIME(6) ) = TIME '12:34:56.123000'; SELECT CAST( TIME '12:34:56.123' AS TIME(1) ) = TIME '12:34:56.1'; SELECT CAST( TIMESTAMP '1997-07-23 12:34:56.123' AS TIME(6) ) = TIME '12:34:56.123000'; rollback; SELECT CAST( TIMESTAMP '1997-07-23 12:34:56.123' AS DATE ) = DATE '1997-07-23'; SELECT CAST( DATE '1997-01-01' AS TIMESTAMP(4)) = '1997-01-01 00:00:00.0000'; rollback; SELECT INTERVAL '3' DAY + INTERVAL '4' DAY = INTERVAL '7' DAY; SELECT INTERVAL '3' DAY + INTERVAL '4' HOUR = INTERVAL '3 4' DAY TO HOUR; SELECT INTERVAL '3' DAY + INTERVAL '8 4' DAY TO HOUR = INTERVAL '11 4' DAY TO HOUR; SELECT INTERVAL '3' DAY - INTERVAL '4' DAY = INTERVAL -'1' DAY; SELECT INTERVAL '3' DAY - INTERVAL -'8 4' DAY TO HOUR = INTERVAL '11 4' DAY TO HOUR; SELECT ( DATE '1997-01-01' - DATE '1996-01-01') DAY = INTERVAL '366' DAY; rollback; SELECT ( DATE '1997-01-01' - DATE '1996-01-01') YEAR TO MONTH = INTERVAL '1-0' YEAR TO MONTH; rollback; SELECT INTERVAL '4' DAY * 3 = INTERVAL '12' DAY; SELECT 3 * INTERVAL '4' DAY = INTERVAL '12' DAY; SELECT INTERVAL '12:30' HOUR TO MINUTE * 3 = INTERVAL '37:30' HOUR TO MINUTE; SELECT INTERVAL '4' DAY / 2 = INTERVAL '2' DAY; SELECT 2 / INTERVAL '4' DAY; -- not permitted ROLLBACK; SELECT - INTERVAL '4' DAY = INTERVAL -'4' DAY; SELECT + INTERVAL '4' DAY = INTERVAL '4' DAY; SELECT CAST('2' AS INTERVAL MONTH ); SELECT CAST('3-7' AS INTERVAL MONTH ); -- wrong ROLLBACK; SELECT CAST(INTERVAL '8-7' YEAR TO MONTH AS INTERVAL MONTH(2) ); -- exception is raised ROLLBACK; SELECT CAST( INTERVAL '3' YEAR AS INTERVAL YEAR TO MONTH ) = INTERVAL '3-0' YEAR TO MONTH; SELECT CAST( 103 AS INTERVAL MONTH ) = INTERVAL '103' MONTH; SELECT CAST( 103 AS INTERVAL MONTH(2) ); -- overflow exception ROLLBACK; SELECT CAST('2 12:34' AS INTERVAL DAY TO MINUTE ); SELECT CAST('12:34' AS INTERVAL DAY TO MINUTE ); -- works not ROLLBACK; SELECT CAST( INTERVAL'86 00:00:00' DAY TO SECOND AS INTERVAL HOUR TO SECOND ) = INTERVAL '2064:00:00' HOUR TO SECOND; SELECT CAST('86 00:00:00' AS INTERVAL HOUR(3) TO SECOND ); -- overflow exception ROLLBACK; SELECT CAST( CAST( 7430400 AS INTERVAL SECOND ) AS INTERVAL DAY TO SECOND ) = INTERVAL '86 00:00:00' DAY TO SECOND; SELECT CAST(DATE '1997-01-01' AS CHARACTER) = '1997-01-01'; SELECT CAST(INTERVAL '7430400' SECOND AS INTEGER) = 7430400; SELECT CAST(CAST(INTERVAL '2064:00:00' HOUR TO SECOND AS INTERVAL SECOND) AS INTEGER) = 7430400; SELECT EXTRACT( YEAR FROM DATE '1970-01-01') = 1970; SELECT EXTRACT( MINUTE FROM INTERVAL '12:34:56' HOUR TO SECOND ) = 34; SELECT EXTRACT( TIMEZONE_HOUR FROM TIME '12:34:56-07:00') = -7; rollback; SELECT EXTRACT( TIMEZONE_MINUTE FROM TIME '12:34:56-07:00') = 0; rollback; CREATE TABLE Employee( Id INTEGER, BirthDate DATE ); INSERT INTO Employee VALUES( 77, '1970-01-01'); INSERT INTO Employee VALUES( 88, '1971-12-13'); COMMIT; SELECT * FROM Employee WHERE BirthDate = DATE '1970-01-01'; SELECT * FROM Employee WHERE BirthDate =ANY ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE BirthDate =ALL ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE BirthDate =SOME ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE BirthDate IN ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE NOT BirthDate NOT IN ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE BirthDate MATCH ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE NOT BirthDate <> DATE '1970-01-01'; rollback; SELECT * FROM Employee WHERE NOT BirthDate <>ANY ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE NOT BirthDate <>ALL ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE NOT BirthDate <>SOME ( VALUES( ( DATE '1970-01-01') ) ); rollback; SELECT * FROM Employee WHERE BirthDate BETWEEN DATE '1970-01-01' AND DATE '1970-01-01'; SELECT * FROM Employee WHERE NOT BirthDate NOT BETWEEN DATE '1970-01-01' AND DATE '1970-01-01'; rollback; SELECT * FROM Employee WHERE ( BirthDate, INTERVAL '0' DAY ) OVERLAPS ( DATE '1970-01-01', INTERVAL '0' DAY ); rollback; SELECT * FROM Employee WHERE ( BirthDate, BirthDate ) OVERLAPS ( DATE '1970-01-01', INTERVAL '0' DAY ); rollback; SELECT * FROM Employee WHERE ( BirthDate, INTERVAL '0' DAY ) OVERLAPS ( DATE '1970-01-01', DATE '1970-01-01'); rollback; SELECT * FROM Employee WHERE ( BirthDate, BirthDate ) OVERLAPS ( DATE '1970-01-01', DATE '1970-01-01'); rollback; SELECT * FROM Employee WHERE ( BirthDate, NULL ) OVERLAPS ( DATE '1970-01-01', INTERVAL '0' DAY ); rollback; SELECT * FROM Employee WHERE ( BirthDate, NULL ) OVERLAPS ( DATE '1970-01-01', NULL ); rollback; SELECT * FROM Employee WHERE ( BirthDate, NULL ) OVERLAPS ( NULL , DATE '1970-01-01'); rollback; SELECT * FROM Employee WHERE CAST( BirthDate AS CHAR ) = '1970-01-01'; SELECT * FROM Employee WHERE CAST( BirthDate AS CHAR ) LIKE '1970-01-01'; SELECT * FROM Employee WHERE CAST( ( DATE '1971-01-01' - BirthDate ) DAY AS INT ) = 365 AND CAST( ( DATE '1971-01-01' - BirthDate ) YEAR AS INT ) = 1; rollback; -- XXX: SELECT * FROM Employee WHERE EXTRACT( YEAR FROM BirthDate ) = 1970 AND EXTRACT( MONTH FROM BirthDate ) = 1 AND EXTRACT( DAY FROM BirthDate ) = 1; DROP TABLE Employee; COMMIT;

2 2

[Monetdb-developers] Re: [MonetDB-users] AMD64 version of MonetDB for Windows?
by Peter Boncz 15 Nov '05

15 Nov '05

Hi Fabian, I just got my new workstation and it is an AMD64 machine with windows64 installed. I also got myself both the microsoft 64 bits compiler as well as the intel 64 bits compiler. With the particular goal of course to port MonetDB. I am not promising any timeframe but if we don't have a native windows64 port in the next couple of months I would be very surprised if not disappointed. Peter >> >> >> >> Just a small note. I don't have any windows building experiences, but >> we currently don't have access to such box running that operating >> system. As far as I can tell, there is no real priority to do so >> either. There are build instructions for windows, but it is unknown how >> 64-bits are enabled and if this will compile and run. This seems an >> unexplored area to me. >> >> Regards, >> Fabian >> >> >> Cardillo Raymond A Civ AFRL/IFEA wrote: >> > Has anyone out there taken the time to build an MSI for the AMD64 versions >> > of Windows? The x64 version of Windows was released a few months ago and >> > was available in Beta for a while, so I'm hoping someone has either done >> > this already, or can provide some advice on how to build/compile for this >> > platform. Anyone know of future plans to make this one of the standard >> > platform builds? Windows x64 is only going to grow in popularity from here, >> > especially amongst researchers and others who can benefit from 64 bits. >> > >> > Thanks for any info, >> > Ray Cardillo >> >> >> >> >>

2 1

[Monetdb-developers] MonetDB::CLI: MapiLib alternatives
by Steffen Goeldner 15 Nov '05

15 Nov '05

I'd like to add a more perlish layer around MapiLib (working title: MonetDB::CLI). This may look like: my $Cxn = MonetDB::CLI->connect( ... ); my $Req = $Cxn->query('select * from env'); while ( my $Cnt = $Req->fetch_row ) { print $Req->fetch_field( $_ ) for 0 .. $Cnt-1; } Still much in the spirit of Mapi, but handles are now objects (with destructors), functions are methods and the methods can throw exceptions. Once we have such an interface, additional implementations are possible. For instance, a XS module could skip the MapiLib layer and use libMapi directly. Later on, an implementation for MCL will be added (I hope) - either in pure perl or on top of libMCL (in case such a library will emerge). Of course, I'd like to use this new interface from DBD::monetdb to be able to choose between various implementations and to ease the transition to MCL. On the downside: additional modules means additional installation efforts. Especially the people resposible for the RPM's will be affected. If this sounds too screwy, it's now the chance to stop me ;-) Steffen

3 5

[Monetdb-developers] MonetDB/XQuery on SunOS 5.9
by Jens Teubner 29 Oct '05

29 Oct '05

Hi all, for our ongoing course "Database-Supported XML Processors" I wanted to install MonetDB/XQuery in our Sun-based computer lab. I encountered a number of pitfalls during the install that I will list below. System is SunOS 5.9. There's a bunch of GNU tools installed (e.g., gcc), but a number of tools is only available in their original Sun version. I've used the 4.8.2/0.8.2 tarballs distributed on the SourceForge website and set `--enable-optimize'. 1. Python ========= MonetDB's ./configure complains about a wrong version of Python and aborts. If I give it `--without-python', however, ./configure no longer complains, and MonetDB compiles fine (apparently). 2. make ======= Default `make' on that system is the one provided by SunOS. Apparently this is *not* sufficient to compile MonetDB: -- Sun's `make' does not like the wildcards (*.mk) in Makefile includes. I'm explicitly mentioning that because that actually annoys me for quite some time also on my system (independent of the Sun make issue). The Makefiles include $(top_srcdir)/*.mk and $(top_builddir)/*.mk. If I build MonetDB (or Pathfinder) directly in the source directory, this leads to any *.mk file being included twice---with loads of `make' warnings. Wouldn't it be more consistent to explicitly list .mk files to be included here with their full name? (Btw. with those wildcards, compilation will inevitably fail if I drop some random .mk file in any of the two directories---a thing that a normal user probably wouldn't expect/understand.) -- Lots of other stuff is not understood by Sun's `make'. Shouldn't ./configure also check whether the `make' implementation on a system suffices for the project? gmake did the job for me. It was available on our Sun, fortunately. 3. libbz2 ========= There's no libbz2 on that system. ./configure still did not complain. Compilation, however failed. Adding a `--without-bz2' fixed the issue. 4. Compilation issue ==================== gcc -DHAVE_CONFIG_H -I. -I../../../src/gdk -I../.. -I../../../src/gdk -I../common -DLIBGDK -O2 -std=c99 -D__EXTENSIONS__ -Wall -W -O2 -fomit-frame-pointer -finline-functions -DHWCOUNTERS -DHW_SunOS -DHW_sun4u -Werror-implicit-function-declaration -Werror -Wno-unused-function -Wno-unused-label -Wno-uninitialized -D_REENTRANT -c gdk_posix.c -fPIC -DPIC -o .libs/libbat_la-gdk_posix.o cc1: warnings being treated as errors ../../../src/gdk/gdk_posix.mx: In function `MT_getrss': ../../../src/gdk/gdk_posix.mx:550: warning: int format, pid_t arg (arg 1) gmake[4]: *** [libbat_la-gdk_posix.lo] Error 1 gmake[4]: Leaving directory `/u/halle/teubnerj/home_sun/MonetDB/src/MonetDB-4.8.2/build/src/gdk' I've removed the -Werror to get past that error. 5. HwCounters ============= ./configure complained about libcpc.h: present but cannot be compiled. Seems like the libcpc.h is there for some other reason. Compiling failed with an error in ..counters.mx. I've thus set `--without-hwcounters'. 6. Parallel Make ================ Tired of long make runs, I've tried `gmake -j4. Result: [...lots of stuff...] ../../../src/mel/ops.mx: ./ops.h - created ../../../src/mel/symtable.mx: ./symtable.h - created gmake[3]: *** No rule to make target `atom.mx', needed by `atom.h'. Stop. gmake[3]: *** Waiting for unfinished jobs.... ../../../src/mel/dependency.mx: ./dependency.h - created gmake[3]: Leaving directory `/u/halle/teubnerj/home_sun/MonetDB/src/MonetDB-4.8.2/build/src/mel' gmake[2]: *** [all-recursive] Error 1 Missing dependencies? Starting gmake again did it for me. Oops! Another one: /u/halle/teubnerj/home_sun/MonetDB/src/MonetDB-4.8.2/build/src/utils/Mx/Mx -x y ../../../src/monet/monet_parse.mx ../../../src/monet/monet_parse.mx: ./monet_parse.h - created gmake[3]: *** No rule to make target `../gdk/../common/stream.mx', needed by `../gdk/../common/stream.h'. Stop. gmake[3]: *** Waiting for unfinished jobs.... ../../../src/monet/monet_parse.mx: ./monet_parse.c - created Another one: /u/halle/teubnerj/home_sun/MonetDB/src/MonetDB-4.8.2/build/src/utils/Mx/Mx -x sh ../../../../src/modules/contrib/ddbench.mx gmake[4]: stat:../../../../src/modules/contrib/bat_mmath.mx: Interrupted system call gmake[4]: *** No rule to make target `bat_mmath.mx', needed by `bat_mmath.m'. Stop. gmake[4]: *** Waiting for unfinished jobs.... ../../../../src/modules/contrib/ddbench.mx: ./ddbench - created ../../../../src/modules/contrib/ddbench.mx: ./ddbench.m - created Another one: /u/halle/teubnerj/home_sun/MonetDB/src/MonetDB-4.8.2/build/src/mel/mel -I../../../../src/modules/contrib -I../../common -I../../gdk -I../../monet -I../plain -glue oo7.m > oo7.glue.c gmake[4]: *** No rule to make target `uchr.mx', needed by `uchr.m'. Stop. gmake[4]: *** Waiting for unfinished jobs.... gmake[4]: Leaving directory `/u/halle/teubnerj/home_sun/MonetDB/src/MonetDB-4.8.2/build/src/modules/contrib' (I know that parallel build have their problems. I've listed the errors here anyway.) 7. Linker Error =============== Finally I hit this linker error that I don't know how to solve: gmake[4]: Entering directory `/u/halle/teubnerj/home_sun/MonetDB/src/MonetDB-4.8.2/build/src/tools' /bin/bash ../../libtool --tag=CC --mode=link gcc -O2 -std=c99 -D__EXTENSIONS__ -Wall -W -O2 -fomit-frame-pointer -finline-functions -Werror-implicit-function-declaration -Werror -Wno-unused-function -Wno-unused-label -Wno-uninitialized -D_REENTRANT -o Mserver Mserver.o initmodules.o ../monet/libmonet.la ../modules/plain/lib_algebra.la ../modules/plain/lib_arith.la ../modules/plain/lib_bat.la ../modules/plain/lib_builtin.la ../modules/plain/lib_str.la ../modules/plain/lib_sys.la ../modules/plain/lib_trans.la ../gdk/libbat.la -lsocket -lnsl -ldl -lpthread -lposix4 -lmalloc ../common/libmutils.la ../common/libstream.la gcc -O2 -std=c99 -D__EXTENSIONS__ -Wall -W -O2 -fomit-frame-pointer -finline-functions -Werror-implicit-function-declaration -Werror -Wno-unused-function -Wno-unused-label -Wno-uninitialized -D_REENTRANT -o .libs/Mserver Mserver.o initmodules.o ../monet/.libs/libmonet.so ../modules/plain/.libs/lib_algebra.so ../modules/plain/.libs/lib_arith.so ../modules/plain/.libs/lib_bat.so ../modules/plain/.libs/lib_builtin.so ../modules/plain/.libs/lib_str.so -liconv ../modules/plain/.libs/lib_sys.so ../modules/plain/.libs/lib_trans.so /u/halle/teubnerj/home_sun/MonetDB/src/MonetDB-4.8.2/build/src/monet/.libs/libmonet.so /u/halle/teubnerj/home_sun/MonetDB/src/MonetDB-4.8.2/build/src/gdk/.libs/libbat.so -lm ../gdk/.libs/libbat.so /u/halle/teubnerj/home_sun/MonetDB/src/MonetDB-4.8.2/build/src/common/.libs/libstream.so -ldl -lpthread -lposix4 -lmalloc ../common/.libs/libmutils.so ../common/.libs/libstream.so /u/halle/teubnerj/home_sun/MonetDB/src/MonetDB-4.8.2/build/src/common/.libs/libmutils.so -lsocket -lnsl -lz -Wl,--rpath -Wl,/u/halle/teubnerj/home_sun/MonetDB/lib -Wl,--rpath -Wl,/u/halle/teubnerj/home_sun/MonetDB/lib/MonetDB ../modules/plain/.libs/lib_arith.so: undefined reference to `__ashrdi3(a)GCC_3.0' ../modules/plain/.libs/lib_arith.so: undefined reference to `__ashldi3(a)GCC_3.0' ../modules/plain/.libs/lib_arith.so: undefined reference to `__floatdisf(a)GCC_3.0' ../modules/plain/.libs/lib_arith.so: undefined reference to `__floatdidf(a)GCC_3.0' collect2: ld returned 1 exit status gmake[4]: *** [Mserver] Error 1 Any ideas so I can continue and hit more compilation problems? I'm not an expert on that system. Actually, I don't have any clue what software, libraries, tools, etc. is available there. I have access to the machine at any time, though, and I'm happy to give fixes a try or figure out, e.g., more detailed error messages. Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 Real programmers don't comment their code. If it was hard to write, why should it be easy to read?

3 3

[Monetdb-developers] eBay Survey's Departament : Paid Survey
by eBay 22 Oct '05

22 Oct '05

1 0

[Monetdb-developers] mail Server
by Jone 21 Oct '05

21 Oct '05

Dear monetdb-developers(a)lists.sourceforge.net: Bullet-Proof server: Fresh IPs 1024MB RAM P4 CPU 72GB SCSI Dedicated 100M fiber Unlimited Data Transfer Any software Based China US$599.00 per month May use the server for: Bulk web Hosting Direct Mail We also supply email list according to your order and sending out your message for you. Hope to service for you. Cheers! Jone Server Team kezunli666(a)sohu.com For.NoSend: MoreNot(a)yahoo.com

1 0

[Monetdb-developers] MonetDB & the c't database contest
by Stefan Manegold 16 Oct '05

16 Oct '05

Dear all, in issue 20/2005, our favorite (German ;-)) computer magazine c't (http://www.heise.de/ct/) calls for a "database contest". The original call and further information (in German) is available online at http://www.heise.de/ct/05/20/156/ an English translation can be found at http://firebird.sourceforge.net/connect/ct-dbContest.html Since we think, it would be a pity, if MonetDB would not participate in this contest, we decided to give it a try. Here at CWI, Stratos is currently looking at how to port the Dell's "DVD-Store" reference implementation (cf. http://linux.dell.com/dvdstore/) to MonetDB. Creating the database and loading the data needed only minor changes of the provided scripts. The next step will be to setup the middleware implementation for the webserver. We plan to use JSP/JDBC, here. Next to the web-application, we also plan to implement a MonetDB-specific driver for DVD-Store's "client-simulator" to allow direct client-server communication. Additionally, Fabian is busy improving the client-server communication (see his recent mails on this list). Of course, other MonetDB-developers/-users are more than welcome to also participate in the c't database contest effort, maybe using other middleware languages like PHP or Perl (Steffen? ;-)). If so, please feel free to let us know, and to ask for support (if necessary ;-)). We will keep you posted about our progress. Regards from A'dam, 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 0

[Monetdb-developers] JDBC/MonetDB performance test update
by Fabian Groffen 15 Oct '05

15 Oct '05

A small update on the results from yesterday. I suspected the stream level protocol we use to be a bit inefficient, so I implemented a IMHO more efficient version. In short I omit doing a 4-byte read and write call to indicate a block of data is done. I now communicate this by misusing a bit somewhere. I hoped for the result to be a bit better, but I won't complain on MonetDB 4: a rough 30% win on the DBTestI case. Since this change first has to be ported into MonetDB/Five those results will be made available later. The 'new' results are marked as M4n. The results follow in the table below: PG8 My4 M4p M4n M5p M5n JDBC local - DBTestI 37s 27s 86s 62s 60s ??s - DBTest 19s 27s 59s 48s 46s ??s - DBTestP 14s 27s 64s 61s 60s ??s

1 0

[Monetdb-developers] BUG in MonetDB V4.8.2 for windows
by Romulo Gonçalves 13 Oct '05

13 Oct '05

This email is to report a bug in MonetDB V4.8.2 for windows. My name is Rómulo Gonçalves, number 0536601. When I tried to insert one date value into one table with this code: Data dat = new Date(); Insert Into Statistic_URL values(dat,2,1); and I receive this error: parse error, expecting `','' or `')'' in: "insert into statistic_url values(tue oct" So I tried wiht this way: Insert Into Statistic_URL values('dat',2,1); I receive this error: ERROR: INSERT INTO: NOT NULL constraint violated for column statistic_url.date_sta I think this means that the data is not parseable, so it becomes null. I hope you understand the bug. If you do not understand something just send an email to me. Greets, Rómulo........

3 2

[Monetdb-developers] Bugreport MonetDB
by Nicolaas Heyning 10 Oct '05

10 Oct '05

Dear mr/mrs, We are experimenting with MonetDB to create a google-like search engine with a database of some 300.000 urls. We used the COPY INTO TEST FROM /../urlFile.txt statement to load all the data in a table. This worked fine and very fast. After this we tried to run the same script again, but errors occured. The connection was lost with the (local) monetDB and when we tried to regain it through: /home/mjmetter/MonetDB/bin/Mserver --dbinit "module(sql_server); sql_server_start();" we got the following output: !FATAL: GDKlockHome: Database lock '.gdk_lock' denied. We think that the loss of connection is caused by the amount of data that was inserted into the table. We did not manage to solve this problem, so maybe you can help us. Thanks in advance, Michael Metternich Nicolaas Heyning

2 1

Re: [Monetdb-developers] DBD::monetdb: DBI registration
by Steffen Goeldner 10 Oct '05

10 Oct '05

Niels Nes wrote (2005-07-16 14:57): > I guess we never told you that we all agree this is a very good idea. We > have similar plans with the jdbc and php/pear-db interfaces. So go ahead. O.k., FYI, I registered the 'monetdb_' prefix within DBI: <http://www.xray.mpe.mpg.de/mailing-lists/dbi/2005-08/msg00102.html> As soon as Tim commits this patch, you'll see it here: <http://svn.perl.org/viewcvs/modules/dbi/trunk/DBI.pm?view=log> Further on, I proposed DBD::monetdb for inclusion in the Module List <http://www.xray.mpe.mpg.de/mailing-lists/modules/2005-08/msg00695.html> Usually, this takes time. (Somebody of the module list maintainers has to acknowledge the proposal.) Certainly, DBI users expect to find a DBI driver on CPAN: <http://search.cpan.org/modlist/Database_Interfaces/DBD> Do you have any objections that I upload snapshots of DBD::monetdb to CPAN? Such a package will be generated as follows: cd MonetDB/src/mapi/clients/perl/DBD Makefile.PL make dist I'm aware that currently, with its MapiLib dependency, the package isn't very useful on its own - the user needs a MonetDB client anyway. That's not nice, but nothing out of the ordinary (and it may be changed). Steffen

3 9

[Monetdb-developers] TTT goes MonetDB-Bug-Day
by Stefan Manegold 06 Oct '05

06 Oct '05

[ I deliberately send this email to various related mailing lists; ] [ in case you receive this email more than once, it might be time ] [ to teach your email client to eliminate multiple copies of the ] [ very same email... ] Dear all, (admittedly on short notice --- sorry for any related inconvenience) you're all "invited" to join a community effort to significantly improve the the MonetDB quality control system: Let's (try to) make "Mtest.py-compliant" test scripts from all bug reports that have been filed on SF since July 2002, and thus ensure that these bugs do not re-occur, respectively ensure that we (via the "TestWeb"; cf. http://monetdb.cwi.nl/Development/TestWeb/) immediately notice whenever code changes do trigger an "old" bug. Summary: ======== When: Thursday, Oct 6, 2005, "all day" Where: Mainly at CWI, but you're also welcome to join "virtually" working from home or any other place in the world; for those who want to turn the Bug-Day into a Bug-"Party", I reserved our meeting room (C0,01) from 12:30 - 17:00 --- you need to bring your own "equipment" though ... Who: Primarily everyone who is in touch with MonetDB, and/or one of its companions/front ends (SQL, XQuery, etc.), has rights to check-in to the MonetDB CVS repository on SourceForge, and is reasonably familiar with "Mtest.py" (cf. http://monetdb.cwi.nl/monet/src/testing/README) But I will also (try to) provide "Testing HowTo" by Thursday, so others are welcome to join; further, if you cannot check-in to the MonetDB CVS repository yourself, a colleague of your's (or one of the core developers) might do this for you, once you prepared the complete test. What: I will prepare a list of all bug that have to test script, yet, and assign them round-robin to all participants (probably, I will try to classify them in say "MIL", "SQL", "XQuery", and "others", and you're welcome to choose your preferred class, given availability). More detailed instructions will follow by Thursday. Background: =========== Next to providing high performance, maintaining correctness and stability of the code base is the major goal of MonetDB and its companions. First of all, the bug tracking system on SourceForge (http://sourceforge.net/tracker/?group_id=56967&atid=482468) is used intensively to report any problems related to MonetDB --- since MonetDB moved to SourceForge in July 2002, almost 700 bug reports have been filed, most of which have been solved. Secondly, our automatic Nightly Multi-Platform Regression Test System (aka "TestWeb"; cf. http://monetdb.cwi.nl/Development/TestWeb/) helps us to ensure that bugs that sneak in with modified or newly added code are detected (and fixed) instantly. Obviously, the test system only work for that features/code that are indeed covered by the available test scripts... Given these two tools, the bug tracker and the test system, we can easily build a system that prevent the (unnoticed) re-occurrence of bug that have been reported and fixed before: We "simply" have to add a proper test script for each bug report. Unfortunately, so far there are test script only for a fraction of the ~700 bug reports. Given that many bugs are reported by users that are not allowed to add test script to the CVS repository, it is not convenient (not even possible) to require that each bug report includes an "Mtest.py-compliant" (cf. http://monetdb.cwi.nl/monet/src/testing/README) test script. Nevertheless, most bug reports come with a query, a script, or a detailed description how to reproduce the respective bug; hence, it should be rather simple to turn these queries / scripts / description into proper "Mtest.py-compliant" test scripts, and thus significantly improve our automatic quality control system. Since this task is quite a challenge (in terms of volume, not intellectual complexity ;-)), the idea popped-up to make it a "community effort", as sketched in the "Summary" above. The advantage of this coordinated community effort should be, that all of us dedicate our time to this concurrently, share the same "context" and hence can support each other efficiently when/where necessary. In advance, thank you very much for your cooperation! Regards, 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 |

8 9

[Monetdb-developers] BUG in MonetDB V4.8.2 for windows
by Romulo Gonçalves 05 Oct '05

05 Oct '05

This email is to report a bug in MonetDB V4.8.2 for windows. My name is Rómulo Gonçalves, number 0536601. When I try to create a table with multiply primary key with the following code (SQL99) : CREATE TABLE URLS ( ID_URL int, ID_Division int, PRIMARY KEY (ID_URL, ID_Division) ); ALTER Table URLs ADD foreign key(ID_Division) references URL_Division(ID_Division); I receive the following error: "[MonetDB][ODBC Driver 1.0]! Could not find referenced primary key in table urls" Then I tried with the following code: CREATE TABLE URLS ( ID_URL int, ID_Division int, primary key(ID_URL), primary key(ID_Division) ); And no error happen when I create the table. Here is the bug. The MonetDB accept that we insert more than one key and then it accepts the first (in this case ID_URL) as a primary key. But there is another bug. I can not create relational tables because I need to have a multiply primary key, in this case one tuplo (ID_URL,ID-Division) and for this I need to have the possibility to do like the following example: CREATE TABLE URLS ( ID_URL int, ID_Division int, * PRIMARY KEY (ID_URL, ID_Division) -> MonetDB not accept this way to define multiple primary key.* ); Maybe the report is not a perfect report because is the first time that I report bugs of one System. I hope that you understand the two bugs of MonetDB that I found, if there is something that you do not understand, please contact me. Greets, Rómulo....

2 1

[Monetdb-developers] Help
by joseph_sciarra＠dofasco.ca 26 Sep '05

26 Sep '05

I am working on an ORACLE Database and the xqueries I am running take forever to run Is there anything I can Do?? Thanks Joe

2 1

[Monetdb-developers] JDBC: transaction/savepoint issue
by Andrei Martsinchyk 02 Sep '05

02 Sep '05

Hello, I am trying to use MonetDB as a backend for Java application I am developing. I have noticed that inserts the application does have no effect. Statements are executed without exceptions, but data rows do not get into table. I have investigated the problem and have figured out that problem is in transaction and savepoint handling. If transaction had savepoints, it could be silently rolled back when Connection.commit() is called. I have finished with short Java program that demonstrate the bug(?), I am attaching it to the message. Please, take a look. I tested with MonetDB-4.8.2+sql-2.8.2 (release, source tarball) and with MonetDB-4.8.3+sql-2.8.3 (nightly build, August 30). Platforms: 32-bit Linux RedHat 9, 32-bit Linux Ubuntu 5.04 -- Best regards, Andrei Martsinchyk mailto:andrei.martsinchyk@gmail.com

2 3

[Monetdb-developers] Directories not created by install
by Robi Sen 02 Sep '05

02 Sep '05

I just installed the windows version of MonetDB and tried to follow the Tutorial on Mknife but was unable to connect. Looking at my system neither of the files /infosets/MILinfoset.xml;/infosets/MILdemo.xml where created nor where the directories. Is this a know issue?

2 1

Re: [Monetdb-developers] Re: [ monetdb-Bugs-1274819 ] "type error: no variant of function ... accepts the the giv"
by Ethan Aubin 29 Aug '05

29 Aug '05

On Mon, Aug 29, 2005 at 12:03:29AM +0200, Ying Zhang wrote: > I'm very sure there is a "make check" for every MonetDB module, so does > pathfinder. I believe it! I just found the immense TestWeb page today. I was initially assuming that pathfinder was distributed with its tests like MonetDB. [Side node: IMO, the web page might be easier to navigate if the subnodes on the left hand side had the same content as the submenus on the top bar. E.g. Starting from http://monetdb.cwi.nl/XQuery/index.html and clicking the Development on the left hand side lists a submenu 'Download from CVS', while clicking Development on the top takes me to a page with 'Partners', 'Contributors', 'TestWeb', etc on the left menu. This was how I missed the TestWeb earlier] Your were right about Mtest not being in my path. I forgot to 'rehash' after installing MonetDB. Cheers - EA

1 0

[Monetdb-developers] Re: [ monetdb-Bugs-1274819 ] "type error: no variant of function ... accepts the the giv"
by Jens Teubner 28 Aug '05

28 Aug '05

(It starts getting a communication thread now, no longer a bug track. So I'll reply via email, with CC to the monetdb-developers list.) > Re: The testsuite. I like a small test suite on my machine, > so that I can check that tools on my box did nothing > unexpected during the > build. Its also the best way to see what behavior can be > expected to work right out of the box. Are the nightly test > scripts available > online? Of course are those test scripts available. Just type `make check'. Be aware, though, that those test cases take their time. Also note that there are currently some tests in that do not work as expected. So you will not get a 100% pass. The `make check' run will print a summary after processing. You will also find a directory that contains the detailed test results marked up with HTML (directory `mTests'). Tests with unexpected outcome are highlighted in red; you will see the diffs between actual and expected outcome. Results of the nightly test runs, btw., are available on the MonetDB TestWeb website: http://monetdb.cwi.nl/Development/TestWeb/index.html. > Re: The usecases. They might be nice just to check > cross-implementation consistency. E.g. have the nightly > test queries been ran by a different xquery processor? Most test cases are tested ``by hand'', sometimes by comparing against other implementations. At least in theory, all of them are cross-checked by hand. > > (well, you may redefine a function with same name, but > > different number of arguments). > Wow, I didn't know that. I learn something new everyday. :-) Regards from Munich Jens -- Jens Teubner Technische Universitaet Muenchen, Department of Informatics D-85748 Garching, Germany Tel: +49 89 289-17259 Fax: +49 89 289-17263 "Tea or coffee?" "Coffee, without cream, please." "It will be without milk, we have no cream."

2 1

[Monetdb-developers] new requirements for building MonetDB and associated projects
by Sjoerd Mullender 24 Aug '05

24 Aug '05

There is a new (well already quite a few weeks old) CVS module available at our SourceForge repository called buildtools. This module is now a prerequisite for compiling MonetDB and all other projects. Check out buildtools: export CVSROOT=... cvs checkout buildtools cd buildtools # read REAME file and follow instructions Then you can update your MonetDB and other projects and bootstrap and build those projects. The main difference is: - autogen.py must be found in your $PATH (autogen is now part of buildtools); - Mx must either be found in your $PATH, or you must specify the option --with-mx=.../Mx on the configure command line; - mel must either be found in your $PATH, or you must specify the option --with-mel=.../mel on the configure command line; - for Pathfinder, burg must either be found in your $PATH, or you must specify --with-burg=.../burg on the configure command line. -- Sjoerd Mullender

3 4

[Monetdb-developers] AMD64 version of MonetDB for Windows?
by Cardillo Raymond A Civ AFRL/IFEA 19 Aug '05

19 Aug '05

Has anyone out there taken the time to build an MSI for the AMD64 versions of Windows? The x64 version of Windows was released a few months ago and was available in Beta for a while, so I'm hoping someone has either done this already, or can provide some advice on how to build/compile for this platform. Anyone know of future plans to make this one of the standard platform builds? Windows x64 is only going to grow in popularity from here, especially amongst researchers and others who can benefit from 64 bits. Thanks for any info, Ray Cardillo

2 1

[Monetdb-developers] quotes around chr values
by Sjoerd Mullender 17 Aug '05

17 Aug '05

I have prepared a patch to put (single) quotes around chr values in tables as printed by the Mserver. E.g.: MonetDB>'a'.print(); [ 'a' ] Previously this resulted in MonetDB>'a'.print(); [ a ] In addition to adding quotes, my patch also escapes control characters: MonetDB>chr(10).print(); [ '\012' ] Previously: MonetDB>chr(10).print(); [ ] This also shows a very important reason for wanting to make this change. Another example which is possibly even worse is chr(0).print(). I ran the pathfinder and sql tests, and only in pathfinder there are 2 tests that are affected (I will appprove them when I check the patch in). This message is a heads up. If you think you might be affected (JDBC, Perl, others?), then maybe you will need to make changes once I check this in. The Mapi library already deals with single-quoted values. -- Sjoerd Mullender

1 0

[Monetdb-developers] Large quantity Telecom products with low price
by Jun Wang 14 Aug '05

14 Aug '05

We supply large quantity low price Telecom products: Fiber optic jumper, UTP Cat5e cable, patch cable, USB cable, Phone cable and various Telecom components. Welcome OEM order and Custom cable. Details pay a visit to: www.sgetek.com. Download our catalogue from: www.sgetek.com/order.asp. Please contact with us by: prestonsh(a)126.com for our newest price list. Jun Wang SGETEK SHANGHAI CO., LIMITED SGETEK UK CO., LIMITED TEL:+86 21 67820784 FAX:+86 21 67820791 ---------------------------------------------------------------------- If no use for you send a "No Thanks" mail to: cable88(a)163.com, your mail will be deleted from our list within 2 working days.

1 0

[Monetdb-developers] Re: [Monetdb-checkins] MonetDB/src/modules/plain pcre.mx,1.14,1.15
by Fabian 10 Aug '05

10 Aug '05

Sjoerd Mullender wrote: > Update of /cvsroot/monetdb/MonetDB/src/modules/plain > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22873 > > Modified Files: > pcre.mx > Log Message: > Do not put anything above the license text (except possibly a > "hash-bang" line (#!/...)). The script that updates the license text > does not like this. > > Furthermore, the standard in the MonetDB code is to use 8-space tabs. > If you want to view things differently, that's fine, but make at least > sure that it still looks correctly with 8-space tabs. Since when? I have been told 4 width *tabs* (not spaces) is the standard in the MonetDB project. You seem to suggest here that I should use spaces instead... Off-topic: is there anyone who actually uses 8 width tabs within vi?

2 1

[Monetdb-developers] max size of a bat
by Peter Boncz 04 Aug '05

04 Aug '05

Folks, MIN(2G, 4GB/sizeof(type)) is indeed the maximum number of elements in a BAT for 32-bits systems. Obviously, for 64-bits operating systems, no such restriction exists. Peter

1 0

[Monetdb-developers] Re: [MonetDB-users] speed comparison off inserts and deletes, and db size question
by Joel Reymont 03 Aug '05

03 Aug '05

On Aug 3, 2005, at 10:40 AM, Fabian wrote: > You should keep in mind that if you use a (V)OID on an 32-bits > platform, that you have a limitation of the number of rows that you > can contain in a BAT. Also, and OID cannot be bigger than the int > it is, so if you do need more rows, or sequence numbers that are > higher, you will have to jump over to lng and do the sequence > numbers yourself or something. > Is it 2^32-1 for the maximum number of rows in a BAT? > You can never join BATs that are bigger than max(OID), so you have > to play tricks like doing the selects on all it's subparts and then > unioning the results, given they are small enough to be stored in > one BAT. > Are you referring to BAT * BATkunion (BAT *b, BAT *c) in the kernel guide? I assume that I need to use BATkunion as opposed to BATsunion since I'm looking only at the head column. And that the fragments satisfy the set property since they are fragments of a larger BAT with a non- repeating oid range. Am I thinking right? Do I need to set any properties on the BAT for the union to work? Thanks, Joel -- http://wagerlabs.com/uptick

3 2

[Monetdb-developers] Re: [MonetDB-users] speed comparison off inserts and deletes, and db size question
by Joel Reymont 03 Aug '05

03 Aug '05

On Aug 3, 2005, at 10:40 AM, Fabian wrote: > > Most of the common MIL operators have C equivalents, like BATnew, > BATcount, etc. Right, I realize that. And that the extension modules are backed by C code as well. > You should keep in mind that if you use a (V)OID on an 32-bits > platform, that you have a limitation of the number of rows that you > can contain in a BAT. Also, and OID cannot be bigger than the int > it is, so if you do need more rows, or sequence numbers that are > higher, you will have to jump over to lng and do the sequence > numbers yourself or something. Is it 2^32-1 for the maximum number of rows in a BAT? > You can never join BATs that are bigger than max(OID), so you have > to play tricks like doing the selects on all it's subparts and then > unioning the results, given they are small enough to be stored in > one BAT. Are you referring to BAT * BATkunion (BAT *b, BAT *c) in the kernel guide? I assume that I need to use BATkunion as opposed to BATsunion since I'm looking only at the head column. And that the fragments satisfy the set property since they are fragments of a larger BAT with a non- repeating oid range. Am I thinking right? Do I need to set any properties on the BAT for the union to work? Thanks, Joel -- http://wagerlabs.com/uptick

1 0

[Monetdb-developers] Splicing vertically fragmented BATs
by Joel Reymont 03 Aug '05

03 Aug '05

Folks, What series of GDK operations (possibly with module extensions) can I use to splice a vertically fragmented BAT? I'm looking to do this in C/C++ as opposed to MIL. Thanks in advance, Joel -- http://wagerlabs.com/uptick

1 0

[Monetdb-developers] X100
by Joel Reymont 02 Aug '05

02 Aug '05

Is it possible to look at the X100 source code or more detailed information right now? What I'm trying to accomplish is basically the same, in Common Lisp. I read through Peter Boncz's Ph.D. thesis as well as the X100 paper. One thing that I don't understand is whether the X100 scan retrieves vectors from _all_ participating BATs. I'm also wondering how the size of the cache (and thus the size of the vector) is determined. Thanks, Joel -- http://wagerlabs.com/uptick

2 3

[Monetdb-developers] Deleting and inserting BUNs. What happens?
by Joel Reymont 01 Aug '05

01 Aug '05

Folks, According to Peter's Ph. D. thesis I need to keep track of deleted (and inserted?) BUNs in [void, ...] BATs since the head is densely packed. Do I still need to do that and what happens when BUNs are deleted and inserted in [oid, ...] BATs? Thanks, Joel -- http://wagerlabs.com/uptick

1 0

[Monetdb-developers] Re: X100
by Peter Boncz 30 Jul '05

30 Jul '05

Hi Joel, About X100. In my opinion this is a very cool project that actually constitutes an entirely new query engine. It is more scalable than the current Monet4 engine, and also than the Monet5 engine. There is no main memory limitation anymore. Let's think about it as Monet6 (though that is not sure). The system is quite functional, but especially regarding APIs, database updates and also binary/source distribution of the code, a lot has to be done. Currently, we are concentrating on obtaining scientific results. Some functioanlities (like database updates) still have to be developed. I think we are more than a year off from a releasable system. Also, it has not been decided yet whether that will be an open-source release. Maybe X100 has some commercial future.. Then more general. I just read your posts on this mailing list and I do not have a full grasp of your plans in order to properly advise you. Some general tips: - try to keep all bulk operations in MIL, with interfaces to the lisp engine that move only little data in and out. - use unary bats preferable. i/e/ those that have a void head type - try to seperate data and metadata. Thus, the schema you use, and also the results, are best kept outside MonetDB. Maybe store them in flat files XML or something. It makes the architecture easier to maintain. Also, your application does not depend that strongly on MonetDB repositories. As for special purpose indexing, often it is possible to represent them as a set of bats. you will have to do some coding in a new monet extension module (a .mx file as found in the src/modules/plain/ directory) to write some primitives that access those bats (that are your index) efficiently. just my 2 cts. Peter

2 1

Re: [Monetdb-developers] enum BATs
by Joel Reymont 30 Jul '05

30 Jul '05

Martin, Thanks for your help and my apologies. I thought there was support for enums in the GDK but I'll take a look at the enum module. I'm trying to implement the pieces of MIL that I need for my trading platform, in Common Lisp. Thanks, Joel On Jul 29, 2005, at 11:52 PM, Martin Kersten wrote: > Joel, > > We apologize that the user-documentation is behind the code. > Nevertheless, the following areas are a good starting point for > gaining additional information. -- http://wagerlabs.com/uptick

1 0

[Monetdb-developers] enum BATs
by Joel Reymont 29 Jul '05

29 Jul '05

Folks, Is there a property I can set on the BAT to mark it as enum? How are num bats implemented in the kernel? I could not find this in the docs. Thanks, Joel -- http://wagerlabs.com/uptick

1 0

Re: [Monetdb-developers] Lisp trading systems kernel on top of GDK
by Joel Reymont 28 Jul '05

28 Jul '05

On Jul 28, 2005, at 1:19 PM, Martin Kersten wrote: >>> MIL is likely >>> to be moved into a corner next year when MonetDB Version 5 is >>> released. >>> >> What is the expected replacement? >> > An assembler-like version, intended as a target language for front-end > compilers and optimizers, not for end-user programming. Then I could actually translate things into this new MIL. Sound good. >> Can I screw it [BAT properties] up by using GDK functions? >> > Mostly not, but you are really linking into a kernel and this requires > a lot more administration to take care off. Not to mention proper > garbage collection,..., i.e. all the stuff hidden by the language > interpreters. Fortunately for me garbage collection is taken care of by Lisp. It's also a mixed interpreted _and_ compiled environment which gives me an additional leg up. > The structure of the table is known and the integrity constraints > allow direct updates on the BATs. Yes, my updates are fixed indeed. Where can I find the batch-loading code? Is that the ascii_io module? > Then a simple IP-channel can be used > to quickly pump data into the system. It does not need to be an IP channel, right? I could just as well pump data into the system directly, right? > Depending on the batching size > implied in a separate data gatherer, you should be able to handle > anywhere between 5K-200K inserts/sec on a normal PC. > It also bypasses the SQL logger, which may not be what you want. I will have to run some experiments here as loosing incoming data would be very bad for me on the one hand and on the other hand I need to store data as quickly as possible. I have a Mac OSX laptop. > A time-series module over BATs would be the preferred way to go. What should this module be written in? > Such a module would have primitives for moving-statistics, > window-based selections, window-based signal analysis, and > schemes for efficient temporal joins (including interpolation). I have more interest in rolling out a trading platform but once the first version is out I could definitely look into optimizations like building a time series module. I recon from your "Efficient k-NN Search on Vertically Decomposed Data" paper that I could calculate the Euclidian distance between time series on the fly since vector ops are very fast. At least I could try. I'm also talking to the http://www.cs.purdue.edu/spgist/ folks and other scientists to see if I could use one of the indexing schemes as a MonetDB search accelerator (hope I have the terminology right). I did not see an answer on my other post so I still don't know if a range search can be efficiently done on a lng bat. If they can then I could just do with that as my queries are mostly run this strategy on this range of data, using a sliding window of X BUNs. The range of data would be a subset of the price BAT, limited by a range of dates in a different BAT. But then I also need to consider a symbol BAT to take only MSFT or IBM, etc. into account. It seems a lot like the problem that you tackled in the k-NN paper. I don't fully understand how indexes work in MonetDB. I don't understand if I need to manually create them on my columns for example. I suppose this does not make sense with MonetDB. It seems that only one index is used, the one that links all BATs in a table so that particular BUNs can be accessed. Let me know if I got it right please. > Unfortunately, there is no free lunch and I guess a more top-down > architectural design is now what you should be looking for. I'm reading through Peter Alexander Boncz's dissertation at the moment. > Before you jump into the MonetDB code. > Compare it with riding a Ferrari the first time around, you can get > good speed-up, but also easily get killed. Yes, I'm aware of the dangers but think that I'm on to something exciting. Your help and advice is greatly appreciated! Thanks, Joel -- http://wagerlabs.com/uptick

1 0

Re: [Monetdb-developers] Lisp trading systems kernel on top of GDK
by Joel Reymont 28 Jul '05

28 Jul '05

Martin, On Jul 28, 2005, at 12:49 PM, Martin Kersten wrote: > 3) is a good option. Separate the database functionality from the > application and only extend the kernel if you can not escape it. > [...] > indeed, accessing points one-by-one nullifies all positive effects of > a database system, you should think set-(list-) at a time I could not see any way of retrieving data in sets or lists using MAPI. Am I missing something? > MIL is likely > to be moved into a corner next year when MonetDB Version 5 is > released. What is the expected replacement? >> or something similar. I'm wondering if MIL would be up to the task. >> #2 is the option that I would prefer as I could hook up into the GDK >> to quickly iterate through BATs and BUNs and use Lisp to write >> > that is feasible and has been done more often. The pitfall here is > that > you may easily screw-up the property infrastructure What is the property infrastructure? Can I screw it up by using GDK functions? > Actually, if your input/updates are fixed, you may consider a much > faster scheme directly interfacing with updates on the BAT structures. > The bulk loading routines may give you the hints how to do this. Just so that I understand you correctly, what do you mean by fixed input/updates? Thanks, Joel -- http://wagerlabs.com/uptick

1 0

[Monetdb-developers] Lisp trading systems kernel on top of GDK
by Joel Reymont 28 Jul '05

28 Jul '05

Folks, The real-time trading platform that I'm building requires running strategies on historical data at very high speed. There could be hundreds of thousands of such runs with different permutations of arguments. I do not want to force my customers to write trading systems in MIL and MIL, according to its description, might not be suitable. So I was wondering if I should 1) try to translate trading systems from Lisp into MIL or if I should 2) build my own Lisp kernel for trading systems execution. There's also 3) the option of not running strategies in MonetDB/MIL. #3 would require using MAPI and extracting data points one by one. I dislike this as it would not let me take advantage of vector processing. #1 would require using MIL to potentially write Fast Fourier Transforms or something similar. I'm wondering if MIL would be up to the task. #2 is the option that I would prefer as I could hook up into the GDK to quickly iterate through BATs and BUNs and use Lisp to write and debug trading systems. With some coordination I think I could even use MonetDB-SQL together with my kernel, so long as I leave all the insertion and update operations outside of Lisp. What do you think? Thanks, Joel -- http://wagerlabs.com/uptick

1 0

[Monetdb-developers] Time series extension module
by Joel Reymont 28 Jul '05

28 Jul '05

Folks, I'm building a real-time, very short-frequency trading platform. The platform needs a backend for storing exchange ticks (quotes) and I think MonetDB could be that platform. My ultimate attraction is the vertical decomposition that sets MonetDB apart. It's the approach taken by KDB http://www.kx.com/products/kdbplusfaq.php http://cs.nyu.edu/cs/faculty/shasha/papers/sigmodpap.pdf and that has already proven immensely effective. My personal need is in searching for matching subsequences in other time series (k-NN?) which would require me to compute the Euclidian distance between points, etc. Martin suggested that I build a time series extension module which is fine with me (see http://wagerlabs.com/resume.pdf) I have several questions before I embark on this project... I don't have a clear understanding of how MonetDB managed indexes. If I'm dealing with timestamp, price and volume and need to search either would I need to build indexes on the three columns? I believe MonetDB supports range queries. Could I just store timestamp as an integer such as YYYYMMDDHHSS and do a range query on that? How would I go about building the time series extension module? Would I need to add custom search accelerators to build a specialized index on the fly? Thanks, Joel -- http://wagerlabs.com/uptick

1 0

[Monetdb-developers] FYI: DBD::monetdb test suite via MonetDB ODBC Driver
by Steffen Goeldner 29 Jun '05

29 Jun '05

FYI, I'm using the DBD::monetdb test suite to test the MonetDB ODBC Driver: set DBI_DSN=dbi:ODBC:driver=MonetDB ODBC Driver dmake test Here is the test summary: Failed Test Stat Wstat Total Fail Failed List of Failed --------------------------------------------------------- t\02cxn.t 5 1280 8 4 50.00% 7-8 t\12bind.t 1 256 6 1 16.67% 3 t\13count.t 16 4096 30 16 53.33% 12-27 t\23null.t 255 65280 14 22 157.14% 4-14 1 test and 2 subtests skipped. Failed 4/22 test scripts, 81.82% okay. 30/382 subtests failed, 92.15% okay. In light of all the additional layers, this is an unexpected good result. (Admittedly, my tests are not very aggressive.) And, even better, all is on the mend: t\02cxn.t This is a bug in DBD::ODBC: <http://www.xray.mpe.mpg.de/mailing-lists/dbi/2005-02/msg00061.html> fixed in svn: <http://svn.perl.org/viewcvs/modules/dbd-odbc/trunk/dbdimp.c?rev=858&r1=561&…> t\12bind.t This is bug #1229018: <http://sourceforge.net/tracker/index.php?func=detail&aid=1229018&group_id=5…> t\13count.t This is a bug in DBD::ODBC. It looks like DBD::ODBC doesn't expect that an ODBC driver is able to return the number of rows of a result set. t\23null.t This is bug #1225455: <http://sourceforge.net/tracker/index.php?func=detail&aid=1225455&group_id=5…> Steffen

1 0

[Monetdb-developers] MonetDB.conf contains path on developer's machine
by Roger Erens 25 Jun '05

25 Jun '05

I don"t know whether MonetDB.conf in CWI\MonetDB\etc is used, but it contains the following lines: # Where MonetDB is installed prefix=C:\Documents and Settings\sjoerd\My Documents\src\MonetDB\NT exec_prefix=C:\Documents and Settings\sjoerd\My Documents\src\MonetDB\NT Roger

2 1