- developers-list - monetdb.org

[Monetdb-developers] (no subject)
by Roger Erens 24 Jun '05

24 Jun '05

Hi, I had some problems installing MonetDB-4.8.0 on MS Windows XP: the Duesseldorf sourceforge mirror still serves the installer that misses the pqueue stuff. Removing the wrong version via the Add or Remove Programs left a filled folder CWI in the Program Files folder and also a filled folder in my home folder's Application Data folder called MonetDB. Only after removing these and using the installer from the Paris sourceforge mirror I was freed from a lot of strange messages. All in all, the installer should have its version number upped, I think. Hopefully this will lead to up-to-date mirrors. Also, the installer should notify the user of the old files and folders, giving the choice of backing those up, or overwrite them, or whatever seems best. ===================================================================== Choosing MonetDB SQL Server and MonetDB SQL Client from the Start Menu: # Monet Database Server V4.8.0 # Copyright (c) 1993-2005, CWI. All rights reserved. # Compiled for i686-pc-win32/32bit with 32bit OIDs; dynamically linked. # Visit http://monetdb.cwi.nl/ for further information. MonetDB> copying from the documentation->Front ends->SQL web page (http://monetdb.cwi.nl/TechDocs/FrontEnds/SQL/index.html) CREATE USER "voc" WITH PASSWORD 'voc' NAME 'VOC Explorer' SCHEMA "sys"; results in a dialog window, containing: Mserver.exe has encountered a problem and needs to close. We are sorry for the inconvenience. AppName: mserver.exe AppVer: 0.0.0.0 ModName: lib_sql_server.dll ModVer: 0.0.0.0 Offset: 00057cfa If you need to have more info, I'll be happy to try to get it for you... ======================================================================= 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 which is not right on my system, of course. ======================================================================== = Met vriendelijke groet, Roger Erens Euroned Systems 0900-3876633 r.erens(a)eurosys.nl

2 1

[Monetdb-developers] Re: FW: Returned mail: see transcript for details
by Fabian (MonetDB Project) 16 Jun '05

16 Jun '05

Ignacio Hernandez-Ros wrote: > Hello, > > I'll try to send a patch. > > This is what happens when the query is executed in MapiClient. > > [ihr@jo-con-el FRTA2]$ cat > test.xq > <hello>hola</hello> > [ihr@jo-con-el FRTA2]$ MapiClient -lxquery test.xq > <hello>hola</hello> > [ihr@jo-con-el FRTA2]$ > > And this is what happens when the query is executed in MapiClient using mil > language. > > [ihr@jo-con-el FRTA2]$ MapiClient -lmil > # Monet Database Server V4.9.0 > # Copyright (c) 1993-2005, CWI. All rights reserved. > # Compiled for i686-pc-linux-gnu/32bit with 32bit OIDs; dynamically linked. > # Visit http://monetdb.cwi.nl/ for further information. > mil>xquery("xml","<hello>hola</hello>"); > <?xml version="1.0" encoding="utf-8"?> > <XQueryResult> > <hello>hola</hello> > </XQueryResult> > mil> > > The result of an xquery is not a table with rows and columns. Is another > piece of XML that I don't know how to get it back into the PHP code. As far as I know, this should be represented as one column. Maybe it isn't. Sjoerd will know the answer. Perhaps it works better for you in this case if you use the xquery language, instead of mil from your PHP script. Again, I think Sjoerd knows for sure how the response is given shape. > > What you sent me didn't work. Thank you for your support. Are there more > alternatives? > > Regards, > IHR > > Ignacio Hernandez-Ros > XBRL International Inc. - Technology Development > ihr(a)xbrl.org > Cell: +34 609027754

2 1

[Monetdb-developers] Re: FW: Returned mail: see transcript for details
by Fabian (MonetDB Project) 16 Jun '05

16 Jun '05

Ignacio Hernandez-Ros wrote: > Hello, > > I've successfully moved the source to work with PHP5. The only change that I > made was to replace occurrences of OnUpdateInt to OnUpdateLong (two > occurrences) Can you supply a patch easily? Would be great to have it. > > Now I'm in the next problem: > > I wish to execute an xquery and receive the XML output back in the php. > This is the example that I'm doing: > > <?php > if (!extension_loaded('monetdb')) { > $loadedOk = dl('monetdb.so'); > if (!loadedOk) { > die('Module not loaded'); > } > } > $link = monetdb_connect('mil'); > if (!$link) { > die('Could not connect: ' . monetdb_error()); > } > $res = monetdb_query('xquery("xml","<hello>hola</hello>");'); > echo $res; > > while($row = monetdb_fetch_row($res)) { > printf("name=%s htype=%s ttype=%s \n",$row[0],$row[1],$row[2]); > } I'm not sure here, but you can try: $cols = monetdb_num_fields($result); while ($row = @monetdb_fetch_row($res)) { for ($i = 0; $i < $cols; $i++) { print htmlspecialchars($row[$i]); } print "<br />"; } have you tried the query you're executing using MapiClient to see if it results in what you expect? You might need to connect using xquery otherwise, but I'm not sure on that. Regards, Fabian > monetdb_close(); > ?> > > The query is executed but I don't find a way to obtain the xml back to the > php. > > What shall I do? > > Ignacio Hernandez-Ros > XBRL International Inc. - Technology Development > ihr(a)xbrl.org > Cell: +34 609027754 >

1 0

[Monetdb-developers] Re: FW: Returned mail: see transcript for details
by Sjoerd Mullender 16 Jun '05

16 Jun '05

Ignacio Hernandez-Ros wrote: > Does the developers list works? Yes. I just sent a test mail and it arrived promptly. >> I tried to compile MonetDB with php 5.0.4 and I get compilation errors. We have only tried compiling agains PHP version 4 so far. Is it possible for you to use PHP 4? >> I wish to use MonetDB to execute xquery against XBRL taxonomies. You >> can see www.xbrl.org <http://www.xbrl.org/> if you wish. >> >> >> >> In file included from ../../../../common/monet_utils.h:5, >> >> from ../../../../common/stream.h:17, >> >> from ../../C/Mapi.h:6, >> >> from >> ../../../../../../src/mapi/clients/php/Cimpl/php_monetdb.c:52: >> >> ../../../../../monetdb_config.h:637:1: warning: "_POSIX_C_SOURCE" >> redefined This doesn look quite right, but my guess is that it doesn't matter too much. For what it's worth, I get this also. >> In file included from >> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/include/stdio.h:37, >> >> from /usr/include/php/Zend/zend.h:37, >> >> from /usr/include/php/main/php.h:34, >> >> from >> ../../../../../../src/mapi/clients/php/Cimpl/php_monetdb.c:44: >> >> /usr/include/features.h:131:1: warning: this is the location of the >> previous definition >> >> ../../../../../../src/mapi/clients/php/Cimpl/php_monetdb.c:109: >> warning: missing initializer >> >> ../../../../../../src/mapi/clients/php/Cimpl/php_monetdb.c:109: >> warning: (near initialization for `monetdb_functions[22].num_args') >> >> ../../../../../../src/mapi/clients/php/Cimpl/php_monetdb.c:178: >> `OnUpdateInt' undeclared here (not in a function) This is the real error. In PHP 4, OnUpdateInt is declared in Zend/zend_ini.h, in the same block which also declares OnUpdateString. Note that in your output there is no indication that OnUpdateString is not defined. zend_ini.h is include by php_ini.h which is included by php_monetdb.c. -- Sjoerd Mullender

1 0

[Monetdb-developers] test
by Sjoerd Mullender 16 Jun '05

16 Jun '05

test, please ignore. -- Sjoerd Mullender

1 0

[Monetdb-developers] license issues
by Sjoerd Mullender 13 Jun '05

13 Jun '05

There is a problem with the MonetDB and Pathfinder licenses. - The new (1.1) license is not yet available on the main web site; - On the staging web site (stem), the license is available with the wrong URL: .../Legal/MonetDBLicense-1.1/index.html instead of .../Legal/MonetDBLicense-1.1.html. I don't know whether the Development that is also stuck into the stem URL is a problem (that depends on how the URLs get translated when this moves to the real web site), but the ending is certainly a problem. The URL must end with MonetDBLicense-1.1.html and not MonetDBLicense-1.1/index.html. And the same for the Pathfinder license. -- Sjoerd Mullender

1 0

[Monetdb-developers] Installation on Windows
by Harry van Lamoen 03 Jun '05

03 Jun '05

I tried to install the binary (.msi) on XP professional. After installation and trying to start the server I get a message Monet Database Server V4.8.0 !ERROR: module/Client: module(pqueue) load error !ERROR: mvc_init: unable to create system tables !WARNING: BBPincref: range error 178 Any idea. Met vriendelijke groet Harry van Lamoen KORÈN Information Technology http://www.koren.nl

2 1

[Monetdb-developers] About MonetDB's modules
by Rodrigo Schmidt 01 Jun '05

01 Jun '05

Hello, I am PhD student at EPFL, Switzerland, and I am working on database replication. I just started looking at MonetDB and I have a simple doubt. Are modules like the SQL module written in MIL or in C/C++? I downloaded the sources of the SQL front end and I found some files whose extension is ".mx" and which seem to implement the SQL translator into MIL. The code looks pretty much like C++. Moreover, I read somewhere in your web page that two-phase-locking is implemented outside the database kernel. Where exactly is it implemented for the SQL front end? Thank you very much in advance! Best regards, Rodrigo Schmidt

3 5

[Monetdb-developers] DBD::monetdb: DBI registration
by Steffen Goeldner 01 Jun '05

01 Jun '05

I'd like to register DBD::monetdb as an official DBI driver: <http://search.cpan.org/~timb/DBI-1.48/lib/DBI/DBD.pm#Registering_a_new_driv…> Of course, the driver and prefix names should be stable. I think, after the last change from 'monet' to 'monetdb', this is the case. Any objections? Steffen

2 1

[Monetdb-developers] SQL upgrade instructions
by Sjoerd Mullender 27 May '05

27 May '05

I wrote the following text to help with upgrading the SQL database. I think something like this should be prominently displayed (or a prominently displayed pointer to the text) so that people read it *before* attempting to upgrade. Comments? Dumping the SQL database. ------------------------- Start the SQL Server and SQL Client as usual. In the SQL Client, type the following three commands. Type them without any extra white space: >.../dump.sql \D > That is, first a line consisting of a greater than symbol followed by the full (!) name of the file in which you want to store the dump. This will redirect future output to the file mentioned. Then a line consisting of just backslash-capital D. This command does the actual dump which is, because of the previous line, stored in the dump file. And finally a line with just a greater than symbol. This closes the file and redirects the output again to the screen. It is also possible to dump from the command line. Start a SQL Server, and then issue the command MapiClient -lsql -umonetdb -Pmonetdb --dump > dump.sql This command will connect to the SQL Server and dump the database into the file dump.sql in the current directory. Restoring the SQL database. --------------------------- After having dumped the database per the preceding instructions, it is possible to restore the database using the following commands. Start the SQL Server and SQL Client as usual. In the SQL Client, type the following command. <.../dump.sql That is, a less than symbol followed by the full (!) path name of the dump file that was produced using the dump instructions. It is also possible to restore from the command line. Start a SQL Server, and then issue the command MapiClient -lsql -umonetdb -Pmonetdb < dump.sql

3 5

[Monetdb-developers] help! where i get manual
by liudawei 26 May '05

26 May '05

Hi: I am a starter on MonetDB,I am interesting in this excllent Database.My questions are is: 1) where I can get the manual of Monet Server and SQL Front End. best regards Peter Chen --------------------------------- Do You Yahoo!? 注册世界一流品质的雅虎免费电邮

2 1

Re: [Monetdb-developers] Install MonetDB-server on SLES 9 64 bit
by Stefan.Manegold＠cwi.nl 25 May '05

25 May '05

Dear Maggie, Thank you very much for being interestedn in MonetDB, and please accept our apologies for the inconvenience you experience. Indeed, we don not have a precompiled install (RPM) for 64-SuSE, yet; you could try the Fedora Core version, but I have no idea, whether it will work on SuSE... The yacc/lex errors you see can savely be ignored. The linker error is the real problem. Unfortunately, I cannot say right now, what the problem is, but it might be related to whether you have your SuSE system installed/configure to support the development/compilation of both, 322- and 64-bit programs (basically, are the system libraries available in both vorsions, or only in one). By default, MonetDB (tries to) compile 32-bit, even on a 64-bit Linux system (admittedly, this is not necessairly intuitive, but we haven't found time, yet, to change this...). To compile for 64-bit, you nedd to run configure with the "--enable-bits=64" option. Hence, my questions would be a) Do you know, whether your system has both 32-bit and 64-bit libraries installed? b) Did you run configure with or without the "--enable-bits=64" option? I hope, that these information will help us, to locate and solve the problem. Kind Regards, Stefan > I have looked for a precompiled install for Suse 9 64 bit but alas cannot > find one, so I changed to compiling from source and during the make I am > getting the following errors > > conflicts: 32 reduce/reduce > conflicts: 32 reduce/reduce > y.tab.c: In function `int yyparse()': > y.tab.c:1868: warning: label `yyerrlab1' defined but not used > /usr/lib64/libbz2.so: could not read symbols: Invalid operation > collect2: ld returned 1 exit status > make[4]: *** [libstream.la] Error 1 > make[3]: *** [all] Error 2 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > any help would be greatly appreciated. > > Maggie > > > > ------------------------------------------------------- > SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate > online with coworkers and clients while avoiding the high cost of travel and > communications. There is no equipment to buy and you can meet as often as > you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click > _______________________________________________ > Monetdb-developers mailing list > Monetdb-developers(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-developers > > > > -- | 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] Install MonetDB-server on SLES 9 64 bit
by Margaret E Johnson 25 May '05

25 May '05

I have looked for a precompiled install for Suse 9 64 bit but alas cannot find one, so I changed to compiling from source and during the make I am getting the following errors conflicts: 32 reduce/reduce conflicts: 32 reduce/reduce y.tab.c: In function `int yyparse()': y.tab.c:1868: warning: label `yyerrlab1' defined but not used /usr/lib64/libbz2.so: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[4]: *** [libstream.la] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 any help would be greatly appreciated. Maggie

1 0

[Monetdb-developers] [Fwd: php api]
by MonetDB Project 14 Mar '05

14 Mar '05

Anybody know anything about the status of the PHP Mapi interface? -- Sjoerd Mullender <Sjoerd.Mullender(a)cwi.nl>

1 0

[Monetdb-developers] problem with ODBC driver
by G.G. Dijkstra 12 Mar '05

12 Mar '05

L.S., I have installed MonetDB after reading the article in Computable. Everythings seems to work (SQP client, Mknife sql demo) but I have a problem with ODBC. Mknife MIL 4.3 demo reports "connection failed" Microsoft ODBC data source adminstrator: when I select the MonetDB driver and click on 'configure' I get the error message ' teh setup routines for the MonetDB ODBC driver ODBC driver could not be loaded due to system error code 126." and next: "could not load the setup or translator library" I also tried to connect the database from MS-Excel as showed in the example on the MonetDB website. Same error (126). Can you help to solve this problem? (I use Windows 2000 prof sr4) Thanks in advance, Gerard Dijkstra

2 1

[Monetdb-developers] kill client mil command
by Niels Nes 22 Feb '05

22 Feb '05

MonetDB developers Are there any users of the kill client mil command (in src/modules/plain/kernel.mx). If not I'd like to remove it as the required pthread functionality (pthread_kill) isn't available with the same semantics on all platforms. Also just killing a client may lead to crashing servers (see bug 1145484). 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

2 1

[Monetdb-developers] No more automatic testing on Windows
by Stefan.Manegold＠cwi.nl 17 Feb '05

17 Feb '05

Hi MonetDB developers, As of now, I stop nightly automatic testing on Windows! The cost of maintaining it be far exceed what I can afford. Admittedly, I am everything but a Windoze guru, and I do not know any more, how to cope with all the problems. Since yesterday, not only tests tend to hang, but also the "tlist" tool that I use to check the process table for hanging tests now hangs "consistently". Sorry, but for me there is no other way than giving up. Volanteers are welcome to pick-up this task! Of course, this also limits our support for MonetDB on Windows. Stefan ps: Yes, this is a "cry for help" ... -- | 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

Re: [Monetdb-developers] HAVE_* conditionals for mapi/clients
by Sjoerd Mullender 11 Feb '05

11 Feb '05

Niels Nes wrote: > On Fri, Feb 11, 2005 at 05:27:36PM +0100, Sjoerd Mullender wrote: > >>Niels, why did you add the HAVE_* conditionals to the mapi/clients >>Makefile.ag? >> >>As far as I can see, creating or installing the Python, Perl, and TCL >>files is not dependent on the presence of the interpreters. It's only >>when you go one level deeper, into the Cimpl and DBD directories that >>you get these dependencies. The Cimpl directories are already protected >>by HAVE_*_SWIG conditionals, so only the perl/DBD directory would need >>to be protected with a conditional. > > > this is needed for rpm. Ie no perl -> no MonetDB_perl rpm. So incase there > is no perl we do not install the perl files. > Indeed this is abit overkill but is it a problem that the perl files > are not installed when perl is missing? The "problem" is (as always ;-) Windows. The question is, should I install the Perl, Python, and TCL files or not? I used to install the Perl and Python files, but since they aren't built if I don't specify HAVE_PERL and HAVE_PYTHON, the installer complains that the files don't exist. I think I'll just remove them from the installer. Of course, we *know* that we have Python, since it is required for building (autogen). -- Sjoerd Mullender <sjoerd(a)acm.org>

1 0

[Monetdb-developers] HAVE_* conditionals for mapi/clients
by Sjoerd Mullender 11 Feb '05

11 Feb '05

Niels, why did you add the HAVE_* conditionals to the mapi/clients Makefile.ag? As far as I can see, creating or installing the Python, Perl, and TCL files is not dependent on the presence of the interpreters. It's only when you go one level deeper, into the Cimpl and DBD directories that you get these dependencies. The Cimpl directories are already protected by HAVE_*_SWIG conditionals, so only the perl/DBD directory would need to be protected with a conditional. -- Sjoerd Mullender <sjoerd(a)acm.org>

1 0

[Monetdb-developers] New release-candidates "MonetDB-4.6.0_rc0" & "MonetDB-SQL-2.6.0_rc0"
by Stefan.Manegold＠cwi.nl 21 Jan '05

21 Jan '05

[ Please accept my apologies for this "broadcast mail". ] [ Future announcements concerning MonetDB and its elated projects will only ] [ go to the monetdb-announce mailing list ] [ (http://lists.sourceforge.net/lists/listinfo/monetdb-announce) so please ] [ do not forget to subscribe there, in case you are not subscribed, yet. ] Dear MonetDB users and developers (and those who want to become either or both ;-), In preparation for the release of the new MonetDB-4.6.0 & MonetDB-SQL-2.6.0 (planned for February 14 2005, cf. http://monetdb.cwi.nl/Development/Roadmap/) I just prepared the respective release-candidate branches "MonetDB_4-6" & "SQL_2-6" in our CVS repository on SourceForge (http://sourceforge.net/cvs/?group_id=56967) The first release-candidate versions are tagged as "MonetDB_4-6-0_rc0" & "SQL_2-6-0_rc0", respectively. Pre-packaged source- & binary-distributions are not available, yet, but they will be made available for download with in a few days, and announced separately. All users are highly advised (actually "requested" ;-) to use the new release-candidate( branche)s as of now (see below for details concerning CVS checkout/update). Please do not hesitate to ask for support and report bugs or problems, preferably via the bug tracing system at SourceForge (http://sourceforge.net/tracker/?group_id=56967&atid=482468) or via email to monet(a)cwi.nl; however, please always state clearly, which version of MonetDB-SQL you are using (as the Mserver tells you at startup)! Any support for the now obsolete "MonetDB-4.4.x" & "MonetDB-SQL_2.4.x" will stop as of now. Contents: ========= - Background - Change Logs - CVS update - CVS check-ins - Testing Background ========== Trying to stick to our road-map (http://monetdb.cwi.nl/Development/Roadmap/) we plan the release of MonetDB-4.6.0 + MonetDB-SQL-2.6.0 for February 14 2004. As with earlier "pre-releases" of MonetDB & MonetDB-SQL, we start with "release-candidates" to allow testing by a larger group of users before we finally make the actual releases. Hence, starting to use the release-candidates as soon as possible will only be for your own benefit ;-) According to our TestWeb (http://monetdb.cwi.nl/Development/TestWeb/) both MonetDB and SQL are doing quite well right now; hence, I don't expect any (major) problems. Change Logs =========== Information about the major changes since MonetDB-4.4.2 / MonetDB-SQL_2.4.2 will follow with the pre-packaged source- & binary-distributions within a few days. CVS update ========== If you are already using the release branches "MonetDB_4-4-0" and "SQL_2-4-0" from CVS, simply run "cvs update -dP" to update your code to this new release candidate version. If you are already using a CVS version of MonetDB/MonetDB-SQL, you can run either "cvs update -dP -rMonetDB_4-6-0_rc0" "cvs update -dP -rSQL_2-6-0_rc0" to get this very release candidate, or "cvs update -dP -rMonetDB_4-6" "cvs update -dP -rSQL_2-6" to get the most recent version in the release candidate branch. The difference is, that via the first option, you are "stuck" with this very release candidate, i.e., future "cvs update -dP" (without "-r..." or "-A") will not change your checked-out version; via the second option, however, future "cvs update -dP" will get you again the latest version in the release candidate branch. CVS check-ins ============= All bug fixes (and only these!) on MonetDB and/or SQL are bound to go to the new release-candidate branches ("MonetDB_4-6"/"SQL_2-6"), only. On a regular basis, I will then take care of propagating these bug-fixes back to the respective main branch. All new features are bound to go to the main branches (and only there!). This release-candidate branch will become the new stable/release branch within the next 3 weeks. Testing ======= Nightly automatic testing will proceed "as usual". See http://monetdb.cwi.nl/Development/TestWeb/ for details. As usually, any (constructive;-) comments and feedback are more than welcome! Enjoy! 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] Mserver hangs on quit(); on RedHat 8.0 (psyche)
by Stefan.Manegold＠cwi.nl 15 Dec '04

15 Dec '04

Hi again, with the latest MonetDB 4.5.0 on RedHat 8.0 (psyche), Jan (F.;-) experiences a "consistently" hang of the Mserver, once he tries to quit it. See below for details. It did work with older versions of MonetDB, but we hanven't locate more precisely, yet, since which version/code change the hang occurs. My question is, has anybody else ever experienced similar problems? I now vaguely recall, that there might have been some related issue, but I don't remember the details, yet --- could someone who does refresh my mind? Thank you very much in advance! Stefan Forwarded message: > From flokstra(a)cs.utwente.nl Wed Dec 15 09:30:02 2004 > X-Sieve: CMU Sieve 2.2 > Content-Type: text/plain; > charset="us-ascii" > From: Jan Flokstra <flokstra(a)cs.utwente.nl> > Organization: University Twente Enschede > To: Stefan.Manegold(a)cwi.nl (Stefan Manegold) > Subject: Re: Monet problem > Date: Wed, 15 Dec 2004 09:27:45 +0100 > User-Agent: KMail/1.4.3 > References: <20041213155606.9656241044(a)draco.ins.cwi.nl> > In-Reply-To: <20041213155606.9656241044(a)draco.ins.cwi.nl> > Cc: "Peter Boncz" <P.Boncz(a)cwi.nl> > MIME-Version: 1.0 > Old-Content-Transfer-Encoding: quoted-printable > Message-Id: <200412150927.47729.flokstra(a)cs.utwente.nl> > X-Spam-Score: -4.9 () BAYES_00 > X-Scanned-By: milter-spamc/0.25.320 (styx.cwi.nl [192.16.191.21]); Wed, 15 Dec 2004 09:28:11 +0100 > X-Scanned-By: MIMEDefang 2.44 > X-Spam-Flag: NO > X-Spam-Status: NO, hits=0.00 required=5.00 > X-Spam-Level: > X-Spam-Report: Content analysis details: (0.0 points, 5.0 required) > Tests (points, rulename, description): > ____ > X-Virus-Scanned: by cwi.nl (CWI/$Revision: 1.25 $) > Content-Transfer-Encoding: 8bit > > Hi Stefan, > > I am using Redhat Linux, version (uname -a) > > Linux psyche 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux > > and the default compilers on this version. I made an strace of the Mserver > and got the following output (just the tail) > It looks it never returns from the rt_sigsuspend() syscall and this is > indeed very strange! > > Regards, Jan. > > > brk(0x8175000) = 0x8175000 > brk(0x8177000) = 0x8177000 > brk(0x8178000) = 0x8178000 > brk(0x8179000) = 0x8179000 > brk(0x817b000) = 0x817b000 > brk(0x817d000) = 0x817d000 > brk(0x817f000) = 0x817f000 > brk(0x8180000) = 0x8180000 > brk(0x8181000) = 0x8181000 > brk(0x8182000) = 0x8182000 > brk(0x8183000) = 0x8183000 > brk(0x8185000) = 0x8185000 > brk(0x8186000) = 0x8186000 > close(7) = 0 > open("/usr/local/flokstra/lib/MonetDB", > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7 > fstat64(7, {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0 > fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 > lseek(7, 0, SEEK_SET) = 0 > getdents64(0x7, 0x80a1b90, 0x1000, 0x4006c4eb) = 4096 > open("/usr/local/flokstra/lib/MonetDB/trans.mil", O_RDONLY|O_LARGEFILE) = 8 > fstat64(8, {st_mode=S_IFREG|0755, st_size=70, ...}) = 0 > fstat64(8, {st_mode=S_IFREG|0755, st_size=70, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x4045f000 > read(8, "# This module is generated using"..., 4096) = 70 > read(8, "", 4096) = 0 > close(8) = 0 > munmap(0x4045f000, 4096) = 0 > close(7) = 0 > open("/usr/local/flokstra/lib/MonetDB", > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7 > fstat64(7, {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0 > fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 > lseek(7, 0, SEEK_SET) = 0 > getdents64(0x7, 0x80a1b90, 0x1000, 0x400709c6) = 4096 > getdents64(0x7, 0x80a1b90, 0x1000, 0x400709c6) = 2504 > open("/usr/local/flokstra/lib/MonetDB/lib_trans.so", O_RDONLY) = 8 > read(8, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\314\16"..., 1024) = > 1024 > fstat64(8, {st_mode=S_IFREG|0755, st_size=78034, ...}) = 0 > old_mmap(NULL, 16136, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x419f7000 > mprotect(0x419fa000, 3848, PROT_NONE) = 0 > old_mmap(0x419fa000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8, > 0x2000) = 0x419fa000 > close(8) = 0 > write(1, "MonetDB>", 8MonetDB>) = 8 > fstat64(0, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x4045f000 > read(0, quit(); > "quit();\n", 1024) = 8 > write(6, "\200\20G@\2\0\0\0\0\0\0\0\222\253\0@\304\363\377\277\300"..., 148) = > 148 > rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 > rt_sigsuspend([] > > > -- | 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] "pseudo" nested BATs
by Stefan.Manegold＠cwi.nl 15 Dec '04

15 Dec '04

Hi MonetDB developers and users, sorry for this "blunt" posting, but I thought, the problem, respectively the solution/recommendation that will hopefully be initiated by this question, might be interesting for some more of you: Triggered by a question from Agustin, I noticed that I (believe it or not ;-) apparently lack some knowledge of / experiences with MonetDB/MIL: Consider you have a variable "a" holding a (possible transient) BAT, and another variable "b" holding a second BAT, which happens to be a view of the first one. Both BATs haven't been baptized ("rename()"), yet; hence they still hold there default names: var a := new(void,int).seqbase(0(a)0).insert(nil,1).insert(nil,2).access(BAT_READ); var b := reverse(a); print(a); #-----------------# # h tmp_29 # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(b); #-----------------# # t tmp_29 # name # int void # type #-----------------# [ 1, 0@0 ] [ 2, 1@0 ] Then, these BATs should be gathered in a "container"-BAT. Since (persistent) nested BATs have disappeared (for good reasons!), we do this by gathering the BAT's name in the container: var c := new(void,str).seqbase(10@0); c.insert(nil,bbpname(a)).insert(nil,bbpname(b)); print(c); #-------------------------# # h tmp_28 # name # void str # type #-------------------------# [ 10@0, "tmp_29" ] [ 11@0, "tmp_29" ] Since the second BAT is only a view of the first one, they share not only the same memory/storage, but also the same (bbp-)name; hence, they are not distinguishable by (only) their (bbp-)names, and thus the container c actually contains the first BAT twice iso each BAT once: print(bat(fetch(c,0))); #-----------------# # h tmp_29 # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(bat(fetch(c,1))); #-----------------# # h tmp_29 # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(bbpname(a)); [ "tmp_29" ] print(bbpname(b)); [ "tmp_29" ] Obviously, the problem can be solved/avoided by baptizing the two BATs, and hence making them unique "individuals": rename(a,"BAT_a"); rename(b,"BAT_b"); print(bbpname(a)); [ "BAT_a" ] print(bbpname(b)); [ "BAT_b" ] c.insert(nil,bbpname(a)).insert(nil,bbpname(b)); print(c); #-------------------------# # h tmp_28 # name # void str # type #-------------------------# [ 10@0, "tmp_29" ] [ 11@0, "tmp_29" ] [ 12@0, "BAT_a" ] [ 13@0, "BAT_b" ] print(bat(fetch(c,0))); !ERROR: interpret_params: print(param 1): invalid BAT. print(bat(fetch(c,1))); !ERROR: interpret_params: print(param 1): invalid BAT. print(bat(fetch(c,2))); #-----------------# # h BAT_b # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(bat(fetch(c,3))); #-----------------# # t BAT_b # name # int void # type #-----------------# [ 1, 0@0 ] [ 2, 1@0 ] My question is now: - Is this the only solution, or am I just not aware of another command iso bbpname() that would return unique "default" name for non-renamed view? Of course, given the fact that only MonetDB itself has control over the default "tmp_*" names, it is always recommendable to assign names that you can control yourself, whenever you use a BAT's name as its only reference... 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

Re: [Monetdb-developers] php
by Arjan Scherpenisse 08 Sep '04

08 Sep '04

De extension_dir .ini variabele kan maar 1 pad bevatten, helaas niet meerdere paden gescheiden door ':'s :(... En de waarde van extension_dir alleen op MONETDB_PREFIX/share/MonetDB/php zetten lijkt me ook geen optie omdat dan andere PHP applicaties gaan breken... Arjen P. de Vries wrote: > hoi Arjan, > > De variable extension_dir kan ook gezet worden in php.ini of httpd.conf > (volgens http://aspn.activestate.com/ASPN/docs/PHP/function.ini-set.html) > > misschien dat het dan geen probleem is, als het monet-path wordt toegevoegd > aan php.ini (even ervanuitgaand dat dat ook per-user kan)? > > Groetjes, > > Arjen > > | De monetdb.so file moet echt in PHP_EXTENSION_DIR staan, anders kan de > | module niet worden gebruikt binnen PHP. Hoe zullen we dit fixen? Goed > | documenteren, of mischien een phpinstall.sh scriptje toevoegen wat het > | voor je regelt (wat als root moet worden uitgevoerd)? > | -- > | Arjan Scherpenisse > | > | Centrum voor Wiskunde en Informatica, > | Amsterdam, the Netherlands > | > | > | ------------------------------------------------------- > | This SF.Net email is sponsored by BEA Weblogic Workshop > | FREE Java Enterprise J2EE developer tools! > | Get your free copy of BEA WebLogic Workshop 8.1 today. > | http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > | _______________________________________________ > | Monetdb-developers mailing list > | Monetdb-developers(a)lists.sourceforge.net > | https://lists.sourceforge.net/lists/listinfo/monetdb-developers > | -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

2 2

[Monetdb-developers] php
by Arjan Scherpenisse 08 Sep '04

08 Sep '04

De monetdb.so file moet echt in PHP_EXTENSION_DIR staan, anders kan de module niet worden gebruikt binnen PHP. Hoe zullen we dit fixen? Goed documenteren, of mischien een phpinstall.sh scriptje toevoegen wat het voor je regelt (wat als root moet worden uitgevoerd)? -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

1 0

[Monetdb-developers] mapi: how to check mil query on errors?
by Arjan Scherpenisse 19 Aug '04

19 Aug '04

For SQL code, I check now with: hdl = mapi_query(mid, "very wrong query."); while( mapi_next_result(hdl) ) { if (mapi_result_error(hdl)) { // error handling here how to do this equivalent for mil queries? Or dont we need mil queries anymore? My personal opinion is to keep doing it the old way for mil-type queries (if (mapi_error()) etc), but that does not seem to work... -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

2 1

[Monetdb-developers] Weird server/client behaviour?
by Fabian 18 Aug '04

18 Aug '04

Because I don't really know if it's a bug on whose side, I decided to at least put in the issue via this list. When I try to load the VOC dataset using the JdbcClient with the new -Xbatching flag, the client hangs when it wants to send its last batch. I'm batching in chunks of 8000 statements. Research pointed out that the Java streams are trying to write data to monet, but it simply can't write it, and locks. I pinned down the problem to be in the very low level code regions which are outside of the Java reachable scope and go into the level of the operating system. It just cannot write to the stream. Monet on the other hand seems to be waiting for data. When I use a smaller dataset the batching goes fine. Any clues on what to look for? GDB couldn't help me out much.

1 0

[Monetdb-developers] Re: DBI
by Arjan Scherpenisse 10 Aug '04

10 Aug '04

Martin Kersten wrote: > That's a real pity. Would it require many changes? > Otherwise, we would have to invalidate the perl API > in the upcoming release. I dont know if it requires many changes. The reply-parsing code in monet.pm looks quite 'unstable' to me; I have not found the problem yet. In my opinion it would be better to base programming language APIs on the existing libMapi C code. That way protocol changes etc. only need to be implemented in a single place... Anyway I do not think I have much time to look further into this, I have a thesis to finish ;-) Arjan > > Arjan Scherpenisse wrote: > >> Martin Kersten wrote: >> >>> Does it run against our current DBI? >> >> >> >> No, it does not run. Connecting works, and executing queries too, but >> fetching results from queries does not. >> >> It is likely that this is the case because it is a pure-perl >> implementation and it is not up-to-date with some of the changes in >> the protocol lately. >> >> Even the simple test script which comes with the current >> implementation does not run anymore :( >> >> Arjan >> > -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

2 1

[Monetdb-developers] How to create Tests
by Stefan.Manegold＠cwi.nl 15 Jul '04

15 Jul '04

Hi, I haven't had any time, yet, to prepare a real HowTo on this topic, but for those of you who are interested, here's a trace of what I did to make Arjan's sql/src/test/bugs/bug-sf-990096.sql script into a "real" test. Stefan ======== 14:51:06 manegold@draco:~/Monet/4.3/sql $ echo 'bug-sf-990096' >> src/test/bugs/Tests/All 14:51:13 manegold@draco:~/Monet/4.3/sql $ echo '$RELSRCDIR/../bug-sf-990096.sql' > src/test/bugs/Tests/bug-sf-990096.sql.src 14:51:21 manegold@draco:~/Monet/4.3/sql $ Mtest_sql src/test/bugs bug-sf-990096 IGNORE = ^# TIMEOUT = 60 RECURSIVE = 0 CONTEXT = -C1 ACCURACY = 1 MONET_SOURCE = /ufs/manegold/Monet/4.3/MonetDB MONET_BUILD = /var/tmp/_BUILD_MONET_GNU_32_d__ MONET_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ TSTSRCBASE = /ufs/manegold/Monet/4.3/sql TSTBLDBASE = /var/tmp/_BUILD_SQL_GNU_32_d__ TSTTRGBASE = /var/tmp/_PREFIX__GNU_32_d__ SQL_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ SQLCLIENT = MapiClient --language=sql MAPICLIENT = MapiClient X100CLIENT = x100run_mapi MAPIPORT = 40891 SQLPORT = 52395 GDK_DEBUG = 10 MONET_MOD_PATH = /var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB SQL_LOGDIR = /var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/log GDK_DBFARM = /var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/dbfarm setMONET_MOD_PATH = --set "monet_mod_path=/var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB" MAPI_MIL = /var/tmp/_BUILD_MONET_GNU_32_d__/src/mapi/mapi.mil SQL_SERVER = sql_server SQL_SERVER_MIL = /var/tmp/_BUILD_SQL_GNU_32_d__/src/backends/monet4/sql_server.mil MDIFF = /var/tmp/_PREFIX__GNU_32_d__/bin/Mdiff : Mdiff MSERVER = /var/tmp/_PREFIX__GNU_32_d__/bin/Mserver : Mserver "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --debug=10 --set "monet_mod_path=/var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB" --set "gdk_dbfarm=/var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/dbfarm" --set "sql_logdir=/var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/log" --set mapi_port=40891 --set sql_port=52395 --set monet_prompt= --trace MTIMEOUT = /var/tmp/_PREFIX__GNU_32_d__/bin/Mtimeout : Mtimeout -timeout 60 MSHUTDOWN = /var/tmp/_PREFIX__GNU_32_d__/bin/Mshutdown.py : Mshutdown.py "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=40891 PYTHON = /usr/bin/python : python SQL_CLIENT = /var/tmp/_PREFIX__GNU_32_d__/bin/MapiClient : MapiClient --language=sql -u monetdb -P monetdb --host=draco --port=52395 X100_CLIENT = : x100run_mapi -u monetdb -P monetdb "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=40891 MAPI_CLIENT = /var/tmp/_PREFIX__GNU_32_d__/bin/MapiClient : MapiClient -u monetdb -P monetdb "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=40891 Bits: 32bit Modules: ('main', 'kernel', '_kernel', 'arith', '_arith', 'str', '_str', 'uchr', '_uchr', 'bat', '_bat', 'algebra', '_algebra', 'sys', '_sys', 'trans', '_trans', 'streams', 'xtables', 'mkey', 'profiler', 'aggr', 'aggrX3', 'alarm', 'ascii_io', 'bat_arith', 'blob', 'decimal', 'enum', 'lock', 'mmath', 'monettime', 'radix', 'stats', 'tcpip', 'unix', 'url', 'counters', 'pcl', 'bitset', 'bitvector', 'cluster', 'iterator', 'malalgebra', 'mel', 'mprof', 'oo7', 'qt', 'salgebra', 'tpcd', 'vector', 'wisc', 'ddbench', 'bat_mmath', 'bat_cast', 'array', 'color', 'image', 'txtsim', 'calib', 'mapi', 'sql_server', 'pf_support') Running tests ['bug-sf-990096'] in directory /ufs/manegold/Monet/4.3/sql/src/test/bugs. 14:51:29> src/test/bugs/bug-sf-990096.sql (<=240s) ... 1.167s bug-sf-990096.stable.out.FILTERED and bug-sf-990096.test.out.FILTERED differ SIGNIFICANTLY! bug-sf-990096.stable.err.FILTERED and bug-sf-990096.test.err.FILTERED differ SIGNIFICANTLY! !ERROR: Testing FAILED SIGNIFICANTLY ! 1 out of 1 tests produced SIGNIFICANTLY different output First, check the testing results in /var/tmp/_PREFIX__GNU_32_d__/mTests/index.html ! Then, fix the problems by: - fixing sources and test scripts - fixing stable output by hand - approving test output by Mapprove.py (cf. Mapprove.py -?) After that, re-run Mtest. 14:51:32 manegold@draco:~/Monet/4.3/sql $ Mapprove_sql src/test/bugs bug-sf-990096 FORCE = 0 RECURSIVE = 0 EXTENSION = ['out', 'err'] SYSTEM = MONET_SOURCE = /ufs/manegold/Monet/4.3/MonetDB MONET_BUILD = /var/tmp/_BUILD_MONET_GNU_32_d__ MONET_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ TSTSRCBASE = /ufs/manegold/Monet/4.3/sql TSTBLDBASE = /var/tmp/_BUILD_SQL_GNU_32_d__ TSTTRGBASE = /var/tmp/_PREFIX__GNU_32_d__ SQL_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ Running tests ['bug-sf-990096'] in directory /ufs/manegold/Monet/4.3/sql/src/test/bugs. Approving src/test/bugs/bug-sf-990096.test.out -> stable.out (creating new file) patching file /ufs/manegold/Monet/4.3/sql/src/test/bugs/Tests/bug-sf-990096.stable.out Approving src/test/bugs/bug-sf-990096.test.err -> stable.err (creating new file) Mapprove.py Warning: Skipping new (error) message: "+ERROR = !Column: a.i unknown" patching file /ufs/manegold/Monet/4.3/sql/src/test/bugs/Tests/bug-sf-990096.stable.err First, run 'cvs -q diff to check what you have changed. Then, re-run Mtest.py. In case (some of) the skipped error messages are correct/expected, re-run Mapprove.py with -f to force their approval. 14:51:51 manegold@draco:~/Monet/4.3/sql $ joe src/test/bugs/Tests/bug-sf-990096.stable.??? Processing '/ufs/manegold/.joerc'...done Processing '/ufs/manegold/.joerc'...done File src/test/bugs/Tests/bug-sf-990096.stable.err not changed so no update needed. 14:52:45 manegold@draco:~/Monet/4.3/sql $ diff -u src/test/bugs/Tests/bug-sf-990096.stable.out{~,} --- src/test/bugs/Tests/bug-sf-990096.stable.out~ 2004-07-13 14:52:43.000000000 +0200 +++ src/test/bugs/Tests/bug-sf-990096.stable.out 2004-07-13 14:52:43.000000000 +0200 @@ -27,6 +27,12 @@ # 0, # id [ 1, 1 ] +# i, i # name +# mediumint, mediumint # type +# 1, # tuplecount +# 0, # id +[ 1, 1 ] + # 14:51:31 > # 14:51:31 > Done. # 14:51:31 > 14:52:54 manegold@draco:~/Monet/4.3/sql $ diff -u src/test/bugs/Tests/bug-sf-990096.stable.err{~,} --- src/test/bugs/Tests/bug-sf-990096.stable.err~ 2004-07-13 14:52:36.000000000 +0200 +++ src/test/bugs/Tests/bug-sf-990096.stable.err 2004-07-13 14:52:36.000000000 +0200 @@ -56,10 +56,6 @@ # 14:51:30 > Mtimeout -timeout 60 MapiClient --language=sql -u monetdb -P monetdb --host=draco --port=52395 < bug-sf-990096.sql # 14:51:30 > -MAPI = monetdb@draco:52395 -ACTION= read_into_cache -QUERY = SELECT a.i FROM - # 14:51:31 > # 14:51:31 > Done. 14:52:58 manegold@draco:~/Monet/4.3/sql $ Mtest_sql src/test/bugs bug-sf-990096 IGNORE = ^# TIMEOUT = 60 RECURSIVE = 0 CONTEXT = -C1 ACCURACY = 1 MONET_SOURCE = /ufs/manegold/Monet/4.3/MonetDB MONET_BUILD = /var/tmp/_BUILD_MONET_GNU_32_d__ MONET_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ TSTSRCBASE = /ufs/manegold/Monet/4.3/sql TSTBLDBASE = /var/tmp/_BUILD_SQL_GNU_32_d__ TSTTRGBASE = /var/tmp/_PREFIX__GNU_32_d__ SQL_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ SQLCLIENT = MapiClient --language=sql MAPICLIENT = MapiClient X100CLIENT = x100run_mapi MAPIPORT = 46225 SQLPORT = 53058 GDK_DEBUG = 10 MONET_MOD_PATH = /var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB SQL_LOGDIR = /var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/log GDK_DBFARM = /var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/dbfarm setMONET_MOD_PATH = --set "monet_mod_path=/var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB" MAPI_MIL = /var/tmp/_BUILD_MONET_GNU_32_d__/src/mapi/mapi.mil SQL_SERVER = sql_server SQL_SERVER_MIL = /var/tmp/_BUILD_SQL_GNU_32_d__/src/backends/monet4/sql_server.mil MDIFF = /var/tmp/_PREFIX__GNU_32_d__/bin/Mdiff : Mdiff MSERVER = /var/tmp/_PREFIX__GNU_32_d__/bin/Mserver : Mserver "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --debug=10 --set "monet_mod_path=/var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB" --set "gdk_dbfarm=/var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/dbfarm" --set "sql_logdir=/var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/log" --set mapi_port=46225 --set sql_port=53058 --set monet_prompt= --trace MTIMEOUT = /var/tmp/_PREFIX__GNU_32_d__/bin/Mtimeout : Mtimeout -timeout 60 MSHUTDOWN = /var/tmp/_PREFIX__GNU_32_d__/bin/Mshutdown.py : Mshutdown.py "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=46225 PYTHON = /usr/bin/python : python SQL_CLIENT = /var/tmp/_PREFIX__GNU_32_d__/bin/MapiClient : MapiClient --language=sql -u monetdb -P monetdb --host=draco --port=53058 X100_CLIENT = : x100run_mapi -u monetdb -P monetdb "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=46225 MAPI_CLIENT = /var/tmp/_PREFIX__GNU_32_d__/bin/MapiClient : MapiClient -u monetdb -P monetdb "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=46225 Bits: 32bit Modules: ('main', 'kernel', '_kernel', 'arith', '_arith', 'str', '_str', 'uchr', '_uchr', 'bat', '_bat', 'algebra', '_algebra', 'sys', '_sys', 'trans', '_trans', 'streams', 'xtables', 'mkey', 'profiler', 'aggr', 'aggrX3', 'alarm', 'ascii_io', 'bat_arith', 'blob', 'decimal', 'enum', 'lock', 'mmath', 'monettime', 'radix', 'stats', 'tcpip', 'unix', 'url', 'counters', 'pcl', 'bitset', 'bitvector', 'cluster', 'iterator', 'malalgebra', 'mel', 'mprof', 'oo7', 'qt', 'salgebra', 'tpcd', 'vector', 'wisc', 'ddbench', 'bat_mmath', 'bat_cast', 'array', 'color', 'image', 'txtsim', 'calib', 'mapi', 'sql_server', 'pf_support') Running tests ['bug-sf-990096'] in directory /ufs/manegold/Monet/4.3/sql/src/test/bugs. 14:53:17> src/test/bugs/bug-sf-990096.sql (<=240s) ... 1.065s bug-sf-990096.stable.out.FILTERED and bug-sf-990096.test.out.FILTERED differ SIGNIFICANTLY! bug-sf-990096.stable.err.FILTERED and bug-sf-990096.test.err.FILTERED differ SIGNIFICANTLY! !ERROR: Testing FAILED SIGNIFICANTLY ! 1 out of 1 tests produced SIGNIFICANTLY different output First, check the testing results in /var/tmp/_PREFIX__GNU_32_d__/mTests/index.html ! Then, fix the problems by: - fixing sources and test scripts - fixing stable output by hand - approving test output by Mapprove.py (cf. Mapprove.py -?) After that, re-run Mtest. 14:53:19 manegold@draco:~/Monet/4.3/sql $ rm src/test/bugs/Tests/bug-sf-990096.stable.???~ -rw-r----- 1 manegold ins 2807 Jul 13 14:52 src/test/bugs/Tests/bug-sf-990096.stable.err~ -rw-r----- 1 manegold ins 1140 Jul 13 14:52 src/test/bugs/Tests/bug-sf-990096.stable.out~ Delete these 2 files/directories? (y/N) \c y 2 files deleted. 14:53:56 manegold@draco:~/Monet/4.3/sql $ cvs add src/test/bugs/Tests/bug-sf-990096.* cvs add: warning: unrecognized response '' from cvs server cvs add: use 'cvs commit' to add these files permanently 14:54:16 manegold@draco:~/Monet/4.3/sql $ cvs up src/test/bugs/Tests M src/test/bugs/Tests/All M src/test/bugs/Tests/bug-00001.stable.out A src/test/bugs/Tests/bug-sf-990096.sql.src A src/test/bugs/Tests/bug-sf-990096.stable.err A src/test/bugs/Tests/bug-sf-990096.stable.out 14:54:34 manegold@draco:~/Monet/4.3/sql $ cvs diff src/test/bugs/Tests Index: src/test/bugs/Tests/All =================================================================== RCS file: /cvsroot/monetdb/sql/src/test/bugs/Tests/All,v retrieving revision 1.17 diff -u -r1.17 All --- src/test/bugs/Tests/All 24 Jun 2004 15:26:59 -0000 1.17 +++ src/test/bugs/Tests/All 13 Jul 2004 12:54:42 -0000 @@ -25,3 +25,4 @@ bug-sf-975308 bug-sf-978043 bug-sf-978045 +bug-sf-990096 Index: src/test/bugs/Tests/bug-00001.stable.out =================================================================== RCS file: /cvsroot/monetdb/sql/src/test/bugs/Tests/bug-00001.stable.out,v retrieving revision 1.3 diff -u -r1.3 bug-00001.stable.out --- src/test/bugs/Tests/bug-00001.stable.out 20 Jun 2004 21:46:22 -0000 1.3 +++ src/test/bugs/Tests/bug-00001.stable.out 13 Jul 2004 12:54:42 -0000 @@ -60,8 +60,8 @@ [ 1005711, "privileges", 1005548, "", 1 ] [ 1005740, "history", 1005548, "", 1 ] [ 1005778, "env", 1005548, "", 1 ] -[ 1007047, "foo", 1005548, "", 0 ] -[ 1007212, "ff", 1005548, "", 0 ] +[ 1007035, "foo", 1005548, "", 0 ] +[ 1007200, "ff", 1005548, "", 0 ] # i # name # int # type # 2 # tuplecount @@ -91,9 +91,9 @@ [ 1005711, "privileges", 1005548, "", 1 ] [ 1005740, "history", 1005548, "", 1 ] [ 1005778, "env", 1005548, "", 1 ] -[ 1007047, "foo", 1005548, "", 0 ] -[ 1007212, "ff", 1005548, "", 0 ] -[ 1007468, "s4", 1005548, "", 0 ] +[ 1007035, "foo", 1005548, "", 0 ] +[ 1007200, "ff", 1005548, "", 0 ] +[ 1007456, "s4", 1005548, "", 0 ] # i # name # int # type # 1 # tuplecount cvs diff: src/test/bugs/Tests/bug-sf-990096.sql.src is a new entry, no comparison available cvs diff: src/test/bugs/Tests/bug-sf-990096.stable.err is a new entry, no comparison available cvs diff: src/test/bugs/Tests/bug-sf-990096.stable.out is a new entry, no comparison available 14:54:43 manegold@draco:~/Monet/4.3/sql $ ======== -- | 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] Auto-commit
by Fabian 04 Jul '04

04 Jul '04

Consider the following multi query statement: (1) update x set somecol = 'newval'; select * form x; (mind the explicit typo in the second query (from)) Now consider this whole statement being sent at once with auto_commit disabled. The second query will fail due to a syntax error and the whole connection will have to be rollbacked. If the error would be reported, and the --- theoretical --- update count would be ignored, there would be no problem at all, I think. However, suppose auto_commit is switched on. Now the scenario brings some problems: 1. the first update is executed, and committed; thus an update count should be returned. 2. the second query fails and generates an error, however this error can't be displayed if the update count is displayed, the statement executes or fails, not partial. As it looks now, using JDBC, a statement has a mutually exclusive result; either success, or failure. The current implementation of auto_commit, commits after each query, I think it should commit after each statement, so the statement as in (1) gets rollbacked as a whole and results in an error, instead of in a result and an error. Is this a reasonable thought of mine, or does it clash with other things? How does ODBC handle this situation?

2 3

[Monetdb-developers] Bus Error?
by Arjan Scherpenisse 01 Jul '04

01 Jul '04

While executing a big query, sometimes I get a Bus error. Now, I've looked up that "This signal is raised when your program accesses memory in an invalid way"; but what i am wondering, is this signal a) A bug in Monet b) A way of Monet telling me that it has run out of memory? -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

1 0

[Monetdb-developers] php module compiling
by Arjan Scherpenisse 14 Jun '04

14 Jun '04

The following code compiles the php module: gcc -fpic -DCOMPILE_DL=1 `php-config --includes` `monet-config --cflags` -c -o monetdb.o php_monetdb.c gcc -shared `php-config --libs` `monet-config --libs` -lMapi -rdynamic -o monetdb.so monetdb.o And installing: cp monetdb.so `php-config --extension-dir` Maybe someone (stefan?) with more knowledge of the build process can integrate this stuff. The only thing is that monet-config --cflags does not list $MONET_PREFIX/include/MonetDB/C as include dir, which is the directory Mapi.h resides in. Can this be fixed, or is this done on purpose? -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

2 1

[Monetdb-developers] readline things
by Arjan Scherpenisse 02 Jun '04

02 Jun '04

Hi, I, as a frequent MapiClient user, have added some convenience functions to the readline interface over time: - commandline-selectable "save/load history" option (default=off). - basic 'tab' command completion (for SQL only, as of now). Completes on table names and SQL commands. Could be improved, but this already saves a lot of typing. I have added the .mx code and patch for MapiClient.mx and Makefile.ag If someone could look over this code; it would be nice to have it in cvs. -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands Index: MapiClient.mx =================================================================== RCS file: /cvsroot/monetdb/MonetDB/src/mapi/clients/C/MapiClient.mx,v retrieving revision 1.57 diff -u -r1.57 MapiClient.mx --- MapiClient.mx 11 May 2004 11:03:04 -0000 1.57 +++ MapiClient.mx 2 Jun 2004 14:56:16 -0000 @@ -56,6 +56,7 @@ -t & --trace & trace Monet interaction \\ -T & --time & time commands \\ -u user & --user=user & user id \\ + -H & --history & load/save cmdline history (default off) \\ -? & --help & show this usage message \\ \end{tabular} @@ -83,6 +84,7 @@ #ifdef HAVE_LIBREADLINE #include <readline/readline.h> #include <readline/history.h> +#include "ReadlineTools.h" #endif #ifndef S_ISCHR @@ -805,6 +807,7 @@ fprintf(stderr, " -t | --trace /* trace Monet interaction */\n"); fprintf(stderr, " -T | --time /* time commands */\n"); fprintf(stderr, " -u user | --user=user /* user id */\n" ); + fprintf(stderr, " -H | --history /* load/save cmdline history (default off) */\n" ); fprintf(stderr, " -? | --help /* show this usage message */\n"); exit(-1); } @@ -832,8 +835,9 @@ int guest = 0; int linemode = 1; int c; - int quiet = 0; Mapi mid; + int quiet = 0; + int save_history = 0; static struct option long_options[] = { {"blocked", 1, 0, 'b'}, {"config", 1, 0, 'c'}, @@ -848,6 +852,7 @@ {"time", 0, 0, 'T'}, {"trace", 0, 0, 't'}, {"user", 1, 0, 'u'}, + {"history", 0, 0, 'H'}, {"quiet", 0, 0, 'q'}, {"help", 0, 0, '?'}, {0, 0, 0, 0} @@ -860,7 +865,7 @@ if ((setlen = mo_builtin_settings(&set)) == 0) usage(argv[0]); - while ((c = getopt_long(argc, argv, "b:c:l:u:p:P:qh:s:DtTd::?", long_options, NULL)) != -1) { + while ((c = getopt_long(argc, argv, "b:c:l:u:p:P:qHh:s:DtTd::?", long_options, NULL)) != -1) { switch (c) { case 'b': if (*optarg == 't' || *optarg == 'T' || *optarg == '1') @@ -924,6 +929,9 @@ *eq = '='; break; } + case 'H': + save_history = 1; + break; case '?': usage(argv[0]); default: @@ -998,6 +1006,10 @@ optind++; } +#ifdef HAVE_LIBREADLINE + init_readline(mid, language, save_history); +#endif + if (command) { c = doRequest(mid, command); } else { @@ -1014,6 +1026,11 @@ } c = doFileByLines(mid, stdin, prompt, linemode); } + +#ifdef HAVE_LIBREADLINE + deinit_readline(); +#endif + mapi_disconnect(mid); return c; } Index: Makefile.ag =================================================================== RCS file: /cvsroot/monetdb/MonetDB/src/mapi/clients/C/Makefile.ag,v retrieving revision 1.3 diff -u -r1.3 Makefile.ag --- Makefile.ag 25 May 2004 21:02:46 -0000 1.3 +++ Makefile.ag 2 Jun 2004 14:56:16 -0000 @@ -27,7 +27,7 @@ MAPI_LIBS = $(SOCKET_LIBS) lib_Mapi = { - SOURCES = Mapi.mx + SOURCES = Mapi.mx LIBS = $(MAPI_LIBS) ../../../common/libmutils ../../../common/libstream HEADERS = h } @@ -37,9 +37,9 @@ SOURCES = Mapi.mx } -BINS = { - SOURCES = MapiClient.mx - MapiClient_LIBS = libMapi $(MAPI_LIBS) $(READLINE_LIBS) \ +bin_MapiClient = { + SOURCES = MapiClient.mx ReadlineTools.mx + LIBS = libMapi $(MAPI_LIBS) $(READLINE_LIBS) \ ../../../common/libmutils ../../../common/libstream \ $(ICONV_LIBS) } @h #ifndef READLINETOOLS_H_INCLUDED #define READLINETOOLS_H_INCLUDED #include <monet_options.h> #include <readline/readline.h> #include <readline/history.h> #include "Mapi.h" void init_readline(Mapi mid, const char *language, int save_history); void deinit_readline(); char **sql_completion (const char *text, int start, int end); char *sql_tablename_generator (const char *text, int state); char *sql_command_generator (const char *text, int state); #endif @c /* * Readline specific stuff */ #include "ReadlineTools.h" #define PATHLENGTH 256 /* maximum file pathname length. */ const char *SQL_COMMANDS[] = { "SELECT", "INSERT", "UPDATE", "SET", "DELETE", "COMMIT", "ROLLBACK", "DROP TABLE", "CREATE", "ALTER", "RELEASE SAVEPOINT", "START TRANSACTION", 0}; Mapi _mid; char _history_file[PATHLENGTH]; int _save_history = 0; void init_readline(Mapi mid, const char *language, int save_history) { _mid = mid; /* Allow conditional parsing of the ~/.inputrc file. */ rl_readline_name = "MapiClient"; /* Tell the completer that we want to try our own completion before std completion (filename) kicks in. */ if (strcmp(language, "sql")==0) { rl_attempted_completion_function = sql_completion; } else { // FIXME: mil completion } if (save_history) { #ifndef NATIVE_WIN32 if (getenv("HOME")!=NULL) { snprintf(_history_file, PATHLENGTH, "%s/.mapiclient_history_%s", getenv("HOME"), language); _save_history = 1; } #else snprintf(_history_file, PATHLENGTH, "%s%c_mapiclient_history_%s", mo_find_option(&set, setlen, "prefix"), DIR_SEP, language); _save_history = 1; #endif read_history(_history_file); } } void deinit_readline() { if (_save_history) { write_history(_history_file); } } char ** sql_completion (const char *text, int start, int end) { char **matches; matches = (char **)NULL; if (start==0 || end == 0) { } if (start == 0) { matches = rl_completion_matches (text, sql_command_generator); } else { matches = rl_completion_matches (text, sql_tablename_generator); } return (matches); } char *sql_tablename_generator (const char *text, int state) { static int seekpos, len, rowcount; static MapiHdl table_hdl; char *name; if (!state) { seekpos = 0; len = strlen (text); if ((table_hdl = mapi_query(_mid, "SELECT name FROM tables"))==NULL || mapi_error(_mid)) { if (table_hdl) { mapi_explain_query(table_hdl, stderr); mapi_close_handle(table_hdl); } else mapi_explain(_mid, stderr); return NULL; } rowcount = mapi_get_row_count(table_hdl); } while (seekpos < rowcount) { mapi_seek_row(table_hdl, seekpos++, MAPI_SEEK_SET); mapi_fetch_row(table_hdl); name = mapi_fetch_field(table_hdl, 0); if (strncmp(name, text, len) == 0) return strdup(name); } return NULL; } // SQL commands (at start of line) char *sql_command_generator (const char *text, int state) { static int index, len; const char *name; if (!state) { index = 0; len = strlen(text); } while ((name = SQL_COMMANDS[index++])) { #ifdef HAVE_STRNCASECMP if (strncasecmp(name, text, len)==0) #else if (strncmp(name, text, len)==0) #endif return strdup(name); } return NULL; }

1 0

[Monetdb-developers] Epoch
by Arjan Scherpenisse 26 May '04

26 May '04

timestamp(0).print; [ 1970-01-01 01:00:00.000 ] --------^ Should this not be 1970-01-01 00:00:00.000? Or has this todo with the Daylight Savings time? -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

1 0

[Monetdb-developers] FASD project: Online survey launched
by benno.luthiger＠id.ethz.ch 25 May '04

25 May '04

Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fasd(a)webboard.ethz.ch for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________

1 0

[Monetdb-developers] RFC: "intermediate" stable release MonetDB-4.3.18 + SQL-2.0.18
by Stefan.Manegold＠cwi.nl 23 May '04

23 May '04

Dear fellow developers, after recent changes, the latest SQL (intendedly) does not compile with the stable MonetDB-4.3.16, anymore. Moreover, we plan to have some "major" changes both on MonetDB and on SQL during the summer heading for the first "official" release MonetDB 4.4 in autumn. Hence, Niels and I had the idea to make a "snapshot" or "intermediate stable" (pre-)release just before we start with major changes. The proposal is to start new release candidate branches, both for MonetDB and SQL (named MonetDB_4-3-18 and SQL_2-0-18, respectively) sometime this week (i.e., before end of May), getting them, stable as soon as possible, and aim for a release date about mid June. The current MonetDB code base seems to be doing quite well, hence I do not expect too much work, here, unless we plan to have some more new features (Peter: xtables, aggregates, ...?; Stefan: merged-union?) in the code. I guess, the same holds for SQL, but I'm not that sure, there. Are there any other features, that should be included in this "intermediate release"? A new "stable" also means, that all add-ons that are currently tested with 4-3-16 need to be ported to 4-3-18 (i.e., XML, PathFinder (HEAD), pruning, misq, gis, acoi) --- which probably requires a careful check, that monetdb_config.h is included in the local *_config.h's, and that the latter one is the FIRST include file in EACH .c file... Any other comments, complaints, suggestions, ...? Open issues (all, mine, I'm afraid |-() are: - testing on AIX (sara, "batch mode"), - testing on medusa (in Tilburg), - testing on native WindowsXP + VS .NET (on Sjoerd's machine) - clean-up / re-implementation of TestTools Stefan ps: we could of course also postpone this action until after the ICDE deadline on July 2nd and condense it to at most one week ... -- | 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] 'MapiClient remember history between sessions' patch
by Arjan Scherpenisse 11 May '04

11 May '04

I have made a RFE for this, including the patch (-u). https://sourceforge.net/tracker/index.php?func=detail&aid=951859&group_id=5… Sjoerd Mullender wrote: > Arjan Scherpenisse wrote: > > Please use a context diff for patches (-c or -u option). > I think this should go in the SourceForge RFE (Request For Enhancement) > tracker (with the patch as attachment). > It should be configurable (both whether, and where), and probably off by > default. > On Windows it is by no means certain that C: exists nor that C:\ is > writable by Joe Random Luser. > What about errors? > > Having said all of this, I think a patch like this has potential and > could be included. > >> regards, >> >> >> ------------------------------------------------------------------------ >> >> Index: MapiClient.mx >> =================================================================== >> RCS file: /cvsroot/monetdb/MonetDB/src/mapi/clients/C/MapiClient.mx,v >> retrieving revision 1.56 >> diff -r1.56 MapiClient.mx >> 854a855,857 >> >>> #ifdef HAVE_LIBREADLINE >>> char history_file[100]; >>> #endif >> >> >> 1000a1004,1012 >> >>> #ifdef HAVE_LIBREADLINE >>> #ifndef NATIVE_WIN32 >>> snprintf(history_file, 100, "%s/.mapiclient_history", >>> getenv("HOME")); >>> #else >>> snprintf(history_file, 100, "C:\\_mapiclient_history"); >>> #endif >>> read_history(history_file); >>> #endif >>> >> >> 1016a1029,1033 >> >>> #ifdef HAVE_LIBREADLINE >>> write_history(history_file); >>> #endif >>> > > -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

1 0

Re: [Monetdb-developers] 'MapiClient remember history between sessions' patch
by Stefan.Manegold＠cwi.nl 11 May '04

11 May '04

> I have written a small patch so mapiclient remembers the query history > > between sessions. Maybe this could be included in CVS. well, if it is tested, "save" (see comments below), and documented (see `Mx -H1 -w MapiClient.mx ; links MapiClient.html` or `Mx -H1 -t MapiClient.mx ; latex MapiClient.tex ; xdvi MapiClient.dvi`), go ahead ;-) Stefan > regards, > -- > Arjan Scherpenisse > > Centrum voor Wiskunde en Informatica, > Amsterdam, the Netherlands > > Index: MapiClient.mx > =================================================================== > RCS file: /cvsroot/monetdb/MonetDB/src/mapi/clients/C/MapiClient.mx,v > retrieving revision 1.56 > diff -r1.56 MapiClient.mx > 854a855,857 > > #ifdef HAVE_LIBREADLINE > > char history_file[100]; ^^^ what about using PATHLENGTH ? > > #endif > 1000a1004,1012 > > #ifdef HAVE_LIBREADLINE > > #ifndef NATIVE_WIN32 > > snprintf(history_file, 100, "%s/.mapiclient_history", getenv("HOME")); ^^^^ what happens if $HOME is not set? > > #else > > snprintf(history_file, 100, "C:\\_mapiclient_history"); > > #endif > > read_history(history_file); what happens, if history_file does not exist or is not readable? > > #endif > > > 1016a1029,1033 > > > > #ifdef HAVE_LIBREADLINE > > write_history(history_file); what happens if $HOME or history_file is not writeable? > > #endif > > > -- | 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] 'MapiClient remember history between sessions' patch
by Arjan Scherpenisse 11 May '04

11 May '04

I have written a small patch so mapiclient remembers the query history between sessions. Maybe this could be included in CVS. regards, -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands Index: MapiClient.mx =================================================================== RCS file: /cvsroot/monetdb/MonetDB/src/mapi/clients/C/MapiClient.mx,v retrieving revision 1.56 diff -r1.56 MapiClient.mx 854a855,857 > #ifdef HAVE_LIBREADLINE > char history_file[100]; > #endif 1000a1004,1012 > #ifdef HAVE_LIBREADLINE > #ifndef NATIVE_WIN32 > snprintf(history_file, 100, "%s/.mapiclient_history", getenv("HOME")); > #else > snprintf(history_file, 100, "C:\\_mapiclient_history"); > #endif > read_history(history_file); > #endif > 1016a1029,1033 > > #ifdef HAVE_LIBREADLINE > write_history(history_file); > #endif >

1 0

[Monetdb-developers] Test Web
by Sjoerd Mullender 07 May '04

07 May '04

Because I forgot to checkin a file yesterday (since corrected), testing failed on all platforms except Native Windows. -- Sjoerd Mullender <sjoerd(a)acm.org>

1 0

[Monetdb-developers] Build date in Mserver startup info
by Arjan Scherpenisse 03 May '04

03 May '04

Hi, Maybe it would be a good idea to include some information about the build date on startup of Mserver, just like other programs do that (Linux uname -a, Python, etc). That way you quickly can see if you have the latest version... druif:~/> Mserver # Monet Database Server V4.3.17 (Apr 27 2004, 14:27:43) <----- # Copyright (c) 1993-2004, CWI. All rights reserved. # Compiled for i686-pc-linux-gnu/32bit; dynamically linked. # Visit http://monetdb.cwi.nl for further information. monet> regards -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

4 11

[Monetdb-developers] New feature policy
by Arjan Scherpenisse 02 May '04

02 May '04

Hello, I am writing a MIL module which exports some functions for computation of different forms of string similarities. I would love to add this module to monet CVS (so I won't have to patch any Makefiles and copy source files whenever I do a new checkout), but I'm hesitating because I am not sure what the policy is for adding functions, library bindings, etc to Monet. Should it go in a separate CVS repository, or should it not be included at all? Could someone elaborate on this? regards -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

2 1

[Monetdb-developers] New feature policy
by Arjan Scherpenisse 29 Apr '04

29 Apr '04

Hello, I am writing a MIL module which exports some functions for computation of different forms of string similarities. I would love to add this module to monet CVS (so I won't have to patch any Makefiles and copy source files whenever I do a new checkout), but I'm hesitating because I am not sure what the policy is for adding functions, library bindings, etc to Monet. Should it go in a separate CVS repository, or should it not be included at all? Could someone elaborate on this? regards -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

1 0

[Monetdb-developers] mindmap
by Martin Kersten 28 Apr '04

28 Apr '04

Updated version. (Should find a place in the MonetDB Repository for it) Inclusion of Peter's comments. - Mserver becomes a watchdog for local Mserver Instances (other name needed) Mguardian itself is a process to manage a community of Mservers, who have delegated some control. Please add comments. <map version="0.7.1"> <node TEXT="Mguardian"> <node TEXT="Introduction" POSITION="right"> <node TEXT="Automated crash recovery" FOLDED="true"> <node TEXT="Single Mserver failure survivals"/> <node TEXT="Fail-over in case of a hardware crash"/> </node> <node TEXT="Resource management" FOLDED="true"> <node TEXT="Dbfarm management" FOLDED="true"> <node TEXT="Creation of necessary directories"/> <node TEXT="Assurance of sufficient space"/> </node> <node TEXT="Load distribution on multiple servers" FOLDED="true"> <node TEXT="Forwarding query clients to slave"/> </node> <node TEXT="Automatic backup/recovery management" FOLDED="true"> <node TEXT="Day/weekly schedules"/> <node TEXT="Highwatermark scheduling"/> </node> <node TEXT="Disk volume management" FOLDED="true"> <node TEXT="Multi-hierarchical chkpoint stores"/> <node TEXT="log compression"/> </node> </node> <node TEXT="Monitoring" FOLDED="true"> <node TEXT="Lifeness of all Mserver instances in the convoy"/> <node TEXT="Resource usage" FOLDED="true"> <node TEXT="MonetDB client load"/> <node TEXT="Host resource load"/> </node> </node> <node TEXT="Authorization" FOLDED="true"> <node TEXT="User administration"/> <node TEXT="Granting access to services"/> </node> </node> <node TEXT="Design goals" POSITION="right"> <node TEXT="appearance"> <node TEXT="Transparent to users"> <node TEXT="Becoming a member of a guardian group 
is an option in the Mserver configuration file."/> </node> <node TEXT="Transparent to location"> <node TEXT="Cluster machines are supported"/> <node TEXT="loosely coupled servers through HTTP"/> </node> <node TEXT="Transparent to hw/sw"> <node TEXT="Platform independent code"/> <node TEXT="Python? Java?"/> </node> </node> <node TEXT="Convoys" FOLDED="true"> <node TEXT="The guardian manages a group of database services"/> <node TEXT="The guardian process acts as a servant to those requiring it"/> <node TEXT="It is a free association, i.e. a Mserver can at any time
join/leave the group. Depending on the way this is
realised, Mguardian may initiate an action"/> </node> <node TEXT="State management"> <node TEXT="Driven by XML configuration file and state file"/> <node TEXT="Ascii-based state management at transaction level"/> <node TEXT="Distributed transaction management"/> </node> <node TEXT="Multiple points of failure infrastructure" FOLDED="true"> <node TEXT="Multiple servers in a cluster"/> <node TEXT="Mguardian lifes outside the area of Mservers?"/> </node> <node TEXT="Web-based status monitoring" FOLDED="true"> <node TEXT="At the level of a single server"/> <node TEXT="At the level of managin multiple Mservers"/> </node> <node TEXT="Active warning system" FOLDED="true"> <node TEXT="Email warning to DBA"/> </node> </node> <node TEXT="Architecture" POSITION="right"> <node TEXT="Configuration files" FOLDED="true"> <node TEXT="XML-based structure of Mserver Farms"/> <node TEXT="Database specific management conditions"/> <node TEXT="Disaster recovery rules"/> </node> <node TEXT="Implementation"> <node TEXT="Watchdog function" FOLDED="true"> <node TEXT="A lightweight independent process that keeps that
keeps a specific Mserver instance alive"> <node TEXT="It 'behaves' as the main thread of Mserver"/> <node TEXT="It should maintain information for restart" FOLDED="true"> <node TEXT="how to know this ?"/> <node TEXT="By being part of Mserver thread group"/> </node> </node> <node TEXT="Recover policy is database specific"> <node TEXT="Simply restart Mserver using known script"/> <node TEXT="Rejoin the Mguardian convoy"/> <node TEXT="Set-back the latest chkpoint instance"/> </node> <node TEXT="Monitoring" FOLDED="true"> <node TEXT="Collect session information"/> <node TEXT="Obtain webbased state of a single Mserver"/> </node> <node TEXT="Connection server"> <node TEXT="Should take over Internet thread listener"/> <node TEXT="Authenticates valid connections"/> <node TEXT="Forward request to convoy if needed"/> </node> </node> <node TEXT="Management function" FOLDED="true"> <node TEXT="Independent MonetDB application" FOLDED="true"> <node TEXT="Runs on secure system and keeps overview"/> <node TEXT="Mknife access possible"/> </node> <node TEXT="Manages allocation of connection requests"/> <node TEXT="Revives the watchdogs or call for DBA help"/> <node TEXT="Monitors high-water marks and calls the DBA"/> </node> </node> <node TEXT="Mguardian GUI" FOLDED="true"> <node TEXT="A system wide control centre "> <node TEXT="Gui-based"/> <node TEXT="Controls instances in cluster"/> <node TEXT="Can collect information from autonomous nodes"/> </node> <node TEXT="It receives reports from the watchdogs" FOLDED="true"> <node TEXT="Incremental load levels"/> <node TEXT="Database farm size"/> <node TEXT="log sizes"/> <node TEXT="Number of concurrent clients"/> <node TEXT="Machine load level"/> </node> <node TEXT="supports remotely initiated actions" FOLDED="true"> <node TEXT="Watchdog is the proxy for local system actions"/> </node> </node> </node> <node TEXT="Implementation strategy" POSITION="right"> <node TEXT="Phase 1: Mserver becomes a watchdog"> <node TEXT="Performs rudimentary guardian actions 
before admitting a Mserver Instance"/> <node TEXT="Performs auto reboot of Mserver Instance"/> <node TEXT="Tell users about the language/instance port to use"/> <node TEXT="Keeps log of user sessions"/> </node> <node TEXT="Phase 2: Mserver monitoring"> <node TEXT="Mguardian database design"/> <node TEXT="Webservice to collect data" FOLDED="true"> <node TEXT="HW load"/> <node TEXT="Free log space"/> <node TEXT="Database space"/> </node> <node TEXT="Simple admin control to change properties"/> <node TEXT="Prototyping as Mknife scripts"/> </node> <node TEXT="Phase 3: Mguardian in control"> <node TEXT="Primary portal for client connectivity"/> <node TEXT="start/stop Mservers"/> </node> </node> </node> </map>

2 1

[Monetdb-developers] Python DB API
by Arjan Scherpenisse 26 Apr '04

26 Apr '04

I have written some wrapper classes around Sjoerd's SWIG-generated Mapi and MapiLib modules, which serve as a Python DB-API 2.0 compliant database interface to Monet. If youre interested check out http://homepages.cwi.nl/~scherpen/Monet-python-DBAPI.tar.gz Maybe someone even should put this into Monet CVS cheers, -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

1 0

[Monetdb-developers] monetdb as embedded database ??
by Roberto Saccon 26 Apr '04

26 Apr '04

Hi all I would like to know whether it makes sense to use monetdb as database embedded into uerapplication, comparable to Berkeley DB (non-relational) or sqlite (relational). What is the footprint size ? What I have seen so far, the C-Apis only allow access to the DB by sockets. Or am I wrong ?? Does there iexisst a project where monetdb is embedded ? regards Roberto

1 0

[Monetdb-developers] micro CVS HowTo
by Stefan.Manegold＠cwi.nl 25 Apr '04

25 Apr '04

Dear fellow developers, for your convenience, here's a micro CVS HowTo: - initial checkout the head of the main/development branch: cvs -d<user>@cvs.sf.net:/cvsroot/monetdb co -P MonetDB - initial checkout the head of a release branch: cvs -d<user>@cvs.sf.net:/cvsroot/monetdb co -P -rMonetDB_4-3-16 MonetDB - tranforming a check-out main/development branch into a checked-out release branch: cvs up -dP -rMonetDB_4-3-16 - tranforming a check-out release branch into a checked-out main/development branch: cvs up -dP -A - updating a check-out main/development or release branch: cvs up -dP - checking, whether your current check-out it a main/development or release branch: cat CVS/Tag main/development branch: CVS/Tag does not exist release branch: CVS/Tag contains branch name/tag - checking you own changes (preferably prior to checkin): cvs diff 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 Testing & Status-Alert
by Stefan.Manegold＠cwi.nl 25 Apr '04

25 Apr '04

Dear fellow developers, let me first apologize for the fact that I haven't been able to maintain the nightly testing as usual while I was abroad the week before last week (Sa, April 10 - Su, April 18). During this time, problems with SourceForge (that are beyond our control) as well as problem with the Windows testing (that are somehow under our control, see below), caused the automatic testing to fail, and hence could not provide you with the usual feedback about your checkins. Furthermore, I also have to apologize, that I did not manage to get the testing working again, during last week, while being back at work. Well, at least, the SF problems seems to be gone, again. The windows problem is still there: recent changes in the release branch(!) of MonetDB seem to cause "Application Errors" (aka SegFaults) on Windows, and my non-interactive test-environment is unfortunately not able to press the "Ok" button on the respective pop-up window... Well, thanks to some hint from our new friends at SAP, I (hopefully) just managed to avoid these pop-up windows on our Windows test machine. Hence, testing should hang there anymore, even in case of "Application Errors". These problem solved, I had a short(!) look at today's Stable testweb, at what I saw did *scare* me a bit: ! The current "stable" version of MonetDB (4.3.16) seems to be pretty broken ! While many difference are "only" due to "harmless" changes in the output (e.g., caused by changes in the behaviour/output of commands such as "atoms()"), there are some changes that indicate that "join" is broken ! Well, I guess, I'll have to spend tomorrow or Monday on looking at the details and sorting out, what did go wrong with your checkins to the (no longer) "stable" release branch... Admittedly, I have to blame myself, again: Not only did I not keep the automatic testing properly running during the last two week, but I also forgot to give any guidelines, how to handle checkins to the "stable" branch after the release had been made... (No, I don't metion anymore, that Mtest might be run by hand on your favorite development platform, at least before checking-in "bug-fixes" to the "stable" branch...) To see it positively, this observation confirms that we do not "waste" any time or money by having one person spending a major part of his/her (official) working hours on "quality control" --- I just forgot to find/name a stand-in while being abroad myself...). Good night, 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 2

[Monetdb-developers] Mapi blocked mode multi query consideration
by Fabian 22 Apr '04

22 Apr '04

Mapi has two modes, which I refer to as line mode and block mode. The main plus for the client when using the block mode variant is that multi-line queries can be sent directly to the server without any parsing. The line mode variant, on the other hand, separates lines by newline characters, so multiline queries are not possible; one has to replace all newlines by spaces when not inside a string, otherwise by \n. (this requires some parsing of the query before sending) Now the problem I'm dealing with is as follows: If I send a multiline query using blockmode to the server, and that query is syntactically incorrect (according to the server), the server returns that same multiline query. In the result mode, however, newlines are treated as row delimiters. The effect of this, is that only the first row of the query sent is visible, which most of the time does not contain the error. For example, suppose the following query is sent: SELECT * FROM "foobar"; where the table foobar does not exist in the catalog, then the error message will be: !ERROR parse error at token (257) in statement: select * from "foobar" which due to row-style parsing will only result in the error message with query 'select *'. The question here is actually, who is doing what wrong? Any thoughts on this?

2 2

Re: [Monetdb-developers] Python + SQL
by Arjan Scherpenisse 22 Apr '04

22 Apr '04

Martin, I have fixed the Mapi.py thanks to Niels' tips. The result strings still need parsing ofcourse. I could write my own parsing or write wrappers for the existing Mapi.h API. I am willing to implement a Python database wrapper according to the Python Database API specs (http://www.python.org/peps/pep-0249.html) Maybe we can talk about this tomorrow with Peter, and how something like this can fit into my graduation work ;) regards, Arjan Martin Kersten wrote: > Arjan, > > It supprises me, because the Mapi protocol does not constrain the > language. I noticed, though, that MapiClient.py is currently hardwired > for mil indeed. It seems that Sjoerd (the Python expert) can help > you (and make MapiClient.py a little better?) > > The main question to decide upon is the functionality required. > Using ODBC would allow your application also to run on other DBMSs > From the perspective of re-use that is a nice property. Ofcourse, > the application builder has to spent more energy to prepare for this. > Using the ODBC layer of Sjoerd would be a good exercise to challenge > its current functionality. Help is close at hand to make it bearable. > > Perhaps an issue to discuss with Peter (and me). > > regards, Martin > > Arjan Scherpenisse wrote: > >> Hello, >> >> can someone point me to a simple way of using the SQL frontend from >> within Python? The default interface (Mapi.py) does only allow the MIL >> language, as far as I can see. >> >> In the past I did it by using the ODBC module, but that was very >> tiresome. Is there a better way? >> >> cheers, Arjan >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Monetdb-developers mailing list >> Monetdb-developers(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/monetdb-developers > > > -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

2 2

[Monetdb-developers] Python + SQL
by Arjan Scherpenisse 20 Apr '04

20 Apr '04

Hello, can someone point me to a simple way of using the SQL frontend from within Python? The default interface (Mapi.py) does only allow the MIL language, as far as I can see. In the past I did it by using the ODBC module, but that was very tiresome. Is there a better way? cheers, Arjan

1 0

[Monetdb-developers] timestamp
by Arjan Scherpenisse 07 Apr '04

07 Apr '04

Hi list, I am importing some tab-separated dump data in which a field is a timestamp, formatted ala "2003-11-26 10:36:53". After importing (through make_persistent/load_data), the two timestamp BATs show up as: [ "profile_track_history_date", "oid", nil, 4516232, 0, "clean", "disk", "pers", 0, 1 ] [ "profile_track_history_serverdate", "oid", nil, 4516232, 0, "clean", "disk", "pers", 0, 1 ] (having a 'nil' tail-type). I guess this is a minor bug; because the BATs are filled with timestamps properly. regards, Arjan

3 5

[Monetdb-developers] Security & usability
by Fabian 04 Apr '04

04 Apr '04

After the checkin by Martin (about giving -u and -P default values on MapiClient), I had to laugh loudly for a minute (or two) after which I had to frown, thinking about the security aspect of this change. Not that it changes much, but being a little minded towards a better situation is not a bad thing IMHO. (Also for the reputation of monet by itself for the outside world) Because I regularly get tired of typing long command line arguments as well, I propose the following solution, which might fit all kinds of tastes. What if we would store some preferences we have in a file ~/.monetdb or something which can be shared by various applications, like MapiClient, JdbcClient, Mserver itself, and maybe any more... The file would be simply a properties file containing something like username=monetdb password=monetdb language=sql startscript=~/monetdb/start_sql which would instruct MapiClient to use sql language with username + pass monetdb and tell Mserver when it starts to load the script ~/monetdb/start_sql so I for instance would not have to type 'module(sql_server);' anymore. Of course command line options override these defaults in this .monetdb file. It is up to the user to chmod it to 600. How about this idea?

3 3

[Monetdb-developers] PHP interface
by Marcin Zukowski 03 Apr '04

03 Apr '04

Hello Monet-hackers, Recently I implemented a PHP Monet interface. Documentation is here: file://localhost/ufs/marcin/utils/phpdoc/html/ref.monetdb.html (accessible from CWI). If anyone of you is interested and would like to play with it, I would be grateful for any comments. Regards, marcin -- : Marcin Zukowski < marcin(a)cwi.nl || eru(a)mimuw.edu.pl > : All true wisdom is found in signatures

1 0