planning a new bugfix release
The issue raised in bug #57501 was quite important and, provided the tests to be carried out soon at FA will prove the bug has been fixed, I would like to release 2.2.2 in a week or two. We usually allow at least 2 / 3 months between bugfix releases but this issue was relevant and the bug was filed just a few days after 2.2.1 went out. cheers -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: planning a 2.1.4 release
The test suite is now performing a few tests on lassign_array and lremove. I wrote 2 simple manual pages for them. I don't know how stable the functions comma_join and comma_split are. They look like pretty stable and adding tests for them should be easy (their original specifications could be easily imagined, but there is little written in the source code). Manual pages are missing though. I still have to elaborate the manual for ::rivet::inspect which now supports also the subcommand ::inspect script. It would be nice to have a few tests for this command. I thinks I need one more week to get this stuff done. -- Massimo On 02/12/2014 12:59 AM, Massimo Manghi wrote: the Tcl implementation of lassign_array was removed from trunk and new tests were added for the same librivetlib implementation of the command. The manual now reflects the latter extended feature of returning the unassigned list values, as Tcl lassign does. I have little time to dedicate on this thus I'm slowly proceeding one step after another towards a release candidate. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: planning a 2.1.4 release
the Tcl implementation of lassign_array was removed from trunk and new tests were added for the same librivetlib implementation of the command. The manual now reflects the latter extended feature of returning the unassigned list values, as Tcl lassign does. I have little time to dedicate on this thus I'm slowly proceeding one step after another towards a release candidate. -- Massimo On 02/08/2014 12:57 AM, Massimo Manghi wrote: Ronnie, you saved me from doing something potentially very stupid. Thanks for pointing this out. I always forget to consider rivetList.c and rivetCrypt.c because they're not documented (unlike rivetWWW.c). It seems to me the C code provides the extended feature of returning the unassigned elements. I will check it more carefully and in case preserve it dropping the Tcl procedure. DIO implementation was kept because it might exist code calling this function as a member procedure of DIO derived class using the '$this method' form. -- Massimo The implementation in dio.tcl was kept On 02/07/2014 03:11 PM, Ronnie Brunner wrote: Hi Massimo 4 command lassign_array was replicated from class ::DIO::Database (being totally general and independent from member variables) and promoted to core command Plausible list except for - and that's my outside view ;-) - this number 4: In Rivet I see a C implementation of lassign_array (rivetList.c) and a Tcl implementation (so far) in dio.tcl. They don't do the same thing. If you promote the dio version to core command, you'll change the mechanics of the existing C implementation. Don't you? Again: me not using Rivet doesn't really make me understand what I'm saying ;-) Best regards Ronnie - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: planning a 2.1.4 release
Hi Massimo 4 command lassign_array was replicated from class ::DIO::Database (being totally general and independent from member variables) and promoted to core command Plausible list except for - and that's my outside view ;-) - this number 4: In Rivet I see a C implementation of lassign_array (rivetList.c) and a Tcl implementation (so far) in dio.tcl. They don't do the same thing. If you promote the dio version to core command, you'll change the mechanics of the existing C implementation. Don't you? Again: me not using Rivet doesn't really make me understand what I'm saying ;-) Best regards Ronnie -- Ronnie Brunner | ronnie.brun...@netcetera.com | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: planning a 2.1.4 release
Ronnie, you saved me from doing something potentially very stupid. Thanks for pointing this out. I always forget to consider rivetList.c and rivetCrypt.c because they're not documented (unlike rivetWWW.c). It seems to me the C code provides the extended feature of returning the unassigned elements. I will check it more carefully and in case preserve it dropping the Tcl procedure. DIO implementation was kept because it might exist code calling this function as a member procedure of DIO derived class using the '$this method' form. -- Massimo The implementation in dio.tcl was kept On 02/07/2014 03:11 PM, Ronnie Brunner wrote: Hi Massimo 4 command lassign_array was replicated from class ::DIO::Database (being totally general and independent from member variables) and promoted to core command Plausible list except for - and that's my outside view ;-) - this number 4: In Rivet I see a C implementation of lassign_array (rivetList.c) and a Tcl implementation (so far) in dio.tcl. They don't do the same thing. If you promote the dio version to core command, you'll change the mechanics of the existing C implementation. Don't you? Again: me not using Rivet doesn't really make me understand what I'm saying ;-) Best regards Ronnie - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
planning a 2.1.4 release
There a few new things in current trunk that are worth be moved to branches/2.1 in view of releasing 2.1.4. 1 ::rivet::inspect command was improved and extended. A better documentation page should be written though. I have to figure out how to implement a few tests for this command. 2 The unconditional call to Tcl_EvalObjEx (and related calls to build the Tcl object holding the script fragment) for the sole purpose of driving the response of 'info script' was removed. 3 Following this track I noticed in Rivet_SendContent the buffer to a TclWebRequest structure (whose pointer is stored in globals-req) was likewise allocated unnecessarily at *every request*. It's allocated only once now in Rivet_PerInterpInit and then initialized by TclWeb_RequestInit in Rivet_SendContent 4 command lassign_array was replicated from class ::DIO::Database (being totally general and independent from member variables) and promoted to core command 5 A Tcl 8.6 incompatibility was detected in dio_Mysql.tcl and fixed (to be committed yet) Furthermore the code in mod_rivet was split moving the configuration specific functions in a new file. This one is clearly invisible to the programmer. feedback would be much appreciated -- -- Massimo Manghi Dipartimento di Neuroscienze Unità di Biofisica e Fisica Medica via Volturno 39 43125 Parma - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Planning
As I already told David, I'd like if we started to think about a planning of the project (as Valery suggested some weeks ago) That would give me a chance to concentrate myself on some aspects or modules and maybe be productive. What is there to plan, really? Some coordination is necessary, such as I'm going to be working on this file today, but aside from architectural questions, Rivet needs doing rather than planning, IMO:-) -- David N. Welton http://www.welton.it/davidw/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning
David Welton wrote: As I already told David, I'd like if we started to think about a planning of the project (as Valery suggested some weeks ago) That would give me a chance to concentrate myself on some aspects or modules and maybe be productive. What is there to plan, really? Some coordination is necessary, such as I'm going to be working on this file today, but aside from architectural questions, Rivet needs doing rather than planning, IMO:-) something like that is already a form of planning, but we should do things to make rivet work also keeping the architectural problems in mind (when possible): the more we can reuse in the future the better is. -- M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
