naviserver-devel — Developer discussion

Re: [naviserver-devel] Naviserver hangs on Windows

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

Stephen,

the Docker image is cool stuff! Many thanks!
This eases mingw builds significantly.

It compiles now fine the first bunch of files in nsthread 
fine, but stops then with

x86_64-w64-mingw32-gcc -shared -L../nsthread -L../nsd 
-L../nsdb -o libnsthread.dll error.o master.o memory.o 
mutex.o cslock.o rwlock.o reentrant.o sema.o thread.o tls.o 
time.o pthread.o fork.o signal.o winthread.o   
-L/usr/local/tcl8.6.2-mingw/lib -ltcl86 -lnetapi32 
-lkernel32 -luser32 -ladvapi32 -lws2_32 
-L/usr/local/tcl8.6.2-mingw/lib
/usr/lib64/gcc/x86_64-w64-mingw32/4.8.3/../../../../x86_64-w64-mingw32/bin/ld: 
cannot find -ltcl86
collect2: error: ld returned 1 exit status
make[1]: *** [libnsthread.dll] Error 1

Looks like the installation of tcl is missing...

-g

On 07.10.14 00:33, Stephen wrote:
> Here are some build errors while cross-compiling with 
> mingw using this docker image:
>
> https://bitbucket.org/groks/build-naviserver-mingw/src/tip/naviserver/
>
>

Re: [naviserver-devel] status of the three main early developers?

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

Hi!

I am closely monitoring all that is happening.
We have significant investment in NS. For the
time being we run our own stable copy because
of the sensitivity of our application. But we
sync up every now and then, if needed.

Stephen is still arround and keeping an
eye on all changes.

IIRC, Vlad is pursuing other activities.

Cheers,
Zoran

#
On 07 Oct 2014, at 01:57, Andrew Piskorski <at...@pi...> wrote:

> As I recall, Stephen Deasey, Zoran Vasiljevic, and Vlad Seryakov were
> the three developers who originally forked the Naviserver project from
> AOLserver 4.0.10 and then did nearly all of the subsequent work on it
> for years.  But I haven't heard from them much lately.  I'm curious,
> are they still actively using and working on Naviserver, or (like Jim
> Davidson), have they mostly moved on to other projects?
> 
> -- 
> Andrew Piskorski <at...@pi...>
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

[naviserver-devel] status of the three main early developers?

[Andrew P. <at...@pi...>]

As I recall, Stephen Deasey, Zoran Vasiljevic, and Vlad Seryakov were
the three developers who originally forked the Naviserver project from
AOLserver 4.0.10 and then did nearly all of the subsequent work on it
for years.  But I haven't heard from them much lately.  I'm curious,
are they still actively using and working on Naviserver, or (like Jim
Davidson), have they mostly moved on to other projects?

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Naviserver hangs on Windows

[Andrew P. <at...@pi...>]

On Mon, Oct 06, 2014 at 11:33:25PM +0100, Stephen wrote:

> Here are some build errors while cross-compiling with mingw using this
> docker image:
> 
>   https://bitbucket.org/groks/build-naviserver-mingw/src/tip/naviserver/

The docker image sounds useful.  However, building with Mingw on
Windows would use the Unix makefiles.  I've never tested that build
combination and doubt that anyone else has done so recently either.
Right now I'm focused on just getting Windows builds to work with
nmake and MSVC.  Mingw can come later, especially since it (at least
currently) and MSVC are tied to different build systems.

It would be nice to eventually adopt a single build system that would
work well with all combinations of platforms and compilers, but
discussing that seems somewhat premature.

Btw, the pages below on Tcl-based replacements for make and autoconf
are interesting, especially in that it should be feasible to have
**Tcl itself** self-host on such tools, while avoiding the
chicken-and-egg problem:

  http://wiki.tcl.tk/27561
  http://wiki.tcl.tk/27197
  http://wiki.tcl.tk/12593

But I'd want get the opinion of the Tcl core team and other experts
before going very far down such a path, either for Naviserver or in my
own code.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Naviserver hangs on Windows

[Stephen <yo...@gr...>]

On Mon, Oct 6, 2014 at 10:31 PM, Gustaf Neumann <ne...@wu...> wrote:
>
> I've merged in your changes to the main branch.

Here are some build errors while cross-compiling with mingw using this
docker image:

  https://bitbucket.org/groks/build-naviserver-mingw/src/tip/naviserver/



---> 0eaa9093aff9
Removing intermediate container 4d4d06c9d5b4
Step 8 : RUN PATH=/usr/x86_64-w64-mingw32/sys-root/mingw/bin:$PATH make all
build-doc \
    INSTALL_ROOT="/"
    STRINGS=/usr/bin/x86_64-w64-mingw32-strings
    OBJCOPY=/usr/bin/x86_64-w64-mingw32-objcopy
    NM=/usr/bin/x86_64-w64-mingw32-nm
    DLLWRAP=/usr/bin/x86_64-w64-mingw32-dllwrap
    GCC=/usr/bin/x86_64-w64-mingw32-gcc
    WINDRES=/usr/bin/x86_64-w64-mingw32-windres
    ADDR2LINE=/usr/bin/x86_64-w64-mingw32-addr2line
    AS=/usr/bin/x86_64-w64-mingw32-as
    PKG_CONFIG=/usr/bin/x86_64-w64-mingw32-pkg-config
    CPP=/usr/bin/x86_64-w64-mingw32-cpp
    ELFEDIT=/usr/bin/x86_64-w64-mingw32-elfedit
    HOST_CC=gcc
    LD=/usr/bin/x86_64-w64-mingw32-ld
    DLLTOOL=/usr/bin/x86_64-w64-mingw32-dlltool
    AR=/usr/bin/x86_64-w64-mingw32-ar
    SIZE=/usr/bin/x86_64-w64-mingw32-size
    WINDMC=/usr/bin/x86_64-w64-mingw32-windmc
    GPROF=/usr/bin/x86_64-w64-mingw32-gprof
    RANLIB=/usr/bin/x86_64-w64-mingw32-ranlib
    CXXFILT=/usr/bin/x86_64-w64-mingw32-c++filt
    GCOV=/usr/bin/x86_64-w64-mingw32-gcov
    CC=x86_64-w64-mingw32-gcc
    READELF=/usr/bin/x86_64-w64-mingw32-readelf
    OBJDUMP=/usr/bin/x86_64-w64-mingw32-objdump
    STRIP=/usr/bin/x86_64-w64-mingw32-strip
    LD_BFD=/usr/bin/x86_64-w64-mingw32-ld.bfd

---> Running in ed1e545df7f9
make[1]: Entering directory `/usr/local/src/naviserver-tip/nsthread'
x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include
-I"/usr/local/tcl8.6.2-mingw/include"  -DHAVE_CONFIG_H   -c -o error.o
error.c
In file included from thread.h:40:0,
                 from error.c:37:
../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default]
 # define lseek                       _lseek
 ^

In file included from ../include/nsthread.h:107:0,
                 from thread.h:40,
                 from error.c:37:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is
the location of the previous definition
 #define lseek lseek64
 ^
x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include
-I"/usr/local/tcl8.6.2-mingw/include"  -DHAVE_CONFIG_H   -c -o master.o
master.c

In file included from thread.h:40:0,
                 from master.c:36:
../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default]
 # define lseek                       _lseek
 ^

In file included from ../include/nsthread.h:107:0,
                 from thread.h:40,
                 from master.c:36:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is
the location of the previous definition
 #define lseek lseek64
 ^

x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include
-I"/usr/local/tcl8.6.2-mingw/include"  -DHAVE_CONFIG_H   -c -o memory.o
memory.c
In file included from thread.h:40:0,
                 from memory.c:36:
../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default]
 # define lseek                       _lseek
 ^

In file included from ../include/nsthread.h:107:0,
                 from thread.h:40,
                 from memory.c:36:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is
the location of the previous definition
 #define lseek lseek64
 ^

x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include
-I"/usr/local/tcl8.6.2-mingw/include"  -DHAVE_CONFIG_H   -c -o mutex.o
mutex.c
In file included from thread.h:40:0,
                 from mutex.c:36:
../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default]
 # define lseek                       _lseek
 ^

In file included from ../include/nsthread.h:107:0,
                 from thread.h:40,
                 from mutex.c:36:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is
the location of the previous definition
 #define lseek lseek64
 ^

x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include
-I"/usr/local/tcl8.6.2-mingw/include"  -DHAVE_CONFIG_H   -c -o cslock.o
cslock.c
In file included from thread.h:40:0,
                 from cslock.c:47:
../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default]
 # define lseek                       _lseek
 ^

In file included from ../include/nsthread.h:107:0,
                 from thread.h:40,
                 from cslock.c:47:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is
the location of the previous definition
 #define lseek lseek64
 ^

x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include
-I"/usr/local/tcl8.6.2-mingw/include"  -DHAVE_CONFIG_H   -c -o rwlock.o
rwlock.c
In file included from thread.h:40:0,
                 from rwlock.c:48:
../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default]
 # define lseek                       _lseek
 ^

In file included from ../include/nsthread.h:107:0,
                 from thread.h:40,
                 from rwlock.c:48:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is
the location of the previous definition
 #define lseek lseek64
 ^

x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include
-I"/usr/local/tcl8.6.2-mingw/include"  -DHAVE_CONFIG_H   -c -o reentrant.o
reentrant.c
In file included from thread.h:40:0,
                 from reentrant.c:38:
../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default]
 # define lseek                       _lseek
 ^

In file included from ../include/nsthread.h:107:0,
                 from thread.h:40,
                 from reentrant.c:38:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is
the location of the previous definition
 #define lseek lseek64
 ^

reentrant.c: In function 'ns_ctime':

reentrant.c:116:5: warning: implicit declaration of function 'ctime_s'
[-Wimplicit-function-declaration]
     ctime_s(tlsPtr->ctbuf, sizeof(tlsPtr->ctbuf), clock);
     ^

x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include
-I"/usr/local/tcl8.6.2-mingw/include"  -DHAVE_CONFIG_H   -c -o sema.o sema.c
In file included from thread.h:40:0,
                 from sema.c:40:
../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default]
 # define lseek                       _lseek
 ^

In file included from ../include/nsthread.h:107:0,
                 from thread.h:40,
                 from sema.c:40:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is
the location of the previous definition
 #define lseek lseek64
 ^

x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include
-I"/usr/local/tcl8.6.2-mingw/include"  -DHAVE_CONFIG_H   -c -o thread.o
thread.c
In file included from thread.h:40:0,
                 from thread.c:37:
../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default]
 # define lseek                       _lseek
 ^

In file included from ../include/nsthread.h:107:0,
                 from thread.h:40,
                 from thread.c:37:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is
the location of the previous definition
 #define lseek lseek64
 ^

x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include
-I"/usr/local/tcl8.6.2-mingw/include"  -DHAVE_CONFIG_H   -c -o tls.o tls.c
In file included from thread.h:40:0,
                 from tls.c:38:
../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default]
 # define lseek                       _lseek
 ^

In file included from ../include/nsthread.h:107:0,
                 from thread.h:40,
                 from tls.c:38:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is
the location of the previous definition
 #define lseek lseek64
 ^

x86_64-w64-mingw32-gcc -g -O2 -fomit-frame-pointer -Wall -pipe -I../include
-I"/usr/local/tcl8.6.2-mingw/include"  -DHAVE_CONFIG_H   -c -o time.o time.c
In file included from thread.h:40:0,
                 from time.c:37:
../include/nsthread.h:168:0: warning: "lseek" redefined [enabled by default]
 # define lseek                       _lseek
 ^

In file included from ../include/nsthread.h:107:0,
                 from thread.h:40,
                 from time.c:37:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/io.h:335:0: note: this is
the location of the previous definition
 #define lseek lseek64
 ^

time.c: In function 'Ns_GetTime':

time.c:65:21: error: invalid suffix "i64" on integer constant
 #define EPOCH_BIAS  116444736000000000i64
                     ^
time.c:72:37: note: in expansion of macro 'EPOCH_BIAS'
     timePtr->sec = (time_t)((ft.i - EPOCH_BIAS) / 10000000i64);
                                     ^

time.c:72:51: error: invalid suffix "i64" on integer constant
     timePtr->sec = (time_t)((ft.i - EPOCH_BIAS) / 10000000i64);
                                                   ^
time.c:73:35: error: invalid suffix "i64" on integer constant
     timePtr->usec =(long)((ft.i / 10i64) % 1000000i64);
                                   ^
time.c:73:44: error: invalid suffix "i64" on integer constant
     timePtr->usec =(long)((ft.i / 10i64) % 1000000i64);
                                            ^

make[1]: *** [time.o] Error 1

make[1]: Leaving directory `/usr/local/src/naviserver-tip/nsthread'
make: *** [all] Error 1

Re: [naviserver-devel] Naviserver hangs on Windows

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

On 06.10.14 23:54, Andrew Piskorski wrote:
> Is my "clean" branch helpful to you, or should I get rid of it?
on the clone used for the pull request, it is easier, if no 
new branches
are introduced (at least for me).

Please something more to try: to provide some potential 
evidence for my
"too early for tcl calls" hypothesis, i've deactivated for 
the time being
the mutex time monitoring for windows, since the earliest 
calls are
from mutex calls. Can you check when possible, whether 
Tcl_GetTime()
can be used now inside Ns_GetTime()?

-g

Re: [naviserver-devel] Naviserver hangs on Windows

[Andrew P. <at...@pi...>]

On Mon, Oct 06, 2014 at 11:31:27PM +0200, Gustaf Neumann wrote:

> I've merged in your changes to the main branch. In order to keep
> your change history, i merged the changes rather than copying the
> files, but had at the end the problem to get rid the branch  "clean",
> since mercurial likes to keep branches around.

Is my "clean" branch helpful to you, or should I get rid of it?

I created that "clean" branch with that idea that you'd prefer to
merge from it rather than from my "default" branch.  But I'm new to
Mercurial and not entirely sure how useful that really is.

What I wanted is to have my "clean" branch be almost exactly the same
as my "default", but with any Andy-specific hacks removed.  So I
branched clean, and then removed my rpath hack.  (As we've previously
discussed, I need that rpath hack to work on Linux, but it's clearly
the wrong fix.  I added it only because I don't understand where the
true bug is coming from.)

In Mercurial, it doesn't seem that easy to keep two branches SLIGHTLY
different from each other.  Apparently the recommended way to "cherry
pick" changes is with "hg graft", but I did not try that, as it didn't
seem like what I really wanted in this case.  I'll see how it goes as
I do more merges across my two branches, assuming I keep the "clean"
branch around.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Naviserver hangs on Windows

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

On 06.10.14 20:15, Andrew Piskorski wrote:.
> Actually, and strangely, my Naviserver on Windows appeared to NEVER
> call gettimeofday() there, regardless of whether HAVE_GETTIMEOFDAY was
> true or false!  I tried it both ways.  I can't explain that; perhaps I
> was merely confused.
Actually, the acronym coming out of configure is

#ifdef HAVE_GETTIMEOFDAY
...
#endif

Note that the expression is true, no matter whether 
HAVE_GETTIMEOFDAY
is set to 1 or 0 ... was that maybe the problem?

> But what is much more important to me, is that running the final
> "portable" Tcl-dependent code at the end definitely triggered a
> serious bug, making Naviserver unusable.
The word "unusable" is a understatement. The problem here 
is, when
the tcl library does not work, most likely other calls to 
the tcl library
will probably fail as well.

Maybe the problem is that functions of the tcl library are 
called to early,
before it is initialized.

I've merged in your changes to the main branch. In order to keep
your change history, i merged the changes rather than 
copying the
files, but had at the end the problem to get rid the branch 
"clean",
since mercurial likes to keep branches around.

when for the clock value for localtime_s() is valid, then 
the only
problem might be the storage area, which is coming from the 
thread-local
storage. Maybe localtime_s is not happy with the provided 
address.
Switching the localtime() might work, but is only a fix for 
the symptoms.

-g

Re: [naviserver-devel] Naviserver hangs on Windows

[Andrew P. <at...@pi...>]

On Sun, Oct 05, 2014 at 09:37:39PM +0200, Maurizio Martignano wrote:
> > Did you use the define _USE_32BIT_TIME_T yes or not?

> I believe you should use it.

I haven't tried using _USE_32BIT_TIME_T yet, but I think using it
would be INCORRECT on Windows-64.

Tcl 8.5.16 does this in win/tclWinPort.h:

  #ifndef _WIN64
  /* See [Bug 3354324]: file mtime sets wrong time */ 
  #   define _USE_32BIT_TIME_T 
  #endif 

So it does NOT set _USE_32BIT_TIME_T when _WIN64 is defined.
I assume _WIN64 is always defined for 64-bit Windows.

Relevant discussion appears to be here:

  http://sourceforge.net/p/tcl/bugs/4845/
  http://sourceforge.net/p/tcl/bugs/5115/
  http://sourceforge.net/p/mingw/bugs/1973/

It looks to me like the horrible confusion about what should be done
is only for ** 32-bit ** Windows systems, especially when trying to
support multiple old and new versions of 32-bit Windows.

In contrast, 64-bit Windows seems straightforward.  And I am on 64-bit
Windows now!  So I think I should simply NEVER set "_USE_32BIT_TIME_T".
Does that sound right?

What does Tcl actually do, in practice, on 64-bit Linux and Window?
Here's a simple test, which shows that Tcl 8.5.x does indeed use a
64-bit time_t in both those cases, and that the integer values are
exactly the same on Windows and Linux, as they should be.  That
corresponds to my understanding of the code above, that Tcl NEVER sets
_USE_32BIT_TIME_T on 64-bit Windows.
 
 
# On Windows 7 64-bit, running ActiveTcl 8.5:

% info patchlevel
8.5.15
% info nameofexecutable
C:/P/Tcl85/bin/tclsh85.exe
% info sharedlibextension
.dll
% set in_l [list {1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT} {9999-12-01 00:00:00 GMT}]
{1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT} {9999-12-01 00:00:00 GMT}
% foreach ss $in_l { set tt [clock scan $ss] ; puts "$tt -> [clock format $tt -gmt 1]" }
0 -> Thu Jan 01 00:00:00 GMT 1970
2174774400 -> Wed Dec 01 00:00:00 GMT 2038
253399622400 -> Wed Dec 01 00:00:00 GMT 9999
% exit


# On Linux 64-bit, Ubuntu 12.04.3 LTS:

$ /usr/bin/tclsh8.5
% info patchlevel
8.5.11
% info nameofexecutable
/usr/bin/tclsh8.5
% info sharedlibextension
.so
% set in_l [list {1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT} {9999-12-01 00:00:00 GMT}]
{1970-01-01 00:00:00 GMT} {2038-12-01 00:00:00 GMT} {9999-12-01 00:00:00 GMT}
% foreach ss $in_l { set tt [clock scan $ss] ; puts "$tt -> [clock format $tt -gmt 1]" }
0 -> Thu Jan 01 00:00:00 GMT 1970
2174774400 -> Wed Dec 01 00:00:00 GMT 2038
253399622400 -> Wed Dec 01 00:00:00 GMT 9999
% exit

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Naviserver hangs on Windows

[Andrew P. <at...@pi...>]

On Mon, Oct 06, 2014 at 10:16:31AM -0700, Jeff Rogers wrote:

> If there is not significant performance advantage to the 
> platform-specific optimized version of Ns_GetTime over the 
> platform-independent Tcl_GetTime, is it worth it to keep the optimized 
> version?

It is very much worth it to me, at least for now, because:

One, I don't understand how the invocation of the
"platform-independent Tcl_GetTime" even works.  There is never any
explicit call to Tcl_GetTime nor any other Tcl function, and
Tcl_GetTime does not appear on the call stack.  The so-callled
"optimized" code is easier to understand.

Two, the current "platform-independent" approach locks up in my
Windows build, while the old Windows-specific code that AOLserver used
for many years does not.  I do not know why this is, but I certainly
will use the old Windows-specific code until I figure it out.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Naviserver hangs on Windows

[Andrew P. <at...@pi...>]

On Sun, Oct 05, 2014 at 09:31:31PM +0200, Gustaf Neumann wrote:

> On busy systems, Ns_GetTime() is one of the most
> frequent calls, used e.g. for mutex timings, so this makes a difference.

Yes, so it's better for performance reasons, like I said.  You may
have written that small paragraph of code from scratch, but it is
still true that inside the ifdef you added, the code calling
gettimeofday() is essentially identical to what AOLserver used for
many years.  This is all fine, I see no problems with that code.

> What i did was to extend "configure" to look, if there is gettimeofday() 

Actually, and strangely, my Naviserver on Windows appeared to NEVER
call gettimeofday() there, regardless of whether HAVE_GETTIMEOFDAY was
true or false!  I tried it both ways.  I can't explain that; perhaps I
was merely confused.

But what is much more important to me, is that running the final
"portable" Tcl-dependent code at the end definitely triggered a
serious bug, making Naviserver unusable.

> b) When Tcl_GetTime() is not working on your system than you have a
>    broken Tcl installation. Does this happen with your self-compiled tcl version?

I do not know whether Tcl_GetTime() is working correctly in ActiveTcl
8.5 on Windows 7 64-bit or not.  I will try something to verify that.
Right now all I can say for sure is that funny indirect way that
Naviserver calls Tcl_GetTime() in Ns_GetTime() fails horribly on my
Windows build.

So far I've never compiled Tcl on Windows 7 myself.  I may try that
soon to help with the debugging, but so far I've been exclusing using
ActiveTcl 8.5.  I strongly suspect that ActiveTcl is compiled
correctly, but perhaps I am somehow linking against it incorrectly, or
using incompatible build options, or something like that.

> >http://msdn.microsoft.com/en-us/library/a442x3ye.aspx
> >
> > The *tp and *clock values look like a correct time_t count of seconds
> > since the Unix epoch.  So perhaps something is wrong with the only
> > other argument ther to localtime_s():  &tlsPtr->ltbuf
> 
> The page you are citing contains the error conditions, when EINVAL
> is returned. The first argument can't be NULL, so clock must be
> invalid according to this information.

No, the clock value is not invalid, I already checked that and it is a
correct count of seconds since the Unix epoch.  The problem must lie
either in the other argument, or in something entirely separate and
out of band (e.g., build options).

> on this issue. Have you tried the suggestion of Maurizio concerning
> 
> USE_32BIT_TIME_T?

I have not tried using it yet, but maybe I should.  Previously, I
wasn't sure if Maurizio was recommending it or warning against it.  (I
see now that he recommends using it.)  My previous experience with
AOLserver 4.0.x on Windows was with 32-bit Windows, which would have
natively used 32-bit time_t.  So perhaps forcing my 64-bit build to
use 32-bit time_t would be useful.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] modules/tcl/ is empty, tcl/ is full

[Andrew P. <at...@pi...>]

On Sun, Oct 05, 2014 at 08:01:13PM +0200, Gustaf Neumann wrote:
> Am 02.10.14 23:40, schrieb Andrew Piskorski:
> >
> > Do we actually need the modules/tcl/ directory for anything now?
> yes, we need it for installing site specific tcl library files.

Ah, so presumably Naviserver's moving of its own files from
modules/tcl/ into tcl/ was in order to keep the Navisever and
site-specific tcl files separate.  Ok, that makes sense.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] NS_EXTERN set wrong on Windows?

[Andrew P. <at...@pi...>]

On Sun, Oct 05, 2014 at 07:58:34PM +0200, Gustaf Neumann wrote:

> the NS_EXPORT situation is a mess, not being able to write to the
> log file in an error situation is not really an option.

The way NS_EXPORT is defined twice, in two totally separate places, is
indeed ugly, but AFAICT, after my one initial fix to it weeks ago, it
hasn't actually had any impact on my attempts to get Naviserver
working on Windows.

> Rather than commenting out error messages, the better option is probably
> to move the ns.h include to the end and add warning lines, since reentrant.c
> contains no NS_EXTERN etc.

AFAICT, it has NEVER worked to call Ns_Log from the reentrant.c file,
not on Linux and not on Windows either.  Never.  Making it work would
be nice, but is well out of scope of my current "fix Naviserver to it
actually builds and runs on Windows" work.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Naviserver hangs on Windows

[Jeff R. <dv...@di...>]

Gustaf Neumann wrote:
> Am 06.10.14 06:46, schrieb Jeff Rogers:
>>
>> This struck me as an interesting optimization question, so I wrote a
>> quick program to test it (attached).

> This is not an interesting optimization question, since Tcl itself uses
> gettimeofday()
> (plus jumping around which might have a bad cache and locality
> influence, and some
> more copying).

I think my underlying point was missed in the measurements.

If there is not significant performance advantage to the 
platform-specific optimized version of Ns_GetTime over the 
platform-independent Tcl_GetTime, is it worth it to keep the optimized 
version?

The penalty to be paid is in problems like the current one, where the 
windows build is for some reason having problems.  On windows the 
function is delegating to Tcl_GetTime, but the system-specific bits 
confuse the issue.

Your measurements are consistent and show the relative results I 
expected.  Such is the benefit of real hardware :)  They show a small 
advantage to Ns_GetTime over Tcl_GetTime, about 1.2%.  This *is* a very 
frequently called function, but it is also pretty fast in any case. 
That's 1.2% of perhaps 5% (??  totally random guess) of overall request 
processing time.  To me, that adds up to not a lot.

A different takeaway from this benchmark is that if you are trying to 
wring every last bit of performance out of this call, it might be 
advantageous to define it as a macro (or use gcc/c99 inline declarations 
so it can be inlined and avoid the function call overhead and get to 
within a few instructions of the raw gettimeofday call (presumably 
you'll still need to copy the elements to the Ns_Time struct).

-J


>
> One cannot expect a big difference. For better reliability,
> i've increased the count. Below are 4 runs on openacs.org.
> The native call is from 8% to 20% faster (the latter one most
> probably due to external influences). The machine is a bare metal.
> Numbers will vary depending on the OS. The faster the
> system function gettimeofday() is, the bigger is the percentage
> difference.
>
> -g
>
> gustafn@openacs:~$ ./tt
> count: 100000000
> Tcl_GetTime:    3858686 usec 0.04 per
> Ns_GetTime:    3811593 usec 0.04 per
> gettimeofday:    3561367 usec 0.04 per
> gustafn@openacs:~$ ./tt
> count: 100000000
> Tcl_GetTime:    3858657 usec 0.04 per
> Ns_GetTime:    3824398 usec 0.04 per
> gettimeofday:    3563398 usec 0.04 per
> gustafn@openacs:~$ ./tt
> count: 100000000
> Tcl_GetTime:    4351765 usec 0.04 per
> Ns_GetTime:    4024717 usec 0.04 per
> gettimeofday:    3594736 usec 0.04 per
> gustafn@openacs:~$ ./tt
> count: 100000000
> Tcl_GetTime:    3864511 usec 0.04 per
> Ns_GetTime:    3831866 usec 0.04 per
> gettimeofday:    3541932 usec 0.04 per
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] Naviserver hangs on Windows

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

Am 06.10.14 06:46, schrieb Jeff Rogers:
>
> This struck me as an interesting optimization question, so I wrote a 
> quick program to test it (attached).
This is not an interesting optimization question, since Tcl itself uses 
gettimeofday()
(plus jumping around which might have a bad cache and locality 
influence, and some
more copying).

One cannot expect a big difference. For better reliability,
i've increased the count. Below are 4 runs on openacs.org.
The native call is from 8% to 20% faster (the latter one most
probably due to external influences). The machine is a bare metal.
Numbers will vary depending on the OS. The faster the
system function gettimeofday() is, the bigger is the percentage
difference.

-g

gustafn@openacs:~$ ./tt
count: 100000000
Tcl_GetTime:    3858686 usec 0.04 per
Ns_GetTime:    3811593 usec 0.04 per
gettimeofday:    3561367 usec 0.04 per
gustafn@openacs:~$ ./tt
count: 100000000
Tcl_GetTime:    3858657 usec 0.04 per
Ns_GetTime:    3824398 usec 0.04 per
gettimeofday:    3563398 usec 0.04 per
gustafn@openacs:~$ ./tt
count: 100000000
Tcl_GetTime:    4351765 usec 0.04 per
Ns_GetTime:    4024717 usec 0.04 per
gettimeofday:    3594736 usec 0.04 per
gustafn@openacs:~$ ./tt
count: 100000000
Tcl_GetTime:    3864511 usec 0.04 per
Ns_GetTime:    3831866 usec 0.04 per
gettimeofday:    3541932 usec 0.04 per

Re: [naviserver-devel] Naviserver hangs on Windows

[Jeff R. <dv...@di...>]

Gustaf Neumann wrote:

> What i did was to extend "configure" to look, if there is gettimeofday()
> available
> on the system. If it is, it bypasses the call to Tcl_GetTime() to get
> the timestamp
> via system call. On busy systems, Ns_GetTime() is one of the most
> frequent calls, used e.g. for mutex timings, so this makes a difference.
>
> The advantage of using Tcl_GetTime() is to delegate system dependencies
> to Tcl.

This struck me as an interesting optimization question, so I wrote a 
quick program to test it (attached).

The only test environment at the moment I have is a linux VPS, so 
there's bound to be random influences from virtualization and whatever 
else happens to be running on the host at the time, so the noise is 
high.  Still, I was not able to see any clear difference between 
gettimeofday(), Ns_GetTime, and Tcl_GetTime - on any given run any of 
the three was equally likely to be fastest.

time-int the program reports typically 2:1 system time:user time.

What this suggests to me is that - at least in my environment - the 
probable few hundred cycles difference in the implementations is 
completely lost to syscall and timeslice overhead or possibly cache line 
flushes, and it's not worth spending too much time worrying about it.

I'd be interested to hear anyone else's results and interpretations, or 
suggestions about how to better measure the differences in these.

-J

Re: [naviserver-devel] Naviserver hangs on Windows

[Maurizio M. <Mau...@sp...>]

I believe you should use it.

Thank you,
Maurizio


-----Original Message-----
From: Andrew Piskorski [mailto:at...@pi...] 
Sent: 05 October 2014 19:47
To: nav...@li...
Cc: Maurizio Martignano
Subject: Re: [naviserver-devel] Naviserver hangs on Windows

On Sat, Oct 04, 2014 at 04:07:27PM +0200, Maurizio Martignano wrote:
> 	What is your target? Windows 32 or Windows 64?

Windows 7, 64-bit.

> Did you use the define _USE_32BIT_TIME_T yes or not?

No I did not.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Naviserver hangs on Windows

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

Am 03.10.14 16:49, schrieb Andrew Piskorski:
> I found two relevant commits in Mercurial, from 2009 and 2012, below.
> >From those logs, it looks like what happened is that in 2009, Zoran
> removed the platform specific C code and instead made Naviserver call
> Tcl_GetTime (somehow).  Then in 2012, Gustaf added back the old
> Unix-specific gettimeofday() implementation for performance reasons.
no, i did NOT "add back the old Unix-specific gettimeofday() 
implementation".

What i did was to extend "configure" to look, if there is gettimeofday() 
available
on the system. If it is, it bypasses the call to Tcl_GetTime() to get 
the timestamp
via system call. On busy systems, Ns_GetTime() is one of the most
frequent calls, used e.g. for mutex timings, so this makes a difference.

The advantage of using Tcl_GetTime() is to delegate system dependencies
to Tcl.

What does this tell us for your situation:

a) you have most probably not HAVE_GETTIMEOFDAY defined in your
   installation, otherwise you have an unresolved external. So, you were
   not at all affected by this change of mine!

b) When Tcl_GetTime() is not working on your system than you have a
   broken Tcl installation. Does this happen with your self-compiled tcl 
version?

In some later mail, you wrote:

>  ./include/nsconfig.h:276:#define SIZEOF_TIME_T 8
>
> That nsconfig.h was created on Linux, but my Windows build uses it
> too.  Perhaps that is the problem?  But how the heck can I generate a
> correct version of nsconfig.h for my Windows 7 system?

I have not checked the details of your changes, but as a background:

If one compiles naviserver with -DHAVE_CONFIG_H (the normal case under 
unix-like systems),
then ./include/nsconfig.h is used. For MSVC is a set minimal set of 
hard-coded
replacement defines included, which might or might not be incomplete or 
requires
win7 or 64bit changes. If you are including ./include/nsconfig.h 
(generated under linux)
under windows, then you are doomed.

> So in LogTime(), I added some simple printf's just before calling
> strftime().  ptm->tm_mday and all the other struct members have a
> value of -1.  That's because in ns_localtime(), localtime_s() returns
> an EINVAL = 22 "Invalid argument" error code, and then sets all the
> members to -1.
>
>http://msdn.microsoft.com/en-us/library/a442x3ye.aspx
>
> The *tp and *clock values look like a correct time_t count of seconds
> since the Unix epoch.  So perhaps something is wrong with the only
> other argument ther to localtime_s():  &tlsPtr->ltbuf

The page you are citing contains the error conditions, when EINVAL
is returned. The first argument can't be NULL, so clock must be
invalid according to this information.


you might check for testing localtime() as a replacement,
but read as well in the manpage aboutUSE_32BIT_TIME_T
     http://msdn.microsoft.com/en-us/library/bf12f0hc.aspx

I am not familiar with the TIME_T mess under windows, check as well
the endless discussions on

http://sourceforge.net/p/mingw/bugs/1973/?page=0

on this issue. Have you tried the suggestion of Maurizio concerning

USE_32BIT_TIME_T?

-g

Re: [naviserver-devel] modules/tcl/ is empty, tcl/ is full

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

Am 02.10.14 23:40, schrieb Andrew Piskorski:
>
> Do we actually need the modules/tcl/ directory for anything now?
yes, we need it for installing site specific tcl library files.

-g

Re: [naviserver-devel] NS_EXTERN set wrong on Windows?

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

sorry for the slow replies, but i was down for a couple of days.
the compatibility changes for windows are far from being finished.  the
NS_EXPORT situation is a mess, not being able to write to the log file
in an error situation is not really an option.

Rather than commenting out error messages, the better option is probably
to move the ns.h include to the end and add warning lines, since reentrant.c
contains no NS_EXTERN etc.

i would not be surprised, if the same problem shows under windows as
well in some modules.

-g





Am 01.10.14 21:12, schrieb Andrew Piskorski:
> On Wed, Sep 17, 2014 at 06:50:08PM -0400, Andrew Piskorski wrote:
>
>> include/ns.h has this:
>>
>>    #define NS_EXTERN                  extern NS_EXPORT
>>
>> But I believe that is NOT relevent here because master.c, thread.h,
>> and nsthread.h (correctly) do NOT include ns.h.
>>
>> Instead, I think it is the separate definition of NS_EXTERN in
>> nsthread.h that matters when building nsthread.
> Gustaf, on 9/27 you changed nsthread/reentrant.c to import ns.h.  It
> never did that before, and now it imports ns.h before thread.h and
> nsthread.h.  It looks like you did that in order to call Ns_Log in
> reentrant.c.
>
> However, I suspect that ALSO changed the definition of NS_EXTERN to
> the one in ns.h rather than nsthread.h.  Was that an unintentional?
> Defining NS_EXTERN in two separate places like that is kind of
> confusing.  Can/should we merge them into one somehow?
>
> I bring this up because after merging all your latest changes into my
> fork, the nsthread Windows build (which worked before) now fails like
> this:
>
>    Creating library nsthread.lib and object nsthread.exp
>    reentrant.o : error LNK2019: unresolved external symbol Ns_Log referenced in function ns_asctime
>    nsthread.dll : fatal error LNK1120: 1 unresolved externals
>
>
> changeset:   2884:950a8cebabb8
> user:        Gustaf Neumann <ne...@wu...>
> date:        Sat Sep 27 22:17:55 2014 +0200
> files:       include/nsthread.h nsd/exec.c nsthread/reentrant.c
> description:
> - setting WINVERSION to Vista to allow usage of InetNtop()
> - make code more robust against previous defines
> - use the right pid_t type for win
> - add shutdown flags
> - use *_s function in win-specific reentrant code
>


-- 
Univ.Prof. Dr. Gustaf Neumann
WU Vienna
Institute of Information Systems and New Media
Welthandelsplatz 1, A-1020 Vienna, Austria

Re: [naviserver-devel] Naviserver hangs on Windows

[Andrew P. <at...@pi...>]

On Sat, Oct 04, 2014 at 04:07:27PM +0200, Maurizio Martignano wrote:
> 	What is your target? Windows 32 or Windows 64?

Windows 7, 64-bit.

> Did you use the define _USE_32BIT_TIME_T yes or not?

No I did not.

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] Naviserver hangs on Windows

[Maurizio M. <Mau...@sp...>]

Again,
	What is your target? Windows 32 or Windows 64?
Did you use the define _USE_32BIT_TIME_T yes or not?

Thank you,
Maurizio


-----Original Message-----
From: Andrew Piskorski [mailto:at...@pi...] 
Sent: 04 October 2014 13:00
To: nav...@li...
Subject: Re: [naviserver-devel] Naviserver hangs on Windows

On Fri, Oct 03, 2014 at 10:49:27AM -0400, Andrew Piskorski wrote:
> Hm, the old AOLserver 4.0.7 version of Ns_GetTime() had a Windows 
> ifdef which is entirely missing from Naviserver!  (See below.)

I added back that Windows-specific Ns_GetTime() here:

 
https://bitbucket.org/apiskors/naviserver/commits/51f1735d788d7b00adc797a757
9272763ddd9bcf

With that change, "nsd -h" started working, but running nsd with any other
arguments now stops with a Windows pop-up box saying:

  Debug Assertion Failed!
  File: f:\dd\vctools\crt_bld\self_64_amd64\crt\src\strftime.c
  Line: 615
  Expression:  ((timeptr->tm_mday >= 1) && (timeptr->tm_mday <= 31))

Mysteriously, with that new next problem I can't seem to get any plausible
backtrace out of WinDbg.  However, strftime() only appears three times in
the entire Naviserver codebase, so I very strongly suspect that it's
actually hitting that assertion in LogTime() (in nsd/log.c).

So in LogTime(), I added some simple printf's just before calling
strftime().  ptm->tm_mday and all the other struct members have a value of
-1.  That's because in ns_localtime(), localtime_s() returns an EINVAL = 22
"Invalid argument" error code, and then sets all the members to -1.

  http://msdn.microsoft.com/en-us/library/a442x3ye.aspx

The *tp and *clock values look like a correct time_t count of seconds since
the Unix epoch.  So perhaps something is wrong with the only other argument
ther to localtime_s():  &tlsPtr->ltbuf

But what?  Any ideas?

--
Andrew Piskorski <at...@pi...>

----------------------------------------------------------------------------
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI
DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you
Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI
DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] Naviserver hangs on Windows

[Andrew P. <at...@pi...>]

On Fri, Oct 03, 2014 at 10:49:27AM -0400, Andrew Piskorski wrote:
> Hm, the old AOLserver 4.0.7 version of Ns_GetTime() had a Windows
> ifdef which is entirely missing from Naviserver!  (See below.)

I added back that Windows-specific Ns_GetTime() here:

  https://bitbucket.org/apiskors/naviserver/commits/51f1735d788d7b00adc797a7579272763ddd9bcf

With that change, "nsd -h" started working, but running nsd with any
other arguments now stops with a Windows pop-up box saying:

  Debug Assertion Failed!
  File: f:\dd\vctools\crt_bld\self_64_amd64\crt\src\strftime.c
  Line: 615
  Expression:  ((timeptr->tm_mday >= 1) && (timeptr->tm_mday <= 31))

Mysteriously, with that new next problem I can't seem to get any
plausible backtrace out of WinDbg.  However, strftime() only appears
three times in the entire Naviserver codebase, so I very strongly
suspect that it's actually hitting that assertion in LogTime() (in
nsd/log.c).

So in LogTime(), I added some simple printf's just before calling
strftime().  ptm->tm_mday and all the other struct members have a
value of -1.  That's because in ns_localtime(), localtime_s() returns
an EINVAL = 22 "Invalid argument" error code, and then sets all the
members to -1.

  http://msdn.microsoft.com/en-us/library/a442x3ye.aspx

The *tp and *clock values look like a correct time_t count of seconds
since the Unix epoch.  So perhaps something is wrong with the only
other argument ther to localtime_s():  &tlsPtr->ltbuf

But what?  Any ideas?

-- 
Andrew Piskorski <at...@pi...>

Re: [naviserver-devel] were all AOLserver 4.0.x bugfixes merged?

[Maurizio M. <Mau...@sp...>]

Dear Andrew,
You have risen a very good point.
This is what I think.
1. Fact - Naviserver forked from Aolserver 4.0.x
2. Fact - Aolserver evolved to Aolserver 4.5.2 and then stopped
3. Fact - Naviserver doesn't contain the changes/improvements occurred in
Aolserver fron 4.0.x to 4.5.2
4. Fact - All new developments are now occurring on Naviserver
5. Opinion - I believe Aolserver code base is more stable (it is used a lot
and there's no development on it)
6. Opinion - I believe Naviserver needs to get more stable both in terms of
build processes(es) and code base
7. Fact - I do not have time at the moment to work on this area but I see
with great pleasure the efforts you are putting on Windows part and the
build process and Gustaf on the code base stability (look at all the changes
Gustaf has recently introduced). Anyhow I am trying to support both efforts
as much as I can (some of the changes Gustaf has introduced are the result
of little suggestions, tips I gave him. I am actually maintaining an on line
database with all the results of some static analyses performed on both
Aolserver 4.5.2 and Naviserver - the very last version.)
8. Opinion - I believe this is the path Naviserver should follow:
8.1 - You improve the build process(es)  and Windows related code base,
looking at what was done in Aolserver till version 4.5.2
8.2 - We retain the results of the wonderful work Gustaf is doing on the
overall codebase.

Hope it helps,
Maurizio


-----Original Message-----
From: Andrew Piskorski [mailto:at...@pi...] 
Sent: 04 October 2014 08:51
To: nav...@li...
Subject: [naviserver-devel] were all AOLserver 4.0.x bugfixes merged?

When exactly did Naviserver fork from AOLserver, and have all the relevent
bugfixes made to AOLserver since then been merged into Naviserver?  (I see a
few that look like they haven't been...)

Although I don't see any official mention of it, from comparing the
Naviserver and aolserver-40x repositories on Bitbucket it sure looks like
Naviserver forked from the aolserver-4.0.10 release, and that this was the
last commit made by anyone PRIOR to forking:

  changeset:   1095:e9c50ae686b5 
  user:        Dossy Shiobara <do...@pa...> 
  date:        Tue Jan 18 21:10:07 2005 +0000 
  description:  Tag aolserver-4.0.10 

--
Andrew Piskorski <at...@pi...>

----------------------------------------------------------------------------
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI
DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you
Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI
DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

[naviserver-devel] use nsconfig.tcl to compile on Windows?

[Andrew P. <at...@pi...>]

On Fri, Oct 03, 2014 at 05:20:48PM +0200, Maurizio Martignano wrote:
> Subject: Re: Naviserver hangs on Windows

> The Windows-OpenACS distribution which I make available here
> (http://www.spazioit.com/pages_en/sol_inf_en/windows-openacs_en/) is based
> on AOLServer 4.5.2, contains the sources, is compiled with Visual Studio
> 2013 and runs on Windows 64.

Indeed, the first thing I noticed is that Maurizio's Windows build
seems to use nsconfig.tcl in place of the Unix configure/autoconf,
which Jim Davidson added back in 2005.

Naviserver folks, can you comment on what you think of that approach?
Does Naviserver not include it solely because it wasn't included in
the AOLserver 4.0.10 branch that Naviserver forked from?


https://bitbucket.org/aolserver/aolserver/src/2aa0f24395ae0a42fd590f3635e4fdf2c7eefdfd/nsconfig.tcl?at=default

andy@milo:/home/nobackup/co/nsd-aol/aolserver-head-hg$ hg log nsconfig.tcl configure.tcl 
changeset:   1370:76895d8bf843 
user:        Jim Davidson <jgd...@ao...> 
date:        Thu Aug 18 21:48:21 2005 +0100 
summary:     Renamed configure script configure.tcl 
 
changeset:   1367:9c88ea73dcad 
user:        Jim Davidson <jgd...@ao...> 
date:        Wed Aug 17 23:55:57 2005 +0100 
summary:     Updates to new build tools to support Unix 
 
changeset:   1360:697679717350 
user:        Jim Davidson <jgd...@ao...> 
date:        Wed Aug 17 22:18:46 2005 +0100 
summary:     New platform-indepedent build support 

-- 
Andrew Piskorski <at...@pi...>