- developers-list - monetdb.org

[Monetdb-developers] Compile M4...
by Romulo Goncalves 05 Dec '06

05 Dec '06

Dear developers, I checkout buildtools and M4 to my machine at home. I am using Fedora Core 4. The version of M4 and the buildtools are the cvs head branch. My gcc compiler is [Romulo@localhost MonetDB]$ gcc --version gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I done boostrap, configure, and make During the compilation I got this error: /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/home/Romulo/MonetDB/MonetDB4/MonetDB/src/gdk -I../.. -I/home/Romulo/MonetDB/MonetDB4/MonetDB/src/gdk -I../common -I/home/Romulo/MonetDB/MonetDB4/MonetDB/src/gdk/../common -DLIBGDK -Wall -W -std=c99 -g -Werror-implicit-function-declaration -Werror -Wno-unused-function -Wno-unused-label -D_REENTRANT -c -o libbat_la-gdk_system.lo `test -f 'gdk_system.c' || echo '/home/Romulo/MonetDB/MonetDB4/MonetDB/src/gdk/'`gdk_system.c gcc -DHAVE_CONFIG_H -I. -I/home/Romulo/MonetDB/MonetDB4/MonetDB/src/gdk -I../.. -I/home/Romulo/MonetDB/MonetDB4/MonetDB/src/gdk -I../common -I/home/Romulo/MonetDB/MonetDB4/MonetDB/src/gdk/../common -DLIBGDK -Wall -W -std=c99 -g -Werror-implicit-function-declaration -Werror -Wno-unused-function -Wno-unused-label -D_REENTRANT -c gdk_system.c -fPIC -DPIC -o .libs/libbat_la-gdk_system.o cc1: warnings being treated as errors /home/Romulo/MonetDB/MonetDB4/MonetDB/src/gdk/gdk_system.mx:224: warning: missing initializer /home/Romulo/MonetDB/MonetDB4/MonetDB/src/gdk/gdk_system.mx:224: warning: (near initialization for 'MT_system_lock.__data.__count') make[5]: *** [libbat_la-gdk_system.lo] Error 1 make[5]: Leaving directory `/home/Romulo/scratch/MonetDB/monetdb4/build/src/gdk' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/Romulo/scratch/MonetDB/monetdb4/build/src/gdk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/Romulo/scratch/MonetDB/monetdb4/build/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/Romulo/scratch/MonetDB/monetdb4/build/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/Romulo/scratch/MonetDB/monetdb4/build' make: *** [all] Error 2 [Romulo@localhost MonetDB]$ I done the same procedures several times and I always got the same error. Any idea what could be the problem? Regards, Romulo

2 8

[Monetdb-developers] configure & *_config.h include files
by Stefan Manegold 01 Dec '06

01 Dec '06

Dear fellow developers, while trying to fix portability issues with the pftijah modules of pathfinder, I noticed the following problem: To ensure portability, each source file should know about and adhere to what configure found out; hence, the respective X_config.h (with X one of monetdb, sql, pf, etc,) must be the first include in each .c file. However, with the front-ends, some files (especially those implementing extension modules) also need to MonetDB's monet.h or gdk.h to get the respective definition. Since monet.h includes gdk.h which includes monet_utils.h which in turn includes monetdb_config.h, these files the include both the "local" X_config.h (with X one of sql, pf, etc,) and the monetdb_config.h. This might trigger two problems: 1) If we compile sql, pf, etc, a against a binary install of MonetDB which was configured and generated on an binary compatible but potentially (slightly) differently configured/installed system, this might lead to conflicting definition/declarations in the two X_config.h. 2) Even if we compile MonetDB and the front-end on the same system, there might be conflicts since the respective configure are not completely identical. In pathfinder/runtime we avoid (2) be not including pf_config.h but only monetdb_config.h (via monet.h or gdk.h) which might actually lead to problems similar to (1). In pathfinder/module/pftijah, we run into (2) with _FILE_OFFSET_BITS (at least) on our Solaris 10 x86 machine, since only MonetDB' configure.ag checks AC_SYS_LARGEFILE() while pathfinder's configure.ag does not. To solve the problem (2) "properly", we could either make all configures identical (e.g., by moving all "local" checks from the various configure.ag to MonetDB/conf.monet.m4). But that still leaves us with (1). To solve (1) (and (2)) "properly", we could avoid the implicit inclusion of monetdb_config.h in monet_utils.h (and hence gdk.h & monet.h) by removing the respective include from monet_utils.h. But then, we'd have to explicitly include monetdb_config.h in each .c file that now includes one of monet_utils.h, gdk.h, monet.h (directly or via some other include) --- a lot of work, with a high risk to overlook some locations... A "better"(?) (at least simpler) solution could be to guard the #include "monetdb_config.h" in MonetDB' monet_utils.h by, say, #ifndef NO_MONETDB_CONFIG ... #endif, and then define NO_MONETDB_CONFIG in X_config.h (with X one of sql, pf, etc,). I'd strongly vote for the last solution. ;-) Comments, ideas, complaints, objections? 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 7

[Monetdb-developers] Compilation of M4, M5 and SQL in the windows 64
by Romulo Goncalves 01 Dec '06

01 Dec '06

Dear developers, During the compilation of M4, M5, and SQL in windows 64 I have to correct all the time the rules.msc: PTHREAD_INCS = "-I$(PTHREAD)\include" PTHREAD_LIBS = "$(PTHREAD)\lib\pthreadVC2.lib" to PTHREAD_INCS = "-I$(PTHREAD)" PTHREAD_LIBS = "$(PTHREAD)\pthreadVC2.lib" TO not get compilation errors. This happen because the compilations of pthread for win64 does not create the directories lib and include. The files are all saved into the main directory pthreads. Being the pthreads directory tree for 64 different of the directory tree for 32. If you could help me to find a solution I will appreciate a lot. Regards, Romulo

2 4

[Monetdb-developers] conf.bash
by Fabian Groffen 01 Dec '06

01 Dec '06

Dear developers, While trying to update conf.bash, I encountered the following problems: 1) I cannot find times100, misq and acoi 2) In playpen and gis conf.bash isn't identical to the other locations Further I wonder why conf.bash isn't just in buildtools for those who need it, but replicated in all modules. It is a great pain to keep them in sync it seems, and causes a lot of email. If someone can solve 1), thanks. I don't know about 2), I just made the change that is necessary for my change.

2 2

[Monetdb-developers] Mtest for M5-SQL
by Romulo Goncalves 01 Dec '06

01 Dec '06

I updated all my system yesterday night. Now I am trying to run the Mtest for M5-SQL and I got this error. [goncalve@amelia src]$ Mtest_5_sql -rq Could not open file /ufs/goncalve/scratch/MonetDB/monetdb5/etc/MonetDB5.conf Mtest.py Warning: TSTSRCBASE: Replacing logical path /ufs/goncalve/MonetDB/SQL/sql/ by absolute physical path /ufs/goncalve/MonetDB/SQL/sql Mtest.py Warning: TSTBLDBASE: Replacing logical path /ufs/goncalve/scratch/SQL/sql/build/ by absolute physical path /net/amelia/export/scratch1/goncalve/SQL/sql/build Mtest.py Warning: TSTTRGBASE: Replacing logical path /ufs/goncalve/scratch/Mtest5/ by absolute physical path /net/amelia/export/scratch1/goncalve/Mtest5 Traceback (most recent call last): File "/ufs/goncalve/scratch/MonetDB/monetdb4/bin/Mtest.py", line 3364, in ? main(sys.argv) File "/ufs/goncalve/scratch/MonetDB/monetdb4/bin/Mtest.py", line 2947, in main os.environ[v] = env[v] KeyError: 'XQUERY_LOGDIR' What can be the problem? Regards, Romulo

2 3

[Monetdb-developers] Triggers owner..
by Romulo Goncalves 29 Nov '06

29 Nov '06

Dear developers, I am using SQL cvs head and M5. If I create a table and a new user with a mclient: create user "user_test" with password 'pass' NAME 'test1_user' SCHEMA "sys"; create table t1 (id int); If then I connect with the new user and I create a trigger on t1: create trigger test1 after insert on t1 insert into t1 values(12); I do not get any error. Well, depending on the approach followed in MonetDB it can be a bug or not. (1) If we decide that a trigger over a table can only be created by the table owner (in this case the monetdb user is the owner of t1) this is a bug. (2) If any user is allowed to create a trigger over any table, this is not a bug. What approach is followed by MonetDB? If any which one we should choose? In my opinion we should choose the first approach. Regards, Romulo

2 2

Re: [Monetdb-developers] error when running simple Xquery on Windows platform
by Fabian Groffen 28 Nov '06

28 Nov '06

Hi Daniel, I'm forwarding your mail to monetdb-developers(a)lists.sourceforge.net in the hope that someone can help you there. I have no idea myself what you can try to resolve this problem. Sorry! On 26-11-2006 23:21:07 -0500, dcr2108(a)columbia.edu wrote: > > Dear Monet Team, > > I am running into a consistent error when I try to run an example > xquery from your website "books1.xq": > > ERROR: interpret_params: mirror(param 1): invalid BAT. > ERROR: interpret_params: [startsWith](param 2): evaluation error. > ERROR: interpret_params: uselect(param 1): evaluation error. > ERROR: interpret_params: +(param 2): evaluation error. > > Steps to reproduce error: > 1) 'Start' -> 'Programs' -> 'MonetDB XQuery' -> 'MonetDB XQuery > Server' > > 2) double click books1.xq > > 3) THE ERROR OCCURS > > Thanks for your help, > Daniel Rappaport > Masters candidate in department of biomedical informatics > > >

3 2

[Monetdb-developers] Mapi and locality
by Sándor Héman 26 Nov '06

26 Nov '06

Hi, I have a problem with Mapi which did not seem to occur in previous releases of MonetDB (<4.15). In the past, I could start an Mserver with a mil script that declared some PROCs, and then let this Mserver accept Mapi connections, with the Mapi clients being able to call the functions that were declared in the server-side startup script. However, since the latest release, the server-side PROCs seem to be invisible to the client: MAPI = monetdb@kanda:50012 QUERY = template_conj_2(1, bat(void, lng).seqbase(0(a)0).append(lng (5394205300074141533)).append(lng(3189196963433190955))); ERROR = !ERROR: interpret: no matching MIL operator to 'template_conj_2(int, BAT[oid,lng])'. If I execute exactly the same call in the server-side console, it just works... Any ideas on this? And whether there is an easy fix? Cheers Sandor

2 4

[Monetdb-developers] Concurrency Problem Mserver
by Robin Aly 24 Nov '06

24 Nov '06

Hello everybody, as I am trying to get some experiments with PFTijah to work I encountered endless loops while executing some queries. Setting the debug_level to 1024 gave me a list of locks which were obviously competing about some resource. The attachment tries to describe what the start parameters, inputs and the log messages were. Can somebody tell me whether that is a problem of mine, or a common one? And what a good approach to fix it would be. Best regards & fijn weekend Robin -- Robin Aly (PhD student, University Twente) Phone: +31 (53) 489 4520 Fax: +31 (53) 489 2927 email: r.aly(a)ewi.utwente.nl gdb -args Mserver --set monet_daemon=yes --dbinit="module(pftijah); mil_start();" /tmp/trec${i}.xq= let $opt := <TijahOptions returnNumber="1000" collection="PFX" algebraType="COARSE2" txtmodel_model="NLLR"/> for $q in doc("/local/alyr/dev/eval/clef-clsr-2006/clef-malach/topics/evaluation2006-en.xml")//top[3] let $q_text := pf:tijah-tokenize(exactly-one($q/title/text())) let $q_nexi := concat("//DOC[about(.,", $q_text, ")];") let $q_num := $q/num/text() let $result := pf:tijah-query-id($opt, (), $q_nexi) for $doc at $rank in pf:tijah-nodes($result) return string-join(($q_num, "Q0", $doc/DOCNO/text(), string($rank), string(pf:tijah-score($result, $doc)), "UTallEN"), " ") MapiClient -l xquery </tmp/trec${i}.xq Output getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604) getRequest: MT_set_lock(0xb7e305ec) getRequest: MT_up_sema(0xb7e30604) getRequest: MT_unset_lock(0xb7e305ec) getRequest: MT_down_sema(0xb7e30604)

2 2

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/runtime shredder.mx, 1.106, 1.106.2.1
by Stefan Manegold 23 Nov '06

23 Nov '06

Peter, this change seems to break the loading of several benchmark documents; see http://sourceforge.net/tracker/index.php?func=detail&aid=1601761&group_id=5… for details. [... sorry, I should have tested BEFORE checking in ...] Stefan On Thu, Nov 23, 2006 at 01:17:43PM +0000, Stefan Manegold wrote: > Update of /cvsroot/monetdb/pathfinder/runtime > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv31539/runtime > > Modified Files: > Tag: XQuery_0-14 > shredder.mx > Log Message: > > Peter's Dagstuhl bug-fixes > for the Pathfinder shredder > [I hope my interpretation/comment is correct...] > > shredBAT_extend needs to set the current size of shredBAT(s) > before extending them > > > Index: shredder.mx > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/runtime/shredder.mx,v > retrieving revision 1.106 > retrieving revision 1.106.2.1 > diff -u -d -r1.106 -r1.106.2.1 > --- shredder.mx 20 Oct 2006 21:59:08 -0000 1.106 > +++ shredder.mx 23 Nov 2006 13:17:40 -0000 1.106.2.1 > @@ -440,6 +440,7 @@ > shredBAT_extend(shredBAT *sb, > size_t newsize) > { > + shredBAT_setcount(sb, sb->size); > sb->size = newsize; > if (sb->bat->ttype == TYPE_void) { > return GDK_SUCCEED; > > > ------------------------------------------------------------------------- > 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-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0