developers-list November 2006

developers-list@monetdb.org

21 participants
43 discussions

[Monetdb-developers] Compiling on Darwin 7

by Fabian Groffen

Is there anyone that can think of a solution for this problem? cc1: warnings being treated as errors /Volumes/Scratch/monetdb/stable/monetdb/src/modules/plain/bat.mx: In function 'local_itoa': /Volumes/Scratch/monetdb/stable/monetdb/src/modules/plain/bat.mx:1253: warning: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t' I mean... is there a difference between "signed size_t" and "ssize_t"? Ehrm. [Orion:src/modules/plain] fabian% uname -a Darwin Orion.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc PowerBook4,3 Darwin [Orion:src/modules/plain] fabian% gcc --version gcc (GCC) 4.0.1 (Apple Computer, Inc. build 5341) 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. Probably just need to compile without -Werror.

14 years, 6 months

[Monetdb-developers] configure & *_config.h include files

by Stefan Manegold

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 |

15 years, 7 months

[Monetdb-developers] Triggers owner..

by Romulo Goncalves

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

15 years, 8 months

Re: [Monetdb-developers] error when running simple Xquery on Windows platform

by Fabian Groffen

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 > > >

15 years, 8 months

[Monetdb-developers] Mapi and locality

by Sándor Héman

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

15 years, 8 months

[Monetdb-developers] Concurrency Problem Mserver

by Robin Aly

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)

15 years, 8 months

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/runtime shredder.mx, 1.106, 1.106.2.1

by Stefan Manegold

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 |

15 years, 8 months

Re: [Monetdb-developers] MonetDB port for Crux Linux

by Martin Kersten

Hello Younes, Thank your very much for this information. We will come back shortly to discuss your experiences and give you early warnings on what to expect next. regards, Martin Kersten Hafri wrote: > Hi guys! > > I would like to inform you that I'm maintaining MonetDB port for Crux > Linux (http://crux.nu/) > at: > http://yhafri.club.fr/crux/index.html > > The package files is here: > http://yhafri.club.fr/crux/monetdb/Pkgfile > > Best Regards > Younès HAFRI >

15 years, 8 months

[Monetdb-developers] MapiClient asynchronous interface?

by Johann Borck

Hi all, I'm using MonetDB as backend for an asynchronous server, and would like to stick to this concurrency model. I'm aware of the TCP/IP module, which supports async io, but as far as I understood it is made for interaction between MonetDB servers. Could someone make an estimation about the effort required to change MapiClient to perform asynchronous operations vs. making use of the TCP/IP module ("faking" another monetdb instance) from a client? My impression from a shallow look at the code is, that the TCP/IP module transfers bats in binary format, whereas mapi-module/MapiClient have to format/parse strings, is that correct? And if, does maybe someone have an idea about the overhead that the string handling of the mapi-interface introduces? Thanks a lot, Johann

15 years, 8 months

[Monetdb-developers] Not descriptive error message

by Robin Aly

Hello all, that is my first mail to this list, so please apologize if I do mistakes. I recently compiled MonetDB on a NFS-home-directory (stupid, now that I think of it). The error message I got was: !FATAL: GDKlockHome: Database lock '.gdk_lock' denied After some investigations I found out that in /cvsroot/monetdb/MonetDB/src/gdk/gdk_posix.mx the original OS-error message was discarded and a simple error-return-value was choosen. I suggest to change it to something like what is attached to this mail. Best regards, Robin -- Robin Aly (PhD student, University Twente) Phone: +31 (53) 489 4520 Fax: +31 (53) 489 2927 email: r.aly(a)ewi.utwente.nl

15 years, 8 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

developers-list November 2006