On 05.11.2006, at 01:11, Agustin Lopez wrote:
Thanks for the answer, Zoran!
Reading your post I think of I must find / replace
all the occurrences of
Tcl_SetObjResult(interp, Tcl_NewXXXObj(...));
by
Tcl_ResetResult(interp);
Tcl_SetXXXObj(Tcl_GetObjResult(interp), ...)
in all the code and
On 31.10.2006, at 12:28, Agustin Lopez wrote:
Tcl_SetBooleanObj called with shared object
The problem is the construct:
Tcl_SetXXXObj(Tcl_GetObjResult(interp), ...)
as the Tcl_Obj stored in the interp result
may turn out to be shared under some circumstances.
You must rewrite all those
On 07.09.2006, at 16:36, Rusty Brooks wrote:
I'd like to see this as a feature of AOLServer... being able to
mark a channel as do-not-cleanup.
You can open a (tcl) channel in one thread, then detach it from the
interpreter/thread and re-use (i.e. attach) it into some other thread.
The only
On 30.08.2006, at 18:02, Tom Jackson wrote:
But with Tcl exec, you never call fork, screw around and then call
exec*(), do
you? Is this an issue for C level tcl? Maybe the issue is that fork
and exec
are separate calls, and something unplanned could happen between
the two, and
Am 20.07.2005 um 09:23 schrieb Bas Scheffers:
Whatever the problem and how to fix it, let this be a lesson to
all: In
this worldwide business we call the Internet, there is only one
charset:
UTF-8.
Composed or decomposed variant?
Once somebody said: the nice thing about standards
is that
Am 12.07.2005 um 16:27 schrieb Tom Jackson:
On Tuesday 12 July 2005 06:28, Adam Turoff wrote:
On 7/11/05, Dossy Shiobara [EMAIL PROTECTED] wrote:
http://aolserver.com/wiki/ns_chan
Thanks. That worked like a charm. ;-)
This is interesting. I'll look at the source, but what
Am 12.07.2005 um 17:23 schrieb Tom Jackson:
I'm guessing you mean in concept, or is AS now using tcl channels
in request
threads?
I mean in concept.
Zoran
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
Am 30.06.2005 um 13:02 schrieb Bas Scheffers:
Hmmm, what kind of problems? I just built using 8.4.10 on OS X last
night
and it seems fine. Both Tcl and AOLserver compiled by the book
without
hitches.
OSX uses different notifier code as other Unices and the code
there is OK.
In attempt to fix
Am 20.06.2005 um 12:50 schrieb Bas Scheffers:
But I was just wondering if something like that could be possible
in some
way in AOLserver, preferably without too much C hacking.
No. It needs much C-hacking.
Zoran
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list,
Am 27.05.2005 um 00:47 schrieb Jeff Hobbs:
This I will disagree with. If you can handle it all in C,
I think you will save time. A lot will be in the copying
itself, but saving any and all parsing is a bonus.
Hmmm...since the scripts will have to jump interp/thread,
they need to be
Am 26.05.2005 um 00:46 schrieb Jeff Hobbs:
Complex, yes, but still possible.
Well... see:
* Limitation: For C-based 'commands' with a non-NULL client data
* we do not know how to handle this. For the moment we simply
* copy the pointer. In the future commands may need a
Am 26.05.2005 um 11:47 schrieb Andrew Piskorski:
On Thu, May 26, 2005 at 10:59:16AM +0200, Zoran Vasiljevic wrote:
Also, although all in Tcl_CloneInterp is done in C, I'm afraid
that it could still take considerable time to copy 1000 or so
commands
But Jeff H. said it has already been
Am 26.05.2005 um 11:47 schrieb Andrew Piskorski:
On Thu, May 26, 2005 at 10:59:16AM +0200, Zoran Vasiljevic wrote:
Also, although all in Tcl_CloneInterp is done in C, I'm afraid
that it could still take considerable time to copy 1000 or so
commands
But Jeff H. said it has already been
Am 26.05.2005 um 12:53 schrieb Andrew Piskorski:
Well, Zoran, you're looking at the code and I'm not, but none of that
seems to jive with what Jeff H. has said before. So if you are
serious about maybe working on this stuff (yeah!), I recommend talking
to him and getting lots more details...
Am 26.05.2005 um 13:58 schrieb Andrew Piskorski:
Here's a naive, clueless-because-I-have-not-read-the-source question:
Is some sort of copy-on-write feasible, for the multi-threaded case?
Or would it even help, if it was possible?
This piece alone is not the only obstacle.
The more
Am 25.05.2005 um 15:39 schrieb Robert Seeger:
To add my two cents... My thought is to avoid namespace variables. I
understand the point that cleaning up after namespace variables
would be
expensive. However, anything that prevents commands in namespaces from
working correctly should be
Am 25.05.2005 um 16:37 schrieb Tom Jackson:
Yes, I use namespace variables to hold package startup info.
Cleaning them out
would not be good. (Since the variables are set during server
startup, they
are expected to exist in every thread.)
Tom,
It is not the question of deleting all those
Am 25.05.2005 um 21:17 schrieb Jeff Hobbs:
I've mentioned it before, but I'll stress it again - it is
possible to improve this speed, possibly dramatically. If
one were to go into the mod-8-3-4-branch that ActiveState
did for Cisco, you will find some interesting core changes.
One of them is
Am 26.05.2005 um 00:46 schrieb Jeff Hobbs:
Complex, yes, but still possible.
OK. I will give this a second look...
I recall looking at that some time ago already.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with
Am 13.04.2005 um 16:48 schrieb Elliott Phil Civ AFMSA/SGSID:
* Sun Takes First Step in Opening Solaris Development
http://www.gartner.com/DisplayDocument?doc_cd=127154
Didn't they try this already some years ago?
Eh, I recall OpenVMS... (anybody still remembers Alpha chip?)
There are quite a few
Am 13.04.2005 um 17:52 schrieb Adam Turoff:
http://opensolaris.org/roadmap/index.html
This will probably be on par with the OpenDarwin/Mac OS X
hybrid, not like OpenVMS/
Aha! Interesting... I will keep an eye on it.
I recall downloading the Solaris sources some years ago...
After some
Am 07.04.2005 um 18:23 schrieb Jeff Hobbs:
I'm not 100% sure, but I think the reinit of the Tcl library
was more important than the 100% clean Finalize, but both were
considered. I need to make sure that the resetting of init to
0 isn't correct for cases like the browser plugin, where Tcl
is
Am 07.04.2005 um 05:34 schrieb Jeff Hobbs:
OK, looks like Tcl 8.4.7 introduced the leak. Here's my test
run against Tcl 8.4.6:
I would suspect this patch from Kenny / Mistachkin (applied by me):
2004-07-20 Jeff Hobbs [EMAIL PROTECTED]
* generic/tclEvent.c: Correct threaded obj
Hi,
Before I start to dig and make fire in Tcl project, I just wanted to
check
this here...
As the matter of fact, the zippy memory allocator (what does zippy
mean, btw?)
seems rather broken. It is, since some time, part of the Tcl and it is
turned on
per-default if compiling with threads enabled.
Am 06.04.2005 um 20:32 schrieb Andrew Piskorski:
On Wed, Apr 06, 2005 at 07:22:08PM +0200, Zoran Vasiljevic wrote:
As the matter of fact, the zippy memory allocator (what does
zippy mean, btw?) seems rather broken. It is, since some time,
It means fast, basically.
OK :-)
Interesting. A leak
Am 06.04.2005 um 22:31 schrieb Dossy Shiobara:
Zoran, if you have some time, could you try building Tcl 8.4.0 with the
threaded memory allocator and see if your tests show whether the same
memory growth problem exists or not?
If not, test 8.4.1, etc. until you find the point where the leak was
Hi!
I've added a patch against the CVS head to get the watchdog functionality
built into the server. For more info, please look at the RFE itself.
Any comments should go there and not on the list, if possible, please.
Cheer's
Zoran
--
AOLserver - http://www.aolserver.com/
To Remove yourself
responsibility.
--
With kind regards,
Mit besten Gruessen,
Meilleures Salutations,
___
Zoran Vasiljevic, Vice President, CTO
E-mail: mailto:[EMAIL PROTECTED]
Web:http://www.archiware.com
Phone: +49 89 319 084 98
Fax:+49 89 319 084
On Friday 25 February 2005 15:28, Dossy Shiobara wrote:
On 2005.02.25, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
All procs are dumped by Tcl interpreter being dumped when the
connection thread exits.
This is not true, unless you set connsperthread != 0, which we've
recently discovered
you'd like to do with them.
Some similar to [file channels] from Tcl.
Zoran
--
With kind regards,
Mit besten Gruessen,
Meilleures Salutations,
___
Zoran Vasiljevic, Vice President, CTO
E-mail: mailto:[EMAIL PROTECTED]
Web:http
On Friday 25 February 2005 18:42, Andrew Piskorski wrote:
On Fri, Feb 25, 2005 at 06:08:05PM +0100, Zoran Vasiljevic wrote:
The real garbage-collection is a tough issue. Hence not tackled by
the AS yet. So, what's here (ns_cleanup) works but not realy universally.
Jeff Hobbs has mentioned
On Friday 25 February 2005 19:31, Jeff Davis wrote:
Speaking of ttrace, is the sourceforge code the latest and greatest?
I attempted to get it to work with openacs but a few things we do
seemed to give it indigestion (some proc renames and such). I have
been meaning to try again but have not
On Friday 25 February 2005 19:16, Andrew Piskorski wrote:
On Fri, Feb 25, 2005 at 12:58:45PM -0500, Dossy Shiobara wrote:
Zoran's ttrace extension might help here, but ttrace doesn't give
you the performance boost of Tcl's parsing and byte compiling on first
execution, and subsequent
On Wednesday 09 February 2005 23:41, Andrew Piskorski wrote:
If you're still thinking about or discussing this and haven't decided
what to do yet, that's fine, just tell us so. But I think you do owe
the AOLserver community some sort of clear statement on this issue.
This is an excerpt from
from the entire year 2004):
1. Jim Davidson (AOL): radical architectural chanes (numerous instances)
2. Dossy Shiobara (AOL): fixing bugs, minor tweaks (numerous instances)
3. Nathan Folkman (AOL): fixing bugs (1 instance)
4. Rob Crittenden (AOL): minor tweaks (3 instances)
5. Zoran
On Wednesday 09 February 2005 08:13, Malte Sussdorff wrote:
On a related note, what is the downside of having an AOLserver stable
branch, where only the AOL approved developers have access to and a testing
branch where everyone can add their patches to. Needless to mention that
from time to
On Wednesday 09 February 2005 11:13, Bas Scheffers wrote:
I have written down my first thoughts on how this could work at:
http://bas.scheffers.net/wiki/14
As you can see, it is not easy to do this quick and dirty as proof of
concept. It will require application awareness in many places
On Wednesday 09 February 2005 16:49, I wrote:
nsv_set [namespace origin [lindex [info level 0] 0]]::myarray key value
Hm... this is more correct:
nsv_set [namespace qualifier [namespace origin [lindex [info level 0]
0]]]::myarray key value
but even worse!
Zoran
--
AOLserver -
On Wednesday 09 February 2005 17:21, Robert Seeger wrote:
Zoran,
I can buy the general logic. However, consider how much code might be
broken by extending the same logic to:
nsv_set myarray key value
How many pieces of code currently do this, and assume its global? All of
it (that was
On Thursday 10 February 2005 00:15, Jeff Hobbs wrote:
Great, so that's taken care of, and I notice that Dossy reiterated
the open CVS policy. So what's the problem again? Some developer's
fear of commiting is not something you can blame AOL for.
Jeff,
I do commit to Tcl project as you
On Monday 07 February 2005 23:25, Dossy Shiobara wrote:
Seems fair. I assume you will be putting responses bypassing this
public list in some place where everybody can see them, right?
Unfortunately, no. I thought about this and decided that I want to
respect people's desire to remain
On Tuesday 08 February 2005 18:32, Andrew Piskorski wrote:
On Tue, Feb 08, 2005 at 09:12:06AM -0800, Tom Jackson wrote:
* Some kind of watchdog functionality
Actually only a built in module would work very well, and fast. Every
solution
I've seen is a true hack, which is why it
On Tuesday 08 February 2005 17:54, Dossy Shiobara wrote:
- Convert docs in Tcl doctools format so you get instant HTML and
nroff output and deliver that with the distro
I'm not convinced that the Tcl doctools format is the way to go
Have you ever tried doctools? Why are you not
On Monday 07 February 2005 16:51, Vlad Seryakov wrote:
I just gave up participating in SF tracker thing.
Sad.
Well, this is what I said... People go away or do nothing...
We need the vision statement.
Zoran
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply
On Monday 10 January 2005 21:03, Dossy Shiobara wrote:
I'd REALLY love it if someone could review the entire list of filed
RFE's at SourceForge and help review and prioritize them, figuring out
which ones make sense for 4.0 vs 4.1 or 5.x, etc. Someone in the
AOLserver Community must have
On Wednesday 15 September 2004 15:26, Janine A Sisk wrote:
In nsd 3.3 we have always had to use a script to get the logs to roll
properly. I had assumed this problem would be fixed by now, but it's
looking like it's not. I've got logroll set to true in my config file
but the error log just
On Monday 30 August 2004 23:33, Howard Uman wrote:
Anyone had any luck doing this? I am having problems after I munge up
the AOLServer/include/Makefile.global and I get the following error:
gcc: file path prefix
I cant say much about Quantify, but I can say something about
Purify. You need
On Friday 20 August 2004 03:45, Dossy Shiobara wrote:
On 2004.08.19, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
It's true, but Jim Davidson gets special exemption. I think we can all
understand and appreciate why. :-)
I understand. Nevertheless, I think everybody should *at least
On Thursday 19 August 2004 00:45, Dossy Shiobara wrote:
After the recent discussions, I felt it may be useful to codify what I
see as the current CVS commit guidelines for project developers. The
current text is up on the wiki:
All this below sounds generaly reasonable.
I do, however, have a
On Wednesday 18 August 2004 16:43, Robert Seeger wrote:
Given the current movement of this thread in the direction of You're
wrong... no, you are!!, I figured I'd toss something out in an attempt
to set it back on track a bit.
What, exactly, is the goal that we are trying to accomplish by
+ 2004-08-16 Dossy Shiobara [EMAIL PROTECTED]
+
+ * nsd/driver.c (1.34): Win32 platform doesn't support mmap().
+ Maybe should define HAVE_MMAP instead in the future.
Maybe we should use:
CreateFileMapping
MapViewOfFile
UnmapViewOfFile
and emulate mmap() instead? I
Hi!
I would like to start a discussion which will eventually lead
to one of the two proposals listed below (one from Vlad Seryakov
and the other from Stephen Deasey) included in the core-server
distribution.
Both proposals look promising and both allow us to add support
for arbitrary protocols
On Tuesday 17 August 2004 11:59, Andrew Piskorski wrote:
On Tue, Aug 17, 2004 at 10:32:56AM +0200, Zoran Vasiljevic wrote:
Vlad's patch implements entirely new socket-level driver and sticks
the whole add-in functionality in the driver itself, effectively
Stephen's patch integrates
On Tuesday 17 August 2004 11:28, Bas Scheffers wrote:
Very interesting. After only reading your nutshell descriptions, to me
what would seem like a nice way of handling this is lightweight plumbing
in C and the bulk in Tcl. Example:
Create a socket driver that, on connection to it's IP/port,
On Tuesday 17 August 2004 13:46, Dossy Shiobara wrote:
Just the other night, I had the need to implement a non-HTTP server in
AOLserver in order to implement the TiVo beacon connection for the
Home Media Option (MHO) feature of the Series2 TiVo. I thought about
both Vlad's and Stephen's
On Tuesday 17 August 2004 14:55, Dossy Shiobara wrote:
Certainly. My own input into the discussion shouldn't preclude others
from participating. However, I tend to believe that my opinion also
counts and deserves to be voiced along with everyone else's for
consideration.
Absolutely.
On Tuesday 17 August 2004 15:37, Andrew Piskorski wrote:
On Wed, Aug 11, 2004 at 09:26:20AM +0200, Zoran Vasiljevic wrote:
When you launch the AOLserver in foreground, run couple of requests
and then ctrl-c it, purify should report all memory that has been
allocated and not freed. The list
PROTECTED] wrote:
On Wed, Aug 11, 2004 at 09:26:20AM +0200, Zoran Vasiljevic wrote:
When you launch the AOLserver in foreground, run couple of requests
and then ctrl-c it, purify should report all memory that has been
allocated and not freed. The list may be long, since AS does not
make
On Tuesday 17 August 2004 10:32, Zoran Vasiljevic wrote:
I would like to start a discussion which will eventually lead
to one of the two proposals listed below (one from Vlad Seryakov
and the other from Stephen Deasey) included in the core-server
distribution.
I anticipated that this one may
to not-exposed C-API things
anytime. This is how things happen, right? ;)
Zoran
Rob Seeger
Zoran Vasiljevic wrote on 8/17/2004, 10:09 AM:
On Tuesday 17 August 2004 16:01, Nathan Folkman wrote:
Off topic, but somewhat related... ;-) I know Tcl can't be used in all
cases, and that sometimes you
On Tuesday 17 August 2004 20:12, Don Baccus wrote:
On Tuesday 17 August 2004 10:17 am, Zoran Vasiljevic wrote:
b. NO, I do not need AS doing anything else than http
and am perfectly happy with status-quo now. Just
forget the whole thing.
This is my vote. Let's keep things
On Tuesday 17 August 2004 20:55, Don Baccus wrote:
Fine. But there's no reason to push forward on this immediately. Resources
are finite, triage and prioritization are important
Of course. There is no need to push this. It is, if at all, going
to be the part of the development branch for 4.1
On Tuesday 17 August 2004 20:17, you wrote:
To maximize portability, AOLserver could probably use the Tcl API even more
than it does now, and in a few cases modules aren't taking advantage of the
portability abstractions we already have, for example, in the latest
nsopenssl sources, struct
On Tuesday 10 August 2004 23:27, Andrew Piskorski wrote:
I'm not and never have been doing any refcounting of Tcl objects at
all, so that can't be it. (Actually, my C code is using the old-style
string based Tcl APIs only, no Tcl objects.)
When you launch the AOLserver in foreground, run
On Tuesday 10 August 2004 08:37, Andrew Piskorski wrote:
So, can anyone suggest what sorts of errors could cause a big memory
leak which is NOT detected by Purify, and how I could check for them
in AOLserver? Or any other ways to figure out WHAT exactly is making
AOLserver steadily use more
On Wednesday 21 July 2004 21:43, you wrote:
So, what's the point of presenting the option? Is it (or rather, should
it be) possible to build a statically linked AOLserver against a shared
Tcl or vice versa?
One point is, if you ever get to mem-debug the nsd executable
with Purify, you would
On Tuesday 06 July 2004 17:06, Dossy wrote:
I want to ask if anyone finds any use or value in having a separate
Patches tracker at SourceForge. It seems to me the only difference
between the Bugs and Patches trackers is that a Patch is a Bug with a
suggested patch to fix it.
There is no
On Tuesday 22 June 2004 18:24, you wrote:
Zoran implemented some recent changes to TclX keyed lists in CVS HEAD
which changed the C API, which broke at least some code at AOL which was
still using the old C API.
Ah, the C-API you're talking about! Well, this is right.
This has changed. I see
On Tuesday 22 June 2004 18:24, you wrote:
Zoran implemented some recent changes to TclX keyed lists in CVS HEAD
which changed the C API, which broke at least some code at AOL which was
still using the old C API.
???
There are no Tcl-level changes to keyed list commands.
Rather than a
On Tuesday 22 June 2004 18:33, you wrote:
On Tuesday 22 June 2004 18:24, you wrote:
Zoran implemented some recent changes to TclX keyed lists in CVS HEAD
which changed the C API, which broke at least some code at AOL which was
still using the old C API.
Ah, the C-API you're talking about!
On Tuesday 22 June 2004 18:48, you wrote:
Zoran,
I am just curious what you have done. Did you update
the AS code to match what is at tclx.sf.net? Or is
this just something you did? I believe you converted
to the Tcl objects, but wasn't sure if you took it
from SF or did it on your own.
It
On Tuesday 22 June 2004 18:24, you wrote:
Zoran implemented some recent changes to TclX keyed lists in CVS HEAD
which changed the C API, which broke at least some code at AOL which was
still using the old C API.
Rather than a wholesale back-out of the changes, I'd like to discuss two
A
On Tuesday 15 June 2004 10:08, you wrote:
So, what's the problem here? Are there just plain not enough people
with both CVS commit and the time to use it? Or are there plenty of
developers with commit available, who just don't use it because of
perceived political or procedural problems, or
On Thursday 10 June 2004 21:47, you wrote:
Hi all,
to manage a global data structure over the course of a single request,
we were thinking about having a global hash table, indexed by the
address returned by Ns_GetConn().
This way, every function could access the request-specific data by
On Thursday 10 June 2004 22:03, you wrote:
This sounds like Connection Local Storage type of need. There is a set
of api's available in aolserver 4.0 which implement this, which you
might find interesting:
http://www.aolserver.com/40drafts/capi/api/newindex.htm
Specifically, for example,
On Wednesday 09 June 2004 00:51, you wrote:
Zoran,
Ok I tried
[exec /bin/csh -c /opt/myscript]
and I get the same error.
I also tried launching aolserver from /bin/csh instead of bash and I still
had the same problem.
Oh... I must say that I had the same problem with one of the
older
On Wednesday 09 June 2004 00:51, you wrote:
Zoran,
Ok I tried
[exec /bin/csh -c /opt/myscript]
and I get the same error.
I also tried launching aolserver from /bin/csh instead of bash and I still
had the same problem.
I did some more testing on our troublesome machine which
behaves as
On Wednesday 09 June 2004 17:23, you wrote:
I didn't mention that I am running redhat 7.3 with java version 1.4.2_03.
Now you know.
My findings do not jive with Zoran's findings. I can run both of the execs
mentioned before in the tcl interpreter. The tcl interpreter is the one
that
On Tuesday 08 June 2004 18:15, you wrote:
AOlserver 4.0.0 to AOlserver 4.0.1 introduces an exec problem. On 4.0.0 I
can run both:
1. [exec /bin/bash -c ls -al]
2. [exec /bin/bash -c /opt/myscript]
But on AOLserver 4.0.1 (with nsjk2) number 2. fails with this error.
error waiting for
On Friday 28 May 2004 19:59, you wrote:
On Fri, May 28, 2004 at 12:58:36PM -0400, Vlad Seryakov wrote:
I have patch that convert aolserver into generic threaded server
platform. I had to write SMTP proxy server and it required just a
small patch to change default HTTP-aware behaiviour of
On Thursday 27 May 2004 20:39, you wrote:
On 2004.05.27, Tilmann Singer [EMAIL PROTECTED] wrote:
Can anyone tell me what the chances are for this bug to get fixed:
[ 932459 ] Impossible to set encoding for ns_sockopen
On Thursday 27 May 2004 21:05, you wrote:
On Thu, 2004-05-27 at 11:46, Zoran Vasiljevic wrote:
He's using the http protocol for that, I assume, not just plain
socket connection.
I think Dossy's suggestion should work. All the tcl exposed sock
commands use tcl channels.
Yes. But so far
On Friday 21 May 2004 15:35, Bob Woodside wrote:
insight into why Dossy said that moving back to an AOLserver is not at
the top of the priority heap, but takes a back seat to revamping the
site's content.
Content??? What content?
Zoran
--
AOLserver - http://www.aolserver.com/
To Remove
On Tuesday 30 March 2004 18:09, you wrote:
I think this bit here where it checks length 0 length maxpost
should almost certainly be || rather than .
/*
* Check for end of headers.
*/
if (e == s) {
reqPtr-coff = reqPtr-roff;
s =
On Friday 12 March 2004 15:09, you wrote:
Zoran Vasiljevic said:
That is *Friday* the 8th of April,
if my clock does not lie.
It lies:
% clock format [clock scan 8 april 2004] -format %A
Thursday
:)
It does, indeed!
That explains why I'm always short on time.
I keep on missing one day
On Monday 08 March 2004 23:47, you wrote:
What happens if the network or some other part of the infrastructure
goes down such that one of the nodes can't communicate with the master?
Do you loose log messages? Does the node block?
What happens when the master fills it's log disk, do all the
On Monday 08 March 2004 17:27, you wrote:
There is Tcl syslog extension, i use it in my Tcl scripts but it is fo
rUnix only.
If Windows is one of the platforms syslog may not be portable solution,
but if only Unix,
collecting nsd.logs over syslog makes life much easier than re-inventing
Tcl
On Monday 08 March 2004 17:53, you wrote:
Shoot, I was hoping you wouldn't notice that point! ... Actually my idea
only addresses one way of registering a way of selecting then setting
the channel, all the work you were going to do would still be required,
but my idea might interfere with
On Monday 08 March 2004 09:13 pm, you wrote:
Also, the ns_logctl command does
have per-thread buffering capabilities -- you could wrap whatever you're
doing with it, e.g., in ADP:
%
ns_logctl hold; # begins buffering log messages in this thread alone
ns_adp_include myfile.adp
set msgs
Hi !
First, I would not like to start another flame...
Now, what I would like to ask is: would anybody have something
against to adding additional functionality to the [ns_logctl]
command so it is possible to assign a regular Tcl channel
as the output for the [ns_log] command?
Like, for
On Sunday 07 March 2004 07:41 pm, you wrote:
On Sun, 2004-03-07 at 04:03, Zoran Vasiljevic wrote:
Like, for example:
set chan [open /some/file.log w]
ns_logctl pushchan $chan
ns_log notice This goes to chan $chan
set chan [ns_logctl popchan]
close $chan
Interesting
On Sunday 07 March 2004 20:14, you wrote:
Why not to use syslog?
What is the advantage of using Tcl channels over syslog for collecting
multiple logs?
Great difference. Everything is under Tcl control and you have
no OS issues (would/should work on Win too). Configuration
pains are avoided
On Sunday 07 March 2004 21:35, you wrote:
On Sun, 2004-03-07 at 11:06, Zoran Vasiljevic wrote:
Oh, misunderstanding...
Zoran, no I think I understood. From what I understand, each request has
a current url, used by the filter/request proc code to handle requests.
Your suggestion is to add
On Friday 05 March 2004 18:59, you wrote:
When I will get some time, I will try to do some tests by splitting the
0-proc nsv array into several arrays to check if I can reduce the lock
contention.
I will let you know if results are better with this technique.
Unfortunately, I am pretty busy
On Thursday 26 February 2004 11:14, you wrote:
Here I am not sure to understand. Why do your cleanup code per request
(the ttrace::cleanup added) delete the loaded functions ?
They should not be deleted... (I am perhaps missing something, I didn't
chek carefully the cleanup code so far).
On Thursday 26 February 2004 12:49, you wrote:
Anyway, I have a question about this cleanup : If I am sure I am not
changing the interp state and procs, there is no need to run this cleanup.
Am I right ?
You are right.
I never use ns_eval on my web site, and I think (90% sure) my procs
On Wednesday 25 February 2004 22:07, you wrote:
The lock contention problem comes from the nsv_array 0-proc.
As I understand TTrace module, the xx-proc (where xx=0 for me) is the
array where all the procs are saved (the proc db we can say).
0 = the epoch time I suppose.
Correct. So you have
On Tuesday 24 February 2004 12:02, you wrote:
BUT... with the same traffic as before my processor (%CPU and load
balancing) is multiplied by about 8 !
After few searches, I realised a nsv lock contention was very high (checked
in nstelemetry.adp).
So it is not directly the TTrace package
On Tuesday 24 February 2004 13:24, you wrote:
I agree 100% with you. Thread should gradually load all the procs.
I may have something wrong somewhere or a special thing in all my tcl
procs, I will check that and let you know.
Pay attention to ns_eval! This can be your bottleneck.
On each
On Tuesday 24 February 2004 13:24, you wrote:
I agree 100% with you. Thread should gradually load all the procs.
I may have something wrong somewhere or a special thing in all my tcl
procs, I will check that and let you know.
You can make your life easier by adding some log displays to
the
1 - 100 of 264 matches
Mail list logo
