October 2006 - developers-list

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