naviserver-devel — Developer discussion

[naviserver-devel] temp file support

[Gustaf N. <ne...@wu...>]

Dear all,

while looking at bugreport #77 [1], i have revisited the situation 
around tmp file generation in NaviServer.
We have currently the following tcl commands implemented

(a) ns_tmpnam

(b) ns_mktemp

the first one is deprecated since a long time, since it uses the 
deprecated c-library function tmpnam(). I am considering on dropping the 
call to tmpnam() in the code, use instead mktemp(), but keeping the 
command for backward compatibility on the Tcl level. Most compiler 
complain already about the usage of tmpnam().

Concerning (b), the usage of mktemp() is also not really recommended, 
since the creation of the tmp file or directory should be atomic (rather 
than two different  calls for creating a name and the creating then the 
resource). One should use mkstemp()/mkdtemp() instead, which perform the 
tmp-file/dir creating in one step and return the created resource. 
However, the recommended functions are not API-compatible, such we can't 
change simply the implementation in ns_mktemp.

Implementing new commands "ns_mkstemp" or "ns_mkdtemp" in NaviServer 
would not be complex, since we have already a ns_mkstemp() function for 
internal use (also for windows), but i am reluctant introducing new 
commands, since starting with Tcl 8.6, Tcl has a new sub-command  "file 
tempfile" to support temporary file generation. We could/should 
recommend its usage instead.

so i am considering turning ns_tmpnam into a backwards (API) compatible 
proc, and leaving ns_mktemp as it is, hoping that more installations 
will switch to Tcl 8.6 sooner or later. Comments? Opinions? Necessities?

all the best

-gn

[1] https://sourceforge.net/p/naviserver/bugs/77/

Re: [naviserver-devel] initial set up and first look

[Gustaf N. <ne...@wu...>]

Am 31.10.16 um 01:59 schrieb Adam Jensen:
> Hi, I am very new to this software.
>
> NaviServer 4.99.14d1 under FreeBSD 11.0-RELEASE-p1
>
> One of the first things that I noticed was the [writer example][1]
the contrib/example pages have not been maintained since ages, ...
but you are right, a novice will reach this pages quickly and gets
a bad impression, if these examples are obviously incorrect.
> doesn't do what it says it does.
I've updated the writer.tcl and the upload.tcl examples (although the latter
has to be tested with a slower upload line).... but esp. for uploading,
there are now many more js widgets available, which do not require
backend support.
> Also, there is broken English all over the place. Is there a convenient
> process to make note of problems or is broken English just the way of
> things? (Jeez, I sound like an ass. That wasn't my intention.)
yes, the documentation should be improved at many places. I think,
we are getting gradually better, but there is still a long way to go.
many of us use naviserver since many years, so we get blind to
things, which pop up immediately to the eye of a new user.
Also keep in mind, that the code and documentation was written
by people with many mother tongues.

But contributing is easy: in case someone finds something to improve
(from wording of README files to docs and code), just clone the project
on bitbucket, improve the issues in your clone and issue a pull request.
> It was at this point in the set up process that I looked for a mailing
> list. (Really, I'm not an ass. It must have been a rough week or something.)
nobody has this impression, instead, your comments are appreciated!
> Anyway, hello.
welcome!
-g

[naviserver-devel] initial set up and first look

[Adam J. <ha...@ri...>]

Hi, I am very new to this software.

NaviServer 4.99.14d1 under FreeBSD 11.0-RELEASE-p1

One of the first things that I noticed was the [writer example][1]
doesn't do what it says it does.

[1]: http://minerva.bohemia.net:8080/examples/writer.tcl

ns/pages/examples/index.adp

Says:

<li> <a href="writer.tcl">Writer</A> page with example how writer
threads can be used to return huge files. It shows all files that
are in <%=[ns_info home]%>/modules/movies directory.

But ns/pages/examples/writer.tcl says:

set files /tmp/*.dat

It seems like it should do something like:

set files [ns_info home]/modules/movies/*

Also, there is broken English all over the place. Is there a convenient
process to make note of problems or is broken English just the way of
things? (Jeez, I sound like an ass. That wasn't my intention.)

Example - https://bitbucket.org/naviserver/naviserver/

3f. To download and install additional modules:

    For releases, usuall a distribution of the current modules is
    provided ass well via sourceforge. To get e.g. a modules
    named "nsfoo" installed

It was at this point in the set up process that I looked for a mailing
list. (Really, I'm not an ass. It must have been a rough week or something.)

Anyway, hello.

Re: [naviserver-devel] Startup Error for tclws in naviserver 4.99.13

[Wolfgang W. <wol...@di...>]

Dear Gustav!

The patch fixed it, everything works flawlessly now.

Thanks (once again) for your help.

Wolfgang

Am 2016-10-21 um 09:33 schrieb Gustaf Neumann:
> Dear Wolfgang,
>
> I found an explanation: probably you have indeed no legacy defer 
> callbacks registered, but NaviServer does an UpdateInterp() even when 
> no defer callbacks were executed, which might have changed the state. 
> During UpdateInterp() it probably re-evaluates the "namespace eval 
> ::WS::Utils {...}", which complains, since tdom rejects to reset "its" 
> variable. I wonder, whether this is the only place, where the 
> interaction between tclws & tdom & interp updates can cause complaints.
>
> Anyhow, the change [1] omits the update of the interpreter, when 
> nothing could have been changed by the defer callbacks. It should be 
> as well performance-wise better.
>
> Hope this helps
> -g
>
> https://bitbucket.org/naviserver/naviserver/commits/526312b7ac23f734f0002d3d1514025dfb4ea36e
>
> Am 21.10.16 um 07:59 schrieb Wolfgang Winkler:
>> We are using
>>
>> ns_param nssock    ${bindir}/nssock.so
>> ns_param nslog      ${bindir}/nslog.so
>> ns_param nsdb       ${bindir}/nsdb.so
>> ns_param nscp       ${bindir}/nscp.so
>> ns_param nsproxy   ${bindir}/nsproxy.so
>>
>> ns_param postgres     "${bindir}/nsdbpg.so"
>>
>> I tried to uncomment them, but the error is still there.
>>
>> I've grepped through all our sources but did not find a call to 
>> Ns_TclRegisterDeferred, ns_ictl cleanup or ns_cleanup.
>>
>>
>> Am 2016-10-20 um 17:18 schrieb Gustaf Neumann:
>>> sure. but the point is, this call does on usual installations 
>>> nothing, .... unless someone registers a function with  
>>> Ns_TclRegisterDeferred().
>>> What modules are you loading?
>>> -g
>>>
>>> Am 20.10.16 um 16:53 schrieb Wolfgang Winkler:
>>>> ns_ictl cleanup is called from ns_cleanup in 
>>>> naviserver/bin/init.tcl. When I remove the call, the error goes 
>>>> way. These are the relevant calls:
>>>>
>>>>
>>>> ns_ictl trace deallocate ns_cleanup
>>>>
>>>> proc ns_cleanup {} {
>>>>     ns_cleanupchans;  # Close files
>>>>     ns_cleanupvars;   # Destroy global variables
>>>>     ns_set  cleanup;  # Destroy non-shared sets
>>>>     ns_http cleanup;  # Abort any http requests
>>>>     #ns_ictl cleanup;  # Run depreciated 1-shot Ns_TclRegisterDefer's.
>>>> }
>>>>
>>>> regards,
>>>>
>>>> Wolfgang
>>>>
>>>> Am 2016-10-20 um 16:26 schrieb Gustaf Neumann:
>>>>> Hmm, it looks to me, as if this error is triggered not from the 
>>>>> startup, but from the shutdown.
>>>>>
>>>>> The backtrace shows, that "ns_ictl cleanup" is causing this, which 
>>>>> in turn calls the callbacks registered with 
>>>>> Ns_TclRegisterDeferred(), which is a deprecated function (since 
>>>>> many years). Ns_TclRegisterDeferred()  is nowhere called within 
>>>>> NaviServer, so it looks to me that you might have c-based module 
>>>>> in use, which  calls this function.... is this correct?
>>>>>
>>>>> Aside form the strange situation around "ns_ictl cleanup", the 
>>>>> error was probably triggered in earlier versions of NaviServer as 
>>>>> well, but in some newer versions of NaviServer, error conditions, 
>>>>> which were silently swallowed before, are now reported back to the 
>>>>> user.
>>>>>
>>>>> The message "var is read-only" is actually generated by tDOM. It 
>>>>> might be the case, that the function registered via 
>>>>> Ns_TclRegisterDeferred() either sources Utilities.tcl (from 
>>>>> tclws), or it might re-evaluate the blueprint during shutdown; 
>>>>> both is probably not wanted.
>>>>>
>>>>> Hope this helps
>>>>> -g
>>>>>
>>>>> Am 20.10.16 um 10:25 schrieb Wolfgang Winkler:
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> We are using webservices for tcl (tclws) with naviserver. For 
>>>>>> naviserver version 4.99.7 we sometimes get the following error 
>>>>>> message:
>>>>>>
>>>>>> Error: can't set "xsltSchemaDom": var is read-only
>>>>>> var is read-only
>>>>>>     (write trace on "xsltSchemaDom")
>>>>>>     invoked from within
>>>>>> "variable xsltSchemaDom domDoc0xa7c640"
>>>>>>     (in namespace eval "::WS::Utils" script line 3)
>>>>>>     invoked from within
>>>>>> "namespace eval ::WS::Utils {
>>>>>>  variable currentNs {}
>>>>>> variable xsltSchemaDom domDoc0xa7c640
>>>>>> variable standardAttributes {
>>>>>>         baseType
>>>>>>         comme..."
>>>>>>     invoked from within
>>>>>> "ns_ictl cleanup"
>>>>>>     (procedure "ns_cleanup" line 6)
>>>>>>     invoked from within
>>>>>> "ns_cleanup"
>>>>>>     while executing callback
>>>>>> ns:tcltrace ns_cleanup
>>>>>> (context: trace proc)
>>>>>>
>>>>>> With version 4.99.13 we get his error on every startup. It seems 
>>>>>> to be connected to thread creation. Has anybody any idea how to 
>>>>>> prevent this error?
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Wolfgang
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>>
>>>>>> *Wolfgang Winkler*
>>>>>> Geschäftsführung
>>>>>> wol...@di...
>>>>>> mobil +43.699.19971172
>>>>>>
>>>>>> dc:*büro*
>>>>>> digital concepts Novak Winkler OG
>>>>>> Software & Design
>>>>>> Landstraße 68, 5. Stock, 4020 Linz
>>>>>> www.digital-concepts.com <http://www.digital-concepts.com>
>>>>>> tel +43.732.997117.72
>>>>>> tel +43.699.1997117.2
>>>>>>
>>>>>> Firmenbuchnummer: 192003h
>>>>>> Firmenbuchgericht: Landesgericht Linz
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org!http://sdm.link/slashdot
>>>
>>>
>>> _______________________________________________
>>> naviserver-devel mailing list
>>> nav...@li...
>>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
>>
>> -- 
>>
>> *Wolfgang Winkler*
>> Geschäftsführung
>> wol...@di...
>> mobil +43.699.19971172
>>
>> dc:*büro*
>> digital concepts Novak Winkler OG
>> Software & Design
>> Landstraße 68, 5. Stock, 4020 Linz
>> www.digital-concepts.com <http://www.digital-concepts.com>
>> tel +43.732.997117.72
>> tel +43.699.1997117.2
>>
>> Firmenbuchnummer: 192003h
>> Firmenbuchgericht: Landesgericht Linz
>>
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel


-- 

*Wolfgang Winkler*
Geschäftsführung
wol...@di...
mobil +43.699.19971172

dc:*büro*
digital concepts Novak Winkler OG
Software & Design
Landstraße 68, 5. Stock, 4020 Linz
www.digital-concepts.com <http://www.digital-concepts.com>
tel +43.732.997117.72
tel +43.699.1997117.2

Firmenbuchnummer: 192003h
Firmenbuchgericht: Landesgericht Linz

Re: [naviserver-devel] Startup Error for tclws in naviserver 4.99.13

[Gustaf N. <ne...@wu...>]

Dear Wolfgang,

I found an explanation: probably you have indeed no legacy defer 
callbacks registered, but NaviServer does an UpdateInterp() even when no 
defer callbacks were executed, which might have changed the state. 
During UpdateInterp() it probably re-evaluates the "namespace eval 
::WS::Utils {...}", which complains, since tdom rejects to reset "its" 
variable. I wonder, whether this is the only place, where the 
interaction between tclws & tdom & interp updates can cause complaints.

Anyhow, the change [1] omits the update of the interpreter, when nothing 
could have been changed by the defer callbacks. It should be as well 
performance-wise better.

Hope this helps
-g

https://bitbucket.org/naviserver/naviserver/commits/526312b7ac23f734f0002d3d1514025dfb4ea36e

Am 21.10.16 um 07:59 schrieb Wolfgang Winkler:
> We are using
>
> ns_param nssock    ${bindir}/nssock.so
> ns_param nslog      ${bindir}/nslog.so
> ns_param nsdb       ${bindir}/nsdb.so
> ns_param nscp       ${bindir}/nscp.so
> ns_param nsproxy   ${bindir}/nsproxy.so
>
> ns_param postgres     "${bindir}/nsdbpg.so"
>
> I tried to uncomment them, but the error is still there.
>
> I've grepped through all our sources but did not find a call to 
> Ns_TclRegisterDeferred, ns_ictl cleanup or ns_cleanup.
>
>
> Am 2016-10-20 um 17:18 schrieb Gustaf Neumann:
>> sure. but the point is, this call does on usual installations 
>> nothing, .... unless someone registers a function with  
>> Ns_TclRegisterDeferred().
>> What modules are you loading?
>> -g
>>
>> Am 20.10.16 um 16:53 schrieb Wolfgang Winkler:
>>> ns_ictl cleanup is called from ns_cleanup in 
>>> naviserver/bin/init.tcl. When I remove the call, the error goes way. 
>>> These are the relevant calls:
>>>
>>>
>>> ns_ictl trace deallocate ns_cleanup
>>>
>>> proc ns_cleanup {} {
>>>     ns_cleanupchans;  # Close files
>>>     ns_cleanupvars;   # Destroy global variables
>>>     ns_set  cleanup;  # Destroy non-shared sets
>>>     ns_http cleanup;  # Abort any http requests
>>>     #ns_ictl cleanup;  # Run depreciated 1-shot Ns_TclRegisterDefer's.
>>> }
>>>
>>> regards,
>>>
>>> Wolfgang
>>>
>>> Am 2016-10-20 um 16:26 schrieb Gustaf Neumann:
>>>> Hmm, it looks to me, as if this error is triggered not from the 
>>>> startup, but from the shutdown.
>>>>
>>>> The backtrace shows, that "ns_ictl cleanup" is causing this, which 
>>>> in turn calls the callbacks registered with 
>>>> Ns_TclRegisterDeferred(), which is a deprecated function (since 
>>>> many years). Ns_TclRegisterDeferred()  is nowhere called within 
>>>> NaviServer, so it looks to me that you might have c-based module in 
>>>> use, which  calls this function.... is this correct?
>>>>
>>>> Aside form the strange situation around "ns_ictl cleanup", the 
>>>> error was probably triggered in earlier versions of NaviServer as 
>>>> well, but in some newer versions of NaviServer, error conditions, 
>>>> which were silently swallowed before, are now reported back to the 
>>>> user.
>>>>
>>>> The message "var is read-only" is actually generated by tDOM. It 
>>>> might be the case, that the function registered via 
>>>> Ns_TclRegisterDeferred() either sources Utilities.tcl (from tclws), 
>>>> or it might re-evaluate the blueprint during shutdown; both is 
>>>> probably not wanted.
>>>>
>>>> Hope this helps
>>>> -g
>>>>
>>>> Am 20.10.16 um 10:25 schrieb Wolfgang Winkler:
>>>>>
>>>>> Hi!
>>>>>
>>>>> We are using webservices for tcl (tclws) with naviserver. For 
>>>>> naviserver version 4.99.7 we sometimes get the following error 
>>>>> message:
>>>>>
>>>>> Error: can't set "xsltSchemaDom": var is read-only
>>>>> var is read-only
>>>>>     (write trace on "xsltSchemaDom")
>>>>>     invoked from within
>>>>> "variable xsltSchemaDom domDoc0xa7c640"
>>>>>     (in namespace eval "::WS::Utils" script line 3)
>>>>>     invoked from within
>>>>> "namespace eval ::WS::Utils {
>>>>>  variable currentNs {}
>>>>> variable xsltSchemaDom domDoc0xa7c640
>>>>> variable standardAttributes {
>>>>>         baseType
>>>>>         comme..."
>>>>>     invoked from within
>>>>> "ns_ictl cleanup"
>>>>>     (procedure "ns_cleanup" line 6)
>>>>>     invoked from within
>>>>> "ns_cleanup"
>>>>>     while executing callback
>>>>> ns:tcltrace ns_cleanup
>>>>> (context: trace proc)
>>>>>
>>>>> With version 4.99.13 we get his error on every startup. It seems 
>>>>> to be connected to thread creation. Has anybody any idea how to 
>>>>> prevent this error?
>>>>>
>>>>> regards,
>>>>>
>>>>> Wolfgang
>>>>>
>>>>>
>>>>> -- 
>>>>>
>>>>> *Wolfgang Winkler*
>>>>> Geschäftsführung
>>>>> wol...@di...
>>>>> mobil +43.699.19971172
>>>>>
>>>>> dc:*büro*
>>>>> digital concepts Novak Winkler OG
>>>>> Software & Design
>>>>> Landstraße 68, 5. Stock, 4020 Linz
>>>>> www.digital-concepts.com <http://www.digital-concepts.com>
>>>>> tel +43.732.997117.72
>>>>> tel +43.699.1997117.2
>>>>>
>>>>> Firmenbuchnummer: 192003h
>>>>> Firmenbuchgericht: Landesgericht Linz
>>>>>
>>>>>
>>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org!http://sdm.link/slashdot
>>
>>
>> _______________________________________________
>> naviserver-devel mailing list
>> nav...@li...
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
>
> -- 
>
> *Wolfgang Winkler*
> Geschäftsführung
> wol...@di...
> mobil +43.699.19971172
>
> dc:*büro*
> digital concepts Novak Winkler OG
> Software & Design
> Landstraße 68, 5. Stock, 4020 Linz
> www.digital-concepts.com <http://www.digital-concepts.com>
> tel +43.732.997117.72
> tel +43.699.1997117.2
>
> Firmenbuchnummer: 192003h
> Firmenbuchgericht: Landesgericht Linz
>
>
>

Re: [naviserver-devel] Startup Error for tclws in naviserver 4.99.13

[Wolfgang W. <wol...@di...>]

We are using

ns_param nssock    ${bindir}/nssock.so
ns_param nslog      ${bindir}/nslog.so
ns_param nsdb       ${bindir}/nsdb.so
ns_param nscp       ${bindir}/nscp.so
ns_param nsproxy   ${bindir}/nsproxy.so

ns_param postgres     "${bindir}/nsdbpg.so"

I tried to uncomment them, but the error is still there.

I've grepped through all our sources but did not find a call to 
Ns_TclRegisterDeferred, ns_ictl cleanup or ns_cleanup.


Am 2016-10-20 um 17:18 schrieb Gustaf Neumann:
> sure. but the point is, this call does on usual installations nothing, 
> .... unless someone registers a function with  Ns_TclRegisterDeferred().
> What modules are you loading?
> -g
>
> Am 20.10.16 um 16:53 schrieb Wolfgang Winkler:
>> ns_ictl cleanup is called from ns_cleanup in naviserver/bin/init.tcl. 
>> When I remove the call, the error goes way. These are the relevant calls:
>>
>>
>> ns_ictl trace deallocate ns_cleanup
>>
>> proc ns_cleanup {} {
>>     ns_cleanupchans;  # Close files
>>     ns_cleanupvars;   # Destroy global variables
>>     ns_set  cleanup;  # Destroy non-shared sets
>>     ns_http cleanup;  # Abort any http requests
>>     #ns_ictl cleanup;  # Run depreciated 1-shot Ns_TclRegisterDefer's.
>> }
>>
>> regards,
>>
>> Wolfgang
>>
>> Am 2016-10-20 um 16:26 schrieb Gustaf Neumann:
>>> Hmm, it looks to me, as if this error is triggered not from the 
>>> startup, but from the shutdown.
>>>
>>> The backtrace shows, that "ns_ictl cleanup" is causing this, which 
>>> in turn calls the callbacks registered with 
>>> Ns_TclRegisterDeferred(), which is a deprecated function (since many 
>>> years). Ns_TclRegisterDeferred()  is nowhere called within 
>>> NaviServer, so it looks to me that you might have c-based module in 
>>> use, which  calls this function.... is this correct?
>>>
>>> Aside form the strange situation around "ns_ictl cleanup", the error 
>>> was probably triggered in earlier versions of NaviServer as well, 
>>> but in some newer versions of NaviServer, error conditions, which 
>>> were silently swallowed before, are now reported back to the user.
>>>
>>> The message "var is read-only" is actually generated by tDOM. It 
>>> might be the case, that the function registered via 
>>> Ns_TclRegisterDeferred() either sources Utilities.tcl (from tclws), 
>>> or it might re-evaluate the blueprint during shutdown; both is 
>>> probably not wanted.
>>>
>>> Hope this helps
>>> -g
>>>
>>> Am 20.10.16 um 10:25 schrieb Wolfgang Winkler:
>>>>
>>>> Hi!
>>>>
>>>> We are using webservices for tcl (tclws) with naviserver. For 
>>>> naviserver version 4.99.7 we sometimes get the following error message:
>>>>
>>>> Error: can't set "xsltSchemaDom": var is read-only
>>>> var is read-only
>>>>     (write trace on "xsltSchemaDom")
>>>>     invoked from within
>>>> "variable xsltSchemaDom domDoc0xa7c640"
>>>>     (in namespace eval "::WS::Utils" script line 3)
>>>>     invoked from within
>>>> "namespace eval ::WS::Utils {
>>>>  variable currentNs {}
>>>> variable xsltSchemaDom domDoc0xa7c640
>>>> variable standardAttributes {
>>>>         baseType
>>>>         comme..."
>>>>     invoked from within
>>>> "ns_ictl cleanup"
>>>>     (procedure "ns_cleanup" line 6)
>>>>     invoked from within
>>>> "ns_cleanup"
>>>>     while executing callback
>>>> ns:tcltrace ns_cleanup
>>>> (context: trace proc)
>>>>
>>>> With version 4.99.13 we get his error on every startup. It seems to 
>>>> be connected to thread creation. Has anybody any idea how to 
>>>> prevent this error?
>>>>
>>>> regards,
>>>>
>>>> Wolfgang
>>>>
>>>>
>>>> -- 
>>>>
>>>> *Wolfgang Winkler*
>>>> Geschäftsführung
>>>> wol...@di...
>>>> mobil +43.699.19971172
>>>>
>>>> dc:*büro*
>>>> digital concepts Novak Winkler OG
>>>> Software & Design
>>>> Landstraße 68, 5. Stock, 4020 Linz
>>>> www.digital-concepts.com <http://www.digital-concepts.com>
>>>> tel +43.732.997117.72
>>>> tel +43.699.1997117.2
>>>>
>>>> Firmenbuchnummer: 192003h
>>>> Firmenbuchgericht: Landesgericht Linz
>>>>
>>>>
>>>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel


-- 

*Wolfgang Winkler*
Geschäftsführung
wol...@di...
mobil +43.699.19971172

dc:*büro*
digital concepts Novak Winkler OG
Software & Design
Landstraße 68, 5. Stock, 4020 Linz
www.digital-concepts.com <http://www.digital-concepts.com>
tel +43.732.997117.72
tel +43.699.1997117.2

Firmenbuchnummer: 192003h
Firmenbuchgericht: Landesgericht Linz

Re: [naviserver-devel] Startup Error for tclws in naviserver 4.99.13

[Gustaf N. <ne...@wu...>]

sure. but the point is, this call does on usual installations nothing, 
.... unless someone registers a function with  Ns_TclRegisterDeferred().
What modules are you loading?
-g

Am 20.10.16 um 16:53 schrieb Wolfgang Winkler:
> ns_ictl cleanup is called from ns_cleanup in naviserver/bin/init.tcl. 
> When I remove the call, the error goes way. These are the relevant calls:
>
>
> ns_ictl trace deallocate ns_cleanup
>
> proc ns_cleanup {} {
>     ns_cleanupchans;  # Close files
>     ns_cleanupvars;   # Destroy global variables
>     ns_set  cleanup;  # Destroy non-shared sets
>     ns_http cleanup;  # Abort any http requests
>     #ns_ictl cleanup;  # Run depreciated 1-shot Ns_TclRegisterDefer's.
> }
>
> regards,
>
> Wolfgang
>
> Am 2016-10-20 um 16:26 schrieb Gustaf Neumann:
>> Hmm, it looks to me, as if this error is triggered not from the 
>> startup, but from the shutdown.
>>
>> The backtrace shows, that "ns_ictl cleanup" is causing this, which in 
>> turn calls the callbacks registered with Ns_TclRegisterDeferred(), 
>> which is a deprecated function (since many years). 
>> Ns_TclRegisterDeferred()  is nowhere called within NaviServer, so it 
>> looks to me that you might have c-based module in use, which  calls 
>> this function.... is this correct?
>>
>> Aside form the strange situation around "ns_ictl cleanup", the error 
>> was probably triggered in earlier versions of NaviServer as well, but 
>> in some newer versions of NaviServer, error conditions, which were 
>> silently swallowed before, are now reported back to the user.
>>
>> The message "var is read-only" is actually generated by tDOM. It 
>> might be the case, that the function registered via 
>> Ns_TclRegisterDeferred() either sources Utilities.tcl (from tclws), 
>> or it might re-evaluate the blueprint during shutdown; both is 
>> probably not wanted.
>>
>> Hope this helps
>> -g
>>
>> Am 20.10.16 um 10:25 schrieb Wolfgang Winkler:
>>>
>>> Hi!
>>>
>>> We are using webservices for tcl (tclws) with naviserver. For 
>>> naviserver version 4.99.7 we sometimes get the following error message:
>>>
>>> Error: can't set "xsltSchemaDom": var is read-only
>>> var is read-only
>>>     (write trace on "xsltSchemaDom")
>>>     invoked from within
>>> "variable xsltSchemaDom domDoc0xa7c640"
>>>     (in namespace eval "::WS::Utils" script line 3)
>>>     invoked from within
>>> "namespace eval ::WS::Utils {
>>>  variable currentNs {}
>>> variable xsltSchemaDom domDoc0xa7c640
>>> variable standardAttributes {
>>>         baseType
>>>         comme..."
>>>     invoked from within
>>> "ns_ictl cleanup"
>>>     (procedure "ns_cleanup" line 6)
>>>     invoked from within
>>> "ns_cleanup"
>>>     while executing callback
>>> ns:tcltrace ns_cleanup
>>> (context: trace proc)
>>>
>>> With version 4.99.13 we get his error on every startup. It seems to 
>>> be connected to thread creation. Has anybody any idea how to prevent 
>>> this error?
>>>
>>> regards,
>>>
>>> Wolfgang
>>>
>>>
>>> -- 
>>>
>>> *Wolfgang Winkler*
>>> Geschäftsführung
>>> wol...@di...
>>> mobil +43.699.19971172
>>>
>>> dc:*büro*
>>> digital concepts Novak Winkler OG
>>> Software & Design
>>> Landstraße 68, 5. Stock, 4020 Linz
>>> www.digital-concepts.com <http://www.digital-concepts.com>
>>> tel +43.732.997117.72
>>> tel +43.699.1997117.2
>>>
>>> Firmenbuchnummer: 192003h
>>> Firmenbuchgericht: Landesgericht Linz
>>>
>>>
>>

Re: [naviserver-devel] Startup Error for tclws in naviserver 4.99.13

[Wolfgang W. <wol...@di...>]

ns_ictl cleanup is called from ns_cleanup in naviserver/bin/init.tcl. 
When I remove the call, the error goes way. These are the relevant calls:


ns_ictl trace deallocate ns_cleanup

proc ns_cleanup {} {
     ns_cleanupchans;  # Close files
     ns_cleanupvars;   # Destroy global variables
     ns_set  cleanup;  # Destroy non-shared sets
     ns_http cleanup;  # Abort any http requests
     #ns_ictl cleanup;  # Run depreciated 1-shot Ns_TclRegisterDefer's.
}

regards,

Wolfgang

Am 2016-10-20 um 16:26 schrieb Gustaf Neumann:
> Hmm, it looks to me, as if this error is triggered not from the 
> startup, but from the shutdown.
>
> The backtrace shows, that "ns_ictl cleanup" is causing this, which in 
> turn calls the callbacks registered with Ns_TclRegisterDeferred(), 
> which is a deprecated function (since many years). 
> Ns_TclRegisterDeferred()  is nowhere called within NaviServer, so it 
> looks to me that you might have c-based module in use, which  calls 
> this function.... is this correct?
>
> Aside form the strange situation around "ns_ictl cleanup", the error 
> was probably triggered in earlier versions of NaviServer as well, but 
> in some newer versions of NaviServer, error conditions, which were 
> silently swallowed before, are now reported back to the user.
>
> The message "var is read-only" is actually generated by tDOM. It might 
> be the case, that the function registered via Ns_TclRegisterDeferred() 
> either sources Utilities.tcl (from tclws), or it might re-evaluate the 
> blueprint during shutdown; both is probably not wanted.
>
> Hope this helps
> -g
>
> Am 20.10.16 um 10:25 schrieb Wolfgang Winkler:
>>
>> Hi!
>>
>> We are using webservices for tcl (tclws) with naviserver. For 
>> naviserver version 4.99.7 we sometimes get the following error message:
>>
>> Error: can't set "xsltSchemaDom": var is read-only
>> var is read-only
>>     (write trace on "xsltSchemaDom")
>>     invoked from within
>> "variable xsltSchemaDom domDoc0xa7c640"
>>     (in namespace eval "::WS::Utils" script line 3)
>>     invoked from within
>> "namespace eval ::WS::Utils {
>>  variable currentNs {}
>> variable xsltSchemaDom domDoc0xa7c640
>> variable standardAttributes {
>>         baseType
>>         comme..."
>>     invoked from within
>> "ns_ictl cleanup"
>>     (procedure "ns_cleanup" line 6)
>>     invoked from within
>> "ns_cleanup"
>>     while executing callback
>> ns:tcltrace ns_cleanup
>> (context: trace proc)
>>
>> With version 4.99.13 we get his error on every startup. It seems to 
>> be connected to thread creation. Has anybody any idea how to prevent 
>> this error?
>>
>> regards,
>>
>> Wolfgang
>>
>>
>> -- 
>>
>> *Wolfgang Winkler*
>> Geschäftsführung
>> wol...@di...
>> mobil +43.699.19971172
>>
>> dc:*büro*
>> digital concepts Novak Winkler OG
>> Software & Design
>> Landstraße 68, 5. Stock, 4020 Linz
>> www.digital-concepts.com <http://www.digital-concepts.com>
>> tel +43.732.997117.72
>> tel +43.699.1997117.2
>>
>> Firmenbuchnummer: 192003h
>> Firmenbuchgericht: Landesgericht Linz
>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel


-- 

*Wolfgang Winkler*
Geschäftsführung
wol...@di...
mobil +43.699.19971172

dc:*büro*
digital concepts Novak Winkler OG
Software & Design
Landstraße 68, 5. Stock, 4020 Linz
www.digital-concepts.com <http://www.digital-concepts.com>
tel +43.732.997117.72
tel +43.699.1997117.2

Firmenbuchnummer: 192003h
Firmenbuchgericht: Landesgericht Linz

Re: [naviserver-devel] Startup Error for tclws in naviserver 4.99.13

[Gustaf N. <ne...@wu...>]

Hmm, it looks to me, as if this error is triggered not from the startup, 
but from the shutdown.

The backtrace shows, that "ns_ictl cleanup" is causing this, which in 
turn calls the callbacks registered with Ns_TclRegisterDeferred(), which 
is a deprecated function (since many years). Ns_TclRegisterDeferred()  
is nowhere called within NaviServer, so it looks to me that you might 
have c-based module in use, which  calls this function.... is this correct?

Aside form the strange situation around "ns_ictl cleanup", the error was 
probably triggered in earlier versions of NaviServer as well, but in 
some newer versions of NaviServer, error conditions, which were silently 
swallowed before, are now reported back to the user.

The message "var is read-only" is actually generated by tDOM. It might 
be the case, that the function registered via Ns_TclRegisterDeferred() 
either sources Utilities.tcl (from tclws), or it might re-evaluate the 
blueprint during shutdown; both is probably not wanted.

Hope this helps
-g

Am 20.10.16 um 10:25 schrieb Wolfgang Winkler:
>
> Hi!
>
> We are using webservices for tcl (tclws) with naviserver. For 
> naviserver version 4.99.7 we sometimes get the following error message:
>
> Error: can't set "xsltSchemaDom": var is read-only
> var is read-only
>     (write trace on "xsltSchemaDom")
>     invoked from within
> "variable xsltSchemaDom domDoc0xa7c640"
>     (in namespace eval "::WS::Utils" script line 3)
>     invoked from within
> "namespace eval ::WS::Utils {
>  variable currentNs {}
> variable xsltSchemaDom domDoc0xa7c640
> variable standardAttributes {
>         baseType
>         comme..."
>     invoked from within
> "ns_ictl cleanup"
>     (procedure "ns_cleanup" line 6)
>     invoked from within
> "ns_cleanup"
>     while executing callback
> ns:tcltrace ns_cleanup
> (context: trace proc)
>
> With version 4.99.13 we get his error on every startup. It seems to be 
> connected to thread creation. Has anybody any idea how to prevent this 
> error?
>
> regards,
>
> Wolfgang
>
>
> -- 
>
> *Wolfgang Winkler*
> Geschäftsführung
> wol...@di...
> mobil +43.699.19971172
>
> dc:*büro*
> digital concepts Novak Winkler OG
> Software & Design
> Landstraße 68, 5. Stock, 4020 Linz
> www.digital-concepts.com <http://www.digital-concepts.com>
> tel +43.732.997117.72
> tel +43.699.1997117.2
>
> Firmenbuchnummer: 192003h
> Firmenbuchgericht: Landesgericht Linz
>
>

[naviserver-devel] Startup Error for tclws in naviserver 4.99.13

[Wolfgang W. <wol...@di...>]

Hi!

We are using webservices for tcl (tclws) with naviserver. For naviserver 
version 4.99.7 we sometimes get the following error message:

Error: can't set "xsltSchemaDom": var is read-only
var is read-only
     (write trace on "xsltSchemaDom")
     invoked from within
"variable xsltSchemaDom domDoc0xa7c640"
     (in namespace eval "::WS::Utils" script line 3)
     invoked from within
"namespace eval ::WS::Utils {
  variable currentNs {}
variable xsltSchemaDom domDoc0xa7c640
variable standardAttributes {
         baseType
         comme..."
     invoked from within
"ns_ictl cleanup"
     (procedure "ns_cleanup" line 6)
     invoked from within
"ns_cleanup"
     while executing callback
ns:tcltrace ns_cleanup
(context: trace proc)

With version 4.99.13 we get his error on every startup. It seems to be 
connected to thread creation. Has anybody any idea how to prevent this 
error?

regards,

Wolfgang


-- 

*Wolfgang Winkler*
Geschäftsführung
wol...@di...
mobil +43.699.19971172

dc:*büro*
digital concepts Novak Winkler OG
Software & Design
Landstraße 68, 5. Stock, 4020 Linz
www.digital-concepts.com <http://www.digital-concepts.com>
tel +43.732.997117.72
tel +43.699.1997117.2

Firmenbuchnummer: 192003h
Firmenbuchgericht: Landesgericht Linz

[naviserver-devel] NaviServer 4.99.13 available

[Gustaf N. <ne...@wu...>]

Dear friends of NaviServer,

on sourceforge the new release of NaviServer 4.99.13 is
available [1]. As always, the newest release can be as
well obtained from bitbucket [2].

One more good news item: With the change [3] (which will be in
the next release of Tcl, probably 8.6.7), one big source for
potential crashes during shutdown is gone
(mostly annoying in "make test" runs), Hooray!

I'll prepare as well an announcement for c.l.tcl and
OpenACS.org. Below are the changes since 4.99.12:

best regards

-gustaf
[1] https://sourceforge.net/projects/naviserver/files/naviserver/4.99.13/
[2] https://bitbucket.org/naviserver/naviserver/overview
[3] http://core.tcl.tk/tcl/tktview?name=3cc1d91345

=======================================
NaviServer 4.99.13, released 2016-10-15
=======================================

  143 files changed, 3051 insertions(+), 2091 deletions(-)

New Features:
   - New Tcl functions:

       * ns_parseurl /url/
         Parse the provided URL into its parts and
         returns these in the form of a Tcl dict. The function supports
         IP-literal notation as specified in RFC 3986.

       * ns_absoluteurl /incompleteurl/ /baseurl/
         Construct a completed URL from a incomplete (e.g. relative)
         URL by taking as many parts as possible from the provided base
         URL.

   - ns_striphtml: The function honors now numeric entities between 33
     and 255 instead of ignoring it.

   - New configure option for error.log: "logrollfmt", which can be
     specified in (section ns/parameters).  This option has the same
     interpretation as already provided for access log and provides
     timestamp based log file naming. This option can reduce back-up
     demands for large error.logs significantly (since the names are
     stable) and increases the orthogonality of options (in respect to
     access.logs).

   - Ns_ParseUrl(): add support for protocol agnostic URLs (starting
     with two slashes as defined in RFC 3986).

   - ns_deletecookie: mark deleted cookie as non-scriptable to improve
     ratings on security scanners.


Bug Fixes:
  - Fix for [naviserver:bugs] #76: ns_configsections returned
    only one section (bug introduced in 4.99.12).
    
  - Fix URL parser in Ns_ParseUrl(), could return incorrect results
    when it received an URL in IP-literal notation (bug introduced in
    4.99.11).
  
  - Fix for potentially incorrect mime-types in fastpath, when static
    gzip is activated. The mime type was incorrectly set to
    application/gzip, when the static gzipped file was returned. This
    bug was introduced in 4.99.12, many thanks to David Osborne for
    reporting).

Documentation improvements:
   - Documenting new functions
   - Several small cleanups
   - Improved sample config files

C API Changes:
    - using unsigned int for ports
        Ns_SockListenUnix(), Ns_SockBindUnix()
    - using "long" for secs
        Ns_SockSetDeferAccept(), ns_poll(), Ns_DiffTime()
    - makeing argument types more precise
        NsPoll(), Ns_SockBinderListen(), Ns_GetNameForGid(), Ns_ThreadStackSize()

Code Changes:
  - Extended regression test
  - Improved source code documentation

  - C-Code cleanup:
    * Removed all implicit type-conversions, signed/unsigned comparisons
      as flagged by the following gcc/clang flags (ensure cleanness on 64bit)
      -Wconversion -Wsign-conversion -Wfloat-conversion -Wsign-compare

    * Reduced number of return statement before end of function
    * Reduced variable scopes
    * added types for uid_t, gid_t if not defined
    
    * Remove calls to Tcl functions which are deprecated/ going to be
      deprecated by Tcl. Code can be compiled now with -DTCL_NO_DEPRECATED
      
    * Converted all remaining Tcl_CmdProc to Tcl_ObjCmdProc
	NsTclAdpStatsCmd    -> NsTclAdpStatsObjCmd
	NsTclCrashCmd       -> NsTclCrashObjCmd
	NsTclHrefsCmd       -> NsTclHrefsObjCmd
	NsTclLibraryCmd     -> NsTclLibraryObjCmd
	NsTclMkTempCmd      -> NsTclMkTempObjCmd
	NsTclParseHeaderCmd -> NsTclParseHeaderObjCmd
	NsTclQuoteHtmlCmd   -> NsTclQuoteHtmlObjCmd
	NsTclStripHtmlCmd   -> NsTclStripHtmlObjCmd
    
  - Tcl-Code
    * tcl/aolserver-openacs.tcl:
      Register delete trace to run nsf::finalize in a safe state (before
      any other c-based finalize handler are fired)
    * regression test: Replaced Tcl "eval" by expand operator

Re: [naviserver-devel] Boot up NS with Daemontools supervisor

[Gustaf N. <ne...@wu...>]

Iuri, you might consider reading: 
http://openacs.org/forums/message-view?message_id=5334880
-gn

Am 15.10.16 um 00:10 schrieb Iuri Sampaio:
> Thanks Gustaf,
>
> The script install.oacs.sh didn't setup NS starting automatically, but 
> I won't bother debuging it for now. I'll will add one update-rc.d, to 
> start on boot, plus an upstart script will do the job.
>
> Best wishes
>
> On 14-10-2016 05:02, Gustaf Neumann wrote:
>> Dear Iuri,
>>
>> One has to use probably foreground mode (-f, see 
>> http://openacs.org/forums/message-view?message_id=187728) for 
>> daemontools. We have not used  daemontools for ages, i would not 
>> recommend it.
>>
>> The install-oacs.sh script [1] installs either a systemd file for 
>> naviserver/openacs, or an upstart file (or both) depending on the 
>> system it is running on. if for some reason, you do not want to run 
>> the script, fill in the variables manually. This way, 
>> naviserver/openacs can be started/restarted/... like all other system 
>> services.
>>
>> all the best
>> -gn
>>
>> [1] 
>> https://github.com/gustafn/install-ns/blob/master/install-oacs.sh#L342
>>

Re: [naviserver-devel] Boot up NS with Daemontools supervisor

[Iuri S. <iu...@iu...>]

Thanks Gustaf,

The script install.oacs.sh didn't setup NS starting automatically, but I 
won't bother debuging it for now. I'll will add one update-rc.d, to 
start on boot, plus an upstart script will do the job.

Best wishes

On 14-10-2016 05:02, Gustaf Neumann wrote:
> Dear Iuri,
>
> One has to use probably foreground mode (-f, see 
> http://openacs.org/forums/message-view?message_id=187728) for 
> daemontools. We have not used  daemontools for ages, i would not 
> recommend it.
>
> The install-oacs.sh script [1] installs either a systemd file for 
> naviserver/openacs, or an upstart file (or both) depending on the 
> system it is running on. if for some reason, you do not want to run 
> the script, fill in the variables manually. This way, 
> naviserver/openacs can be started/restarted/... like all other system 
> services.
>
> all the best
> -gn
>
> [1] https://github.com/gustafn/install-ns/blob/master/install-oacs.sh#L342
>
> Am 12.10.16 um 19:00 schrieb Iuri Sampaio:
>> Thanks Cyan,
>>
>> Good that you mentioned it, but I tried after I've sent the email. 
>> Both have the same behavior.
>>
>> ####
>> sleep 4
>> exec /usr/local/ns/bin/nsd -it /usr/local/ns/iurix.tcl -u iurix -g 
>> web -b 192.199.241.135:80 <http://192.199.241.135:80>
>> ####
>>
>>
>> Best wishes
>>
>>
>>
>>
>> On 12-10-2016 13:52, Cyan Ogilvie wrote:
>>> Maybe add -i
>>>
>>> Cyan
>>>
>>> On Wed, Oct 12, 2016 at 5:59 PM, Iuri Sampaio <iu...@iu... 
>>> <mailto:iu...@iu...>> wrote:
>>>
>>>     Hi there,
>>>
>>>     In order to get NS to start automatically, I installed
>>>     daemontools (i.e.
>>>     debian server - apt-get install). However, when I start the
>>>     supervisor,
>>>     it starts to boot up hundreds of NS instances until that it eats
>>>     up all
>>>     the memory and crashes the whole server. My intuition tells that
>>>     there's
>>>     a problem with apt-get installation but I'm still digging in.
>>>     The script
>>>     is a simple line as bellow:
>>>
>>>     ####
>>>     sleep 4
>>>     exec /usr/local/ns/bin/nsd -t /usr/local/ns/iurix.tcl -u iurix
>>>     -g web -b
>>>     192.199.241.135:80 <http://192.199.241.135:80>
>>>     ####
>>>
>>>     How do I setup NS automatically start supervisor correctly?
>>>
>>>     Best wishes
>>>     Iuri
>>>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] Boot up NS with Daemontools supervisor

[Gustaf N. <ne...@wu...>]

Dear Iuri,

One has to use probably foreground mode (-f, see 
http://openacs.org/forums/message-view?message_id=187728) for 
daemontools. We have not used  daemontools for ages, i would not 
recommend it.

The install-oacs.sh script [1] installs either a systemd file for 
naviserver/openacs, or an upstart file (or both) depending on the system 
it is running on. if for some reason, you do not want to run the script, 
fill in the variables manually. This way, naviserver/openacs can be 
started/restarted/... like all other system services.

all the best
-gn

[1] https://github.com/gustafn/install-ns/blob/master/install-oacs.sh#L342

Am 12.10.16 um 19:00 schrieb Iuri Sampaio:
> Thanks Cyan,
>
> Good that you mentioned it, but I tried after I've sent the email. 
> Both have the same behavior.
>
> ####
> sleep 4
> exec /usr/local/ns/bin/nsd -it /usr/local/ns/iurix.tcl -u iurix -g web 
> -b 192.199.241.135:80 <http://192.199.241.135:80>
> ####
>
>
> Best wishes
>
>
>
>
> On 12-10-2016 13:52, Cyan Ogilvie wrote:
>> Maybe add -i
>>
>> Cyan
>>
>> On Wed, Oct 12, 2016 at 5:59 PM, Iuri Sampaio <iu...@iu... 
>> <mailto:iu...@iu...>> wrote:
>>
>>     Hi there,
>>
>>     In order to get NS to start automatically, I installed
>>     daemontools (i.e.
>>     debian server - apt-get install). However, when I start the
>>     supervisor,
>>     it starts to boot up hundreds of NS instances until that it eats
>>     up all
>>     the memory and crashes the whole server. My intuition tells that
>>     there's
>>     a problem with apt-get installation but I'm still digging in. The
>>     script
>>     is a simple line as bellow:
>>
>>     ####
>>     sleep 4
>>     exec /usr/local/ns/bin/nsd -t /usr/local/ns/iurix.tcl -u iurix -g
>>     web -b
>>     192.199.241.135:80 <http://192.199.241.135:80>
>>     ####
>>
>>     How do I setup NS automatically start supervisor correctly?
>>
>>     Best wishes
>>     Iuri
>>

Re: [naviserver-devel] Boot up NS with Daemontools supervisor

[Iuri S. <iu...@iu...>]

Thanks Cyan,

Good that you mentioned it, but I tried after I've sent the email. Both 
have the same behavior.

####
sleep 4
exec /usr/local/ns/bin/nsd -it /usr/local/ns/iurix.tcl -u iurix -g web 
-b 192.199.241.135:80 <http://192.199.241.135:80>
####


Best wishes




On 12-10-2016 13:52, Cyan Ogilvie wrote:
> Maybe add -i
>
> Cyan
>
> On Wed, Oct 12, 2016 at 5:59 PM, Iuri Sampaio <iu...@iu... 
> <mailto:iu...@iu...>> wrote:
>
>     Hi there,
>
>     In order to get NS to start automatically, I installed daemontools
>     (i.e.
>     debian server - apt-get install). However, when I start the
>     supervisor,
>     it starts to boot up hundreds of NS instances until that it eats
>     up all
>     the memory and crashes the whole server. My intuition tells that
>     there's
>     a problem with apt-get installation but I'm still digging in. The
>     script
>     is a simple line as bellow:
>
>     ####
>     sleep 4
>     exec /usr/local/ns/bin/nsd -t /usr/local/ns/iurix.tcl -u iurix -g
>     web -b
>     192.199.241.135:80 <http://192.199.241.135:80>
>     ####
>
>     How do I setup NS automatically start supervisor correctly?
>
>     Best wishes
>     Iuri
>
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>     _______________________________________________
>     naviserver-devel mailing list
>     nav...@li...
>     <mailto:nav...@li...>
>     https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>     <https://lists.sourceforge.net/lists/listinfo/naviserver-devel>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] Boot up NS with Daemontools supervisor

[Wolfgang W. <wol...@di...>]

Hi!

Try the "-i" parameter :

-i  inittab mode

regards,

Wolfgang

Am 2016-10-12 um 17:59 schrieb Iuri Sampaio:
> Hi there,
>
> In order to get NS to start automatically, I installed daemontools (i.e.
> debian server - apt-get install). However, when I start the supervisor,
> it starts to boot up hundreds of NS instances until that it eats up all
> the memory and crashes the whole server. My intuition tells that there's
> a problem with apt-get installation but I'm still digging in. The script
> is a simple line as bellow:
>
> ####
> sleep 4
> exec /usr/local/ns/bin/nsd -t /usr/local/ns/iurix.tcl -u iurix -g web -b
> 192.199.241.135:80
> ####
>
> How do I setup NS automatically start supervisor correctly?
>
> Best wishes
> Iuri
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel


-- 

*Wolfgang Winkler*
Geschäftsführung
wol...@di...
mobil +43.699.19971172

dc:*büro*
digital concepts Novak Winkler OG
Software & Design
Landstraße 68, 5. Stock, 4020 Linz
www.digital-concepts.com <http://www.digital-concepts.com>
tel +43.732.997117.72
tel +43.699.1997117.2

Firmenbuchnummer: 192003h
Firmenbuchgericht: Landesgericht Linz

Re: [naviserver-devel] Boot up NS with Daemontools supervisor

[Cyan O. <cya...@gm...>]

Maybe add -i

Cyan

On Wed, Oct 12, 2016 at 5:59 PM, Iuri Sampaio <iu...@iu...> wrote:

> Hi there,
>
> In order to get NS to start automatically, I installed daemontools (i.e.
> debian server - apt-get install). However, when I start the supervisor,
> it starts to boot up hundreds of NS instances until that it eats up all
> the memory and crashes the whole server. My intuition tells that there's
> a problem with apt-get installation but I'm still digging in. The script
> is a simple line as bellow:
>
> ####
> sleep 4
> exec /usr/local/ns/bin/nsd -t /usr/local/ns/iurix.tcl -u iurix -g web -b
> 192.199.241.135:80
> ####
>
> How do I setup NS automatically start supervisor correctly?
>
> Best wishes
> Iuri
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

[naviserver-devel] Boot up NS with Daemontools supervisor

[Iuri S. <iu...@iu...>]

Hi there,

In order to get NS to start automatically, I installed daemontools (i.e. 
debian server - apt-get install). However, when I start the supervisor, 
it starts to boot up hundreds of NS instances until that it eats up all 
the memory and crashes the whole server. My intuition tells that there's 
a problem with apt-get installation but I'm still digging in. The script 
is a simple line as bellow:

####
sleep 4
exec /usr/local/ns/bin/nsd -t /usr/local/ns/iurix.tcl -u iurix -g web -b 
192.199.241.135:80
####

How do I setup NS automatically start supervisor correctly?

Best wishes
Iuri

[naviserver-devel] Release candidate for NaviServer 4.99.13

[Gustaf N. <ne...@wu...>]

Dear friends of NaviServer,

on sourceforge is a release candidate for NaviServer 4.99.13 (see [1]).
The version fixes essentially two relatively fresh bugs and continues
the ongoing code cleanup process. For example, NaviServer compiles now
clean with the type conversion, signed-unsigned comparisons etc. flags
turned on in clang/gcc, which are discussed in the interesting paper [2]
published recently at at CCS’16, where the authors identified
related security flaws in prominent software such as the Linux
Kernel, Chromium, boost, libarchive and zlib.

If everything goes well, the release should follow end of this week.
Please test if possible. Below are the changes since 4.99.12:

best regards

-gustaf
[1] https://sourceforge.net/projects/naviserver/files/naviserver/4.99.13/
[2] https://www.tu-braunschweig.de/Medien-DB/sec/pubs/2016-ccs.pdf

=======================================
NaviServer 4.99.13, released 2016-XX-XX
=======================================

  137 files changed, 2808 insertions(+), 1913 deletions(-)

New Features:
   - New Tcl functions:

       * ns_parseurl /url/
         Parse the provided URL into its parts and
         returns these in the form of a Tcl dict. The function supports
         IP-literal notation as specified in RFC 3986.

       * ns_absoluteurl /incompleteurl/ /baseurl/
         Construct a completed URL from a incomplete (e.g. relative)
         URL by taking as many parts as possible from the provided base
         URL.

   - ns_striphtml: The function honors now numeric entities between 33
     and 255 instead of ignoring it.

   - New configure option for error.log: "logrollfmt", which can be
     specified in (section ns/parameters).  This option has the same
     interpretation as already provided for access log and provides
     timestamp based log file naming. This option can reduce back-up
     demands for large error.logs significantly (since the names are
     stable) and increases the orthogonality of options (in respect to
     access.logs).

   - Ns_ParseUrl(): add support for protocol agnostic URLs (starting
     with two slashes as defined in RFC 3986).

   - ns_deletecookie: mark deleted cookie as non-scriptable to improve
     ratings on security scanners.


Performance Improvements:

Bug Fixes:
  - Fix for [naviserver:bugs] #76: ns_configsections returned
    only one section (bug introduced in 4.99.12).
    
  - Fix URL parser in Ns_ParseUrl(), could return incorrect results
    when it received an URL in IP-literal notation (bug introduced in
    4.99.11).
  
  - Fix for potentially incorrect mime-types in fastpath, when static
    gzip is activated. The mime type was incorrectly set to
    application/gzip, when the static gzipped file was returned. This
    bug was introduced in 4.99.12, many thanks to David Osborne for
    reporting).

Documentation improvements:
   - Documenting new functions
   - Several small cleanups
   - Improved sample config files

Tcl API Changes:

C API Changes:

Incompatible API Changes:

Configuration Changes:

Command Line Changes:

Code Changes:
  - Extended regression test
  - Improved source code documentation

  - C-Code cleanup:
    * Removed all implicit type-conversions, signed/unsigned comparisons
      as flagged by the following gcc/clang flags (ensure cleanness on 64bit)
      -Wconversion -Wsign-conversion -Wfloat-conversion -Wsign-compare

    * Reduced number of return statement before end of function
    * Reduced variable scopes
    
    * Remove calls to Tcl functions which are deprecated/ going to be
      deprecated by Tcl. Code can be compiled now with -DTCL_NO_DEPRECATED
      
    * Converted all remaining Tcl_CmdProc to Tcl_ObjCmdProc
	NsTclAdpStatsCmd    -> NsTclAdpStatsObjCmd
	NsTclCrashCmd       -> NsTclCrashObjCmd
	NsTclHrefsCmd       -> NsTclHrefsObjCmd
	NsTclLibraryCmd     -> NsTclLibraryObjCmd
	NsTclMkTempCmd      -> NsTclMkTempObjCmd
	NsTclParseHeaderCmd -> NsTclParseHeaderObjCmd
	NsTclQuoteHtmlCmd   -> NsTclQuoteHtmlObjCmd
	NsTclStripHtmlCmd   -> NsTclStripHtmlObjCmd
    
  - Tcl-Code
    * tcl/aolserver-openacs.tcl:
      Register delete trace to run nsf::finalize in a safe state (before
      any other c-based finalize handler are fired)
    * regression test: Replaced Tcl "eval" by expand operator

Re: [naviserver-devel] Naviserver 4.99.12 : content-type of gzipped static content

[David O. <da...@qc...>]

Thanks Gustaf. I've added that patch to our build and it works fine now.
Cheers.

-- 
David


On 30 September 2016 at 09:14, Gustaf Neumann <ne...@wu...> wrote:

> Am 29.09.16 um 13:03 schrieb David Osborne:
> > I've come across a change in behaviour on upgrading to the 4.99.12
> > tagged version which looks like it may be a bug - certainly it's
> > breaking our current config.
> > Can you help us with it?
> Hi David,
>
> you are absolute right, there was a bug, fixed by [1]. I'll try to a
> test-case to the regression test.
> We will aim for a patch release soon.
>
> Many thanks for the excellent bug report!
>
> -g
>
>
> PS: In OpenACS setting, practically all files are returned via
> ns_return/ns_returnfile, where the bug does not exit, so it remained
> undetected.
>
> [1]
> https://bitbucket.org/naviserver/naviserver/commits/
> e26c913dd15c96ee0827a0cbf084936ff34bea49
>
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] Naviserver 4.99.12 : content-type of gzipped static content

[Gustaf N. <ne...@wu...>]

Am 29.09.16 um 13:03 schrieb David Osborne:
> I've come across a change in behaviour on upgrading to the 4.99.12 
> tagged version which looks like it may be a bug - certainly it's 
> breaking our current config.
> Can you help us with it?
Hi David,

you are absolute right, there was a bug, fixed by [1]. I'll try to a 
test-case to the regression test.
We will aim for a patch release soon.

Many thanks for the excellent bug report!

-g


PS: In OpenACS setting, practically all files are returned via 
ns_return/ns_returnfile, where the bug does not exit, so it remained 
undetected.

[1] 
https://bitbucket.org/naviserver/naviserver/commits/e26c913dd15c96ee0827a0cbf084936ff34bea49

[naviserver-devel] Naviserver 4.99.12 : content-type of gzipped static content

[David O. <da...@qc...>]

Hi,

I've come across a change in behaviour on upgrading to the 4.99.12 tagged
version which looks like it may be a bug - certainly it's breaking our
current config.
Can you help us with it?

It's when we're delivering gzipped static content.

Previously, a gzipped delivery of an html file would have:

Content-Encoding: gzip
Content-Type: text/html

Since updating to 4.99.12, fastpath is delivering the gzipped content as:

Content-Encoding: gzip
Content-Type: application/gzip


Here's the behaviour at 4.99.11:

[image: Inline images 1]

And at 4.99.12

[image: Inline images 2]


To reproduce I do the following on Debian Jessie 8.6:

hg clone -r naviserver-4.99.12 https://bitbucket.org/naviserver/naviserver
cd naviserver
./autogen.sh --disable-ipv6 --with-tcl=/usr/lib/tcl8.5 --enable-rpath
--enable-threads
make
make install
Edit: /usr/local/ns/conf/nsd-config.tcl
   -> change port from 8080->80
   -> add the following to the fastpath section
ns_param        gzip_static         true
ns_param        gzip_cmd            "/bin/gzip -9"
ns_param        gzip_refresh        true

Create /usr/local/ns/pages/test.html with:

<html>
  <head>
    <title>Hello World</title>
  </head>
  <body>
    <h1>HelloWorld</h1>
  </body>
</html>

Run: gzip -c /usr/local/ns/pages/test.html > /usr/local/ns/pages/
test.html.gz

Start the server /usr/local/ns/bin/nsd -c -u nsd -t
/usr/local/ns/conf/nsd-config.tcl -b 0.0.0.0:80

Browse to http://myip/test.html

Thanks for any help.
Regards,
-- 
David

[naviserver-devel] Changes on the NaviServer code base in the last year

[Gustaf N. <ne...@wu...>]

Dear all,

Over the last year, much of the NaviServer source code basis was 
changed. Part of the changes were to extend functionality, improve 
performance, reduce the number of bugs, but most of the changes were 
actually to remove code smells/issues for on the NaviServer code bases. 
In the last years, the quality of static analysis tools (such as 
cppcheck, clang static checker, pclint, ...) has improved, finding more 
potential issues. However, getting these tools installed, and run the
code-bases on it, keeping track of fixed/new issues is a substantial 
amount of work.

Thankfully, Maurizio Martignano set up a website 
(http://sonarsrv.spazioit.com) based on SonarQube, which collects the 
results of various tools and provides means to locate certain code 
smells efficiently. Based on the results on sonarsrv, we could reduce 
the number of issues/code smells from several thousand to serval 
hundreds. We started out with more than 10.000 issues about two years 
ago, which was more than in AOLserver (due to a more differentiated 
typing, trying to use posix-style types internally). By using the code 
static code checkers, the code basis can be made more strict and to make 
certain properties of the code  explicit (e.g. adding "const" 
declarations, adding assertions, reducing the number of implicit 
conversions). By making assumptions explicit, the code bears less 
surprises in boundary cases. Other changes were done to improve 
maintainability (e.g. reducing the scope of variables) and to ease code 
comprehension (e.g. reducing the number of return statements per 
functions, ideally to 1; improving comment ratio, reducing deprecated 
code, etc.).

If one checks the results on sonarsrv, one can see that there are still 
many open issue. Furthermore, one can expect that the number of reported 
issues will rise even without code changes, when the static checkers 
improve. But altogether, i would expect, that the number of changes 
between releases will reduce.

All the best

-gustaf neumann

4.99.11 -> 4.99.12:  195 files changed, 20265 insertions(+), 13421 deletions(-)
4.99.10 -> 4.99.11:  156 files changed,  8613 insertions(+),  3142 deletions(-)
4.99.9  -> 4.99.10:   32 files changed,   404 insertions(+),   123 deletions(-)
4.99.8  -> 4.99.9:   146 files changed,  5595 insertions(+),  4389 deletions(-)
4.99.7  -> 4.99.8:    55 files changed,  1088 insertions(+),   527 deletions(-)
4.99.6  -> 4.99.7:   216 files changed, 20967 insertions(+), 13287 deletions(-)
4.99.5  -> 4.99.6:   198 files changed,  4972 insertions(+),  2657 deletions(-)

Re: [naviserver-devel] NaviServer market statistics

[Gustaf N. <ne...@wu...>]

Just a small followup: The positive download trend is continuing, in 
August we saw twice the downloads of July.

2016-06       52
2016-07     106
2016-08     215

all the best
-g




https://sourceforge.net/projects/naviserver/files/stats/timeline?dates=2005-02-05+to+2016-08-31

[naviserver-devel] NaviServer 4.99.12 available

[Gustaf N. <ne...@wu...>]

Dear friends,

NaviServer 4.99.12 is available. The new version is tagged with
naviserver-4.99.12 in mercurial on bitbucket and is as well
available at source-forge on the usual places (NaviServer,
modules, documentation pages). I'll prepare as well an
announcement for c.l.tcl and OpenACS.org.

Below is the section for 4.99.12 from the NEWS file.

all the best

-gustaf neumann


=======================================
NaviServer 4.99.12, released 2016-08-21
=======================================

  195 files changed, 20265 insertions(+), 13421 deletions(-)

New Features:
   * OpenSSL support integrated with NaviServer core
     - ns_http can handle now http and https urls
     - Added backward_compatibility stub for ns_ssl
     - Added configure switch --with-openssl?=path?

   * Improved crypto support (through OpenSSL)
     New commands:
       - ns_hmac
       - ns_md (generalization of ns_md5 and ns_sha1,
         but supports by default 14 different digest algorithms)
       - ns_hotp (one-time passwords as defined in RFC 4226)
       - ns_totp (time-based one-time passwords as defined in RFC 6238)

     StartTLS support (contributed by Constantin Șerban-Rădoi)
      - "ns_sendmail" is now able to connect to servers via StartTLS
         (requires the Tcl "tls" package, since ns_sendmail is
         implemented in Tcl)
       - Client and server support for StartTLS in the nssmtpd module.

   * New Command "ns_rlimit" to get/set various resource limits from
     the operating system. A typical use case for this command is to
     query or set e.g. the core size via the NaviServer startup file or
     to change it at runtime in a syntax independent from the naming
     and conventions in the various startup scripts (e.g. upstart,
     systemd, ...). This is e.g. useful when a core dump should be
     created from the running state (e.g. in combination with the
     "ns_crash" command).
   
   * Improvements for "ns_connchan":
      - Supports now client functionality via
           ns_connchan open ...
        (works for http:// and https:// URLs)
      - New subcommand "ns_connchan exists /channel/"
      - Added runtime switchable debug severity "Debug(connchan)"

Performance Improvements:

Bug Fixes:
   * Fix ns_set management of headers (which was broken since the
     introduction of the leftover management when requests are
     pipelined in 4.99.11). The problem was that the "static" ns_set for headers is
     was freed to early in the pipelined case.

   * Fix for a serious bug in cookie management which could lead to false
     positives in ns_getcookie:

       - Previous versions of NaviServer searched the "Cookie" and
	"Set-Cookie" header files for a string "NAME=" and returned
	the value provided after this string, when found.

       - However, the "Cookie" and "Set-Cookie" header fields have
	contents in a different a different syntax (see
	https://tools.ietf.org/html/rfc6265 section 4.1.1 vs. 4.2.1),
	such as e.g. Cookie: cookie1="value1"; cookie2="value2";
	style=null; ... Set-Cookie: cookie1="new- value"; Expires=Fri,
	01-Jan-2035 01:00:00 GMT; Path=/; HttpOnly

       - Therefore, searching in the "Cookie" header field e.g. for a
         cookie named "tyle" lead to a success as well as a search in
         "Set-Cookies" for e.g. a cookie named "Expires".

   * Improved handling of erroneous requests (some where treated as
     HTTP/0.9 requests before, leading to strange behavior/error
     messages).

   * Fix potential memory leak for "ns_mutex eval"

   * Long standing bug when exiting "make test" should be fixed by now.
     The problem was that the the Tcl exit handler was kicking in when
     the end-of file was reached, interfering with the NaviServer
     shutdown steps.

   * Improved portability for *BSD systems and recent Windows
     build environments (e.g. Visual Studio 2015)
	

Documentation improvements:
   * New man pages for ns_hmac, hs_md, ns_hotp, ns_totp
   * Various man pages updated/improved
   * Improved sample config files
   

C API Changes:

   *  Introduction of Ns_ReturnCode: use an enumeration type instead of
      preprocessor based constants + int. The change revealed several
      places, where NS_OK/NS_ERROR and TCL_OK/TCL_ERROR were intermixed.

   * New functions

     - Ns_GetBinaryString() to obtain from a Tcl_Obj the binary
       representation if available, otherwise the string representation.
       
     - Ns_SetRecreate() which is a combination of a create and a move
       operation, but avoiding malloc operations on all keys/values.

     - Ns_DStringAppendTime() to ease uniform printing of
       Ns_Time structs into DStrings

     - Ns_SubcmdObjv(): New infrastructure support for commands with
       subcommands: instead of long switch statements with nested
       structures with often many returns, one can now register
       Tcl_ObjCmdProcs for subcommands in an Ns_SubCmdSpec structure.
       
     - New argv checkers Ns_ObjvUShort() and ObjvQueue()
     

Configuration Changes:
     - added configure switch --with-openssl?=path?


Code Changes:
   * Improved naming of Mutexes: much more mutexes are named now.
   
   * Code cleanup:
     - Modernized argv parsing by using Ns_ParseObjv() for
       many functions.
     - Introduced enumeration types Ns_ReturnCode
       and NsWriterStreamState
     - New macro INTCHAR to pass "char" values to library
     - Use "unsigned short" consistently for port numbers
       functions requiring "int" to avoid code smells
     - Use boolean types on more occasions
     - Use more often typedef-ed function definitions
     - Reduced number of multiple returns per function
     - Removed all calls to deprecated Tcl API Function
       Tcl_AppendElement()
     - Reduced calls to Tcl_AppendResult() and use explicit
       Tcl_Objs instead for results
     - Generation of error messages made more consistent
     - Removed useless calls to Ns_DStringFree() after Tcl_DStringResult()
     - Replaced deprecated atoll() by strtoll()
     - Reduced variable scopes
     - Added more const declarations
     - Don't use boolean values as arguments of comparison operators
     - Many large functions split into smaller units

   * Made testing more robust when IPv6 is available, but
     turned off in the kernel
     
   * NaviServer driver:
     - Added (clientInitProc, protocol and default port) to info record
     - Bumped driver version to 4
     
   * Ignore less soft error conditions, but report in the error.log