Re: [naviserver-devel] ns_log output garbled on Windows
On Tue, Jan 29, 2019 at 12:02:23AM +0100, Gustaf Neumann wrote: > In case, the name is for unknown reason not initialized, the change [1] > should help. > https://bitbucket.org/naviserver/naviserver/commits/a1a07e7f1397e71809c74ca3a4bf93649affd8b2 That didn't make any difference. > The function Ns_ThreadId() returns uintptr_t, which is printed with > format-code PRIxPTR, maybe here is something > wrong. There is some indication [2], that the C99 prefix "ll" does not > work in all versions of MSC. > https://stackoverflow.com/questions/18107426/printf-format-for-unsigned-int64-on-windows Ah ha, thanks! I'm building NaviServer 32-bit on Windows. The garbled output was due to using that "PRIxPTR" macro to format the ThreadId. If I replace that format specifier with a either plain "%u" or "%I32u", then everything works fine! Hm, Ns_ThreadId() returns type uintptr_t, so why does LogToDString() use PRIxPTR in the first place? Shouldn't it use PRIuPTR, with a "u" for unsigned? I think so, so I switched to that. Here's the fix I'm using now: https://bitbucket.org/apiskors/naviserver/commits/16e6658319ae9595e7d874e68086e482f2f74f85 Fix garbled log output on Windows, PRIuPTR now gives I64u or I32u there. And here's a pull request that includes that, plus a couple other (very minor) fixes: https://bitbucket.org/naviserver/naviserver/pull-requests/20/fix-garbled-log-output-on-windows/diff -- Andrew Piskorski ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Using tcllib ::try
On 29.01.19 13:49, Gustaf Neumann wrote: I see, ... i can reproduce this, hopefully i can look into this today evening or tomorrow. just a quick thought, although it does not solve the not-for-me reproducible issue of [2] the change [1] seem to fix all known problems problems mentioned here. So, [2] is then probably again open, but the issues mentioned here are more serious. We should stick for this solution at least for Tcl 8.5. -gn [1] https://bitbucket.org/naviserver/naviserver/commits/24796ea1438eddfdbe3288891775f702c9b30a63 [2] https://stackoverflow.com/questions/49031790/how-can-i-debug-a-tcl-8-6-error-in-clock-tcl -- Univ.Prof. Dr. Gustaf Neumann WU Vienna Institute of Information Systems and New Media Welthandelsplatz 1, A-1020 Vienna, Austria ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Using tcllib ::try
On 29.01.19 13:13, David Osborne wrote:
The output you have pasted is the same as mine up to that point. I
wouldn't have seen an error by then either.
It's the *subsequent* calls to "clock scan" and "::try {} on error .."
which then fail.
I see, ... i can reproduce this, hopefully i can look into this today
evening or tomorrow.
-gn
[29/Jan/2019:13:45:13][22500.7efe1caec740][-main-] Notice: nsmain:
NaviServer/4.99.17 (bb78064b1137+ default tip) starting
...
[29/Jan/2019:13:45:13][22500.7efe0efa3700][-conn:default:0:0-] Notice: thread
initialized (0.003295 secs)
%
% ::try { puts trying } on error [list message options] { puts error }
can't read "magicCodes": no such variable
%
___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Using tcllib ::try
Thanks for looking at that Gustaf.
I can definitely relate to Zoran's comment:
> "In the moment all is pretty "spooky" and it is difficult to grasp..."
Your change doesn't seem to help the problems I'm looking at here
unfortunately.
The output you have pasted is the same as mine up to that point. I wouldn't
have seen an error by then either.
It's the *subsequent* calls to "clock scan" and "::try {} on error .."
which then fail.
To illustrate I made a bash script (which needs run by sudo) which starts
up naviserver to a prompt:
#!/bin/bash
hg clone https://bitbucket.org/naviserver/naviserver
cd naviserver
./autogen.sh --disable-ipv6 --with-tcl=/usr/lib/tcl8.5 --enable-rpath
--enable-threads --enable-symbols
make
make install
cat
Re: [naviserver-devel] Using tcllib ::try
On Tue, 29 Jan 2019 12:12:12 +0100 Gustaf Neumann wrote: > So, i think, it is the best strategy for NaviServer to put the > fingers away on stuff > coming from Tcl. ... indeed, and not *only* Tcl. I doubt we can be absolutely correct at that place, since the task itself is far to complex to be solved in a "cost-effective" way (the task is to replicate a fully loaded Tcl interpreter from one thread to another). So "problems" like this one will re-appear in the future and in other setups. Perhaps we can put the "magic" that ttrace module is doing out of the main configuration setup and use it for special purposes? The people then need to use [ns_ictl] to register callbacks for interp initialization themselves. In that case they (should) know what they can expect. In the moment all is pretty "spooky" and it is difficult to grasp... Cheers, Zoran ___ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
Re: [naviserver-devel] Using tcllib ::try
On 28.01.19 18:10, David Osborne wrote:
Thanks Gustaf,
That got me past the immediate problem - but I'm now seeing some
further issues which I can't fully explain.
1. Tcl8.5 only - After clock scan : invalid command name
"::tcl::clock::scan"
2. Tcl8.5 & Tcl8.6 After ::try .. on error : can't read "magicCodes":
no such variable
The errors only seem to happen after the commands are executed on
startup within ns/tcl
actually, i cannot reproduce this problem (while i could reproduce the
original "::try" issue
with Tcl 8.5.19). The underlying problem is that Tcl does some
optimization upon
initialization of Tcl, assuming a certain initialization sequence. The
order on vars,
procs and namespaces in NaviServer is more or less random (depending on
hash
table populations).
So, i think, it is the best strategy for NaviServer to put the fingers
away on stuff
coming from Tcl. The "clock" command seems to populate as well the ::msgcat
namespace (it would be better if it had been named ::tcl::msgcat). When
"clock" is called
during initialization (where content for the blueprint is collected),
then NaviServer puts
this as well into the blueprint. I have made now a modification [1] to
exclude the ::msgcat
namespace as well. All my test continue to work, maybe this is some
improvement
for the problem in your configuration.
-g
[1]
https://bitbucket.org/naviserver/naviserver/commits/641903183cc8e836109edb06d01450f041aa7818
# cat ~/test.tcl
package require try
::try {
ns_log Notice "=== scan returns [clock scan "+365 days"]"
} on error [list message options] {
ns_log Notice "=== scan fails $message"
ns_log Notice "=== scan fails $options"
}
# /usr/local/bin/nsd -u nsadmin -c
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: OpenSSL 1.1.1 11
Sep 2018 initialized
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: nsmain:
NaviServer/4.99.17 (bb78064b1137+ default tip) starting
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: nsmain: security
info: uid=1000, euid=1000, gid=1000, egid=1000
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: nsmain: Tcl version:
8.5.19
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: nsmain: max files:
soft limit 1073741816, hard limit 1073741816
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Warning: nsmain: rl_cur
(1073741816) > FD_SETSIZE (1024), select() calls should not be used
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Error: pidfile: failed to
open pid file '/usr/local/logs/nsd.pid': 'Permission denied'
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: pool default:
queueLength 90 low water 9 high water 72
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: nsd/init.tcl[default]: booting
virtual server: Tcl system encoding: "utf-8"
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: binder: started
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: Using ns_cache
implemented as a Tcl proc
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Warning: ns_md, ns_hmac,
ns_hotp and ns_totp are not available
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: === scan returns
1580252400
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: update interpreter
to epoch 1, trace deallocate, time 0.002598 secs
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: update interpreter
to epoch 1, trace none, time 0.002262 secs
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: nsmain:
NaviServer/4.99.17 (bb78064b1137+ default tip) running
[29/Jan/2019:11:57:09][22340.7f8bfc178740][-main-] Notice: nsmain: security
info: uid=1000, euid=1000, gid=1000, egid=1000
[29/Jan/2019:11:57:09][22340.7f8beeef0700][-command-] Notice: update
interpreter to epoch 1, trace none, time 0.002163 secs
[29/Jan/2019:11:57:09][22340.7f8bfc178740][binder] Notice: binder: stopped
[29/Jan/2019:11:57:09][22340.7f8bee62f700][-conn:default:0:0-] Notice: update
interpreter to epoch 1, trace none, time 0.002218 secs
[29/Jan/2019:11:57:09][22340.7f8bee62f700][-conn:default:0:0-] Notice: thread
initialized (0.003557 secs)
%
$ uname -a
Linux stretch 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27)
x86_64 GNU/Linux
$ cat /etc/debian_version
9.6
$ apt-cache policy tcl8.5
tcl8.5:
Installed: 8.5.19-2+b1
Candidate: 8.5.19-2+b1
$ hg clonehttps://bitbucket.org/naviserver/naviserver
$ cd naviserver
$ ./autogen.sh --disable-ipv6 --with-tcl=/usr/lib/tcl8.5
--enable-rpath --enable-threads --enable-symbols
$ make
$ sudo make install
$ cat ~/test.tcl
package require try
::try {
ns_log Notice "[clock scan "+365 days"]"
} on error [list message options] {
ns_log Notice "$message"
ns_log Notice "$options"
}
## Copy test.tcl into tcl dir
$ sudo cp test.tcl /usr/local/ns/tcl/
$ sudo /usr/local/ns/bin/nsd -u nsd -t
/usr/local/ns/conf/nsd-config.tcl -c
## Not working
% ::try { puts trying } on error [list message options] { puts error }
can't read "magicCodes": no such
