Re: rivet 3.0.1 build fails for Scientific Linux 7
Hi Massimo, it is a more genera decission. Scintific Linux, Apache etc have TCL 8.5 as default. If we want to support them (with Rivet 3), it has to build here. I may add a switch that TCL must have 8.6.1 minimum. The current spec file says: %define use_newer %(echo 'puts [package vsatisfies [info patch] 8.5.10]' | tclsh) Name: apache2-mod_rivet %if %{use_newer} Version:3.0.1 %else Version:2.0.6 %endif So, we may add a switch case to use 2.3.4 from 8.5.10 to 8.6.0. About the try command: I normally have a compatibility layer to emulate new commands by a tcl command, if I am forced to support older interpreters: if {0 == [llength [info commands ::try]]} { proc ::try args {...} } There is no tcl equivalent of try in the wiki, strange... There was one in the TIP 329, but the link is dead. Thank you, Harald Am 16.02.2018 um 23:06 schrieb Massimo Manghi: > On 02/16/2018 08:17 PM, Harald Oehlmann wrote: >> Hi Massimo, >> >> thank you for the reply ! >> >> About the compiler: the log file says: >> gcc-4.8.2-16 > > that's rather old, I haven't seen gcc 4.8 around for quite a long time, > but this package could not work properly (at least as a fully compatible > replacement of a 2.x module) because rivet 3.0 requires Tcl >= 8.6.1 > > the reason is very easy: the central request processing procedure uses > the 'try' command. It could work if this procedure is replaced in the > configuration. If there is interest in supporting Tcl 8.5 I think we > should analyze the implications: providing a request processing > procedure for Tcl 8.5 would be possible, but I have to check if Tcl 8.6 > is demanded in other places > >> >> You find most of this information at the top of the log file when >> packages are installed. >> >> You also have the configure options with a warning: >> ./configure --build=x86_64-redhat-linux-gnu >> --host=x86_64-redhat-linux-gnu --program-prefix= >> --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr >> --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc >> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 >> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib >> --mandir=/usr/share/man --infodir=/usr/share/info --with-tcl=/usr/lib64 >> --with-apache-version=2 --with-tclsh=/usr/bin/tclsh --with-apache=/usr >> --with-rivet-target-dir=/usr/lib64/tcl8.5/apache2-mod_rivet3.0.1 >> --with-apxs=/usr/bin/apxs --with-pic --disable-rpath >> [ 55s] configure: WARNING: unrecognized options: --with-apache-version >> >> Later on, there is the warning caused by my bad experiences: >> configure: WARNING: >> --enable-threads requested, but building against a Tcl that is NOT >> thread-enabled. This is an OK configuration that will also run in >> a thread-enabled core. >> >> Thank you, >> Harald >> >> > > I remember and IIRC that also means the module can work without > asynchronous I/O but it can work for a whole class of application > without need of sophisticated interaction with sockets or other services > > -- Massimo -- 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-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: rivet 3.0.1 build fails for Scientific Linux 7
On 02/16/2018 08:17 PM, Harald Oehlmann wrote: Hi Massimo, thank you for the reply ! About the compiler: the log file says: gcc-4.8.2-16 You find most of this information at the top of the log file when packages are installed. You also have the configure options with a warning: ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-tcl=/usr/lib64 --with-apache-version=2 --with-tclsh=/usr/bin/tclsh --with-apache=/usr --with-rivet-target-dir=/usr/lib64/tcl8.5/apache2-mod_rivet3.0.1 --with-apxs=/usr/bin/apxs --with-pic --disable-rpath [ 55s] configure: WARNING: unrecognized options: --with-apache-version Later on, there is the warning caused by my bad experiences: configure: WARNING: --enable-threads requested, but building against a Tcl that is NOT thread-enabled. This is an OK configuration that will also run in a thread-enabled core. Thank you, Harald I'm attaching here a patch that should fix the compilation issue. The function is still unused but I'll keep it hoping one day we'll be able to treat threads running Tcl interps as real lightweight processes and dispose and recreate them separately from their process. still to be committed to the repository -- Massimo Index: src/mod_rivet_ng/worker_prefork_common.c === --- src/mod_rivet_ng/worker_prefork_common.c (revision 1824558) +++ src/mod_rivet_ng/worker_prefork_common.c (working copy) @@ -272,8 +272,6 @@ void Rivet_ProcessorCleanup (void *data) { rivet_thread_private* private = (rivet_thread_private *) data; -Tcl_HashSearch* searchCtx; -Tcl_HashEntry* entry; int i; rivet_server_conf* rsc = RIVET_SERVER_CONF(module_globals->server->module_config); @@ -293,24 +291,14 @@ Tcl_SetStdChannel(NULL,TCL_STDOUT); /* there must be always a root interpreter in the slot 0 of private->interps, - so there is always need to run at least one cycle here */ + so we always need to run this cycle at least onece */ i = 0; do { -/* cleaning the cache contents and deleting it */ +RivetCache_Cleanup(private,private->ext->interps[i]); -searchCtx = apr_pcalloc(private->pool,sizeof(Tcl_HashSearch)); -entry = Tcl_FirstHashEntry(private->ext->interps[i]->objCache,searchCtx); -while (entry) -{ -Tcl_DecrRefCount(Tcl_GetHashValue(entry)); /* Let Tcl clear the mem allocated */ -Tcl_DeleteHashEntry(entry); - -entry = Tcl_NextHashEntry(searchCtx); -} - if ((i > 0) && rsc->separate_channels) Rivet_ReleaseRivetChannel(private->ext->interps[i]->interp,private->channel); - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: rivet 3.0.1 build fails for Scientific Linux 7
On 02/16/2018 08:17 PM, Harald Oehlmann wrote: Hi Massimo, thank you for the reply ! About the compiler: the log file says: gcc-4.8.2-16 that's rather old, I haven't seen gcc 4.8 around for quite a long time, but this package could not work properly (at least as a fully compatible replacement of a 2.x module) because rivet 3.0 requires Tcl >= 8.6.1 the reason is very easy: the central request processing procedure uses the 'try' command. It could work if this procedure is replaced in the configuration. If there is interest in supporting Tcl 8.5 I think we should analyze the implications: providing a request processing procedure for Tcl 8.5 would be possible, but I have to check if Tcl 8.6 is demanded in other places You find most of this information at the top of the log file when packages are installed. You also have the configure options with a warning: ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-tcl=/usr/lib64 --with-apache-version=2 --with-tclsh=/usr/bin/tclsh --with-apache=/usr --with-rivet-target-dir=/usr/lib64/tcl8.5/apache2-mod_rivet3.0.1 --with-apxs=/usr/bin/apxs --with-pic --disable-rpath [ 55s] configure: WARNING: unrecognized options: --with-apache-version Later on, there is the warning caused by my bad experiences: configure: WARNING: --enable-threads requested, but building against a Tcl that is NOT thread-enabled. This is an OK configuration that will also run in a thread-enabled core. Thank you, Harald I remember and IIRC that also means the module can work without asynchronous I/O but it can work for a whole class of application without need of sophisticated interaction with sockets or other services -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: rivet 3.0.1 build fails for Scientific Linux 7
Hi Massimo, thank you for the reply ! About the compiler: the log file says: gcc-4.8.2-16 You find most of this information at the top of the log file when packages are installed. You also have the configure options with a warning: ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-tcl=/usr/lib64 --with-apache-version=2 --with-tclsh=/usr/bin/tclsh --with-apache=/usr --with-rivet-target-dir=/usr/lib64/tcl8.5/apache2-mod_rivet3.0.1 --with-apxs=/usr/bin/apxs --with-pic --disable-rpath [ 55s] configure: WARNING: unrecognized options: --with-apache-version Later on, there is the warning caused by my bad experiences: configure: WARNING: --enable-threads requested, but building against a Tcl that is NOT thread-enabled. This is an OK configuration that will also run in a thread-enabled core. Thank you, Harald Am 16.02.2018 um 19:43 schrieb Massimo Manghi: > The error is correctly raised and I wonder why other builds didn't > notice it. What C compiler are they using? The good news is the whole > function could be removed because it's not used. It was meant to clean > up the resources of a thread but as long as Tcl interpreters cannot be > safely deleted we cannot simply let single threads exit cleaning > everything left behind, we must terminate a whole process. > > Handling a whole process termination is just about making possible to > applications to clean up their own resources but it makes the problem of > memory leaks of mod_rivet internal stuff easy to handle. Nonetheless I > tried as much as possible to look ahead when Tcl is able to consistently > release Tcl interpreters, that would offer the chance to design flexible > threaded bridges. > > -- Massimo > > > On 02/16/2018 07:01 PM, Harald Oehlmann wrote: >> Dear Friends, >> >> OBS build for Scientific Linux for 3.0.1 started but fails unfortunately >> in compilation. >> >> See overview of all platforms: >> https://build.opensuse.org/package/show/home:oehhar/apache2-mod_rivet >> >> Here is the ScientificLinux 7 compile error: >> >> [ 62s] libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. >> -I./mod_rivet_ng -I./request -I/usr/include -O2 -g -pipe -Wall >> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong >> --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic >> -I/usr/include/httpd -I/usr/include/apr-1 -I/usr/include/apr-1 -DLINUX >> -D_REENTRANT -D_GNU_SOURCE "-DSTART_TAG=\"\"" >> -DUSE_TCL_STUBS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >> -m64 -mtune=generic -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c >> librivet/rivetWWW.c -fPIC -DPIC -o >> librivet/.libs/librivetlib_la-rivetWWW.o >> [ 62s] In file included from mod_rivet_ng/mod_rivet.h:31:0, >> [ 62s] from mod_rivet_ng/worker_prefork_common.c:26: >> [ 62s] mod_rivet_ng/worker_prefork_common.c: In function >> 'Rivet_ProcessorCleanup': >> [ 62s] mod_rivet_ng/worker_prefork_common.c:308:13: error: request for >> member 'refCount' in something not a structure or union >> [ 62s] Tcl_DecrRefCount(Tcl_GetHashValue(entry)); /* Let >> Tcl clear the mem allocated */ >> [ 62s] ^ >> >> Has anybody an idea ? >> >> Thank you, >> Harald >> >> >> >> >> - >> To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org >> For additional commands, e-mail: rivet-dev-h...@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-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: rivet 3.0.1 build fails for Scientific Linux 7
The error is correctly raised and I wonder why other builds didn't notice it. What C compiler are they using? The good news is the whole function could be removed because it's not used. It was meant to clean up the resources of a thread but as long as Tcl interpreters cannot be safely deleted we cannot simply let single threads exit cleaning everything left behind, we must terminate a whole process. Handling a whole process termination is just about making possible to applications to clean up their own resources but it makes the problem of memory leaks of mod_rivet internal stuff easy to handle. Nonetheless I tried as much as possible to look ahead when Tcl is able to consistently release Tcl interpreters, that would offer the chance to design flexible threaded bridges. -- Massimo On 02/16/2018 07:01 PM, Harald Oehlmann wrote: Dear Friends, OBS build for Scientific Linux for 3.0.1 started but fails unfortunately in compilation. See overview of all platforms: https://build.opensuse.org/package/show/home:oehhar/apache2-mod_rivet Here is the ScientificLinux 7 compile error: [ 62s] libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./mod_rivet_ng -I./request -I/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -I/usr/include/httpd -I/usr/include/apr-1 -I/usr/include/apr-1 -DLINUX -D_REENTRANT -D_GNU_SOURCE "-DSTART_TAG=\"\"" -DUSE_TCL_STUBS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c librivet/rivetWWW.c -fPIC -DPIC -o librivet/.libs/librivetlib_la-rivetWWW.o [ 62s] In file included from mod_rivet_ng/mod_rivet.h:31:0, [ 62s] from mod_rivet_ng/worker_prefork_common.c:26: [ 62s] mod_rivet_ng/worker_prefork_common.c: In function 'Rivet_ProcessorCleanup': [ 62s] mod_rivet_ng/worker_prefork_common.c:308:13: error: request for member 'refCount' in something not a structure or union [ 62s] Tcl_DecrRefCount(Tcl_GetHashValue(entry)); /* Let Tcl clear the mem allocated */ [ 62s] ^ Has anybody an idea ? Thank you, Harald - 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: rivet 3.0.1 released
Dear Massimo, the rpm buildscript just makes a basic test with a file included in the demo folder of Rivet. Maybe, this demo folder does not exist any more. So lets look: Log: [ 81s] --- [ 81s] APACHE MODULE TEST [ 81s] [ 81s] modules to load: mime rivet [ 81s] configs to include: mod_rivet.conf [ 81s] Will load mime_module /usr/lib64/apache2/mod_mime.so [ 81s] Will load rivet_module /home/abuild/rpmbuild/BUILDROOT/apache2-mod_rivet-3.0.1-1.1.x86_64/usr/lib64/apache2/mod_rivet.so [ 81s] Will include /home/abuild/rpmbuild/BUILDROOT/apache2-mod_rivet-3.0.1-1.1.x86_64/etc/apache2/conf.d/mod_rivet.conf [ 83s] Starting Apache ... FAILED, /tmp/apache2-mod_rivet-test/error_log: >&2 [ 83s] [Thu Feb 15 22:29:42.562197 2018] [rivet:error] [pid 6765] (20014)Internal error (specific information not available): mod_rivet: could not read rivet default handler [ 83s] See /tmp/apache2-mod_rivet-test for details So that is the code: # exit code from the %check phase (0 means success) exit_code=0 # package is not installed during %check phase, need to redirect to %{buildroot}%{rivetdir} export TCLLIBPATH="%{buildroot}%{rivetdir}" # create test DocumentRoot for apache instance; # %{apache_test_module_dir} is not created until now too mkdir -p %{apache_test_module_dir}/test-document-root # copy example doc to test DocumentRoot cp doc/examples/table.rvt %{apache_test_module_dir}/test-document-root # start test apache instance with mod_mime and (just built) mod_rivet loaded, include # native mod_rivet.conf and with DocumentRoot at %{apache_test_module_dir}/test-document-root %apache_test_module_start_apache -m mime:rivet -r %{apache_test_module_dir}/test-document-root -i mod_rivet.conf Does anybody see any issue? Danilo Chang has copied the spec file, removed the test and has put it on his account: https://build.opensuse.org/package/show/home:danilochang/apache2-mod_rivet The result is a successful build. Maybe, that is a way to go... Thank you, Harald Am 10.02.2018 um 09:51 schrieb Massimo Manghi: > Thank you Harald > > the error is raised by a failed attempt to read a file, actually a Tcl > script, which is not 'sourced', it's read and stored in memory > > The problem could arise from a structural flawed design of the test > suite as I have developed it from its original functionalities: > basically you need to install rivet in order to be able to test it. I > can't make out exactly what the SuSE build service does, but I suspect > the environment is not perfectly set up when the test runs. > > A better test suite could be a goal for this year > > -- Massimo > > > On 02/09/2018 08:49 PM, Harald Oehlmann wrote: >> Hi Massimo, >> >> thank you ! >> >> I have tried to put it on open build service. >> >> It builds well but a test fails (on SuSE Tumbleweed): >> >> [ 53s] Will load mime_module /usr/lib64/apache2/mod_mime.so >> [ 53s] Will load rivet_module >> /home/abuild/rpmbuild/BUILDROOT/apache2-mod_rivet-3.0.1-1.1.x86_64/usr/lib64/apache2/mod_rivet.so >> >> [ 53s] Will include >> /home/abuild/rpmbuild/BUILDROOT/apache2-mod_rivet-3.0.1-1.1.x86_64/etc/apache2/conf.d/mod_rivet.conf >> >> [ 55s] Starting Apache ... FAILED, >> /tmp/apache2-mod_rivet-test/error_log: >&2 >> [ 55s] [Fri Feb 09 19:39:39.340521 2018] [rivet:error] [pid 6704] >> (20014)Internal error (specific information not available): mod_rivet: >> could not read rivet default handler >> [ 55s] See /tmp/apache2-mod_rivet-test for details >> [ 55s] FAILED, /tmp/apache2-mod_rivet-test/error_log: >> [ 55s] [Fri Feb 09 19:39:39.340521 2018] [rivet:error] [pid 6704] >> (20014)Internal error (specific information not available): mod_rivet: >> could not read rivet default handler >> >> Maybee, many things changed since 2.x... >> >> So, the install command is: >> >> if [ -x %{_sbindir}/a2enmod ] >> then >> if ! a2enmod -q rivet; then >> a2enmod rivet >> fi >> fi >> >> Rivet conf file: >> >> # Let the module handle .rvt and .tcl files. >> AddType application/x-httpd-rivet rvt >> AddType application/x-rivet-tcl tcl >> >> # The default charset can be specified in the configuration >> AddType "application/x-httpd-rivet; charset=utf-8" rvt >> >> # Add index.rvt to the list of files that will be served >> DirectoryIndex index.rvt >> >> The full log is attached. >> >> Thanks for any help to the occacional worker... >> >> Enjoy, >> Harald >> >> Am 09.02.2018 um 19:18 schrieb Massimo Manghi: >>> I just released rivet 3.0.1 and should be available soon from the ASF >>> distribution. This bugfix release basically includes >>> >>> * the namespace determination in librivet has been revised to >>> avoid to check for the module globals and therefore avoiding >>> the inclusion of mod_rivet.h >>> >>> * a few details in the worker bridge have been fixed >>> >>> * the lazy bridge has been extensively commented >>> >>> * document
Re: rivet 3.0.1 released
Thank you Harald the error is raised by a failed attempt to read a file, actually a Tcl script, which is not 'sourced', it's read and stored in memory The problem could arise from a structural flawed design of the test suite as I have developed it from its original functionalities: basically you need to install rivet in order to be able to test it. I can't make out exactly what the SuSE build service does, but I suspect the environment is not perfectly set up when the test runs. A better test suite could be a goal for this year -- Massimo On 02/09/2018 08:49 PM, Harald Oehlmann wrote: Hi Massimo, thank you ! I have tried to put it on open build service. It builds well but a test fails (on SuSE Tumbleweed): [ 53s] Will load mime_module /usr/lib64/apache2/mod_mime.so [ 53s] Will load rivet_module /home/abuild/rpmbuild/BUILDROOT/apache2-mod_rivet-3.0.1-1.1.x86_64/usr/lib64/apache2/mod_rivet.so [ 53s] Will include /home/abuild/rpmbuild/BUILDROOT/apache2-mod_rivet-3.0.1-1.1.x86_64/etc/apache2/conf.d/mod_rivet.conf [ 55s] Starting Apache ... FAILED, /tmp/apache2-mod_rivet-test/error_log: >&2 [ 55s] [Fri Feb 09 19:39:39.340521 2018] [rivet:error] [pid 6704] (20014)Internal error (specific information not available): mod_rivet: could not read rivet default handler [ 55s] See /tmp/apache2-mod_rivet-test for details [ 55s] FAILED, /tmp/apache2-mod_rivet-test/error_log: [ 55s] [Fri Feb 09 19:39:39.340521 2018] [rivet:error] [pid 6704] (20014)Internal error (specific information not available): mod_rivet: could not read rivet default handler Maybee, many things changed since 2.x... So, the install command is: if [ -x %{_sbindir}/a2enmod ] then if ! a2enmod -q rivet; then a2enmod rivet fi fi Rivet conf file: # Let the module handle .rvt and .tcl files. AddType application/x-httpd-rivet rvt AddType application/x-rivet-tcltcl # The default charset can be specified in the configuration AddType "application/x-httpd-rivet; charset=utf-8" rvt # Add index.rvt to the list of files that will be served DirectoryIndex index.rvt The full log is attached. Thanks for any help to the occacional worker... Enjoy, Harald Am 09.02.2018 um 19:18 schrieb Massimo Manghi: I just released rivet 3.0.1 and should be available soon from the ASF distribution. This bugfix release basically includes * the namespace determination in librivet has been revised to avoid to check for the module globals and therefore avoiding the inclusion of mod_rivet.h * a few details in the worker bridge have been fixed * the lazy bridge has been extensively commented * documentation has been expanded and corrected in various sections -- Massimo - 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: rivet 3.0.1 released
I just released rivet 3.0.1 and should be available soon from the ASF distribution. This bugfix release basically includes * the namespace determination in librivet has been revised to avoid to check for the module globals and therefore avoiding the inclusion of mod_rivet.h * a few details in the worker bridge have been fixed * the lazy bridge has been extensively commented * documentation has been expanded and corrected in various sections * and most important George Petasis fix of interpreter initialization in the worker bridge. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Rivet 3.0.1
Thank you Ronnie, I checked the patch and it's fine to menot for laziness but I invite you to commit the patch yourself. I would be happy you receive a full credit and have your name in one of rivet's ChangeLog entries. -- Massimo On 02/08/2018 12:24 PM, Ronnie Brunner wrote: Hi Massimo I did a little digging and I finally understand what’s happening and I could fix my testing problems (hopefully for good)… 1.When I ran the test, the “Running all tests against one server process.” failed to run the tests because Tcl didn’t find the librivet package and threw an error. Providing for this in my automation script solved the problem.-> I now run 130 tests J 2.While I faked TclX’s kill, I didn’t fake the wait, which is also used, but within a catch, that’s why I never noticed. And that’s why I had the timing issues: my kill just needs to properly “wait” too J To address both (for easier handling), I propose the following changes: for 1. I added a [puts stderr $::errorInfo] to show what goes wrong if the code provided for the test fails (this revealed the problem of the missing librivet) for 2. I porpose to get rid of TclX by providing a “waiting” Tcl implementation using [exec kill] and [exec ps]. (Yes, not particularly portable, but I don’t think the test run under Windows anyway, do they?.) Also, you currently send a QUIT signal to apache to kill the process, this is not very reliable for me. Also the TERM signal takes 1.5 seconds on average to kill the process (in my env) sometimes over 2 seconds, that’s why some of my tests fails. I changed the signal to KILL and the suite runs much faster now. A modified version of test/pachetest/apachetest.tcl and the corresponding patch is attached. Last but not least, I propose to drop the module test for the prefork mpm in tests/runtests.tcl so we can test w/o modification against both mpms… Thanks and best regards Ronnie - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
RE: Rivet 3.0.1
Hi Massimo I did a little digging and I finally understand what’s happening and I could fix my testing problems (hopefully for good)… 1. When I ran the test, the “Running all tests against one server process.” failed to run the tests because Tcl didn’t find the librivet package and threw an error. Providing for this in my automation script solved the problem.-> I now run 130 tests ☺ 2. While I faked TclX’s kill, I didn’t fake the wait, which is also used, but within a catch, that’s why I never noticed. And that’s why I had the timing issues: my kill just needs to properly “wait” too ☺ To address both (for easier handling), I propose the following changes: for 1. I added a [puts stderr $::errorInfo] to show what goes wrong if the code provided for the test fails (this revealed the problem of the missing librivet) for 2. I porpose to get rid of TclX by providing a “waiting” Tcl implementation using [exec kill] and [exec ps]. (Yes, not particularly portable, but I don’t think the test run under Windows anyway, do they?.) Also, you currently send a QUIT signal to apache to kill the process, this is not very reliable for me. Also the TERM signal takes 1.5 seconds on average to kill the process (in my env) sometimes over 2 seconds, that’s why some of my tests fails. I changed the signal to KILL and the suite runs much faster now. A modified version of test/pachetest/apachetest.tcl and the corresponding patch is attached. Last but not least, I propose to drop the module test for the prefork mpm in tests/runtests.tcl so we can test w/o modification against both mpms… Thanks and best regards Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 21:01 To: Ronnie Brunner ; Massimo Manghi ; petas...@yahoo.gr Cc: rivet-dev@tcl.apache.org Subject: Re: Rivet 3.0.1 Thank you Ronnie, still the discrepancy between my PC and yours bothers me quite a bit. I would like to have more time to investigate, in the meanwhile would you sent over your error_log and output? Thank you -- Massimo Manghi Da: Ronnie Brunner mailto:ronnie.brun...@netcetera.com>> Inviato: martedì 6 febbraio 2018 20:48 A: Massimo MANGHI; Massimo Manghi; petas...@yahoo.gr<mailto:petas...@yahoo.gr> Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Oggetto: RE: Rivet 3.0.1 Hi Massimo Sorry, I haven’t noticed your answer w/ the rc2 earlier. Thought it referred to George’s issue with the test suite… I have compared 3.0.1rc1 w/ 3.0.1rc2: they show the same result. Running tests now gives 38 failed tests for both. (I’m not sure why I got fewer errors when I tried initially. Could well be that some of it is and or was timing related, the machine I use is used by many and although virtualized, it’s not always under the same or even just similar load…) So I stand by the statement: it’s an improvement since 3.0.0, so nothing speaks against a release, but there is still something amiss. (No guarantee it’s not my somewhat homegrown environment: I compiled httpd as well as Tcl locally to have control over the versions and I refer to only those versions when testing. Great for testing different versions, but as I learned, the test suite currently runs on Tcl8.6 and http 2.4 only…. I use Tcl.8.6.6 and hddpt-2.4.27 currently) Regards Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com<mailto:ronnie.brun...@netcetera.com> | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 18:33 To: Ronnie Brunner mailto:ronnie.brun...@netcetera.com>>; Massimo Manghi mailto:massimo.man...@alice.it>>; petas...@yahoo.gr<mailto:petas...@yahoo.gr> Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Subject: Re: Rivet 3.0.1 Hi Ronnie are your latest test results obtained from 3.0.1rc2? I fixed a problem that made the server fail in most cases, their are all OK for me now Another issue with your test output is the overall number of tests actually carried out: 83. I have 130 tests running and 3.0.1rc2 passes each and everyone on my PC. Why your test suite is avoiding ~50 tests? -- Massimo Da: Ronnie Brunner mailto:ronnie.brun...@netcetera.com>> Inviato: martedì 6 febbraio 2018 17:05 A: Massimo MANGHI; Massimo Manghi; petas...@yahoo.gr<mailto:petas...@yahoo.gr> Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Oggetto: RE: Rivet 3.0.1 Hi Massimo My problem for the worker mpm is certainly not a blocker, as I never managed (actually, really tried) to run
Re: Rivet 3.0.1
Good, really neat! I suppose this result is suggesting we drop TclX and replace that function with our homemade kill proc with a cautionary timing that could help to make tests at least reproducible. cheers -- Massimo On 02/07/2018 06:36 PM, Ronnie Brunner wrote: Hi Massimo Well, who would have thought: I made the testsuite work for the worker mpm, by just giving my pseudo kill proc to fake TclX a bit more time (5 secs) to do the job ☺. I noticed that I didn’t get the same result always, that’s why I suspected a timing issue… The tests run forever now, but nothing fails for the worker mpm anymore! I still got only 83 tests though, but I’ll have to look into that another time. As for now, I guess, I scared you for nothing. Sorry for that! Gruess Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 21:01 To: Ronnie Brunner ; Massimo Manghi ; petas...@yahoo.gr Cc: rivet-dev@tcl.apache.org Subject: Re: Rivet 3.0.1 Thank you Ronnie, still the discrepancy between my PC and yours bothers me quite a bit. I would like to have more time to investigate, in the meanwhile would you sent over your error_log and output? Thank you -- Massimo Manghi - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
RE: Rivet 3.0.1
Hi Massimo Well, who would have thought: I made the testsuite work for the worker mpm, by just giving my pseudo kill proc to fake TclX a bit more time (5 secs) to do the job ☺. I noticed that I didn’t get the same result always, that’s why I suspected a timing issue… The tests run forever now, but nothing fails for the worker mpm anymore! I still got only 83 tests though, but I’ll have to look into that another time. As for now, I guess, I scared you for nothing. Sorry for that! Gruess Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 21:01 To: Ronnie Brunner ; Massimo Manghi ; petas...@yahoo.gr Cc: rivet-dev@tcl.apache.org Subject: Re: Rivet 3.0.1 Thank you Ronnie, still the discrepancy between my PC and yours bothers me quite a bit. I would like to have more time to investigate, in the meanwhile would you sent over your error_log and output? Thank you -- Massimo Manghi Da: Ronnie Brunner mailto:ronnie.brun...@netcetera.com>> Inviato: martedì 6 febbraio 2018 20:48 A: Massimo MANGHI; Massimo Manghi; petas...@yahoo.gr<mailto:petas...@yahoo.gr> Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Oggetto: RE: Rivet 3.0.1 Hi Massimo Sorry, I haven’t noticed your answer w/ the rc2 earlier. Thought it referred to George’s issue with the test suite… I have compared 3.0.1rc1 w/ 3.0.1rc2: they show the same result. Running tests now gives 38 failed tests for both. (I’m not sure why I got fewer errors when I tried initially. Could well be that some of it is and or was timing related, the machine I use is used by many and although virtualized, it’s not always under the same or even just similar load…) So I stand by the statement: it’s an improvement since 3.0.0, so nothing speaks against a release, but there is still something amiss. (No guarantee it’s not my somewhat homegrown environment: I compiled httpd as well as Tcl locally to have control over the versions and I refer to only those versions when testing. Great for testing different versions, but as I learned, the test suite currently runs on Tcl8.6 and http 2.4 only…. I use Tcl.8.6.6 and hddpt-2.4.27 currently) Regards Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com<mailto:ronnie.brun...@netcetera.com> | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 18:33 To: Ronnie Brunner mailto:ronnie.brun...@netcetera.com>>; Massimo Manghi mailto:massimo.man...@alice.it>>; petas...@yahoo.gr<mailto:petas...@yahoo.gr> Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Subject: Re: Rivet 3.0.1 Hi Ronnie are your latest test results obtained from 3.0.1rc2? I fixed a problem that made the server fail in most cases, their are all OK for me now Another issue with your test output is the overall number of tests actually carried out: 83. I have 130 tests running and 3.0.1rc2 passes each and everyone on my PC. Why your test suite is avoiding ~50 tests? -- Massimo Da: Ronnie Brunner mailto:ronnie.brun...@netcetera.com>> Inviato: martedì 6 febbraio 2018 17:05 A: Massimo MANGHI; Massimo Manghi; petas...@yahoo.gr<mailto:petas...@yahoo.gr> Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Oggetto: RE: Rivet 3.0.1 Hi Massimo My problem for the worker mpm is certainly not a blocker, as I never managed (actually, really tried) to run the tests for that mpm. I always tested exclusively against prefork, mainly because I thought the others aren’t supported yet. Also: The test result of Rivet 3.0.0 that I get in my setup is much worse than the result of 3.0.1. So 3.0.1 actually brings an improvement as previously, almost no tests worked. (I just reran my setup w/ 3.0.0 -> rivet.test: Total 83 Passed 4 Skipped 0 Failed 79) Hth and best regards Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com<mailto:ronnie.brun...@netcetera.com> | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 16:29 To: Ronnie Brunner mailto:ronnie.brun...@netcetera.com>>; Massimo Manghi mailto:massimo.man...@alice.it>>; petas...@yahoo.gr<mailto:petas...@yahoo.gr> Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Subject: Re: Rivet 3.0.1 Should we consider this issue a reason for withholding 3.0.1? I think that as long as 2.2
Re: Rivet 3.0.1
Thank you Ronnie, still the discrepancy between my PC and yours bothers me quite a bit. I would like to have more time to investigate, in the meanwhile would you sent over your error_log and output? Thank you -- Massimo Manghi Da: Ronnie Brunner Inviato: martedì 6 febbraio 2018 20:48 A: Massimo MANGHI; Massimo Manghi; petas...@yahoo.gr Cc: rivet-dev@tcl.apache.org Oggetto: RE: Rivet 3.0.1 Hi Massimo Sorry, I haven’t noticed your answer w/ the rc2 earlier. Thought it referred to George’s issue with the test suite… I have compared 3.0.1rc1 w/ 3.0.1rc2: they show the same result. Running tests now gives 38 failed tests for both. (I’m not sure why I got fewer errors when I tried initially. Could well be that some of it is and or was timing related, the machine I use is used by many and although virtualized, it’s not always under the same or even just similar load…) So I stand by the statement: it’s an improvement since 3.0.0, so nothing speaks against a release, but there is still something amiss. (No guarantee it’s not my somewhat homegrown environment: I compiled httpd as well as Tcl locally to have control over the versions and I refer to only those versions when testing. Great for testing different versions, but as I learned, the test suite currently runs on Tcl8.6 and http 2.4 only…. I use Tcl.8.6.6 and hddpt-2.4.27 currently) Regards Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 18:33 To: Ronnie Brunner ; Massimo Manghi ; petas...@yahoo.gr Cc: rivet-dev@tcl.apache.org Subject: Re: Rivet 3.0.1 Hi Ronnie are your latest test results obtained from 3.0.1rc2? I fixed a problem that made the server fail in most cases, their are all OK for me now Another issue with your test output is the overall number of tests actually carried out: 83. I have 130 tests running and 3.0.1rc2 passes each and everyone on my PC. Why your test suite is avoiding ~50 tests? -- Massimo Da: Ronnie Brunner mailto:ronnie.brun...@netcetera.com>> Inviato: martedì 6 febbraio 2018 17:05 A: Massimo MANGHI; Massimo Manghi; petas...@yahoo.gr<mailto:petas...@yahoo.gr> Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Oggetto: RE: Rivet 3.0.1 Hi Massimo My problem for the worker mpm is certainly not a blocker, as I never managed (actually, really tried) to run the tests for that mpm. I always tested exclusively against prefork, mainly because I thought the others aren’t supported yet. Also: The test result of Rivet 3.0.0 that I get in my setup is much worse than the result of 3.0.1. So 3.0.1 actually brings an improvement as previously, almost no tests worked. (I just reran my setup w/ 3.0.0 -> rivet.test: Total 83 Passed 4 Skipped 0 Failed 79) Hth and best regards Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com<mailto:ronnie.brun...@netcetera.com> | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 16:29 To: Ronnie Brunner mailto:ronnie.brun...@netcetera.com>>; Massimo Manghi mailto:massimo.man...@alice.it>>; petas...@yahoo.gr<mailto:petas...@yahoo.gr> Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Subject: Re: Rivet 3.0.1 Should we consider this issue a reason for withholding 3.0.1? I think that as long as 2.2 is supported we may exploit the compatibility with 2.4. When 2.2 is deprecated we may proceed with the new macro definition. This is good example where having a versioning system like git or fossil could be handy. Can I start the vote for releasing 3.0.1? -- Massimo Da: Georgios Petasis mailto:petas...@yahoo.gr>> Inviato: domenica 4 febbraio 2018 14:54 A: Massimo MANGHI; Ronnie Brunner; Massimo Manghi Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Oggetto: Re: Rivet 3.0.1 Dear Massimo, According to the documentation: https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html We should also modify rivet.c to use AP_DECLARE_MODULE instead of "module AP_MODULE_DECLARE_DATA rivet_module = " we now have. I have tried it, and there was no difference (of course we must take care the old way is used in versions < 2.4 of apache). I tried to run the tests, but I am missing the TclX package. Where can I find its sources? In sourceforge? Best, George Στις 3/2/2018 20:52, ο Massimo Manghi έγραψε: > I've just uploaded to > www.rivetweb.org/~mxm/rivet<http://www.rivetweb.org/~mxm/rivet> a RC2
RE: Rivet 3.0.1
Hi Massimo Sorry, I haven’t noticed your answer w/ the rc2 earlier. Thought it referred to George’s issue with the test suite… I have compared 3.0.1rc1 w/ 3.0.1rc2: they show the same result. Running tests now gives 38 failed tests for both. (I’m not sure why I got fewer errors when I tried initially. Could well be that some of it is and or was timing related, the machine I use is used by many and although virtualized, it’s not always under the same or even just similar load…) So I stand by the statement: it’s an improvement since 3.0.0, so nothing speaks against a release, but there is still something amiss. (No guarantee it’s not my somewhat homegrown environment: I compiled httpd as well as Tcl locally to have control over the versions and I refer to only those versions when testing. Great for testing different versions, but as I learned, the test suite currently runs on Tcl8.6 and http 2.4 only…. I use Tcl.8.6.6 and hddpt-2.4.27 currently) Regards Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 18:33 To: Ronnie Brunner ; Massimo Manghi ; petas...@yahoo.gr Cc: rivet-dev@tcl.apache.org Subject: Re: Rivet 3.0.1 Hi Ronnie are your latest test results obtained from 3.0.1rc2? I fixed a problem that made the server fail in most cases, their are all OK for me now Another issue with your test output is the overall number of tests actually carried out: 83. I have 130 tests running and 3.0.1rc2 passes each and everyone on my PC. Why your test suite is avoiding ~50 tests? -- Massimo Da: Ronnie Brunner mailto:ronnie.brun...@netcetera.com>> Inviato: martedì 6 febbraio 2018 17:05 A: Massimo MANGHI; Massimo Manghi; petas...@yahoo.gr<mailto:petas...@yahoo.gr> Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Oggetto: RE: Rivet 3.0.1 Hi Massimo My problem for the worker mpm is certainly not a blocker, as I never managed (actually, really tried) to run the tests for that mpm. I always tested exclusively against prefork, mainly because I thought the others aren’t supported yet. Also: The test result of Rivet 3.0.0 that I get in my setup is much worse than the result of 3.0.1. So 3.0.1 actually brings an improvement as previously, almost no tests worked. (I just reran my setup w/ 3.0.0 -> rivet.test: Total 83 Passed 4 Skipped 0 Failed 79) Hth and best regards Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com<mailto:ronnie.brun...@netcetera.com> | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 16:29 To: Ronnie Brunner mailto:ronnie.brun...@netcetera.com>>; Massimo Manghi mailto:massimo.man...@alice.it>>; petas...@yahoo.gr<mailto:petas...@yahoo.gr> Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Subject: Re: Rivet 3.0.1 Should we consider this issue a reason for withholding 3.0.1? I think that as long as 2.2 is supported we may exploit the compatibility with 2.4. When 2.2 is deprecated we may proceed with the new macro definition. This is good example where having a versioning system like git or fossil could be handy. Can I start the vote for releasing 3.0.1? -- Massimo Da: Georgios Petasis mailto:petas...@yahoo.gr>> Inviato: domenica 4 febbraio 2018 14:54 A: Massimo MANGHI; Ronnie Brunner; Massimo Manghi Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Oggetto: Re: Rivet 3.0.1 Dear Massimo, According to the documentation: https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html We should also modify rivet.c to use AP_DECLARE_MODULE instead of "module AP_MODULE_DECLARE_DATA rivet_module = " we now have. I have tried it, and there was no difference (of course we must take care the old way is used in versions < 2.4 of apache). I tried to run the tests, but I am missing the TclX package. Where can I find its sources? In sourceforge? Best, George Στις 3/2/2018 20:52, ο Massimo Manghi έγραψε: > I've just uploaded to > www.rivetweb.org/~mxm/rivet<http://www.rivetweb.org/~mxm/rivet> a RC2 tar > archive > with a proposed patch of the problem that made most tests fail. > > The bug has surfaced when George introduced the APLOG_USE_MODULE in > mod_rivet.h, since also rivetlib/rivetPkgInit.c used it in order to > get the definition of the module globals. But since the generation of > the pkgIndex.tcl file takes place outside of mod_rivet the mk_pkgIndex > failed for rivetlib and became impossible to mod_rivet to
Re: Rivet 3.0.1
Hi Ronnie are your latest test results obtained from 3.0.1rc2? I fixed a problem that made the server fail in most cases, their are all OK for me now Another issue with your test output is the overall number of tests actually carried out: 83. I have 130 tests running and 3.0.1rc2 passes each and everyone on my PC. Why your test suite is avoiding ~50 tests? -- Massimo Da: Ronnie Brunner Inviato: martedì 6 febbraio 2018 17:05 A: Massimo MANGHI; Massimo Manghi; petas...@yahoo.gr Cc: rivet-dev@tcl.apache.org Oggetto: RE: Rivet 3.0.1 Hi Massimo My problem for the worker mpm is certainly not a blocker, as I never managed (actually, really tried) to run the tests for that mpm. I always tested exclusively against prefork, mainly because I thought the others aren’t supported yet. Also: The test result of Rivet 3.0.0 that I get in my setup is much worse than the result of 3.0.1. So 3.0.1 actually brings an improvement as previously, almost no tests worked. (I just reran my setup w/ 3.0.0 -> rivet.test: Total 83 Passed 4 Skipped 0 Failed 79) Hth and best regards Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 16:29 To: Ronnie Brunner ; Massimo Manghi ; petas...@yahoo.gr Cc: rivet-dev@tcl.apache.org Subject: Re: Rivet 3.0.1 Should we consider this issue a reason for withholding 3.0.1? I think that as long as 2.2 is supported we may exploit the compatibility with 2.4. When 2.2 is deprecated we may proceed with the new macro definition. This is good example where having a versioning system like git or fossil could be handy. Can I start the vote for releasing 3.0.1? -- Massimo Da: Georgios Petasis mailto:petas...@yahoo.gr>> Inviato: domenica 4 febbraio 2018 14:54 A: Massimo MANGHI; Ronnie Brunner; Massimo Manghi Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Oggetto: Re: Rivet 3.0.1 Dear Massimo, According to the documentation: https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html We should also modify rivet.c to use AP_DECLARE_MODULE instead of "module AP_MODULE_DECLARE_DATA rivet_module = " we now have. I have tried it, and there was no difference (of course we must take care the old way is used in versions < 2.4 of apache). I tried to run the tests, but I am missing the TclX package. Where can I find its sources? In sourceforge? Best, George Στις 3/2/2018 20:52, ο Massimo Manghi έγραψε: > I've just uploaded to > www.rivetweb.org/~mxm/rivet<http://www.rivetweb.org/~mxm/rivet> a RC2 tar > archive > with a proposed patch of the problem that made most tests fail. > > The bug has surfaced when George introduced the APLOG_USE_MODULE in > mod_rivet.h, since also rivetlib/rivetPkgInit.c used it in order to > get the definition of the module globals. But since the generation of > the pkgIndex.tcl file takes place outside of mod_rivet the mk_pkgIndex > failed for rivetlib and became impossible to mod_rivet to find the > library. As as consequence the server failed because rivetlib is > loaded in the process of initializing a Rivet interpreter > > Actually the introduction of the macro was correct and it's was > librivet/rivetPkgInit.c duty to determine the ::rivet name space > pointer in a different and sane way. This is the crux of the patch > included in RC2 > > -- Massimo > > On 02/01/2018 01:07 PM, Ronnie Brunner wrote: >> Hi Massimo >> >> Attached the output (stout and sdterr) of running the test suite >> (including the compilation of rivet), the error_log and access_log >> from rivet-3.0.1/tests after running the test suite. >> >> I'm running a CentOS Linux release 7.1.1503 (Core) os for these >> tests, Tcl8.6.6 and httpd 2.4.27 with the worker mpm. The only >> modification to runtests.tcl was to remove the prefork module check, >> which obviously fails if you run the worker mpm. >> >> Let me know if you need anything else. >> >> Hth Ronnie >> > > - > To unsubscribe, e-mail: > rivet-dev-unsubscr...@tcl.apache.org<mailto:rivet-dev-unsubscr...@tcl.apache.org> > For additional commands, e-mail: > rivet-dev-h...@tcl.apache.org<mailto:rivet-dev-h...@tcl.apache.org> > >
RE: Rivet 3.0.1
Hi Massimo My problem for the worker mpm is certainly not a blocker, as I never managed (actually, really tried) to run the tests for that mpm. I always tested exclusively against prefork, mainly because I thought the others aren’t supported yet. Also: The test result of Rivet 3.0.0 that I get in my setup is much worse than the result of 3.0.1. So 3.0.1 actually brings an improvement as previously, almost no tests worked. (I just reran my setup w/ 3.0.0 -> rivet.test: Total 83 Passed 4 Skipped 0 Failed 79) Hth and best regards Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | From: Massimo MANGHI [mailto:massimo.man...@unipr.it] Sent: Dienstag, 6. Februar 2018 16:29 To: Ronnie Brunner ; Massimo Manghi ; petas...@yahoo.gr Cc: rivet-dev@tcl.apache.org Subject: Re: Rivet 3.0.1 Should we consider this issue a reason for withholding 3.0.1? I think that as long as 2.2 is supported we may exploit the compatibility with 2.4. When 2.2 is deprecated we may proceed with the new macro definition. This is good example where having a versioning system like git or fossil could be handy. Can I start the vote for releasing 3.0.1? -- Massimo Da: Georgios Petasis mailto:petas...@yahoo.gr>> Inviato: domenica 4 febbraio 2018 14:54 A: Massimo MANGHI; Ronnie Brunner; Massimo Manghi Cc: rivet-dev@tcl.apache.org<mailto:rivet-dev@tcl.apache.org> Oggetto: Re: Rivet 3.0.1 Dear Massimo, According to the documentation: https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html We should also modify rivet.c to use AP_DECLARE_MODULE instead of "module AP_MODULE_DECLARE_DATA rivet_module = " we now have. I have tried it, and there was no difference (of course we must take care the old way is used in versions < 2.4 of apache). I tried to run the tests, but I am missing the TclX package. Where can I find its sources? In sourceforge? Best, George Στις 3/2/2018 20:52, ο Massimo Manghi έγραψε: > I've just uploaded to > www.rivetweb.org/~mxm/rivet<http://www.rivetweb.org/~mxm/rivet> a RC2 tar > archive > with a proposed patch of the problem that made most tests fail. > > The bug has surfaced when George introduced the APLOG_USE_MODULE in > mod_rivet.h, since also rivetlib/rivetPkgInit.c used it in order to > get the definition of the module globals. But since the generation of > the pkgIndex.tcl file takes place outside of mod_rivet the mk_pkgIndex > failed for rivetlib and became impossible to mod_rivet to find the > library. As as consequence the server failed because rivetlib is > loaded in the process of initializing a Rivet interpreter > > Actually the introduction of the macro was correct and it's was > librivet/rivetPkgInit.c duty to determine the ::rivet name space > pointer in a different and sane way. This is the crux of the patch > included in RC2 > > -- Massimo > > On 02/01/2018 01:07 PM, Ronnie Brunner wrote: >> Hi Massimo >> >> Attached the output (stout and sdterr) of running the test suite >> (including the compilation of rivet), the error_log and access_log >> from rivet-3.0.1/tests after running the test suite. >> >> I'm running a CentOS Linux release 7.1.1503 (Core) os for these >> tests, Tcl8.6.6 and httpd 2.4.27 with the worker mpm. The only >> modification to runtests.tcl was to remove the prefork module check, >> which obviously fails if you run the worker mpm. >> >> Let me know if you need anything else. >> >> Hth Ronnie >> > > - > To unsubscribe, e-mail: > rivet-dev-unsubscr...@tcl.apache.org<mailto:rivet-dev-unsubscr...@tcl.apache.org> > For additional commands, e-mail: > rivet-dev-h...@tcl.apache.org<mailto:rivet-dev-h...@tcl.apache.org> > >
Re: Rivet 3.0.1
Should we consider this issue a reason for withholding 3.0.1? I think that as long as 2.2 is supported we may exploit the compatibility with 2.4. When 2.2 is deprecated we may proceed with the new macro definition. This is good example where having a versioning system like git or fossil could be handy. Can I start the vote for releasing 3.0.1? -- Massimo Da: Georgios Petasis Inviato: domenica 4 febbraio 2018 14:54 A: Massimo MANGHI; Ronnie Brunner; Massimo Manghi Cc: rivet-dev@tcl.apache.org Oggetto: Re: Rivet 3.0.1 Dear Massimo, According to the documentation: https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html We should also modify rivet.c to use AP_DECLARE_MODULE instead of "module AP_MODULE_DECLARE_DATA rivet_module = " we now have. I have tried it, and there was no difference (of course we must take care the old way is used in versions < 2.4 of apache). I tried to run the tests, but I am missing the TclX package. Where can I find its sources? In sourceforge? Best, George Στις 3/2/2018 20:52, ο Massimo Manghi έγραψε: > I've just uploaded to > www.rivetweb.org/~mxm/rivet<http://www.rivetweb.org/~mxm/rivet> a RC2 tar > archive > with a proposed patch of the problem that made most tests fail. > > The bug has surfaced when George introduced the APLOG_USE_MODULE in > mod_rivet.h, since also rivetlib/rivetPkgInit.c used it in order to > get the definition of the module globals. But since the generation of > the pkgIndex.tcl file takes place outside of mod_rivet the mk_pkgIndex > failed for rivetlib and became impossible to mod_rivet to find the > library. As as consequence the server failed because rivetlib is > loaded in the process of initializing a Rivet interpreter > > Actually the introduction of the macro was correct and it's was > librivet/rivetPkgInit.c duty to determine the ::rivet name space > pointer in a different and sane way. This is the crux of the patch > included in RC2 > > -- Massimo > > On 02/01/2018 01:07 PM, Ronnie Brunner wrote: >> Hi Massimo >> >> Attached the output (stout and sdterr) of running the test suite >> (including the compilation of rivet), the error_log and access_log >> from rivet-3.0.1/tests after running the test suite. >> >> I'm running a CentOS Linux release 7.1.1503 (Core) os for these >> tests, Tcl8.6.6 and httpd 2.4.27 with the worker mpm. The only >> modification to runtests.tcl was to remove the prefork module check, >> which obviously fails if you run the worker mpm. >> >> Let me know if you need anything else. >> >> Hth Ronnie >> > > - > To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org > For additional commands, e-mail: rivet-dev-h...@tcl.apache.org > >
RE: Rivet 3.0.1
Hi George I'm also running the tests w/o TclX. I usually just fake the kill command (which is the only thing used from TclX) and run the tests as follows: echo "package provide Tclx 0.0;proc kill {d s} {catch {exec kill \$s};after 2000}; set argv0 runtests.tcl; set argc 1; set argv /path/to/httpd; source runtests.tcl " | /path/to/tclsh hth Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | -Original Message- From: Georgios Petasis [mailto:petas...@yahoo.gr] Sent: Sonntag, 4. Februar 2018 14:54 To: Massimo Manghi ; Ronnie Brunner ; Massimo Manghi Cc: rivet-dev@tcl.apache.org Subject: Re: Rivet 3.0.1 Dear Massimo, According to the documentation: https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html We should also modify rivet.c to use AP_DECLARE_MODULE instead of "module AP_MODULE_DECLARE_DATA rivet_module = " we now have. I have tried it, and there was no difference (of course we must take care the old way is used in versions < 2.4 of apache). I tried to run the tests, but I am missing the TclX package. Where can I find its sources? In sourceforge? Best, George Στις 3/2/2018 20:52, ο Massimo Manghi έγραψε: > I've just uploaded to www.rivetweb.org/~mxm/rivet a RC2 tar archive > with a proposed patch of the problem that made most tests fail. > > The bug has surfaced when George introduced the APLOG_USE_MODULE in > mod_rivet.h, since also rivetlib/rivetPkgInit.c used it in order to > get the definition of the module globals. But since the generation of > the pkgIndex.tcl file takes place outside of mod_rivet the mk_pkgIndex > failed for rivetlib and became impossible to mod_rivet to find the > library. As as consequence the server failed because rivetlib is > loaded in the process of initializing a Rivet interpreter > > Actually the introduction of the macro was correct and it's was > librivet/rivetPkgInit.c duty to determine the ::rivet name space > pointer in a different and sane way. This is the crux of the patch > included in RC2 > > -- Massimo > > On 02/01/2018 01:07 PM, Ronnie Brunner wrote: >> Hi Massimo >> >> Attached the output (stout and sdterr) of running the test suite >> (including the compilation of rivet), the error_log and access_log >> from rivet-3.0.1/tests after running the test suite. >> >> I'm running a CentOS Linux release 7.1.1503 (Core) os for these >> tests, Tcl8.6.6 and httpd 2.4.27 with the worker mpm. The only >> modification to runtests.tcl was to remove the prefork module check, >> which obviously fails if you run the worker mpm. >> >> Let me know if you need anything else. >> >> Hth 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: Rivet 3.0.1
What is the sane way to check the version number in preprocessor #if clauses. I looked at ap_release.h but I didn't find a macro specialized for that -- Massimo Da: Georgios Petasis Inviato: domenica 4 febbraio 2018 14:54 A: Massimo MANGHI; Ronnie Brunner; Massimo Manghi Cc: rivet-dev@tcl.apache.org Oggetto: Re: Rivet 3.0.1 Dear Massimo, According to the documentation: https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html API Changes in Apache HTTP Server 2.4 since 2.2<https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html> httpd.apache.org This document describes changes to the Apache HTTPD API from version 2.2 to 2.4, that may be of interest to module/application developers and core hacks. As of the ... We should also modify rivet.c to use AP_DECLARE_MODULE instead of "module AP_MODULE_DECLARE_DATA rivet_module = " we now have. I have tried it, and there was no difference (of course we must take care the old way is used in versions < 2.4 of apache). I tried to run the tests, but I am missing the TclX package. Where can I find its sources? In sourceforge? Best, George Στις 3/2/2018 20:52, ο Massimo Manghi έγραψε: > I've just uploaded to > www.rivetweb.org/~mxm/rivet<http://www.rivetweb.org/~mxm/rivet> a RC2 tar > archive > with a proposed patch of the problem that made most tests fail. > > The bug has surfaced when George introduced the APLOG_USE_MODULE in > mod_rivet.h, since also rivetlib/rivetPkgInit.c used it in order to > get the definition of the module globals. But since the generation of > the pkgIndex.tcl file takes place outside of mod_rivet the mk_pkgIndex > failed for rivetlib and became impossible to mod_rivet to find the > library. As as consequence the server failed because rivetlib is > loaded in the process of initializing a Rivet interpreter > > Actually the introduction of the macro was correct and it's was > librivet/rivetPkgInit.c duty to determine the ::rivet name space > pointer in a different and sane way. This is the crux of the patch > included in RC2 > > -- Massimo > > On 02/01/2018 01:07 PM, Ronnie Brunner wrote: >> Hi Massimo >> >> Attached the output (stout and sdterr) of running the test suite >> (including the compilation of rivet), the error_log and access_log >> from rivet-3.0.1/tests after running the test suite. >> >> I'm running a CentOS Linux release 7.1.1503 (Core) os for these >> tests, Tcl8.6.6 and httpd 2.4.27 with the worker mpm. The only >> modification to runtests.tcl was to remove the prefork module check, >> which obviously fails if you run the worker mpm. >> >> Let me know if you need anything else. >> >> Hth Ronnie >> > > - > To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org > For additional commands, e-mail: rivet-dev-h...@tcl.apache.org > >
Re: Rivet 3.0.1
Dear Massimo, According to the documentation: https://httpd.apache.org/docs/2.4/developer/new_api_2_4.html We should also modify rivet.c to use AP_DECLARE_MODULE instead of "module AP_MODULE_DECLARE_DATA rivet_module = " we now have. I have tried it, and there was no difference (of course we must take care the old way is used in versions < 2.4 of apache). I tried to run the tests, but I am missing the TclX package. Where can I find its sources? In sourceforge? Best, George Στις 3/2/2018 20:52, ο Massimo Manghi έγραψε: I've just uploaded to www.rivetweb.org/~mxm/rivet a RC2 tar archive with a proposed patch of the problem that made most tests fail. The bug has surfaced when George introduced the APLOG_USE_MODULE in mod_rivet.h, since also rivetlib/rivetPkgInit.c used it in order to get the definition of the module globals. But since the generation of the pkgIndex.tcl file takes place outside of mod_rivet the mk_pkgIndex failed for rivetlib and became impossible to mod_rivet to find the library. As as consequence the server failed because rivetlib is loaded in the process of initializing a Rivet interpreter Actually the introduction of the macro was correct and it's was librivet/rivetPkgInit.c duty to determine the ::rivet name space pointer in a different and sane way. This is the crux of the patch included in RC2 -- Massimo On 02/01/2018 01:07 PM, Ronnie Brunner wrote: Hi Massimo Attached the output (stout and sdterr) of running the test suite (including the compilation of rivet), the error_log and access_log from rivet-3.0.1/tests after running the test suite. I'm running a CentOS Linux release 7.1.1503 (Core) os for these tests, Tcl8.6.6 and httpd 2.4.27 with the worker mpm. The only modification to runtests.tcl was to remove the prefork module check, which obviously fails if you run the worker mpm. Let me know if you need anything else. Hth 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: Rivet 3.0.1
I've just uploaded to www.rivetweb.org/~mxm/rivet a RC2 tar archive with a proposed patch of the problem that made most tests fail. The bug has surfaced when George introduced the APLOG_USE_MODULE in mod_rivet.h, since also rivetlib/rivetPkgInit.c used it in order to get the definition of the module globals. But since the generation of the pkgIndex.tcl file takes place outside of mod_rivet the mk_pkgIndex failed for rivetlib and became impossible to mod_rivet to find the library. As as consequence the server failed because rivetlib is loaded in the process of initializing a Rivet interpreter Actually the introduction of the macro was correct and it's was librivet/rivetPkgInit.c duty to determine the ::rivet name space pointer in a different and sane way. This is the crux of the patch included in RC2 -- Massimo On 02/01/2018 01:07 PM, Ronnie Brunner wrote: Hi Massimo Attached the output (stout and sdterr) of running the test suite (including the compilation of rivet), the error_log and access_log from rivet-3.0.1/tests after running the test suite. I'm running a CentOS Linux release 7.1.1503 (Core) os for these tests, Tcl8.6.6 and httpd 2.4.27 with the worker mpm. The only modification to runtests.tcl was to remove the prefork module check, which obviously fails if you run the worker mpm. Let me know if you need anything else. Hth Ronnie - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
RE: Rivet 3.0.1
Hi Massimo Attached the output (stout and sdterr) of running the test suite (including the compilation of rivet), the error_log and access_log from rivet-3.0.1/tests after running the test suite. I'm running a CentOS Linux release 7.1.1503 (Core) os for these tests, Tcl8.6.6 and httpd 2.4.27 with the worker mpm. The only modification to runtests.tcl was to remove the prefork module check, which obviously fails if you run the worker mpm. Let me know if you need anything else. Hth Ronnie -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | -Original Message- From: Massimo Manghi [mailto:massimo.man...@unipr.it] Sent: Donnerstag, 1. Februar 2018 12:33 To: Ronnie Brunner ; Massimo Manghi Cc: rivet-dev@tcl.apache.org Subject: Re: Rivet 3.0.1 That's sound like very bad news. I ran the test suite yesterday with the worker bridge and it was OK (130 tests). What do you read in tests/error_log ? -- Massimo On 02/01/2018 11:15 AM, Ronnie Brunner wrote: > Hi Massimo > > Test suite works for prefork, but just for the fun of it, I checked with the > worker (and event) mpms, as you mentioned that the worker bridge was > improved. The test suite fails for some tests on both other mpms. See below. > > Can you quickly elaborate whether that's OK and/or what you'd expect to work > and what not? > > Thanks for your continued support... > Ronnie > > > Prefork MPM: > rivet.test: Total 83 Passed 83 Skipped 0 Failed 0 > test.out.gz Description: test.out.gz error_log.gz Description: error_log.gz access_log.gz Description: access_log.gz - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Rivet 3.0.1
That's sound like very bad news. I ran the test suite yesterday with the worker bridge and it was OK (130 tests). What do you read in tests/error_log ? -- Massimo On 02/01/2018 11:15 AM, Ronnie Brunner wrote: Hi Massimo Test suite works for prefork, but just for the fun of it, I checked with the worker (and event) mpms, as you mentioned that the worker bridge was improved. The test suite fails for some tests on both other mpms. See below. Can you quickly elaborate whether that's OK and/or what you'd expect to work and what not? Thanks for your continued support... Ronnie Prefork MPM: rivet.test: Total 83 Passed 83 Skipped 0 Failed 0 - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
RE: Rivet 3.0.1
Hi Massimo Test suite works for prefork, but just for the fun of it, I checked with the worker (and event) mpms, as you mentioned that the worker bridge was improved. The test suite fails for some tests on both other mpms. See below. Can you quickly elaborate whether that's OK and/or what you'd expect to work and what not? Thanks for your continued support... Ronnie Prefork MPM: rivet.test: Total 83 Passed 83 Skipped 0 Failed 0 Worker MPM: headers-1.1 load_headers test FAILED include-1.1 Include command FAILED broken-1.1 error page test FAILED config-1.2 ErrorScript config test FAILED vhost-5.1 vhost with ChildInitScript FAILED vhost-6.2 vhost with BeforeScript and SeparateVirtualInterps FAILED inspect-1.1 basic introspection FAILED bailout-3.3 ::rivet::try handling continue return code FAILED bailout-3.5 ::rivet::try handling ::rivet::exit FAILED rivet.test: Total 83 Passed 74 Skipped 0 Failed 9 Event MPM: postvariables-1.1 POST variables FAILED postvariables-2.1 POST variables + I18N FAILED postvariables-2.2 POST variables + I18N + encoding FAILED postvariables-3.1 POST multi-value variable FAILED postvariables-3.2 POST multi-value variable as list FAILED postvariables-4.1 var_post FAILED makeurl-1.1 makeurl FAILED makeurl-1.2 makeurl FAILED makeurl-1.3 makeurl FAILED broken-1.1 error page test FAILED config-auto-2.1 config test FAILED config-auto-9.1 config test FAILED vhost-5.1 vhost with ChildInitScript FAILED vhost-6.1 vhost with ChildInitScript and SeparateVirtualInterps FAILED vhost-6.3 vhost with AfterScript and SeparateVirtualInterps FAILED bailout-2.2 ::rivet::catch command abort_page handling FAILED bailout-3.0 ::rivet::try successful procedure call FAILED rivet.test: Total 83 Passed 66 Skipped 0 Failed 17 -- We innovate. You win. http://netcetera.com Ronnie Brunner | ronnie.brun...@netcetera.com | T +41 44 297 59 79 | Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.com | -Original Message- From: Massimo Manghi [mailto:massimo.man...@alice.it] Sent: Donnerstag, 1. Februar 2018 00:43 To: rivet-dev@tcl.apache.org Subject: Rivet 3.0.1 I just uploaded at http://www.rivetweb.org/~mxm/rivet/ a 3.0.1rc1 artifact for your evaluation. Basically, differences from 3.0.0 are + applied patch provided by George Petasis that correctly initializes interpreters in the worker bridge + Documentation amended and expanded in various sections I think we can proceed to vote within a few days, since differences are crucial but point like -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org