On 09.10.14 02:16, Andrew Piskorski wrote:
> So clearly we do NOT need to make Ns_Time.sec a time_t.
that's what i've said :)
> Separately,
> I've asked tcl-c...@lists.sourceforge.net why it is a long in Tcl.
another practical reason in addition to Joe's answer is
binary compatibility
for extensio
On 08.10.14 20:25, Gustaf Neumann wrote:
> I've revived an old installation of win7 based on VirtualBox and Visual
> Studio 11,
> used the version of naviserver from bitbucket, compiled tcl, switched
> the line for the win-makefile, compiled nsd using nmake, and to my big
> surprise, "nsd,exe -c" w
Gustaf, my fork should be suitable for merging back into
naviserver/naviserver now.
On Wed, Oct 08, 2014 at 09:32:56AM +0200, Gustaf Neumann wrote:
> So at least, when using Tcl_GetTime(),
> which returns the time as Tcl_Time, everything should be
> fine. Note, that in your native time implementa
---
> From: Andrew Piskorski [mailto:a...@piskorski.com]
> Sent: 08 October 2014 18:39
> To: naviserver-devel@lists.sourceforge.net
> Subject: Re: [naviserver-devel] Naviserver hangs on Windows
>
> On Wed, Oct 08, 2014 at 09:32:56AM +0200, Gustaf Neumann wrote:
>
>> the adva
>> The problem seems to be: DllMain() calls certain functions
>> before the normal entry point main() is called, which initializes
>> tcl etc. The Windows man page [1] says:
> Interesting. And of course DllMain() only exists on Windows. But,
> why do we need DllMain() at all? I assume we DO nee
On Wed, Oct 08, 2014 at 06:50:35PM +0200, Maurizio Martignano wrote:
> Dear Andrew and Gustaf,
> In due time, when you both are confident on the status of Naviserver
> on Windows, I would try it inside my Windows-OpenACS distribution.
That sounds excellent to me. My own use of Naviserver on
Subject: Re: [naviserver-devel] Naviserver hangs on Windows
On Wed, Oct 08, 2014 at 09:32:56AM +0200, Gustaf Neumann wrote:
> the advantage of approach 2 (disable mutex timings, use ) is that
> this works for 32bit and 64 bit, while (1) works most likely only for
> 64bit (if i lo
On Wed, Oct 08, 2014 at 09:32:56AM +0200, Gustaf Neumann wrote:
> the advantage of approach 2 (disable mutex timings, use ) is that this
> works for 32bit and 64 bit, while (1)
> works most likely only for 64bit (if i look at the constant).
No, I'm confident that the approach using EPOCH_BIAS w
On Wed, Oct 08, 2014 at 08:05:42AM +0200, Maurizio Martignano wrote:
> I do agree with your remarks in your mail, I had a look at the Visual Studio
> Project Files you use, the only relevant differences I can see are the
I do not use any Visual Studio Project Files for Naviserver. The ones
in Me
I have to look at this closer before i have a better seeing
of consequences of changing the types in Ns_Time, i would
certainly prefer to stick to the Tcl conventions, since we
depend
strongly on tcl behavior all over the place.
There was a bug in log.c passing the argument to ns_localtime,
whi
Andrew, these are good news!
the advantage of approach 2 (disable mutex timings, use ) is that this
works for 32bit and 64 bit, while (1)
works most likely only for 64bit (if i look at the constant). The
mutex timings is an additional feature in naviserver, so at least
for the time being, one
ctive TCL is built)
Hope this helps,
Maurizio
-Original Message-
From: Andrew Piskorski [mailto:a...@piskorski.com]
Sent: 07 October 2014 22:36
To: naviserver-devel@lists.sourceforge.net
Subject: Re: [naviserver-devel] Naviserver hangs on Windows
On Mon, Oct 06, 2014 at 05:18:08PM
On Tue, Oct 07, 2014 at 12:09:41AM +0200, Gustaf Neumann wrote:
> 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 c
On Tue, Oct 07, 2014 at 05:02:41PM -0400, Andrew Piskorski wrote:
> And yet it still fails in exactly the same way, with EINVAL = 22.
> This makes me think there is nothing wrong with the tlsPtr code or
> data, rather something is seriously broken in my build.
I think my analysis above was entire
On Tue, Oct 07, 2014 at 04:09:02PM -0400, Andrew Piskorski wrote:
> C:\> C:\web\nsd-atp\bin\nsd -c
> [384.e14][-main-] Notice: nsmain: NaviServer/4.99 starting
> [384.e14][-main-] Fatal: nsthreads: localtime_s failed in ns_localtime: win32
> err: 22
In ns_localtime(), I changed this call:
er
On Mon, Oct 06, 2014 at 05:18:08PM -0400, Andrew Piskorski wrote:
> 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 haven't tried using _USE_32BIT_TIME_T yet, but I think using it
> would be INCORRECT on Windows-64
On Tue, Oct 07, 2014 at 12:09:41AM +0200, Gustaf Neumann wrote:
> 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 c
On Fri, Oct 03, 2014 at 04:16:41PM +0200, Maurizio Martignano wrote:
> Dear Andrew,
> These are the basic options I would use for a Windows 64 bit, AMD64:
>
> COPTS = /EHsc /W3 /nologo /c
> DEFS = $(DEFS) /D "_WINDOWS" /D "TCL_THREADS=1" /D "WIN32" /D "_WIN32" \
> /D "FD_SETSIZE=128
On Tue, Oct 7, 2014 at 12:11 PM, Gustaf Neumann wrote:
>
> 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 -
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
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
On Mon, Oct 6, 2014 at 10:31 PM, Gustaf Neumann 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 i
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 ear
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
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
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.
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 m
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 cod
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
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 loca
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 timin
I believe you should use it.
Thank you,
Maurizio
-Original Message-
From: Andrew Piskorski [mailto:a...@piskorski.com]
Sent: 05 October 2014 19:47
To: naviserver-devel@lists.sourceforge.net
Cc: Maurizio Martignano
Subject: Re: [naviserver-devel] Naviserver hangs on Windows
On Sat, Oct
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, Gusta
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
: 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_G
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
hangs on Windows
Hm, the old AOLserver 4.0.7 version of Ns_GetTime() had a Windows ifdef
which is entirely missing from Naviserver! (See below.)
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
Hm, the old AOLserver 4.0.7 version of Ns_GetTime() had a Windows
ifdef which is entirely missing from Naviserver! (See below.)
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
quot; /D "_MBCS" # /D
"_USE_32BIT_TIME_T"
LOPTS = /NOLOGO /SUBSYSTEM:CONSOLE /OPT:NOREF /OPT:NOICF
Hope it helps,
Maurizio
-Original Message-
From: Andrew Piskorski [mailto:a...@piskorski.com]
Sent: 03 October 2014 15:58
To: naviserver-devel@lists.sourceforge
: Re: [naviserver-devel] Naviserver hangs on Windows
On Fri, Oct 03, 2014 at 03:21:02PM +0200, Maurizio Martignano wrote:
> Dear Andrew,
> Did you happen to use this define _USE_32BIT_TIME_T?
No, I did not. Should I? Does Tcl use that?
Grepping my source files, I see this:
./i
On Fri, Oct 03, 2014 at 03:21:02PM +0200, Maurizio Martignano wrote:
> Dear Andrew,
> Did you happen to use this define _USE_32BIT_TIME_T?
No, I did not. Should I? Does Tcl use that?
Grepping my source files, I see this:
./include/nsconfig.h:276:#define SIZEOF_TIME_T 8
That nsconfig.h
Dear Andrew,
Did you happen to use this define _USE_32BIT_TIME_T?
Hope it helps,
Maurizio
-Original Message-
From: Andrew Piskorski [mailto:a...@piskorski.com]
Sent: 03 October 2014 14:49
To: naviserver-devel@lists.sourceforge.net
Subject: [naviserver-devel] Naviserver hangs on
With my changes here, the core Naviserver compiles now on my Windows 7
64-bit machine:
https://bitbucket.org/naviserver/naviserver/pull-requests
https://bitbucket.org/apiskors/naviserver/commits/all
However, it doesn't work at all. If I simply run "nsd -h", it hangs
indefinitely, and locks u
43 matches
Mail list logo
