naviserver-devel — Developer discussion

[naviserver-devel] ns_sendmail

[Bernd E. <eid...@we...>]

Hi!

I re-wrote ns_sendmail a bit and wanted to ask you if you find the following 
things interesting/important enough to commit it to HEAD for further review 
and testing:

1. Uses utf-8 (or any other TCL supported, configurable) encoding
2. Quoted-Printable subject
3. Quoted-Printable body
4. Locale independent Date
5. Allows pretty names (Peter foo <pf...@ex...>) in to,cc,bcc-list and 
From
6. Creates message-id if none is specified (where the right part of @, the 
hostname is optionally configurable)
7. Allows logging of complete mail transfer instead of sending (configurable)

My goal was not to replace the mime/sendmail stuff from tcllib, which is still 
the better choice for more complex situations, but to have something that 
better works for non-ascii-world users and does trigger less spam filter 
rules.

What I would finish before commit is: 
(to 4) I have to work on a proper timezone creation
(to 1) Turn off encoding support by default, to be fully backwards compatible; 
maybe also for (2-3).

What do you think?

Bernd.

Re: [naviserver-devel] Trace errors

[Vlad S. <vl...@cr...>]

it works now, fresh CVs version

Stephen Deasey wrote:
> I just grepped through all the modules on SF and couldn't find any
> calls to NS_TCL_TRACE_CEALLOCATE (or Ns_TclRegisterAtCleanup).
> 
> Make sure you're running the latest CVS.  I fixed a bug in nsdb which
> causes this log message a couple of days ago.
> 
> 
> On 10/21/05, Vlad Seryakov <vl...@cr...> wrote:
> 
>>I this NS_TCL_TRACE_DEALLOCATE is used to delay delallocation of
>>interps, i do not explicitely register any traces.
>>
>>
>>Stephen Deasey wrote:
>>
>>>On 10/21/05, Vlad Seryakov <vl...@cr...> wrote:
>>>
>>>
>>>>[21/Oct/2005:09:30:55][8454.3004771248][-thread-1290196048-] Error: Can
>>>>not register Tcl trace, server already started.
>>>>
>>>>The trace which is called is NS_TCL_TRACE_DEALLOCATE
>>>
>>>
>>>
>>>This has been the case for quite a while, it just never used to log an
>>>error (which is why the bug in nsdb went unnoticed).
>>>
>>>The trace api is limited to pre-start up because the locking would be
>>>a pain.  It's possible for example for a Tcl trace callback to add
>>>another trace, causing a deadlock if we don't use something like a
>>>critical section, which seems a little over the top.
>>>
>>>Which code is trying to register a trace, and why?
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by:
>>>Power Architecture Resource Center: Free content, downloads, discussions,
>>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>>_______________________________________________
>>>naviserver-devel mailing list
>>>nav...@li...
>>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
>>--
>>Vlad Seryakov
>>571 262-8608 office
>>vl...@cr...
>>http://www.crystalballinc.com/vlad/
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Power Architecture Resource Center: Free content, downloads, discussions,
>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>_______________________________________________
>>naviserver-devel mailing list
>>nav...@li...
>>https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] ns_cache

[Vlad S. <vl...@cr...>]

Yes, dynamic caches are very useful, i checked my code and i use them as 
well

Zoran Vasiljevic wrote:
> 
> Am 22.10.2005 um 15:51 schrieb Stephen Deasey:
> 
>> On 10/22/05, Zoran Vasiljevic <zv...@ar...> wrote:
>>
>>>
>>> Am 21.10.2005 um 15:19 schrieb Vlad Seryakov:
>>>
>>>
>>>> Looks okay, API has changed but if we accept it, i suppose onetime
>>>> code change is acceptable
>>>>
>>>>
>>>
>>> What about timed cache? I miss this (for us) important feature.
>>>
>>
>>
>> The existing implementation doesn't make a lot of sense to me.  You
>> can create either a size limited cache, OR a time based cache.  A time
>> based cache has it's entries flushed based on the mtime, i.e. only
>> when they're unused.  This means popular entries will never be
>> flushed.
>>
>> What you really want is for entries to have a max cache lifetime (ADP
>> pages), possibly different for each entry (DNS lookups).
> 
> 
> 
> OK. This is true, indded.
> 
> 
>>
>>
>>
>>> Why passing the cacheTable over ClientData?
>>>
>>
>>
>> That's just because I implemented this as a module so it could be
>> tested easily without patching.  A merged version would add a slot to
>> the NsServer structure.
> 
> 
> OK. This is clear.
> 
>>
>>
>>
>>> Why not creating caches during server lifetime instead of only
>>> at startup?
>>>
>>
>>
>> Locking overhead.  The current implementation doesn't lock the caches
>> when for example the stats command is run, which could have the cache
>> deleted out from under it, causing a crash.
>>
>> I did try a couple of ways to enable safe cache creation at runtime,
>> including reference counting of the caches themselves.  It just seemed
>> over engineered.
>>
>> Do you have a situation in mind where caches should be created at  
>> runtime?
> 
> 
> Oh yes... We have a database lib (Codebase) which is fast, but some  of the
> things we did there take time. Hence, I use the cache module to keep  those
> difficult computations in a timed-cache. Now, I have attached a cache to
> each opened database. The databases can be opened for read/write  
> (single writer
> multiple readers) by any thread during the runtime. I do not want to  open
> all those db's on the filesystem. For example, our backup index may  
> consists
> of 100's of tiny databases. I can't just open them all at startup.
> Oh yes: a database is just a handful of files: datafile, index file,  
> blob file.
> 
> Hm... to be ultimately useful, it would need to be dynamic, I'm afraid.
> 
> OTOH, you need not make it 100% dynamic. You can just create caches, but
> never destroy them, for example. In our app, the name of the cache is
> bound to a file-name (i.e. directory where db files live). This does not
> change over lifetime.
> 
> 
> Cheers
> Zoran
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

[naviserver-devel] vfs packages

[Zoran V. <zv...@ar...>]

Apropos VFS'es...

This looks promising indeed:

    http://math.nist.gov/~DPorter/tcltk/trofs/

Now that we are VFS clean, we could take advantage
of those things.

I'm also going to look at tclvfs which is a similar
beast but with different filesystem backends written
in plain Tcl. Also an interesting idea...

    http://sourceforge.net/projects/tclvfs

We would like to stuff pretty much everything into
such archives as this simplifies our distribution.
Moreover, we can serve pages directly out of the thing.
And because *we* can cache it on the fly, the performance
should be no issue, I believe.

Cheers
Zoran

Re: [naviserver-devel] ns_cache

[Zoran V. <zv...@ar...>]

Am 22.10.2005 um 15:51 schrieb Stephen Deasey:

> On 10/22/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
>>
>> Am 21.10.2005 um 15:19 schrieb Vlad Seryakov:
>>
>>
>>> Looks okay, API has changed but if we accept it, i suppose onetime
>>> code change is acceptable
>>>
>>>
>>
>> What about timed cache? I miss this (for us) important feature.
>>
>
>
> The existing implementation doesn't make a lot of sense to me.  You
> can create either a size limited cache, OR a time based cache.  A time
> based cache has it's entries flushed based on the mtime, i.e. only
> when they're unused.  This means popular entries will never be
> flushed.
>
> What you really want is for entries to have a max cache lifetime (ADP
> pages), possibly different for each entry (DNS lookups).


OK. This is true, indded.


>
>
>
>> Why passing the cacheTable over ClientData?
>>
>
>
> That's just because I implemented this as a module so it could be
> tested easily without patching.  A merged version would add a slot to
> the NsServer structure.

OK. This is clear.

>
>
>
>> Why not creating caches during server lifetime instead of only
>> at startup?
>>
>
>
> Locking overhead.  The current implementation doesn't lock the caches
> when for example the stats command is run, which could have the cache
> deleted out from under it, causing a crash.
>
> I did try a couple of ways to enable safe cache creation at runtime,
> including reference counting of the caches themselves.  It just seemed
> over engineered.
>
> Do you have a situation in mind where caches should be created at  
> runtime?

Oh yes... We have a database lib (Codebase) which is fast, but some  
of the
things we did there take time. Hence, I use the cache module to keep  
those
difficult computations in a timed-cache. Now, I have attached a cache to
each opened database. The databases can be opened for read/write  
(single writer
multiple readers) by any thread during the runtime. I do not want to  
open
all those db's on the filesystem. For example, our backup index may  
consists
of 100's of tiny databases. I can't just open them all at startup.
Oh yes: a database is just a handful of files: datafile, index file,  
blob file.

Hm... to be ultimately useful, it would need to be dynamic, I'm afraid.

OTOH, you need not make it 100% dynamic. You can just create caches, but
never destroy them, for example. In our app, the name of the cache is
bound to a file-name (i.e. directory where db files live). This does not
change over lifetime.


Cheers
Zoran

Re: [naviserver-devel] ns_cache

[Stephen D. <sd...@gm...>]

On 10/22/05, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 21.10.2005 um 15:19 schrieb Vlad Seryakov:
>
> > Looks okay, API has changed but if we accept it, i suppose onetime
> > code change is acceptable
> >
>
> What about timed cache? I miss this (for us) important feature.


The existing implementation doesn't make a lot of sense to me.  You
can create either a size limited cache, OR a time based cache.  A time
based cache has it's entries flushed based on the mtime, i.e. only
when they're unused.  This means popular entries will never be
flushed.

What you really want is for entries to have a max cache lifetime (ADP
pages), possibly different for each entry (DNS lookups).


> Why passing the cacheTable over ClientData?


That's just because I implemented this as a module so it could be
tested easily without patching.  A merged version would add a slot to
the NsServer structure.


> Why not creating caches during server lifetime instead of only
> at startup?


Locking overhead.  The current implementation doesn't lock the caches
when for example the stats command is run, which could have the cache
deleted out from under it, causing a crash.

I did try a couple of ways to enable safe cache creation at runtime,
including reference counting of the caches themselves.  It just seemed
over engineered.

Do you have a situation in mind where caches should be created at runtime?


> I guess answer to all of those is: this is a work in progress :-)
> Well, I just wanted to put those on the table so we know what
> is still left to do?
>
> What I miss: what is the main benefit of nscache2/cache2 over
> the existing nsache/cache?


The user of this code never has to do any locking.  The required
locking is extremely difficult, in my opinion.

The API is smaller, but also more functional.  It's easy to get right.

Couple of extra features: built in reference counting of entries,
support for per-thread caches, etc.

Re: [naviserver-devel] PACKAGE, VERSION collision

[Zoran V. <zv...@ar...>]

Am 22.10.2005 um 15:20 schrieb Stephen Deasey:
>
> How about this:
>
> Rename nsconfig.h -> config.h and don't install it.
> Include it explicitly where it's needed, not via ns.h.
> Create nsversion.h to hold version info, install it.

Yes. This stops the blues.

>
> This would mean that the results of configuration probing are not
> available to modules, but I'd like to move towards having modules run
> their own configure scripts, a bit like TEA.  Is anyone depending on
> this?

Yes. Modules should do somethig similar Tcl modules are doing.
This is well-known and (well) tested and understood. This way
the module writer may/should/must perform his own specific configure
step.


Cheers
Zoran

Re: [naviserver-devel] PACKAGE, VERSION collision

[Stephen D. <sd...@gm...>]

On 10/21/05, Zoran Vasiljevic <zv...@ar...> wrote:
> Hi!
>
> I do not know how to resolve those...
>
> Normally, I have a Tcl module (built with TEA) and would like
> to link it together with NS. It complains about PACKAGE and
> VERSION already being defined in nsconfig.h... Bad thing is
> that I use those things in my C-code so whenever I load
> nsconfig.h, it re-defines them :-(
>
> Using TEA, you get all those things defined on the command line:
>
> gcc -pipe -DTCL_THREADS=3D1 -DUSE_THREAD_ALLOC=3D1 -D_REENTRANT=3D1 -
> D_THREAD_SAFE=3D1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=3D1 -
> DHAVE_PTHREAD_ATFORK=3D1 -DHAVE_READDIR_R=3D1 -
> DHAVE_THREE_ARG_READDIR_R=3D1 -DHAVE_LIBKERN_OSATOMIC_H=3D1 -
> DHAVE_OSSPINLOCKLOCK=3D1 -DMAC_OSX_TCL=3D1 -DUSE_VFORK=3D1 -
> DTCL_DEFAULT_ENCODING=3D\"utf-8\" -DTCL_LOAD_FROM_MEMORY=3D1 -
> DTCL_WIDE_INT_TYPE=3Dlong\ long -DWORDS_BIGENDIAN=3D1 -DHAVE_GETCWD=3D1 -
> DHAVE_OPENDIR=3D1 -DHAVE_STRSTR=3D1 -DHAVE_STRTOL=3D1 -DHAVE_STRTOLL=3D1 =
-
> DHAVE_STRTOULL=3D1 -DHAVE_TMPNAM=3D1 -DHAVE_WAITPID=3D1 -DNO_VALUES_H=3D1=
 -
> DHAVE_LIMITS_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_SYS_PARAM_H=3D1 -
> DUSE_TERMIOS=3D1 -DHAVE_SYS_TIME_H=3D1 -DTIME_WITH_SYS_TIME=3D1 -
> DHAVE_TM_ZONE=3D1 -DHAVE_GMTIME_R=3D1 -DHAVE_LOCALTIME_R=3D1 -
> DHAVE_TM_GMTOFF=3D1 -DHAVE_ST_BLKSIZE=3D1 -DSTDC_HEADERS=3D1 -
> DHAVE_SIGNED_CHAR=3D1 -DHAVE_PUTENV_THAT_COPIES=3D1 -DHAVE_LANGINFO=3D1 -
> DHAVE_SYS_IOCTL_H=3D1 -DHAVE_SYS_FILIO_H=3D1  -DTCL_WIDE_INT_TYPE=3Dlong\
> long -DNO_VALUES_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_SYS_PARAM_H=3D1 -DVERSI=
ON=3D
> \"0.2\" -DPACKAGE=3D\"archdev\" -DUSE_THREAD_ALLOC=3D1 -D_REENTRANT=3D1 -
> D_THREAD_SAFE=3D1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=3D1 -DHAVE_READDIR_R=
=3D1
> -DTCL_THREADS=3D1 -DUSE_TCL_STUBS=3D1 -DNS_AOLSERVER=3D1   -arch ppc -pip=
e -
> I"/usr/local/include" -DNO_CONST -I../generic -I/Users/zoran/dev/
> libmacbinary/generic -I/Users/zoran/dev/libarchdev/generic -I/Users/
> zoran/dev/findutils-4.1/find -g  -fno-common -g  -fno-common -I/usr/
> local/aolserver/include -c `echo tclp_bg.c` -o tclp_bg.o
>
>      -DVERSION=3D\"0.2\"
>      -DPACKAGE=3D\"archdev\"
>
> Now, as I understand, those symbols are defined by autoconf
> automatically.
>
> Does anybody have any idea how to get out of this blues?
> At the moment, I have to edit the nsconfig.h and remove
> lines definig PACKAGE and VERSION but I assume this is
> not the most elegant and fail-safe way...
>
> Another blues: the new TEA (3.3) uses PACKAGE_NAME and
> PACKAGE_VERSION (obviously because of the above reason)
> but NS uses them AS WELL since it also uses TEA!
> My god, what a mess...


How about this:

Rename nsconfig.h -> config.h and don't install it.
Include it explicitly where it's needed, not via ns.h.
Create nsversion.h to hold version info, install it.

This would mean that the results of configuration probing are not
available to modules, but I'd like to move towards having modules run
their own configure scripts, a bit like TEA.  Is anyone depending on
this?

Generating nsversion.h feels better to me than running ns.h through configu=
re.

Re: [naviserver-devel] Trace errors

[Stephen D. <sd...@gm...>]

I just grepped through all the modules on SF and couldn't find any
calls to NS_TCL_TRACE_CEALLOCATE (or Ns_TclRegisterAtCleanup).

Make sure you're running the latest CVS.  I fixed a bug in nsdb which
causes this log message a couple of days ago.


On 10/21/05, Vlad Seryakov <vl...@cr...> wrote:
> I this NS_TCL_TRACE_DEALLOCATE is used to delay delallocation of
> interps, i do not explicitely register any traces.
>
>
> Stephen Deasey wrote:
> > On 10/21/05, Vlad Seryakov <vl...@cr...> wrote:
> >
> >>[21/Oct/2005:09:30:55][8454.3004771248][-thread-1290196048-] Error: Can
> >>not register Tcl trace, server already started.
> >>
> >>The trace which is called is NS_TCL_TRACE_DEALLOCATE
> >
> >
> >
> > This has been the case for quite a while, it just never used to log an
> > error (which is why the bug in nsdb went unnoticed).
> >
> > The trace api is limited to pre-start up because the locking would be
> > a pain.  It's possible for example for a Tcl trace callback to add
> > another trace, causing a deadlock if we don't use something like a
> > critical section, which seems a little over the top.
> >
> > Which code is trying to register a trace, and why?
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads, discussion=
s,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > naviserver-devel mailing list
> > nav...@li...
> > https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
> --
> Vlad Seryakov
> 571 262-8608 office
> vl...@cr...
> http://www.crystalballinc.com/vlad/
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] ns_cache

[Zoran V. <zv...@ar...>]

Am 21.10.2005 um 15:19 schrieb Vlad Seryakov:

> Looks okay, API has changed but if we accept it, i suppose onetime  
> code change is acceptable
>

What about timed cache? I miss this (for us) important feature.
Why passing the cacheTable over ClientData?
Why not creating caches during server lifetime instead of only
at startup?

I guess answer to all of those is: this is a work in progress :-)
Well, I just wanted to put those on the table so we know what
is still left to do?

What I miss: what is the main benefit of nscache2/cache2 over
the existing nsache/cache?

Zoran

[naviserver-devel] Test milestone

[Stephen D. <sd...@gm...>]

Tests ended at Sat Oct 22 06:46:36 AM MDT 2005
all.tcl:        Total   500     Passed  500     Skipped 0       Failed  0

Re: [naviserver-devel] ctrl-c not blocked during startup

[Zoran V. <zv...@ar...>]

Am 21.10.2005 um 21:37 schrieb Zoran Vasiljevic:

>
> The problem is that signal handling is completely messed up.
> =10Not only that it does not correctly handle the sigint, it
> also fails when opening pipes (exec) and alike. On Linux it
> breaks as well, but with core.
>
> This is very very bad...
>


Indeed, and I'm the one to blame!

The problem was:  Tcl_FindExecutable(argv[0]);

This problematic call has SIGNIFICANT side-effects.
It efefctively initializes Tcl library for the process.

Before VFS changes, this was first called way after
all signal blocking and forks we may had, so Tcl was
always initialized in a ready-to-go process.

After VFS changes, I had to move this way up, before
any file-related operation was possibly underway.
Unformtunately, after that, we were happily blocking
signals, forking etc, which totally freaked Tcl libaray.
The Tcl library itself is not safe in relation to fork
and is very picky about that.

So, eventually I will have to reorganize the nsmain.c
in respect of what is started when...

Sorry for all this confusion.

Zoran=

Re: [naviserver-devel] Trace errors

[Vlad S. <vl...@cr...>]

I this NS_TCL_TRACE_DEALLOCATE is used to delay delallocation of 
interps, i do not explicitely register any traces.


Stephen Deasey wrote:
> On 10/21/05, Vlad Seryakov <vl...@cr...> wrote:
> 
>>[21/Oct/2005:09:30:55][8454.3004771248][-thread-1290196048-] Error: Can
>>not register Tcl trace, server already started.
>>
>>The trace which is called is NS_TCL_TRACE_DEALLOCATE
> 
> 
> 
> This has been the case for quite a while, it just never used to log an
> error (which is why the bug in nsdb went unnoticed).
> 
> The trace api is limited to pre-start up because the locking would be
> a pain.  It's possible for example for a Tcl trace callback to add
> another trace, causing a deadlock if we don't use something like a
> critical section, which seems a little over the top.
> 
> Which code is trying to register a trace, and why?
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] Trace errors

[Stephen D. <sd...@gm...>]

On 10/21/05, Vlad Seryakov <vl...@cr...> wrote:
>
> [21/Oct/2005:09:30:55][8454.3004771248][-thread-1290196048-] Error: Can
> not register Tcl trace, server already started.
>
> The trace which is called is NS_TCL_TRACE_DEALLOCATE


This has been the case for quite a while, it just never used to log an
error (which is why the bug in nsdb went unnoticed).

The trace api is limited to pre-start up because the locking would be
a pain.  It's possible for example for a Tcl trace callback to add
another trace, causing a deadlock if we don't use something like a
critical section, which seems a little over the top.

Which code is trying to register a trace, and why?

Re: [naviserver-devel] ctrl-c not blocked during startup

[Vlad S. <vl...@cr...>]

On Linux it exits and NsRestoreSignals sets all handlers back to SIG_DFL 
which makes it exit on sigint

Zoran Vasiljevic wrote:
> 
> Am 21.10.2005 um 21:23 schrieb Zoran Vasiljevic:
> 
>>
>> Am 21.10.2005 um 21:19 schrieb Vlad Seryakov:
>>
>>
>>>     if (mode == 'c') {
>>>         /*
>>>          * Initialize Tcl and start interpreting commands.
>>>          * This function never returns, so no clean shutdown.
>>>          */
>>>
>>>         NsRestoreSignals();
>>>
>>>
>>
>> No, this is totally unrelated.
>> See my other email.
> 
> 
> 
> The problem is that signal handling is completely messed up.
> Not only that it does not correctly handle the sigint, it
> also fails when opening pipes (exec) and alike. On Linux it
> breaks as well, but with core.
> 
> This is very very bad...
> 
> Zoran
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] ctrl-c not blocked during startup

[Zoran V. <zv...@ar...>]

Am 21.10.2005 um 21:23 schrieb Zoran Vasiljevic:

>
> Am 21.10.2005 um 21:19 schrieb Vlad Seryakov:
>
>
>>     if (mode =3D=3D 'c') {
>>         /*
>>          * Initialize Tcl and start interpreting commands.
>>          * This function never returns, so no clean shutdown.
>>          */
>>
>>         NsRestoreSignals();
>>
>>
>
> No, this is totally unrelated.
> See my other email.


The problem is that signal handling is completely messed up.
=10Not only that it does not correctly handle the sigint, it
also fails when opening pipes (exec) and alike. On Linux it
breaks as well, but with core.

This is very very bad...

Zoran

Re: [naviserver-devel] ctrl-c not blocked during startup

[Zoran V. <zv...@ar...>]

Am 21.10.2005 um 21:19 schrieb Vlad Seryakov:

>     if (mode == 'c') {
>         /*
>          * Initialize Tcl and start interpreting commands.
>          * This function never returns, so no clean shutdown.
>          */
>
>         NsRestoreSignals();
>

No, this is totally unrelated.
See my other email.

Zoran

Re: [naviserver-devel] ctrl-c not blocked during startup

[Zoran V. <zv...@ar...>]

Am 21.10.2005 um 21:00 schrieb Zoran Vasiljevic:

>
> Am 21.10.2005 um 19:41 schrieb Zoran Vasiljevic:
>
>
>> Hi !
>>
>> Another one... (maybe I broke that?)
>> During the interactive startup server can be killed
>> by simple ctrl-c. I will have to see why...
>>
>>

On Linux if does not break. So there was something changed
in this respect but I do not know what. In any case, Solaris
and Mac OS X are broken, whereas Linux performs apparently OK.

Stephen, did you change something related to signal handling?

Zoran

Re: [naviserver-devel] ctrl-c not blocked during startup

[Vlad S. <vl...@cr...>]

     if (mode == 'c') { 

         /* 

          * Initialize Tcl and start interpreting commands. 

          * This function never returns, so no clean shutdown. 

          */ 

 

         NsRestoreSignals(); 



Zoran Vasiljevic wrote:
> 
> Am 21.10.2005 um 19:41 schrieb Zoran Vasiljevic:
> 
>> Hi !
>>
>> Another one... (maybe I broke that?)
>> During the interactive startup server can be killed
>> by simple ctrl-c. I will have to see why...
>>
> 
> Hm... this is a very serious thing... NsBlockSignals
> seems to block the SIGINT but the process does not
> seem to care... I do not understand this at all.
> I can repeat this on Solaris and Darwin. The 4.99.0
> works fine in this respect. So something has changed
> radically here. Can you verify on your installation?
> Just add "after 50000" somewhwere in the bin/init.tcl,
> hit the server interactively in the foreground and
> before it finished startup hit ctrl-c.
> 
> Zoran
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] ctrl-c not blocked during startup

[Zoran V. <zv...@ar...>]

Am 21.10.2005 um 19:41 schrieb Zoran Vasiljevic:

> Hi !
>
> Another one... (maybe I broke that?)
> During the interactive startup server can be killed
> by simple ctrl-c. I will have to see why...
>

Hm... this is a very serious thing... NsBlockSignals
seems to block the SIGINT but the process does not
seem to care... I do not understand this at all.
I can repeat this on Solaris and Darwin. The 4.99.0
works fine in this respect. So something has changed
radically here. Can you verify on your installation?
Just add "after 50000" somewhwere in the bin/init.tcl,
hit the server interactively in the foreground and
before it finished startup hit ctrl-c.

Zoran

[naviserver-devel] ctrl-c not blocked during startup

[Zoran V. <zv...@ar...>]

Hi !

Another one... (maybe I broke that?)
During the interactive startup server can be killed
by simple ctrl-c. I will have to see why...

Zoran

Re: [naviserver-devel] PACKAGE, VERSION collision

[Zoran V. <zv...@ar...>]

Am 21.10.2005 um 17:42 schrieb Vlad Seryakov:

> Can we use NS_VERSION and NS_PACKAGE instead in nsconfig.h?
>

Well I think not that easy:

(configure.in)
AC_INIT(NaviServer, 4.99.1, nav...@li...)
AC_CONFIG_SRCDIR(include/ns.h)
AC_CONFIG_HEADER(include/nsconfig.h)
AC_PREREQ(2.50)
AC_REVISION($Revision: 1.15 $)
AM_INIT_AUTOMAKE


(aclocal.m4)
# AM_INIT_AUTOMAKE(PACKAGE, VERSION, [NO-DEFINE])
# AM_INIT_AUTOMAKE([OPTIONS])
# -----------------------------------------------
# The call with PACKAGE and VERSION arguments is the old style
# call (pre autoconf-2.50), which is being phased out.  PACKAGE
# and VERSION should now be passed to AC_INIT and removed from
# the call to AM_INIT_AUTOMAKE.
# We support both call styles for the transition.  After
# the next Automake release, Autoconf can make the AC_INIT
# arguments mandatory, and then we can depend on a new Autoconf
# release and drop the old call support.


I believe autoconf defines those automatically when you call AC_INIT.
The way we now generate headers (autoheader), it gets included in the
nsconfig.h automatically...
I do not know the autoconf machinery enough, unfortunately.

Zoran

Re: [naviserver-devel] PACKAGE, VERSION collision

[Vlad S. <vl...@cr...>]

Can we use NS_VERSION and NS_PACKAGE instead in nsconfig.h?

Zoran Vasiljevic wrote:
> Hi!
> 
> I do not know how to resolve those...
> 
> Normally, I have a Tcl module (built with TEA) and would like
> to link it together with NS. It complains about PACKAGE and
> VERSION already being defined in nsconfig.h... Bad thing is
> that I use those things in my C-code so whenever I load
> nsconfig.h, it re-defines them :-(
> 
> Using TEA, you get all those things defined on the command line:
> 
> gcc -pipe -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 - 
> D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 - 
> DHAVE_PTHREAD_ATFORK=1 -DHAVE_READDIR_R=1 - DHAVE_THREE_ARG_READDIR_R=1 
> -DHAVE_LIBKERN_OSATOMIC_H=1 - DHAVE_OSSPINLOCKLOCK=1 -DMAC_OSX_TCL=1 
> -DUSE_VFORK=1 - DTCL_DEFAULT_ENCODING=\"utf-8\" -DTCL_LOAD_FROM_MEMORY=1 
> - DTCL_WIDE_INT_TYPE=long\ long -DWORDS_BIGENDIAN=1 -DHAVE_GETCWD=1 - 
> DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 - 
> DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DNO_VALUES_H=1 - 
> DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 - DUSE_TERMIOS=1 
> -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 - DHAVE_TM_ZONE=1 
> -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 - DHAVE_TM_GMTOFF=1 
> -DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 - DHAVE_SIGNED_CHAR=1 
> -DHAVE_PUTENV_THAT_COPIES=1 -DHAVE_LANGINFO=1 - DHAVE_SYS_IOCTL_H=1 
> -DHAVE_SYS_FILIO_H=1  -DTCL_WIDE_INT_TYPE=long\  long -DNO_VALUES_H=1 
> -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DVERSION= \"0.2\" 
> -DPACKAGE=\"archdev\" -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 - 
> D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_READDIR_R=1  
> -DTCL_THREADS=1 -DUSE_TCL_STUBS=1 -DNS_AOLSERVER=1   -arch ppc -pipe - 
> I"/usr/local/include" -DNO_CONST -I../generic -I/Users/zoran/dev/ 
> libmacbinary/generic -I/Users/zoran/dev/libarchdev/generic -I/Users/ 
> zoran/dev/findutils-4.1/find -g  -fno-common -g  -fno-common -I/usr/ 
> local/aolserver/include -c `echo tclp_bg.c` -o tclp_bg.o
> 
>     -DVERSION=\"0.2\"
>     -DPACKAGE=\"archdev\"
> 
> Now, as I understand, those symbols are defined by autoconf
> automatically.
> 
> Does anybody have any idea how to get out of this blues?
> At the moment, I have to edit the nsconfig.h and remove
> lines definig PACKAGE and VERSION but I assume this is
> not the most elegant and fail-safe way...
> 
> Another blues: the new TEA (3.3) uses PACKAGE_NAME and
> PACKAGE_VERSION (obviously because of the above reason)
> but NS uses them AS WELL since it also uses TEA!
> My god, what a mess...
> 
> Zoran
>  
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

[naviserver-devel] PACKAGE, VERSION collision

[Zoran V. <zv...@ar...>]

Hi!

I do not know how to resolve those...

Normally, I have a Tcl module (built with TEA) and would like
to link it together with NS. It complains about PACKAGE and
VERSION already being defined in nsconfig.h... Bad thing is
that I use those things in my C-code so whenever I load
nsconfig.h, it re-defines them :-(

Using TEA, you get all those things defined on the command line:

gcc -pipe -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 - 
D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 - 
DHAVE_PTHREAD_ATFORK=1 -DHAVE_READDIR_R=1 - 
DHAVE_THREE_ARG_READDIR_R=1 -DHAVE_LIBKERN_OSATOMIC_H=1 - 
DHAVE_OSSPINLOCKLOCK=1 -DMAC_OSX_TCL=1 -DUSE_VFORK=1 - 
DTCL_DEFAULT_ENCODING=\"utf-8\" -DTCL_LOAD_FROM_MEMORY=1 - 
DTCL_WIDE_INT_TYPE=long\ long -DWORDS_BIGENDIAN=1 -DHAVE_GETCWD=1 - 
DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 - 
DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DNO_VALUES_H=1 - 
DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 - 
DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 - 
DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 - 
DHAVE_TM_GMTOFF=1 -DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 - 
DHAVE_SIGNED_CHAR=1 -DHAVE_PUTENV_THAT_COPIES=1 -DHAVE_LANGINFO=1 - 
DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_FILIO_H=1  -DTCL_WIDE_INT_TYPE=long\  
long -DNO_VALUES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DVERSION= 
\"0.2\" -DPACKAGE=\"archdev\" -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 - 
D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_READDIR_R=1  
-DTCL_THREADS=1 -DUSE_TCL_STUBS=1 -DNS_AOLSERVER=1   -arch ppc -pipe - 
I"/usr/local/include" -DNO_CONST -I../generic -I/Users/zoran/dev/ 
libmacbinary/generic -I/Users/zoran/dev/libarchdev/generic -I/Users/ 
zoran/dev/findutils-4.1/find -g  -fno-common -g  -fno-common -I/usr/ 
local/aolserver/include -c `echo tclp_bg.c` -o tclp_bg.o

     -DVERSION=\"0.2\"
     -DPACKAGE=\"archdev\"

Now, as I understand, those symbols are defined by autoconf
automatically.

Does anybody have any idea how to get out of this blues?
At the moment, I have to edit the nsconfig.h and remove
lines definig PACKAGE and VERSION but I assume this is
not the most elegant and fail-safe way...

Another blues: the new TEA (3.3) uses PACKAGE_NAME and
PACKAGE_VERSION (obviously because of the above reason)
but NS uses them AS WELL since it also uses TEA!
My god, what a mess...

Zoran
  

[naviserver-devel] Trace errors

[Vlad S. <vl...@cr...>]

[21/Oct/2005:09:30:55][8454.3004771248][-thread-1290196048-] Error: Can 
not register Tcl trace, server already started.

The trace which is called is NS_TCL_TRACE_DEALLOCATE

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/