[Monetdb-developers] MonetDB release planning
Dear fellow MonetDB developers, this is to keep you up-to-date about the short-term release plans for the MonetDB product family as they have recently been discussed here at CWI in A'dam. Please read until the end. Thank you very much in advance for your patience ans cooperation! Triggered by (1) the major progress in extending the functionality of the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery) to (almost) meet the functionality as provided by the (til date) default "milprint_summer back-end" based version (see details below), and (2) the desire of at least one distinct client to use the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery), we plan to have a new release of Pathfinder (MonetDB/XQuery), soon. Unfortunately, the functionality of the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery) is not yet identical with that of the (til date) default "milprint_summer back-end" based version. First of all, extensions beyond the XQuery and XQuery Updates standards, such as XRpc, StandOff, and pre-compiled XQuery modules ("MIL modules") are not supported, as well as recursive user-defined functions are not supported, yet. (The not yet working id/idref functionality is currently being implemented.) Moreover, the XQuery Update functionality is not yet complete/correct, as it cannot yet handle inserts of node who's type is not statically known at query compile time. In particular the latter shortcoming currently keeps us from our original plans of making the new "Algebra back-end" the default in the upcoming release. Hence, most probably, the upcoming release will still come with the "milprint_summer back-end" set as default. However, as already in the latest release, runtime options allow users to easily enable the new "Algebra back-end". Some (internal) API changes on the development trunk since the last release (mainly the signatures of GDK functions BAT_select(), BATmmap() & BATmadvice()), prohibit a new "feature release" of pathfinder, only, as this is incompatible with currently available releases of MonetDB4 (Server) and MonetDB (Common). Hence, also this upcoming release will be a "complete" one, i.e., all MonetDB related packages (MonetDB Common, Clients, MonetDB4 Server, MonetDB5 Server, MonetDB/SQL, MonetDB/Geom & MonetDB/XQuery will (have to be) released. Given this, our plan is as follows: Within the next week, we will fork new "Stable" branches of the current development trunks. Please let us know at your earliest convenience, in case you have new feature developments "in the pipe", that should go into the new release. In case you have just started new "cutting edge" developments that are still far from mature to be released soon, please refrain from checking them in until the new release branches have been created. Once the new release branches are created, we plan to spend about one month on thoroughly testing and stabilizing the new release and its packaging. Any help from all of you is highly appreciated! In particular, we count on the support for all "first users" of the new Pathfinder (MonetDB/XQuery) "Algebra back-end' (even if it will not be the default choice). The envisioned release date is "End of June". Please let us know, in case you have any questions, comments, suggestions, etc. Yours Sincerely, 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 |
On Fri, May 16, 2008 at 09:33:43PM +0200, Stefan de Konink wrote:
On Fri, 16 May 2008, Stefan Manegold wrote:
Please let us know, in case you have any questions, comments, suggestions, etc.
Is there currently any ETA to get the Geom extention in a workable shape again?
What exactly is not working (for you)? According to the TestWeb, all available Geom tests work fine, both in the latest "Stable" release and in the "Current" development version: http://monetdb.cwi.nl/testing/projects/monetdb/Stable/geom/.mTests4103/index... http://monetdb.cwi.nl/testing/projects/monetdb/Stable/geom/.mTests5103/index... http://monetdb.cwi.nl/testing/projects/monetdb/Current/geom/.mTests4103/inde... http://monetdb.cwi.nl/testing/projects/monetdb/Current/geom/.mTests5103/inde... Stefan
Yours Sincerely,
Stefan de Konink
-- | 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 |
On Fri, 16 May 2008, Stefan Manegold wrote:
On Fri, May 16, 2008 at 09:33:43PM +0200, Stefan de Konink wrote:
On Fri, 16 May 2008, Stefan Manegold wrote:
Please let us know, in case you have any questions, comments, suggestions, etc.
Is there currently any ETA to get the Geom extention in a workable shape again?
What exactly is not working (for you)?
According to the TestWeb, all available Geom tests work fine, both in the latest "Stable" release and in the "Current" development version: http://monetdb.cwi.nl/testing/projects/monetdb/Stable/geom/.mTests4103/index... http://monetdb.cwi.nl/testing/projects/monetdb/Stable/geom/.mTests5103/index... http://monetdb.cwi.nl/testing/projects/monetdb/Current/geom/.mTests4103/inde... http://monetdb.cwi.nl/testing/projects/monetdb/Current/geom/.mTests5103/inde...
The last time I checked (with CVS) this didn't work at all. See: http://article.gmane.org/gmane.comp.db.monetdb.devel/911 Ok it is 5 months ago... but still, if you say everything works then the example should work too. Stefan
On Fri, May 16, 2008 at 11:28:56PM +0200, Stefan de Konink wrote:
On Fri, 16 May 2008, Stefan Manegold wrote:
On Fri, May 16, 2008 at 09:33:43PM +0200, Stefan de Konink wrote:
On Fri, 16 May 2008, Stefan Manegold wrote:
Please let us know, in case you have any questions, comments, suggestions, etc.
Is there currently any ETA to get the Geom extention in a workable shape again?
What exactly is not working (for you)?
According to the TestWeb, all available Geom tests work fine, both in the latest "Stable" release and in the "Current" development version: http://monetdb.cwi.nl/testing/projects/monetdb/Stable/geom/.mTests4103/index... http://monetdb.cwi.nl/testing/projects/monetdb/Stable/geom/.mTests5103/index... http://monetdb.cwi.nl/testing/projects/monetdb/Current/geom/.mTests4103/inde... http://monetdb.cwi.nl/testing/projects/monetdb/Current/geom/.mTests5103/inde...
The last time I checked (with CVS) this didn't work at all.
See: http://article.gmane.org/gmane.comp.db.monetdb.devel/911
Ok it is 5 months ago...
feel free to check with the latest release or development version, again ;-) In case it does not work, feel free to file a bug report via the MonetDB BugTracker at SF.
but still, if you say everything works then the example should work too.
Well, I only said that all available tests do work fine. I don't know the tests by hard, and hence cannot tell whether you scenario is (already) covered. In case you find it not working and file a bug report, a test will be added before the bug report is closed. We mght also consider adding a test even without bug report, once we have some spare time --- any help is more than aprechiated ;-) Stefan
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 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Stefan Manegold schreef:
Well, I only said that all available tests do work fine. I don't know the tests by hard, and hence cannot tell whether you scenario is (already) covered. In case you find it not working and file a bug report, a test will be added before the bug report is closed. We mght also consider adding a test even without bug report, once we have some spare time --- any help is more than aprechiated ;-)
From: http://monetdb.cwi.nl/SQL/Documentation/SQL_002fGIS.html (One thing that should get an update is the location of geom.sql) skinkie@nemesis /opt/osm/bin $ ./mclient -lsq sql>CREATE TABLE forests(id INT,name TEXT,shape MULTIPOLYGON); sql>CREATE TABLE buildings(id INT,name TEXT,location POINT,outline POLYGON); sql>INSERT INTO forests VALUES(109, 'Green Forest', more>'MULTIPOLYGON( ((28 26,28 0,84 0,84 42,28 26), (52 18,66 23,73 9,48 6,52 18)), ((59 18,67 18,67 13,59 13,59 18)))'); Rows affected 1 sql>INSERT INTO buildings VALUES(113, '123 Main Street', more>'POINT( 52 30 )', more>'POLYGON( ( 50 31, 54 31, 54 29, 50 29, 50 31) )'); Rows affected 1 sql>INSERT INTO buildings VALUES(114, '215 Main Street', more>'POINT( 64 33 )', more>'POLYGON( ( 66 34, 62 34, 62 32, 66 32, 66 34) )'); Rows affected 1 sql> sql>SELECT forests.name,buildings.name more>FROM forests,buildings more>WHERE forests.name = 'Green Forest' and more> Overlaps(forests.shape, buildings.outline) = true; !types multipolygon(0,0) (wkb) and geometry(0,0) (wkb) are not equal http://xen.bot.nu/mTests/ (output) Help is nice :) Please review all errors even if they 'matchup'. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkg4qRgACgkQYH1+F2Rqwn3RGwCghaNao7Z5/pZyq7hf+LAO1dCs T1kAnRiZzTlP7z/ilRTWQgg7tPV6Itq9 =p9DG -----END PGP SIGNATURE-----
On Sun, May 25, 2008 at 01:47:36AM +0200, Stefan de Konink wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Stefan Manegold schreef:
Well, I only said that all available tests do work fine. I don't know the tests by hard, and hence cannot tell whether you scenario is (already) covered. In case you find it not working and file a bug report, a test will be added before the bug report is closed. We mght also consider adding a test even without bug report, once we have some spare time --- any help is more than aprechiated ;-)
From: http://monetdb.cwi.nl/SQL/Documentation/SQL_002fGIS.html
(One thing that should get an update is the location of geom.sql)
??? Could you *please* be a bit more verbose and/or precise?
skinkie@nemesis /opt/osm/bin $ ./mclient -lsq sql>CREATE TABLE forests(id INT,name TEXT,shape MULTIPOLYGON); sql>CREATE TABLE buildings(id INT,name TEXT,location POINT,outline POLYGON); sql>INSERT INTO forests VALUES(109, 'Green Forest', more>'MULTIPOLYGON( ((28 26,28 0,84 0,84 42,28 26), (52 18,66 23,73 9,48 6,52 18)), ((59 18,67 18,67 13,59 13,59 18)))'); Rows affected 1 sql>INSERT INTO buildings VALUES(113, '123 Main Street', more>'POINT( 52 30 )', more>'POLYGON( ( 50 31, 54 31, 54 29, 50 29, 50 31) )'); Rows affected 1 sql>INSERT INTO buildings VALUES(114, '215 Main Street', more>'POINT( 64 33 )', more>'POLYGON( ( 66 34, 62 34, 62 32, 66 32, 66 34) )'); Rows affected 1 sql> sql>SELECT forests.name,buildings.name more>FROM forests,buildings more>WHERE forests.name = 'Green Forest' and more> Overlaps(forests.shape, buildings.outline) = true; !types multipolygon(0,0) (wkb) and geometry(0,0) (wkb) are not equal
Please file this as a bug report via SF.
http://xen.bot.nu/mTests/ (output)
Looks OK. Differences are minor due to changes between geos 2.2.3 and geos 3.0.0; see also http://monetdb.cwi.nl/testing/projects/monetdb/Stable/geom/.mTests5103/index...
Help is nice :)
Which help do you refer to?
Please review all errors even if they 'matchup'.
The differences under http://xen.bot.nu/mTests/ are only minor due do output / precision changes between geos 2.2.3 and geos 3.0.0; see above. The error with the web site example seems to be a bug --- either in the code or in the example --- and should be filed as such via SF. Thanks in advance! Stefan
Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREKAAYFAkg4qRgACgkQYH1+F2Rqwn3RGwCghaNao7Z5/pZyq7hf+LAO1dCs T1kAnRiZzTlP7z/ilRTWQgg7tPV6Itq9 =p9DG -----END PGP SIGNATURE-----
-- | 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 |
Please review all errors even if they 'matchup'.
The differences under http://xen.bot.nu/mTests/ are only minor due do output / precision changes between geos 2.2.3 and geos 3.0.0; see above.
The error with the web site example seems to be a bug --- either in the code or in the example --- and should be filed as such via SF.
I'm confused about your testing methods, but they seem to test also the produced errors. I'll see if I understand some test and try my luck on them. Stefan
On Sun, May 25, 2008 at 03:10:45AM +0200, Stefan de Konink wrote:
Please review all errors even if they 'matchup'.
The differences under http://xen.bot.nu/mTests/ are only minor due do output / precision changes between geos 2.2.3 and geos 3.0.0; see above.
The error with the web site example seems to be a bug --- either in the code or in the example --- and should be filed as such via SF.
I'm confused about your testing methods, but they seem to test also the produced errors.
Not sure whether I understand exectly what you mean, but yes, our testsystem also allows us to test whether our code produces the correct/expected error messages on case of incorrect use.
I'll see if I understand some test and try my luck on them.
See http://monetdb.cwi.nl/projects/monetdb/Development/TestWeb/Background/index.... and in particular http://monetdb.cwi.nl/projects/monetdb/Development/TestWeb/Mtest/index.html And don't hesitate to ask specific questions whenever necessary. Stefan
Stefan
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@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 |
On 05/16/2008 08:32 PM, Stefan Manegold wrote with possible deletions:
[...] Moreover, the XQuery Update functionality is not yet complete/correct, as it cannot yet handle inserts of node who's type is not statically known at query compile time. In particular the latter shortcoming currently keeps us from our original plans of making the new "Algebra back-end" the default in the upcoming release. Hence, most probably, the upcoming release will still come with the "milprint_summer back-end" set as default.
I just added typeswitch support for nodes. This should fix the failing update tests (at least functionality-wise). Jan -- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/
Dear fellow MonetDB developers, unless there are (strong) objections, I plan to create the new CVS branches for the upcoming release on Saturday (May 24 2008). In that case, I'd ask you to finish your pending checkins to any of the MonetDB-related CVS repositories by tomorrow evening (Friday, May 23 2008, 23:59 CEST) and refrain from checkins as of Saturday, May 24 2008, 0:01 CEST, to ensure smooth CVS management --- I'll let you know, once I'm done, and you're free to check in, again. Being out of office, I have not closely followed the code development, checkins and/or TestWeb status during the last week. Hence, please speak-up in case there are any reasons not to start the release process on Saturday. Thank you very much for your cooperation! Stefan On Fri, May 16, 2008 at 08:32:53PM +0200, Stefan Manegold wrote:
Dear fellow MonetDB developers,
this is to keep you up-to-date about the short-term release plans for the MonetDB product family as they have recently been discussed here at CWI in A'dam.
Please read until the end. Thank you very much in advance for your patience ans cooperation!
Triggered by (1) the major progress in extending the functionality of the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery) to (almost) meet the functionality as provided by the (til date) default "milprint_summer back-end" based version (see details below), and (2) the desire of at least one distinct client to use the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery), we plan to have a new release of Pathfinder (MonetDB/XQuery), soon.
Unfortunately, the functionality of the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery) is not yet identical with that of the (til date) default "milprint_summer back-end" based version. First of all, extensions beyond the XQuery and XQuery Updates standards, such as XRpc, StandOff, and pre-compiled XQuery modules ("MIL modules") are not supported, as well as recursive user-defined functions are not supported, yet. (The not yet working id/idref functionality is currently being implemented.) Moreover, the XQuery Update functionality is not yet complete/correct, as it cannot yet handle inserts of node who's type is not statically known at query compile time. In particular the latter shortcoming currently keeps us from our original plans of making the new "Algebra back-end" the default in the upcoming release. Hence, most probably, the upcoming release will still come with the "milprint_summer back-end" set as default. However, as already in the latest release, runtime options allow users to easily enable the new "Algebra back-end".
Some (internal) API changes on the development trunk since the last release (mainly the signatures of GDK functions BAT_select(), BATmmap() & BATmadvice()), prohibit a new "feature release" of pathfinder, only, as this is incompatible with currently available releases of MonetDB4 (Server) and MonetDB (Common). Hence, also this upcoming release will be a "complete" one, i.e., all MonetDB related packages (MonetDB Common, Clients, MonetDB4 Server, MonetDB5 Server, MonetDB/SQL, MonetDB/Geom & MonetDB/XQuery will (have to be) released.
Given this, our plan is as follows:
Within the next week, we will fork new "Stable" branches of the current development trunks. Please let us know at your earliest convenience, in case you have new feature developments "in the pipe", that should go into the new release. In case you have just started new "cutting edge" developments that are still far from mature to be released soon, please refrain from checking them in until the new release branches have been created.
Once the new release branches are created, we plan to spend about one month on thoroughly testing and stabilizing the new release and its packaging. Any help from all of you is highly appreciated! In particular, we count on the support for all "first users" of the new Pathfinder (MonetDB/XQuery) "Algebra back-end' (even if it will not be the default choice).
The envisioned release date is "End of June".
Please let us know, in case you have any questions, comments, suggestions, etc.
Yours Sincerely, 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 |
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@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 |
Dear fellow MonetDB developers, since there have been now objections, I'll proceed with creating the new release branches tomorrow. To ensure a smooth(er) process, please *refrain from checkins* to any of the MonetDB-related repositories *as of midnight* (CEST). I'll let you know, once I'm done and you're welcome to checkin, again. Thank you very much in advance your cooperation! Stefan On Thu, May 22, 2008 at 07:11:15PM +0200, Stefan Manegold wrote:
Dear fellow MonetDB developers,
unless there are (strong) objections, I plan to create the new CVS branches for the upcoming release on Saturday (May 24 2008).
In that case, I'd ask you to finish your pending checkins to any of the MonetDB-related CVS repositories by tomorrow evening (Friday, May 23 2008, 23:59 CEST) and refrain from checkins as of Saturday, May 24 2008, 0:01 CEST, to ensure smooth CVS management --- I'll let you know, once I'm done, and you're free to check in, again.
Being out of office, I have not closely followed the code development, checkins and/or TestWeb status during the last week. Hence, please speak-up in case there are any reasons not to start the release process on Saturday.
Thank you very much for your cooperation!
Stefan
On Fri, May 16, 2008 at 08:32:53PM +0200, Stefan Manegold wrote:
Dear fellow MonetDB developers,
this is to keep you up-to-date about the short-term release plans for the MonetDB product family as they have recently been discussed here at CWI in A'dam.
Please read until the end. Thank you very much in advance for your patience ans cooperation!
Triggered by (1) the major progress in extending the functionality of the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery) to (almost) meet the functionality as provided by the (til date) default "milprint_summer back-end" based version (see details below), and (2) the desire of at least one distinct client to use the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery), we plan to have a new release of Pathfinder (MonetDB/XQuery), soon.
Unfortunately, the functionality of the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery) is not yet identical with that of the (til date) default "milprint_summer back-end" based version. First of all, extensions beyond the XQuery and XQuery Updates standards, such as XRpc, StandOff, and pre-compiled XQuery modules ("MIL modules") are not supported, as well as recursive user-defined functions are not supported, yet. (The not yet working id/idref functionality is currently being implemented.) Moreover, the XQuery Update functionality is not yet complete/correct, as it cannot yet handle inserts of node who's type is not statically known at query compile time. In particular the latter shortcoming currently keeps us from our original plans of making the new "Algebra back-end" the default in the upcoming release. Hence, most probably, the upcoming release will still come with the "milprint_summer back-end" set as default. However, as already in the latest release, runtime options allow users to easily enable the new "Algebra back-end".
Some (internal) API changes on the development trunk since the last release (mainly the signatures of GDK functions BAT_select(), BATmmap() & BATmadvice()), prohibit a new "feature release" of pathfinder, only, as this is incompatible with currently available releases of MonetDB4 (Server) and MonetDB (Common). Hence, also this upcoming release will be a "complete" one, i.e., all MonetDB related packages (MonetDB Common, Clients, MonetDB4 Server, MonetDB5 Server, MonetDB/SQL, MonetDB/Geom & MonetDB/XQuery will (have to be) released.
Given this, our plan is as follows:
Within the next week, we will fork new "Stable" branches of the current development trunks. Please let us know at your earliest convenience, in case you have new feature developments "in the pipe", that should go into the new release. In case you have just started new "cutting edge" developments that are still far from mature to be released soon, please refrain from checking them in until the new release branches have been created.
Once the new release branches are created, we plan to spend about one month on thoroughly testing and stabilizing the new release and its packaging. Any help from all of you is highly appreciated! In particular, we count on the support for all "first users" of the new Pathfinder (MonetDB/XQuery) "Algebra back-end' (even if it will not be the default choice).
The envisioned release date is "End of June".
Please let us know, in case you have any questions, comments, suggestions, etc.
Yours Sincerely, 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 |
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@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 |
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@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 |
Dear fellow MonetDB developers, I'm done with creating the following "Stable" CVS branches for the upcoming "Jun2008" release: package branch-name ----------------------- (on SourceForge) buildtools MonetDB_1-24 MonetDB MonetDB_1-24 clients Clients_1-24 MonetDB5 MonetDB_5-6 sql SQL_2-24 geom Geom_0-4 MonetDB4 MonetDB_4-24 pathfinder XQuery_0-24 template MonetDB_1-24 (java has an independent release schema, and hence does not have/need a CVS branch (yet?)) (CWI internally) TestTools MonetDB_1-24 monetweb Stable_Jun2008 Hence, you welcome to checkin, again, provided you acknowledge the follwoing IMPORTANT NOTES: 1) As usually, once I have officially released the check-in lock, a) ALL bug fixes (and ONLY those) MUST be checked in to the above release branches (and ONLY there)! b) ALL new features (and ONLY those) MUST be checked in to the development trunk (HEAD) (and ONLY there)! (In case you need assistance please feel free to contact MonetDB-developers@lists.sourceforge.net .) Until different notice, any propagation of bug-fixes from the new release branches to the respective development trunks will be done / controlled by Sjoerd and me, only, i.e., no one else is supposed to do any propagation, unless Sjoerd or I explicitly allow such propagation. Obviously, Sjoerd or I may ask for assistance. Propagation from the development trunks to the release branches does not exist. 2) At CWI, all changes for the web site that are supposed to be put online with the upcoming "Jun2008" release must be checked in to the "Stable_Jun2008" branch of "monetweb". As of tomorrow morning (once nightly Stable testing has finished) this branch will be used to build the pre-view web site on koala. (Until the actual release, the life web site will remain being built from the "Stable_2008-02-03" branch of "monetweb".) Thank you very much for you patience! Stefan On Fri, May 23, 2008 at 07:33:20PM +0200, Stefan Manegold wrote:
Dear fellow MonetDB developers,
since there have been now objections, I'll proceed with creating the new release branches tomorrow.
To ensure a smooth(er) process, please *refrain from checkins* to any of the MonetDB-related repositories *as of midnight* (CEST).
I'll let you know, once I'm done and you're welcome to checkin, again.
Thank you very much in advance your cooperation!
Stefan
On Thu, May 22, 2008 at 07:11:15PM +0200, Stefan Manegold wrote:
Dear fellow MonetDB developers,
unless there are (strong) objections, I plan to create the new CVS branches for the upcoming release on Saturday (May 24 2008).
In that case, I'd ask you to finish your pending checkins to any of the MonetDB-related CVS repositories by tomorrow evening (Friday, May 23 2008, 23:59 CEST) and refrain from checkins as of Saturday, May 24 2008, 0:01 CEST, to ensure smooth CVS management --- I'll let you know, once I'm done, and you're free to check in, again.
Being out of office, I have not closely followed the code development, checkins and/or TestWeb status during the last week. Hence, please speak-up in case there are any reasons not to start the release process on Saturday.
Thank you very much for your cooperation!
Stefan
On Fri, May 16, 2008 at 08:32:53PM +0200, Stefan Manegold wrote:
Dear fellow MonetDB developers,
this is to keep you up-to-date about the short-term release plans for the MonetDB product family as they have recently been discussed here at CWI in A'dam.
Please read until the end. Thank you very much in advance for your patience ans cooperation!
Triggered by (1) the major progress in extending the functionality of the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery) to (almost) meet the functionality as provided by the (til date) default "milprint_summer back-end" based version (see details below), and (2) the desire of at least one distinct client to use the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery), we plan to have a new release of Pathfinder (MonetDB/XQuery), soon.
Unfortunately, the functionality of the new "Algebra back-end" based version of Pathfinder (MonetDB/XQuery) is not yet identical with that of the (til date) default "milprint_summer back-end" based version. First of all, extensions beyond the XQuery and XQuery Updates standards, such as XRpc, StandOff, and pre-compiled XQuery modules ("MIL modules") are not supported, as well as recursive user-defined functions are not supported, yet. (The not yet working id/idref functionality is currently being implemented.) Moreover, the XQuery Update functionality is not yet complete/correct, as it cannot yet handle inserts of node who's type is not statically known at query compile time. In particular the latter shortcoming currently keeps us from our original plans of making the new "Algebra back-end" the default in the upcoming release. Hence, most probably, the upcoming release will still come with the "milprint_summer back-end" set as default. However, as already in the latest release, runtime options allow users to easily enable the new "Algebra back-end".
Some (internal) API changes on the development trunk since the last release (mainly the signatures of GDK functions BAT_select(), BATmmap() & BATmadvice()), prohibit a new "feature release" of pathfinder, only, as this is incompatible with currently available releases of MonetDB4 (Server) and MonetDB (Common). Hence, also this upcoming release will be a "complete" one, i.e., all MonetDB related packages (MonetDB Common, Clients, MonetDB4 Server, MonetDB5 Server, MonetDB/SQL, MonetDB/Geom & MonetDB/XQuery will (have to be) released.
Given this, our plan is as follows:
Within the next week, we will fork new "Stable" branches of the current development trunks. Please let us know at your earliest convenience, in case you have new feature developments "in the pipe", that should go into the new release. In case you have just started new "cutting edge" developments that are still far from mature to be released soon, please refrain from checking them in until the new release branches have been created.
Once the new release branches are created, we plan to spend about one month on thoroughly testing and stabilizing the new release and its packaging. Any help from all of you is highly appreciated! In particular, we count on the support for all "first users" of the new Pathfinder (MonetDB/XQuery) "Algebra back-end' (even if it will not be the default choice).
The envisioned release date is "End of June".
Please let us know, in case you have any questions, comments, suggestions, etc.
Yours Sincerely, 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 |
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@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 |
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@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 |
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@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 |
On Sun, 25 May 2008, Stefan Manegold wrote:
I'm done with creating the following "Stable" CVS branches for the upcoming "Jun2008" release:
Hi, I've just checked out SF again. But I'm heading onto this one: checking whether MonetDB5 version 5.24.0 or newer is installed... no: found only version 5.7.0 configure: error: MonetDB/SQL requires at least version 4.24.0 of MonetDB4 (found none) or version 5.24.0 of MonetDB5 (found 5.7.0). In ./sql What could be done to solve this problem? Stefan
On Sun, May 25, 2008 at 12:50:39AM +0200, Stefan de Konink wrote:
On Sun, 25 May 2008, Stefan Manegold wrote:
I'm done with creating the following "Stable" CVS branches for the upcoming "Jun2008" release:
Hi,
I've just checked out SF again. But I'm heading onto this one:
checking whether MonetDB5 version 5.24.0 or newer is installed... no: found only version 5.7.0 configure: error: MonetDB/SQL requires at least version 4.24.0 of MonetDB4 (found none) or version 5.24.0 of MonetDB5 (found 5.7.0).
my fault. sorry for the inconvenience, and thanks for finding & reporting it!
In ./sql
What could be done to solve this problem?
( cd sql && cvs update ) ;-) Stefan
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 |
Stefan Manegold schreef:
( cd sql && cvs update )
As real l33t h4x0r I changed the configure file by hand already. (And the solution will probably only work in a few hours, pserver crap) But it seems mr-meltdown and my C compiler don't get along. gcc -DHAVE_CONFIG_H -I. -I../../.. -I. -I../../include -I./../../include -I../../common -I./../../common -I../../storage -I./../../storage -I../../server -I./../../server -I/opt/osm/include/MonetDB5/atoms -I/opt/osm/include/MonetDB5/compiler -I/opt/osm/include/MonetDB5/kernel -I/opt/osm/include/MonetDB5/mal -I/opt/osm/include/MonetDB5/optimizer -I/opt/osm/include/MonetDB5/scheduler -I/opt/osm/include/MonetDB5 -I/opt/osm/include/MonetDB -I/opt/osm/include/MonetDB/mapilib -I/opt/osm/include/MonetDB -I/opt/osm/include/MonetDB/common -I/opt/osm/include/MonetDB/gdk -g -O2 -Wall -Wextra -std=c99 -fgnu89-inline -Werror-implicit-function-declaration -Werror -Wpointer-arith -Wdeclaration-after-statement -Wundef -Wp,-D_FORTIFY_SOURCE=2 -c merovingian.c cc1: warnings being treated as errors merovingian.mx: In functie ‘discoveryRunner’: merovingian.mx:1336: let op: ‘sp’ is used uninitialized in this function merovingian.mx:1379: let op: ‘sp’ is used uninitialized in this function gcc --version gcc (GCC) 4.2.4 (Gentoo 4.2.4 p1.0) I could hack out the warning, only looking at the code, I wonder what is actually wrong. The error complains about the declaration, and the first use of the variable will initialize it. Stefan
On Sun, May 25, 2008 at 01:19:37AM +0200, Stefan de Konink wrote:
Stefan Manegold schreef:
( cd sql && cvs update )
As real l33t h4x0r I changed the configure file by hand already. (And the solution will probably only work in a few hours, pserver crap)
But it seems mr-meltdown and my C compiler don't get along.
gcc -DHAVE_CONFIG_H -I. -I../../.. -I. -I../../include -I./../../include -I../../common -I./../../common -I../../storage -I./../../storage -I../../server -I./../../server -I/opt/osm/include/MonetDB5/atoms -I/opt/osm/include/MonetDB5/compiler -I/opt/osm/include/MonetDB5/kernel -I/opt/osm/include/MonetDB5/mal -I/opt/osm/include/MonetDB5/optimizer -I/opt/osm/include/MonetDB5/scheduler -I/opt/osm/include/MonetDB5 -I/opt/osm/include/MonetDB -I/opt/osm/include/MonetDB/mapilib -I/opt/osm/include/MonetDB -I/opt/osm/include/MonetDB/common -I/opt/osm/include/MonetDB/gdk -g -O2 -Wall -Wextra -std=c99 -fgnu89-inline -Werror-implicit-function-declaration -Werror -Wpointer-arith -Wdeclaration-after-statement -Wundef -Wp,-D_FORTIFY_SOURCE=2 -c merovingian.c cc1: warnings being treated as errors merovingian.mx: In functie ‘discoveryRunner’: merovingian.mx:1336: let op: ‘sp’ is used uninitialized in this function merovingian.mx:1379: let op: ‘sp’ is used uninitialized in this function
gcc --version gcc (GCC) 4.2.4 (Gentoo 4.2.4 p1.0)
I could hack out the warning, only looking at the code, I wonder what is actually wrong. The error complains about the declaration, and the first use of the variable will initialize it.
(The compiler cannot see that the function will initialise the pointer!) Please bear with us! The problem was detected by last night's (Fri->Sat) testing, but could not be fixed in CVS on Sat due to my "CVS lock" for creating the new release branches. 1) The problem should NOT occur if you use (as always recommended for non core developers) the latest "Stable" branches instead of the "Current" cutting-edge development trunk. 2) With the development trunk, the problem should NOT occur if you configure with "--disable-strict" (which is the default in the Stable branches. 3) Attached patch prevents the problem. Stefan
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 |
On 25-05-2008 01:19:37 +0200, Stefan de Konink wrote:
Stefan Manegold schreef:
( cd sql && cvs update )
As real l33t h4x0r I changed the configure file by hand already. (And the solution will probably only work in a few hours, pserver crap)
But it seems mr-meltdown and my C compiler don't get along.
yeah, but I couldn't fix due to the **$*$%*$%*# branch freeze.
I could hack out the warning, only looking at the code, I wonder what is actually wrong. The error complains about the declaration, and the first use of the variable will initialize it.
compiler just doesn't see it, assigning it to NULL at declaration time silences it.
On Sun, May 25, 2008 at 10:28:12AM +0200, Fabian Groffen wrote:
On 25-05-2008 01:19:37 +0200, Stefan de Konink wrote:
Stefan Manegold schreef:
( cd sql && cvs update )
As real l33t h4x0r I changed the configure file by hand already. (And ^^^^ ^^^^^ the solution will probably only work in a few hours, pserver crap)
But it seems mr-meltdown and my C compiler don't get along.
yeah, but I couldn't fix due to the **$*$%*$%*# branch freeze. ^^^^^^^^^^^
I know and explained it. Gentlemen, please fix your keyboards! Stefan
I could hack out the warning, only looking at the code, I wonder what is actually wrong. The error complains about the declaration, and the first use of the variable will initialize it.
compiler just doesn't see it, assigning it to NULL at declaration time silences it.
-- | 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 |
On 25-05-2008 10:34:35 +0200, Stefan Manegold wrote:
On Sun, May 25, 2008 at 10:28:12AM +0200, Fabian Groffen wrote:
On 25-05-2008 01:19:37 +0200, Stefan de Konink wrote:
Stefan Manegold schreef:
( cd sql && cvs update )
As real l33t h4x0r I changed the configure file by hand already. (And ^^^^ ^^^^^ the solution will probably only work in a few hours, pserver crap)
But it seems mr-meltdown and my C compiler don't get along.
yeah, but I couldn't fix due to the **$*$%*$%*# branch freeze. ^^^^^^^^^^^
I know and explained it.
Gentlemen, please fix your keyboards!
First one is perfectly readable, second one is censored. (... en gaat over tot de orde van de dag)
On Sun, 25 May 2008, Fabian Groffen wrote:
On 25-05-2008 10:34:35 +0200, Stefan Manegold wrote:
On Sun, May 25, 2008 at 10:28:12AM +0200, Fabian Groffen wrote:
On 25-05-2008 01:19:37 +0200, Stefan de Konink wrote:
Stefan Manegold schreef:
( cd sql && cvs update )
As real l33t h4x0r I changed the configure file by hand already. (And ^^^^ ^^^^^ the solution will probably only work in a few hours, pserver crap)
But it seems mr-meltdown and my C compiler don't get along.
yeah, but I couldn't fix due to the **$*$%*$%*# branch freeze. ^^^^^^^^^^^
I know and explained it.
Gentlemen, please fix your keyboards!
First one is perfectly readable, second one is censored.
(... en gaat over tot de orde van de dag)
Is this the moment to start a flamewar over CVS vs git? ;) But ok :) I understand the difficulty of active development and cvs locks. Bad mkay :) Stefan
participants (4)
-
Fabian Groffen -
Jan Rittinger -
Stefan de Konink -
Stefan Manegold