- developers-list - monetdb.org

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

24 Nov '06

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

2 2

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

23 Nov '06

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

1 0

Re: [Monetdb-developers] MonetDB port for Crux Linux
by Martin Kersten 21 Nov '06

21 Nov '06

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

1 0

[Monetdb-developers] MapiClient asynchronous interface?
by Johann Borck 19 Nov '06

19 Nov '06

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

3 12

[Monetdb-developers] Not descriptive error message
by Robin Aly 17 Nov '06

17 Nov '06

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

2 2

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/algebra/opt opt_set.c, 1.1, 1.2
by Maurice van Keulen 17 Nov '06

17 Nov '06

Hi Jan, I just thought: how does your duplicate generating scjoins relate to the generalized scjoin I proposed in my TDM 2004-paper? <http://db.cs.utwente.nl/Publications/PaperStore/db-utwente-0000003587.pdf> Maurice. Jan Rittinger wrote: > Update of /cvsroot/monetdb/pathfinder/compiler/algebra/opt > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv23019/algebra/opt > > Modified Files: > opt_set.c > Log Message: > -- Rewrite scjoin operators into duplicate generating ones as intermediate > step. (This helps the join pushdown phase to push down more joins.) > > > Index: opt_set.c > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/algebra/opt/opt_set.c,v > retrieving revision 1.1 > retrieving revision 1.2 > diff -u -d -r1.1 -r1.2 > --- opt_set.c 13 Nov 2006 17:10:59 -0000 1.1 > +++ opt_set.c 17 Nov 2006 14:03:41 -0000 1.2 > @@ -50,6 +50,11 @@ > #define L(p) ((p)->child[0]) > /** starting from p, make a step right */ > #define R(p) ((p)->child[1]) > +/** and so on ... */ > +#define LL(p) (L(L(p))) > +#define LR(p) (R(L(p))) > +#define RL(p) (L(R(p))) > +#define RR(p) (R(R(p))) > > #define SEEN(p) ((p)->bit_dag) > > @@ -71,6 +76,56 @@ > > /* action code */ > switch (p->kind) { > + case la_eqjoin: > + /* Rewrite scjoin into duplicate generating scjoins > + (underneath join operators). This hopefully allows > + the above join to be pushed down in a later phase. */ > + if (PFprop_set (p->prop) && > + L(p)->kind == la_scjoin && > + PFprop_set (L(p)->prop)) { > + PFalg_att_t item_res; > + item_res = PFalg_ori_name ( > + PFalg_unq_name (att_item, 0), > + ~(L(p)->sem.scjoin.item | > + L(p)->sem.scjoin.iter)); > + *L(p) = *PFla_project ( > + PFla_dup_scjoin ( > + LL(p), > + LR(p), > + L(p)->sem.scjoin.axis, > + L(p)->sem.scjoin.ty, > + L(p)->sem.scjoin.item, > + item_res), > + PFalg_proj (L(p)->sem.scjoin.iter, > + L(p)->sem.scjoin.iter), > + PFalg_proj (L(p)->sem.scjoin.item, > + item_res)); > + break; > + } > + if (PFprop_set (p->prop) && > + R(p)->kind == la_scjoin && > + PFprop_set (R(p)->prop)) { > + PFalg_att_t item_res; > + item_res = PFalg_ori_name ( > + PFalg_unq_name (att_item, 0), > + ~(R(p)->sem.scjoin.item | > + R(p)->sem.scjoin.iter)); > + *R(p) = *PFla_project ( > + PFla_dup_scjoin ( > + RL(p), > + RR(p), > + R(p)->sem.scjoin.axis, > + R(p)->sem.scjoin.ty, > + R(p)->sem.scjoin.item, > + item_res), > + PFalg_proj (R(p)->sem.scjoin.iter, > + R(p)->sem.scjoin.iter), > + PFalg_proj (R(p)->sem.scjoin.item, > + item_res)); > + break; > + } > + break; > + > case la_distinct: > if (PFprop_set (p->prop)) > *p = *PFla_dummy (L(p)); > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > -- ---------------------------------------------------------------------- Dr.Ir. M. van Keulen - Assistant Professor, Data Management Technology Univ. of Twente, Dept of EEMCS, POBox 217, 7500 AE Enschede, Netherlands Email: m.vankeulen(a)utwente.nl, Phone: +31 534893688, Fax: +31 534892927 Room: ZI 3039, WWW: http://www.cs.utwente.nl/~keulen

1 0

Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/include logical.h, 1.25, 1.26 logical_mnemonic.h, 1.14, 1.15
by Maurice van Keulen 13 Nov '06

13 Nov '06

Hi Jan, Can you explain a little bit more about this? Or is there a Wiki page that explains it? I'm rather curious about what you mean by "duplicate generating path step operator" Maurice. Jan Rittinger wrote: > Update of /cvsroot/monetdb/pathfinder/compiler/include > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv28492/include > > Modified Files: > logical.h logical_mnemonic.h > Log Message: > -- Introduced a new duplicate generating path step operator. This operator > is introduced in the proxy detection phase and replaces the following > pattern by a new dup_scjoin operator: > > |X| > __/ \__ > / \ > (pi) | > | | > scjoin (pi) > / | | > (pi) | > \__ __/ > \ / > # > > The new operator keeps all the columns of its right argument -- the left > argument refers to the fragment information -- and adds a new column > (stored in the semantical field scjoin.item_res) based on the context column > (stored in the semantical field scjoin.item). Because the result may change > the cardinality all the other columns are mapped based on the input context > nodes. > > > Index: logical_mnemonic.h > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/include/logical_mnemonic.h,v > retrieving revision 1.14 > retrieving revision 1.15 > diff -u -d -r1.14 -r1.15 > --- logical_mnemonic.h 27 Sep 2006 12:03:51 -0000 1.14 > +++ logical_mnemonic.h 13 Nov 2006 09:58:40 -0000 1.15 > @@ -134,6 +134,7 @@ > > /** staircase join */ > #define scjoin(a,b,c,d,e,f,g) PFla_scjoin ((a),(b),(c),(d),(e),(f),(g)) > +#define dup_scjoin(a,b,c,d,e,f) PFla_dup_scjoin ((a),(b),(c),(d),(e),(f)) > > /** document table */ > #define doc_tbl(a,b,c,d) PFla_doc_tbl((a),(b),(c),(d)) > > Index: logical.h > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/compiler/include/logical.h,v > retrieving revision 1.25 > retrieving revision 1.26 > diff -u -d -r1.25 -r1.26 > --- logical.h 31 Oct 2006 09:32:45 -0000 1.25 > +++ logical.h 13 Nov 2006 09:58:40 -0000 1.26 > @@ -87,8 +87,9 @@ > iteration (Pathfinder extension) */ > , la_all = 44 /**< test if all items in an iteration are true */ > , la_scjoin = 50 /**< staircase join */ > - , la_doc_tbl = 51 /**< document relation (is also a fragment) */ > - , la_doc_access = 52 /**< document access necessary for pf:string-value */ > + , la_dup_scjoin = 51 /**< staircase join */ > + , la_doc_tbl = 52 /**< document relation (is also a fragment) */ > + , la_doc_access = 53 /**< document access necessary for pf:string-value */ > , la_element = 60 /**< element-constructing operator */ > , la_element_tag = 61 /**< part of the element-constructing operator; > connecting element tag and content; > @@ -604,6 +605,16 @@ > PFalg_att_t iter, PFalg_att_t item, > PFalg_att_t item_res); > > +/** > + * Staircase join without duplicates between two relations. > + * Each such join corresponds to the evaluation of an XPath > + * location step. > + */ > +PFla_op_t * PFla_dup_scjoin (const PFla_op_t *doc, const PFla_op_t *n, > + PFalg_axis_t axis, PFty_t seqty, > + PFalg_att_t item, > + PFalg_att_t item_res); > + > /*********** node construction functionality *************/ > > /* > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > -- ---------------------------------------------------------------------- Dr.Ir. M. van Keulen - Assistant Professor, Data Management Technology Univ. of Twente, Dept of EEMCS, POBox 217, 7500 AE Enschede, Netherlands Email: m.vankeulen(a)utwente.nl, Phone: +31 534893688, Fax: +31 534892927 Room: ZI 3039, WWW: http://www.cs.utwente.nl/~keulen

2 1

Re: [Monetdb-developers] Monetdb-developers Digest, Vol 6, Issue 15
by p.a.boncz 11 Nov '06

11 Nov '06

Hi Stefan, Thanks for bringing this up. While I started with (1) for some of the most glaring bugs on Wednesday to ensure that the HEAD has some functionality; I switched to (2) since yesterday. Peter ------------------------------ Message: 2 Date: Fri, 10 Nov 2006 00:39:08 +0100 From: Stefan Manegold <Stefan.Manegold(a)cwi.nl> Subject: [Monetdb-developers] Branches, Checkins & Propagation To: monetdb-developers(a)lists.sourceforge.net Message-ID: <20061109233908.GA13905(a)corona.ins.cwi.nl> Content-Type: text/plain; charset=us-ascii Esteemed fellow developers, having two tightly related branches --- the release branch and the development trunk --- give us the opportunity to clearly and conveniently isolate new "progressive" developments on the development trunk from "conservative" code consolidation and bug fixing on the release branch. Unfortunately, also this medal has a second side: to make the development trunk benefit from the code consolidation and bug fixes on the release branch either (1) *each* of the respective changes has to be checked in twice (by *each* developer), or (2) the checkins to the branch are *in bulk* (aka. "automa[tgn]ically") propagated from the release branch to the development trunk on an (ir?)regular basis or on need/request. (1) has the advantage that all bug fixes are "instantly" available in the development trunk, too, but comes at the cost of double checkins and bears the risk of "forgetting" one. (2) keep all developers from extra work and -responsibility, but has the disadvantage that the availability of bug fixes in the development trunk is delayed. Both strategies bear the risk of conflicts in case development has modified code before a bug fix is applied. That's obviously unavoidable and such conflicts need to be resolved "by hand". Provided only one of the two strategies is strictly applied these should be the only conflicts. Mixing the two strategies, however, is IMHO no option, as it will/does/did introduce extra conflicts: Say developer A applies a bug fix X to both the release branch and the development trunk. Later developer B applies once bug fix Y that (partly) changes the code that was also modified by bug fix X. Finally, when developer C tries to perform the bulk propagation of bug fixes since the last propagation (i.e., X & Y) from branch to the trunk, a conflict occurs since X had already been applied on the trunk. Hence, mixing both strategies forces us to spend even more of our precious time and energy on fixing these *avoidable* conflicts by hand. I guess, I can assume that you all agree that this is not desirable. Since we started with the first release branch a couple of years ago, we have been using strategy (2), summarized as * all bug-fixes (and only these) must go to the new release branches (and only there) * all new features must go to the development trunks (and only there) However, since the above (and similar) situation of mixing the strategies with all its consequences has just occurred, I'm wondering whether you're all still "satisfied" with strategy (2), or whether you'd prefer to switch (completely!) to strategy (1). I'm in favor of sticking to (2), but I'm perfectly fine if we agree on *consequently* switching to (1). Hence, please hit your keyboard, comment, and vote for either strategy. Looking forward to hearing your verdict! 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 | ------------------------------ Message: 3 Date: Fri, 10 Nov 2006 09:39:23 +0100 From: Torsten Grust <torsten.grust(a)gmail.com> Subject: Re: [Monetdb-developers] Branches, Checkins & Propagation To: Stefan Manegold <Stefan.Manegold(a)cwi.nl> Cc: monetdb-developers(a)lists.sourceforge.net Message-ID: <85BE9631-CA92-4AF0-817D-F6352C2BDD15(a)gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear all, I'm all with option (2) here. --Teggy On Nov 10, 2006, 12:39 AM, Stefan Manegold wrote with possible deletions: > [...] Unfortunately, also this medal has a second side: to make the > development > trunk benefit from the code consolidation and bug fixes on the release > branch either (1) *each* of the respective changes has to be > checked in > twice (by *each* developer), or (2) the checkins to the branch are > *in bulk* > (aka. "automa[tgn]ically") propagated from the release branch to the > development trunk on an (ir?)regular basis or on need/request. [...] -- | Torsten Grust | torsten.grust(a)gmail.com ------------------------------ Message: 4 Date: Fri, 10 Nov 2006 11:33:13 +0100 From: Stefan Manegold <Stefan.Manegold(a)cwi.nl> Subject: Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/runtime pathfinder.mx, 1.269.2.7, 1.269.2.8 To: monetdb-developers(a)lists.sourceforge.net, Peter Boncz <P.Boncz(a)cwi.nl> Cc: monetdb-pf-checkins(a)lists.sourceforge.net Message-ID: <20061110103313.GA26099(a)corona.ins.cwi.nl> Content-Type: text/plain; charset=us-ascii Peter are the *.print() below debugging output that should not be in and hence be removed again? Thanks! Stefan On Thu, Nov 09, 2006 at 11:35:05PM +0000, Peter Boncz wrote: > Update of /cvsroot/monetdb/pathfinder/runtime > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv29555 > > Modified Files: > Tag: XQuery_0-14 > pathfinder.mx > Log Message: > - newnids(): prevent error in slice > > > > Index: pathfinder.mx > =================================================================== > RCS file: /cvsroot/monetdb/pathfinder/runtime/pathfinder.mx,v > retrieving revision 1.269.2.7 > retrieving revision 1.269.2.8 > diff -u -d -r1.269.2.7 -r1.269.2.8 > --- pathfinder.mx 9 Nov 2006 18:17:58 -0000 1.269.2.7 > +++ pathfinder.mx 9 Nov 2006 23:35:02 -0000 1.269.2.8 > @@ -1488,10 +1488,10 @@ > { > var free_nids := runtime.fetch(RT_NID_FREELIST); > var i := count(free_nids); > - > +free_nids.col_name("free_nids").print(); > # re-use a page from the list; or -if empty- append a new page > if (i > 0) { > - var ret := free_nids.slice(i - cnt, i - 1).copy(); > + var ret := free_nids.slice(max(0, i - cnt), i - 1).copy(); > free_nids.delete(ret); > return ret; > } > @@ -1797,6 +1797,7 @@ > lock_set(coll_lock); > var newnids := empty_bat, err := CATCH(newnids := __runtime_newnids(runtime, cnt)); > lock_unset(coll_lock); > +newnids.col_name("newnids").print(); > > if (isnil(err) and bit(cnt :-= count(newnids))) { > # not enough free nids page: we must physically extend the nid_rid table > @@ -1834,6 +1835,7 @@ > var delta := reverse(nid_rid.slice(nid_off,nid_cnt - 1)); > # put nids in reverse order in the freelist, so they are given out in order > delta := delta.copy().access(BAT_WRITE).revert(); > +delta.col_name("delta").print(); > > # add extra created NIDs to the freelist > lock_set(coll_lock); > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Monetdb-pf-checkins mailing list > Monetdb-pf-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins > > -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 | ------------------------------ ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ------------------------------ _______________________________________________ Monetdb-developers mailing list Monetdb-developers(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers End of Monetdb-developers Digest, Vol 6, Issue 15 *************************************************

3 2

Re: [Monetdb-developers] [Monetdb-checkins] MonetDB/src/modules/plain logger.mx, 1.49.2.4, 1.49.2.5
by Stefan Manegold 11 Nov '06

11 Nov '06

Niels, maybe, we should consider making --enable-strict the default also in the branch as long as development/bug-fixing goes on and only switch back to --disable-strict ust before we actually build the release? Stefan On Sat, Nov 11, 2006 at 08:11:33AM +0000, Niels Nes wrote: > Update of /cvsroot/monetdb/MonetDB/src/modules/plain > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv2406 > > Modified Files: > Tag: MonetDB_4-14 > logger.mx > Log Message: > (reconfigured using --enable-strict), ie more compilation fixes > > > Index: logger.mx > =================================================================== > RCS file: /cvsroot/monetdb/MonetDB/src/modules/plain/logger.mx,v > retrieving revision 1.49.2.4 > retrieving revision 1.49.2.5 > diff -u -d -r1.49.2.4 -r1.49.2.5 > --- logger.mx 11 Nov 2006 08:03:35 -0000 1.49.2.4 > +++ logger.mx 11 Nov 2006 08:11:31 -0000 1.49.2.5 > @@ -359,7 +359,7 @@ > } > > static int > -log_read_seq(logger *logger, trans *tr, logformat *l) > +log_read_seq(logger *logger, logformat *l) > { > int seq = l->nr; > lng id; > @@ -532,6 +532,7 @@ > static void > log_read_destroy(logger *logger, trans *tr, char *name) > { > + (void)logger; > tr_grow(tr); > tr->changes[tr->nr].type = LOG_DESTROY; > tr->changes[tr->nr].name = GDKstrdup(name); > @@ -607,6 +608,7 @@ > static void > log_read_use(logger *logger, trans *tr, logformat *l, char *name) > { > + (void)logger; > tr_grow(tr); > tr->changes[tr->nr].type = LOG_USE; > tr->changes[tr->nr].nr = l->nr; > @@ -814,7 +816,7 @@ > tr = tr_commit(logger, tr); > break; > case LOG_SEQ: > - err = (log_read_seq(logger, tr, &l) != LOG_OK); > + err = (log_read_seq(logger, &l) != LOG_OK); > break; > case LOG_INSERT: > case LOG_DELETE: > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Monetdb-checkins mailing list > Monetdb-checkins(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/monetdb-checkins -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

[Monetdb-developers] Functions & macros
by Wouter Scherphof 10 Nov '06

10 Nov '06

Let me just check if I got this correctly: Is it a general rule that each call to a function generates overhead, that can be eliminated by replacing the function with a macro and "calling" the macro instead? Regards, Wouter.

4 3