You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Massimo Manghi <mx...@apache.org> on 2013/09/14 15:57:08 UTC
plans to release rivet 2.1.3
As usual I'm asking on rivet-dev if anyone has something at stake that
might go into a new release of Rivet. There are quite a few things
listed in Changelog worth to go into a bug fix release. If the path is
clear I will call for a formal vote on private@tcl.apache.org (I'm
waiting for feedback from Brice on dio_Mysql.tcl)
A short summary of changes (after 2.1.2 release)
- installation target 'make install' restored to its previous
functionality (hence the whole module and packages are installed)
by making it depend on the two targets install-binaries and
install-packages
- Documentation for make install updated in the manual and INSTALL
- New command variant 'parse -string'
- C API to the parsed moved into the ::rivet namespace
- Fixed some non fully qualified calls to rivet core commands
- Rivet core commands are now in src/rivetcmds as their not expected
to significantly depend from Apache's API and from mod_rivet
- ::rivet::parray is now escaping SGML characters
- Detection of SELECT queries in ::DIO::Mysql improved (conditionally
to Brice's feedback)
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: plans to release rivet 2.1.3
Posted by Massimo Manghi <ma...@unipr.it>.
Hi Jeff,
I've removed them: honestly it was a bit paranoid to log a message to
know whether the ::rivet namespace had been exported, but I couldn't
imagine a context where rivet/init.tcl could be useful outside mod_rivet.
-- Massimo
On 09/18/2013 04:59 AM, Jeff Lawson wrote:
> Massimo, one thing perhaps you can change before the next release...
>
> In lib/rivet/init.tcl there are two instances of "apache_log_error" that
> are problematic for us when we use rivet in non-embedded (outside of
> Apache) environments, so we currently have to create a stub proc for
> that to suppress those calls. Could you make those two calls to
> "apache_log_error" resilient to non-existence?
--
-- Massimo Manghi
Dipartimento di Neuroscienze
Unità di Biofisica e Fisica Medica
via Volturno 39
43125 Parma
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: plans to release rivet 2.1.3
Posted by Jeff Lawson <je...@bovine.net>.
Massimo, one thing perhaps you can change before the next release...
In lib/rivet/init.tcl there are two instances of "apache_log_error" that
are problematic for us when we use rivet in non-embedded (outside of
Apache) environments, so we currently have to create a stub proc for that
to suppress those calls. Could you make those two calls to
"apache_log_error" resilient to non-existence?
On Tue, Sep 17, 2013 at 4:15 PM, Massimo Manghi <mx...@apache.org> wrote:
> thanks Harald
>
>
> On 09/17/2013 09:14 AM, Harald Oehlmann wrote:
>
>> Dear Massimo,
>>
>> thank you for the great action.
>> My "requests" are the maximum and there is no need to comply to them.
>>
>> About the text: which exactly happens is: "fileevents do never fire".
>> The event loop works, as "after 10 {set a 1};vwait a"" works.
>>
>> How to detect "atfork" ?
>> Here is what Jan did in tcl8.5.14:
>> http://core.tcl.tk/tcl/info/**02909e227f<http://core.tcl.tk/tcl/info/02909e227f>
>>
>
>
> yes, thats for the tests etc, but I would like something that could be
> checked when I build. Otherwise we should write it in the release notes and
> warn people the notifier will not be working on OS that don't support
> atfork. As we gathered from the various sources the atfork call has entered
> the POSIX specifications long ago and the support is rather wide.
>
> I'm going to do one more commit...I don't understand why but the
> AM_CPPFLAGS are not a transparent replacement for INCLUDES in Makefile.am,
> at least when placed in a subdir. We have to put the include compilation
> switches in the target specific CPPFLAGS variable
>
> -- Massimo
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.**apache.org<ri...@tcl.apache.org>
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
>
Re: plans to release rivet 2.1.3
Posted by Massimo Manghi <mx...@apache.org>.
thanks Harald
On 09/17/2013 09:14 AM, Harald Oehlmann wrote:
> Dear Massimo,
>
> thank you for the great action.
> My "requests" are the maximum and there is no need to comply to them.
>
> About the text: which exactly happens is: "fileevents do never fire".
> The event loop works, as "after 10 {set a 1};vwait a"" works.
>
> How to detect "atfork" ?
> Here is what Jan did in tcl8.5.14:
> http://core.tcl.tk/tcl/info/02909e227f
yes, thats for the tests etc, but I would like something that could be
checked when I build. Otherwise we should write it in the release notes
and warn people the notifier will not be working on OS that don't
support atfork. As we gathered from the various sources the atfork call
has entered the POSIX specifications long ago and the support is rather
wide.
I'm going to do one more commit...I don't understand why but the
AM_CPPFLAGS are not a transparent replacement for INCLUDES in
Makefile.am, at least when placed in a subdir. We have to put the
include compilation switches in the target specific CPPFLAGS variable
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: plans to release rivet 2.1.3
Posted by Harald Oehlmann <ha...@elmicron.de>.
Dear Massimo,
thank you for the great action.
My "requests" are the maximum and there is no need to comply to them.
About the text: which exactly happens is: "fileevents do never fire".
The event loop works, as "after 10 {set a 1};vwait a"" works.
How to detect "atfork" ?
Here is what Jan did in tcl8.5.14:
http://core.tcl.tk/tcl/info/02909e227f
Thank you,
Harald
Am 16.09.2013 23:05, schrieb Massimo Manghi:
>
> This is the messages printed by 'configure' in case Tcl version is not
> fulfilling the condition for the safe fork.
>
> ========================================================================
> WARNING!
> ========================================================================
> The Tcl notifier (and consequently the event loop) will not be working
> in Rivet running Tcl 8.5.14 and the 'prefork' MPM of Apache.
> Recommended versions are:
> - threaded builds: Tcl >= 8.5.15 (8.5 version) or Tcl >= 8.6.1
> - any non-threaded build of Tcl >= 8.5.10
> ========================================================================
>
> The message is open about the possibility the event loop is functioning,
> but definitely says with which versions of Tcl the event loop is
> expected to work.
>
> I will change it into
>
> "The Tcl notifier .... will not be working....
>
> I don't know how to detect the support of atfork at configure time.
>
> It should also be said that Rivet and Tcl are functional provided the
> programmers don't have to call the event loop. After all we all have
> been programming thousands of lines of Tcl call that work nonetheless.
>
> I should also quote the bugzilla issue that started the whole business
> about fork and the notifier
>
> There is more I'm committing: autoreconf complained about an outdated
> 'missing' file and also about the INCLUDES file that is supposed to be
> replaced by AM_CPPFLAGS
>
> why is automake using a variable hinting at C++ even though the project
> is entirely in C is beyond my comprehension.
>
>
> -- Massimo
>
> On 09/15/2013 07:13 PM, Harald Oehlmann wrote:
>> Massimo,
>> thank you for the summary and the release plans.
>>
>> I did not check the sources, if the following is already included.
>> It is a proposition. We can also say, that we do not need that.
>>
>> Inder the conditions:
>> C1) TCL threaded
>> C2) TCL Verson at least 8.5.15 or 8.6.1
>> C3) atfork not available on the system
>> Introduce a call to:
>> Tcl_InitNotifier()
>> for example in
>> Rivet_ChildInit
>> (it must be after the fork, I don't know the exact place...)
>>
>> It is also possible to introduce theis call always and not under the
>> conditions C1-C3. It does not harm. It just does not help neither:
>> C1: Unthreaded does not have the issue
>> C2: The rivet fork patch will only be in from those TCL versions
>> C3: If atfork is available, TCL does this already.
>>
>> Thank you,
>> Harald
>>
>
--
ELMICRON Dr. Harald Oehlmann GmbH
Koesener Str. 85
06618 Naumburg
Germany
Phone: +49 (0)3445 78112-0
Fax: +49 (0)3445 78112-19
www.Elmicron.de
German legal references:
Geschaeftsfuehrer: Dr. Harald Oehlmann, Jens Oehlmann
UST Nr. / VAT ID No.: DE206105272
HRB 212803 Stendal
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: plans to release rivet 2.1.3
Posted by Massimo Manghi <mx...@apache.org>.
This is the messages printed by 'configure' in case Tcl version is not
fulfilling the condition for the safe fork.
========================================================================
WARNING!
========================================================================
The Tcl notifier (and consequently the event loop) will not be working
in Rivet running Tcl 8.5.14 and the 'prefork' MPM of Apache.
Recommended versions are:
- threaded builds: Tcl >= 8.5.15 (8.5 version) or Tcl >= 8.6.1
- any non-threaded build of Tcl >= 8.5.10
========================================================================
The message is open about the possibility the event loop is functioning,
but definitely says with which versions of Tcl the event loop is
expected to work.
I will change it into
"The Tcl notifier .... will not be working....
I don't know how to detect the support of atfork at configure time.
It should also be said that Rivet and Tcl are functional provided the
programmers don't have to call the event loop. After all we all have
been programming thousands of lines of Tcl call that work nonetheless.
I should also quote the bugzilla issue that started the whole business
about fork and the notifier
There is more I'm committing: autoreconf complained about an outdated
'missing' file and also about the INCLUDES file that is supposed to be
replaced by AM_CPPFLAGS
why is automake using a variable hinting at C++ even though the project
is entirely in C is beyond my comprehension.
-- Massimo
On 09/15/2013 07:13 PM, Harald Oehlmann wrote:
> Massimo,
> thank you for the summary and the release plans.
>
> I did not check the sources, if the following is already included.
> It is a proposition. We can also say, that we do not need that.
>
> Inder the conditions:
> C1) TCL threaded
> C2) TCL Verson at least 8.5.15 or 8.6.1
> C3) atfork not available on the system
> Introduce a call to:
> Tcl_InitNotifier()
> for example in
> Rivet_ChildInit
> (it must be after the fork, I don't know the exact place...)
>
> It is also possible to introduce theis call always and not under the
> conditions C1-C3. It does not harm. It just does not help neither:
> C1: Unthreaded does not have the issue
> C2: The rivet fork patch will only be in from those TCL versions
> C3: If atfork is available, TCL does this already.
>
> Thank you,
> Harald
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: plans to release rivet 2.1.3
Posted by Harald Oehlmann <ha...@elmicron.de>.
Massimo,
thank you for the summary and the release plans.
I did not check the sources, if the following is already included.
It is a proposition. We can also say, that we do not need that.
Inder the conditions:
C1) TCL threaded
C2) TCL Verson at least 8.5.15 or 8.6.1
C3) atfork not available on the system
Introduce a call to:
Tcl_InitNotifier()
for example in
Rivet_ChildInit
(it must be after the fork, I don't know the exact place...)
It is also possible to introduce theis call always and not under the
conditions C1-C3. It does not harm. It just does not help neither:
C1: Unthreaded does not have the issue
C2: The rivet fork patch will only be in from those TCL versions
C3: If atfork is available, TCL does this already.
Thank you,
Harald
Am 14.09.2013 15:57, schrieb Massimo Manghi:
> As usual I'm asking on rivet-dev if anyone has something at stake that
> might go into a new release of Rivet. There are quite a few things
> listed in Changelog worth to go into a bug fix release. If the path is
> clear I will call for a formal vote on private@tcl.apache.org (I'm
> waiting for feedback from Brice on dio_Mysql.tcl)
>
> A short summary of changes (after 2.1.2 release)
>
> - installation target 'make install' restored to its previous
> functionality (hence the whole module and packages are installed)
> by making it depend on the two targets install-binaries and
> install-packages
> - Documentation for make install updated in the manual and INSTALL
> - New command variant 'parse -string'
> - C API to the parsed moved into the ::rivet namespace
> - Fixed some non fully qualified calls to rivet core commands
> - Rivet core commands are now in src/rivetcmds as their not expected
> to significantly depend from Apache's API and from mod_rivet
> - ::rivet::parray is now escaping SGML characters
> - Detection of SELECT queries in ::DIO::Mysql improved (conditionally
> to Brice's feedback)
>
> -- Massimo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
--
ELMICRON Dr. Harald Oehlmann GmbH
Koesener Str. 85
06618 Naumburg
Germany
Phone: +49 (0)3445 78112-0
Fax: +49 (0)3445 78112-19
www.Elmicron.de
German legal references:
Geschaeftsfuehrer: Dr. Harald Oehlmann, Jens Oehlmann
UST Nr. / VAT ID No.: DE206105272
HRB 212803 Stendal
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org