developers-list May 2007

developers-list@monetdb.org

14 participants
29 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] MonetDB Release Preparation

by Martin Kersten

Dear fellow MonetDB developers/users, we plan to have a new release of the MonetDB software family within the next two weeks, i.e., Feature Freeze: Friday Jun 01 2007 Release: Monday Jun 11 2007 This release cycle is used to reduce the component dependencies, such that we are better prepared to release individual components more frequently. A synopsis of what to expect: MonetDB 5 beta status is dropped and it becomes the sole back-end for the SQL front-end. SQL now supports Persistent Stored Modules. XQuery Update Facility has undergone a large series of stress tests to improve correctness, performance and robustness against concurrent updates. Many bug-fixes based on highly appreciated feedback from our user community. The priorities set for post-release actions as agreed upon by the development team are: shortterm:(summer) SQL GIS geometry model testing and release SQL/XML support development and release PF/SQL exploration (research focus) Skyserver demo website (target 2.7TB online demo) midterm: (fall) Remote SQL execution in a cluster setting SQL adaptive partitioning of large databases XQuery Algebra -> MIL compiler Date/time support in XQuery MonetDB Private BATs policy (kernel modification) lngterm: (fall/spring) XQuery Algebra -> MAL compiler public release of StreetTivo for collaborative media analysis Of course, as always, progress in each of these areas depend on availability of resources and their contribution to our research agenda. We are looking forward to messages from projects based on/exploitation of the MonetDB platform. We plan to add a section in the website to make this work more broadly visible. regards, Martin

15 years, 2 months

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/modules/pftijah pftijah.mx, 1.123, 1.124

by Stefan Manegold

On Tue, May 29, 2007 at 12:20:21PM +0000, Jan Flokstra wrote: > Update of /cvsroot/monetdb/pathfinder/modules/pftijah > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv10231 > > Modified Files: > pftijah.mx > Log Message: > - try to repair pftijah "testcoll2" bug on 64bit archs > > > > Index: pftijah.mx > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/modules/pftijah/pftijah.mx,v > retrieving revision 1.123 > retrieving revision 1.124 > diff -u -d -r1.123 -r1.124 > --- pftijah.mx 25 May 2007 12:34:24 -0000 1.123 > +++ pftijah.mx 29 May 2007 12:20:18 -0000 1.124 > @@ -3267,15 +3267,16 @@ > return GDK_FAIL; > } > > - doc_start = *(oid*)BUNtail(doc_firstpre,r); > - oid tj_nextIndex = tj_docIndex + 1; > + // 64bit ERROR?? doc_start = *(oid*)BUNtail(doc_firstpre,r); ^^^^^^^^^^^^^ No, a bug in the code: BAT doc_firstpre is [oid,int]., i.e., its tail is int, not oid, and int != oid; ======== pathfinder/modules/pftijah/pftijah.mx-73-.COMMAND pf2tijah_node( pathfinder/modules/pftijah/pftijah.mx-74- BAT[oid,str] doc_name, pathfinder/modules/pftijah/pftijah.mx:75: BAT[oid,int] doc_firstpre, ^^^^^^^^^^^^^^^^^^^^^^^^^ pathfinder/modules/pftijah/pftijah.mx-76- BAT[oid,oid] pfpre, pathfinder/modules/pftijah/pftijah.mx-77- BAT[oid,oid] item, pathfinder/modules/pftijah/pftijah.mx-78- BAT[oid,int] kind, pathfinder/modules/pftijah/pftijah.mx-79- BAT[oid,str] doc_loaded) pathfinder/modules/pftijah/pftijah.mx-80- : BAT[void,oid] = CMDpf2tijah_node; pathfinder/modules/pftijah/pftijah.mx-81- "Translate Pathfinder node sequence to tijah node sequence" ======== hence, to access the tail in C, you (obviously!) need to use int doc_start = *(int*) BUNtail(doc_firstpre,r); ^^^ ^^^ if (for what ever reason) doc_start needs to be of type oid instead of int, you need to use oid doc_start = (oid) *(int*) BUNtail(doc_firstpre,r); ^^^ ^^^ ^^^ (as you do below); in fact, you should first check, whether the respective tail value of doc_firstpre is not negative, before you caat it to oid! > + doc_start = (oid)*(int*)BUNtail(doc_firstpre,r); > + oid tj_nextIndex = tj_docIndex + (oid)1; > if ( BATcount(doc_firstpre) > tj_nextIndex ) { > r = BUNfnd(doc_firstpre,&tj_nextIndex); > if ( !r ) { > stream_printf(GDKout,"Cannot do range for tijah-firstpre @ %d.\n",tj_docIndex); > return GDK_FAIL; > } > - doc_end = *(oid*)BUNtail(doc_firstpre,r) - 1; > + doc_end = *(oid*)BUNtail(doc_firstpre,r) - (oid)1; NOPE! either int doc_end = *(int*) BUNtail(doc_firstpre,r) - 1; or oid doc_end = (oid) (*(int*) BUNtail(doc_firstpre,r) - 1); plus a check, whether *(int*) BUNtail(doc_firstpre,r) is > 0 ! Stefan > } else { > doc_end = oid_nil; > } > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > > -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

15 years, 2 months

Re: [Monetdb-developers] [Monetdb-checkins] MonetDB5/conf monetdb5.conf.in, 1.11, 1.12

by Stefan Manegold

Another M4 -> M5 "incompatibility" that should be documented properly in the M4 -> M5 transition documentation: ` While with M4, "mapi_open=true"/"mapi_open=false" works fine, M5 (seems to) require(s) "mapi_open=1"/"mapi_open=0". ` Stefan On Sun, May 27, 2007 at 05:27:33PM +0000, Martin Kersten wrote: > Update of /cvsroot/monetdb/MonetDB5/conf > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv31984 > > Modified Files: > monetdb5.conf.in > Log Message: > Use the proper values for mapi_open > > > Index: monetdb5.conf.in > =================================================================== > RCS file: /cvsroot/monetdb/MonetDB5/conf/monetdb5.conf.in,v > retrieving revision 1.11 > retrieving revision 1.12 > diff -u -d -r1.11 -r1.12 > --- monetdb5.conf.in 17 May 2007 09:51:09 -0000 1.11 > +++ monetdb5.conf.in 27 May 2007 17:27:31 -0000 1.12 > @@ -126,7 +126,7 @@ > # Monet Application Interface Section > #==================================== > mapi_port=0 #default port to address a mserver > -mapi_open=false #should be set to 'true' to allow for > +mapi_open=0 #should be set to '1' to allow for > #remote access to a server > > # SQL Interface Section > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Monetdb-checkins mailing list > Monetdb-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-checkins -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

15 years, 2 months

Re: [Monetdb-developers] [Monetdb-sql-checkins] sql/src/sql random.sql, 1.1, NONE

by Romulo Goncalves

This means that it has to be removed from the Makefile (the compilation crash due this problem). I will remove it, if none disagree. Regards, Romulo Niels Nes wrote: > Update of /cvsroot/monetdb/sql/src/sql > In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv24021 > > Removed Files: > random.sql > Log Message: > removed as random functions moved into the default set (as they have > side effects, which currently cannot be specified in sql) > > > --- random.sql DELETED --- > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Monetdb-sql-checkins mailing list > Monetdb-sql-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-sql-checkins

15 years, 2 months

[Monetdb-developers] Debian/Ubuntu not in testweb?

by Jan Flokstra

Hi All, Is there a specific reason why there is no Debian Linux version in the testweb or was there just no machine available. We are experiencing a couple of very strange compilation and runtime errors with student projects running Ubuntu Linux and wonder if the Pathfinder HEAD is even supposed to work on Ubuntu? Regards, JanF.

15 years, 2 months

[Monetdb-developers] nightly current target missing

by Colin Foss

It appears something bad happened to the overnight builds. i.e. --22:27:57-- http://www.ins.cwi.nl/~fabian/monetdb/tars/latest/current/MonetDB.tar.gz => `/var/tmp/MonetDB-1179984476/MonetDB/MonetDB.tar.gz' Resolving www.ins.cwi.nl... 192.16.196.21 Connecting to www.ins.cwi.nl|192.16.196.21|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 22:27:58 ERROR 403: Forbidden. also, http://monetdb.cwi.nl/testing/projects/monetdb/Current/.DailyBuilds./200705… is empty.

15 years, 2 months

[Monetdb-developers] Infinite loop...

by Romulo Goncalves

Dear developers, I opened a bug related to an infinite loop created by this example: create table t1(id int, name varchar(1024), age int); create table t2(id int, age int); create PROCEDURE p1(id int, age int) BEGIN insert into t2 values(id, age); END; create PROCEDURE p1() BEGIN declare id int, age int; set id = 1; set age = 23; call p1(id, age); END; create trigger test_0 after insert on t2 BEGIN ATOMIC insert into t1 values(1, 'monetdb', 24); call p1(); END; insert into t2 values(0, 24); AS you can see the procedure p1() will do an insertion in t2 which will fire the trigger test_0 again and all the process will be repeated again. I decided to check what happen in another DBMS (I checked postgres because it is used as a reference). Looking to this example http://archives.postgresql.org/pgsql-general/2003-07/msg01530.php It seems postgres has the same problem, but should we consider this a problem or bug? SQL with procedures (function...) can almost be considered a programming language so it is not our responsibility to kill loops created by users SQL code. If an user see a infinite loop he has to construct the schema in such way that the infinite loops are avoided. Another point is the restriction that we created for recursive triggers (we only allow at least one call for each trigger in each statement execution) which I think it is not correct. Imagine that the user has an "if clause" to recursively fire a trigger 10 times and after that 10 times the trigger is not fired anymore. Should we restrict this example in our system? I do not think so. However, If the clause check is wrong and an infinite loop is created it is the user who has to correct his schema. The big conclusion of the day is: More programing language features do we offer to the user less control we have over his SQL code. If everyone agree I will close the bug infinite loop and remove the loop check for triggers. Regards, Romulo

15 years, 2 months

[Monetdb-developers] nightly target contents

by Colin Foss

Sorry if this question is borderline user. Using monetdb-install.sh, what does --nightly=stable actually contain? What does --nightly=current contain? Do the nightly tar files contain source from a sucessful build or simply a CVS checkout? Is a cross-reference between bug number and --nightly=<target> maintained?

15 years, 2 months

Re: [Monetdb-developers] possible bug regarding auto-commit mixing with start transaction?

by Martin Kersten

Hi, Alexandru Toth wrote: > Hi, > > Not in console. But if you create a file , it will show up with command > line bellow. > > mclient -lsql -umonetdb 1.sql Confirmed. > > Or, is Mac OS -speciffic ? No, also on Linux PC. You assume here that auto-commit is re-enabled when the statements fall outside the transaction brackets. The mode change and the consequences should be clearly documented in Mapi. It may indeed be useful to fall-back to auto-commit outside explicit transaction boundaries. regards, Martin > > BR, Alex > > On May 22, 2007, at 11:43 PM, Martin Kersten wrote: > >> Hi, >> >> Bug not confirmed on my Linux PC using >> direct execution at the console, nor >> using MapiClient. >> >> % sys.tbl_xy, sys.tbl_xy # table_name >> % x, y # name >> % int, int # type >> % 2, 4 # length >> [ 0, 0 ] >> [ 1, 1 ] >> [ 2, 2 ] >> [ 3, 3 ] >> [ 4, 4 ] >> [ 5, 5 ] >> [ 6, 6 ] >> [ 7, 7 ] >> [ -1, -100 ] >> [ 8, 8 ] >> [ 9, 9 ] >> [ 10, 10 ] >> >> >> >> Alexandru Toth wrote: >>> Hi, >>> Test script bellow has few transactions, and statements outside any >>> transaction which are not executed (INSERT negative numbers, easy to >>> spot). Is this a bug? Both MySQL and SQLite inserts the row with >>> negative numbers (after replacing "start transaction" with "begin"). >>> Save the script bellow as 1.sql >>> ----------------- >>> start transaction; >>> create table tbl_xy (x int , y int); >>> insert into tbl_xy values (0,0); >>> insert into tbl_xy values (1,1); >>> commit; >>> start transaction; >>> insert into tbl_xy values (2,2); >>> insert into tbl_xy values (3,3); >>> insert into tbl_xy values (4,4); >>> commit; >>> start transaction; >>> insert into tbl_xy values (5,5); >>> insert into tbl_xy values (6,6); >>> insert into tbl_xy values (7,7); >>> commit; >>> insert into tbl_xy values (-1, -100); >>> start transaction; >>> insert into tbl_xy values (8,8); >>> insert into tbl_xy values (9,9); >>> insert into tbl_xy values (10,10); >>> commit; >>> ---------------- >>> Execution of script: >>> macu:~/Desktop alex$ mclient -lsql -umonetdb ~/Desktop/1.sql >>> [ 1 ] >>> [ 1 ] >>> [ 1 ] >>> [ 1 ] >>> [ 1 ] >>> [ 1 ] >>> [ 1 ] >>> [ 1 ] >>> [ 1 ] >>> [ 1 ] >>> [ 1 ] >>> [ 1 ] >>> -------------------- >>> Looking for negative numbers, none found: >>> macu:~/Desktop alex$ mclient -lsql -umonetdb >>> sql>select * from tbl_xy; >>> % sys.tbl_xy, sys.tbl_xy # table_name >>> % x, y # name >>> % int, int # type >>> % 2, 2 # length >>> [ 0, 0 ] >>> [ 1, 1 ] >>> [ 2, 2 ] >>> [ 3, 3 ] >>> [ 4, 4 ] >>> [ 5, 5 ] >>> [ 6, 6 ] >>> [ 7, 7 ] >>> [ 8, 8 ] >>> [ 9, 9 ] >>> [ 10, 10 ] >>> Version: MonetDB Server v5.0.0_beta2_1 >>> BR, Alex >> >

15 years, 2 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

developers-list May 2007