Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Zoran Vasiljevic]

On Friday 06 June 2003 17:35, you wrote:
> On Friday 06 June 2003 08:15 am, Zoran Vasiljevic wrote:
> > My initial idea was to simply make the Nsd as static package by doing
> > Tcl_StaticPackage() at the end of InitInterp() and then do from Tcl:
> >
> > set interp [interp create]
> > $interp eval {load "" Nsd}
> > $interp eval [ns_ictl get]
> >
> > and so on... but this won't get the proper virtual server context
> > so it'll skip the traces. Phew. I must dig little bit more there.
>

Mark just brought a good idea on how to solve the ns_eval problem
w/o digging into C-code. We'd just spin-of a new thread, do the
eval there, get the blueprint and use it for initializing of other interps.
It's not fast, as it requires a thread-creation, but given the low frequency
of ns_eval's this should do the work. The net-effect is that all can be
done in Tcl alone in couple of lines.
So I assume Mark will take care of that in bin/init.tcl file.

Cheers,
Zoran


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Don Baccus]

On Saturday 07 June 2003 09:59 am, Zoran Vasiljevic wrote:
> On Friday 06 June 2003 17:35, Don Baccus wrote:
> > Right, if you skip the traces you don't get the module-defined ns_*
> > commands, we're on the same page here ... as far as this bit goes anyway.
>
> After thinking again and again, I see two possible scenarios.
> One thing upfront: I'd like to have *both* of the ns_eval behaviours
> available: the older one (as in 3.x) and the new " interp sync" mode.
> This is my target.

I agree ...

> Well, either of those will lead to solution. The second option
> allows for more flexibility. The first is simpler to implement.
>
> Thoughts?

I don't have strong feelings either way.  Synching of the state of all
interpreters is something that won't be done often and requires great care in
how you write the rest of your application so I don't think we need the
command to be particularly aesthetic, elegant etc.

The second approach is more flexible so is attractive but I don't think
there's a lot of demand for the extra functionality.  Then again if you
implement it the masses may suddenly start wondering how they ever lived
without it in earlier versions of AOLserver!   Who knows? :)


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Zoran Vasiljevic]

On Friday 06 June 2003 17:35, Don Baccus wrote:

> Right, if you skip the traces you don't get the module-defined ns_*
> commands, we're on the same page here ... as far as this bit goes anyway.

After thinking again and again, I see two possible scenarios.
One thing upfront: I'd like to have *both* of the ns_eval behaviours
available: the older one (as in 3.x) and the new " interp sync" mode.
This is my target.
To achieve this, there are couple of possibilitites. I'd present
two of them for the discussion.

First one is to move "ns_eval" to C-level since there we have
access to the ns_* specific initialization of Tcl interps.
The command syntax would be changed (backward-compatible)
to read:

ns_eval ?-syncinterps --? arg ? ... arg?

where "-syncinterps" would actually replicate the state of the
current interp to all other interps in the process (new behaviour).
BTW, everybody is welcome to suggest better option name :)
W/o the option, command would do what ns_eval did in 3.x,
so older scripts are happy.

Second one is to add new command "ns_interp" and do some
wrapping of Tcl "interp" command so it can create ns_*
instrumented interpreters. This way we can implement the
ns_eval in Tcl alone, possibly with the same syntax as above.

Well, either of those will lead to solution. The second option
allows for more flexibility. The first is simpler to implement.

Thoughts?

Zoran


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Vinod Kurup]

On Friday, June 6, 2003, at 05:42  PM, Don Baccus wrote:

(for those of you not part of the OpenACS community, Vinod is a
practicing MD.
Isn't Open Source great?)
Open Source definitely is great. I can't wait for the day that my
patients come with error logs and gdb-hook-ups. Then my 2 worlds will
be 1 and I'll be very happy. ;-)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Don Baccus]

On Friday 06 June 2003 11:54 am, Vinod Kurup wrote:
> On Fri, 6 Jun 2003 11:12:43 -0400, Lamar Owen wrote:
> > So, when a patch for OpenACS that doesn't use ns_eval is ready, those of
> > you who have problems with the nsdb0 stuff, if yu could please determine
> > whether the elimination of ns_eval fixes it.
>
> I made a patch
>  and it gets
> rid of the nsdb0 problem for me and at least a few others who have emailed
> me.

Hey, sweet, Vinod!  Great doctoring of the code there!

(for those of you not part of the OpenACS community, Vinod is a practicing MD.
Isn't Open Source great?)


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Vinod Kurup]

On Fri, 6 Jun 2003 11:12:43 -0400, Lamar Owen wrote:

> So, when a patch for OpenACS that doesn't use ns_eval is ready, those of you
> who have problems with the nsdb0 stuff, if yu could please determine whether
> the elimination of ns_eval fixes it.

I made a patch 
and it gets rid of the nsdb0 problem for me and at least a few others who have
emailed me.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Lamar Owen]

On Friday 06 June 2003 11:50, Don Baccus wrote:
> On Friday 06 June 2003 08:12 am, Lamar Owen wrote:
> > The other side effect (that we've been seeing complained about lately) is
> > related to the following in acs-tcl

> I didn't bother mentioning these because I thought pointing out the problem
> with ns_getform would get people's attention :)

Excellent point.  I just wanted to correlate, since the driver was initially
questioned.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Don Baccus]

On Friday 06 June 2003 08:12 am, Lamar Owen wrote:
> On Thursday 05 June 2003 22:28, Don Baccus wrote:
> > The implementation in AOLserver 4 is very, very different.  The script is
> > executed then the ENTIRE set of namespaces and procs are saved to the
> > server's "tcl.script" pointer.
>
> Argh!
>
> > One EVIL side effect of this is that some of the standard ns_* Tcl API is
> > implemented in Tcl, in some cases using global variables.  So, for
> > instance, I have a test case in which the following code:
>
> The other side effect (that we've been seeing complained about lately) is
> related to the following in acs-tcl

I didn't bother mentioning these because I thought pointing out the problem
with ns_getform would get people's attention :)

I'd kludged around some of these by initializing them in the request processor
before I figured out that our two calls to ns_evil were the problem.

> Methinks this could have bad side-effects, particularly if a thread without
> a pool and without handles executes ns_eval.  The next invocation of any of
> the db_* API could produce the uninitialized pool result 'nsdb0' (I knew I
> remembered that from somewhere -- I've seen the nsdb0 result before when a
> pool wasn't properly initialized (way back when the PostgreSQL driver was
> being beta tested for PostgreSQL 6.2.1, and AOLserver was at 2.2)).

This was the first problem I ran into, indeed, after kludging around it I ran
into the ns_getform problem and decided to start reading AOLserver sources
since I had no idea that ns_eval was the problem ...

> But this behavior of ns_eval could explain that problem, depending upon the
> timing of its execution, as well as where the ns_eval was used.

Yes, I believe you'll find that this is the problem.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Don Baccus]

On Friday 06 June 2003 08:15 am, Zoran Vasiljevic wrote:

> My initial idea was to simply make the Nsd as static package by doing
> Tcl_StaticPackage() at the end of InitInterp() and then do from Tcl:
>
> set interp [interp create]
> $interp eval {load "" Nsd}
> $interp eval [ns_ictl get]
>
> and so on... but this won't get the proper virtual server context
> so it'll skip the traces. Phew. I must dig little bit more there.

Right, if you skip the traces you don't get the module-defined ns_* commands,
we're on the same page here ... as far as this bit goes anyway.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Zoran Vasiljevic]

On Friday 06 June 2003 17:11, you wrote:
>
> how about:
> ns_interp sync
> ns_interp eval ?
>

Hey Tom, thanks!

 You just gave me the idea: extend the Tcl "interp" with custom
"ns_interp" and do the necessary plumbing on C level before
returning the interp to caller. This might work. Have to check yet.
I think the first "interp" subcommand we'd override would be the
create, so:

interp create == ns_interp create

but with additional step of preparing the interp aolserver-way
so we get all those extended commands. Well, this would mean
we'd need to introduce new ns_* command to the cmd set.
Let see if anybody comes with the better idea. If not, I think this
might be the way to go.
This could also take the ns_markfordelete, for example:

ns_interp markfordelete

or similar. Well, well...

Zoran


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Zoran Vasiljevic]

On Friday 06 June 2003 17:11, Don Baccus wrote:
> On Friday 06 June 2003 08:03 am, Zoran Vasiljevic wrote:
> > Nevertheles, to be really fair, there is some more work to be done
> > under the hood to get this working. The problem is in 1/.
> > Simple "interp create" won't work since script passed to ns_eval
> > might contain ns_* commands which are not part of the virgin
> > Tcl interp.
>
> These get defined if you run the THREAD_INIT callbacks registered by
> various modules to define their ns_* API commands, no?  Or are there others
> I'm not aware of?  As I said, yesterday afternoon was the first time I
> looked at this code so I don't pretend to understand all of it fully.

Look for InitInterp() in nsd/tclinit.c. The problem is that, although most of
the commands are already loaded (call to NsTclAddCmds(interp, itPtr))
those created by running traces (as registered by loaded modules)
are run only in the context of the running virtual server.

My initial idea was to simply make the Nsd as static package by doing
Tcl_StaticPackage() at the end of InitInterp() and then do from Tcl:

set interp [interp create]
$interp eval {load "" Nsd}
$interp eval [ns_ictl get]

and so on... but this won't get the proper virtual server context
so it'll skip the traces. Phew. I must dig little bit more there.

Zoran


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Lamar Owen]

On Thursday 05 June 2003 22:28, Don Baccus wrote:
> The implementation in AOLserver 4 is very, very different.  The script is
> executed then the ENTIRE set of namespaces and procs are saved to the
> server's "tcl.script" pointer.

Argh!

> One EVIL side effect of this is that some of the standard ns_* Tcl API is
> implemented in Tcl, in some cases using global variables.  So, for
> instance, I have a test case in which the following code:

The other side effect (that we've been seeing complained about lately) is
related to the following in acs-tcl:
00-database-procs-oracle.tcl:global errorInfo errorCode
00-database-procs-oracle.tcl:global db_state
00-database-procs-oracle.tcl:global errorInfo errorCode
00-database-procs-oracle.tcl:global env
00-database-procs-oracle.tcl:global env
00-database-procs-postgresql.tcl:global errorInfo errorCode
00-database-procs-postgresql.tcl:global errorInfo errorCode
00-database-procs-postgresql.tcl:global db_state
00-database-procs-postgresql.tcl:global errorInfo errorCode
00-database-procs-postgresql.tcl:global tcl_platform
00-database-procs-postgresql.tcl:global errorCode
00-database-procs.tcl:global db_state
00-database-procs.tcl:  global errorInfo errorCode
00-database-procs.tcl:  global errorInfo errorCode
00-database-procs.tcl:global db_state
00-database-procs.tcl:global errorInfo errorCode
00-database-procs.tcl:  global errorInfo errorCode
00-database-procs.tcl:  global errorInfo errorCode
00-database-procs.tcl:global db_state
00-database-procs.tcl:  global errorInfo errorCode
00-database-procs.tcl:  global errorInfo errorCode
00-database-procs.tcl:  global errorInfo errorCode
00-database-procs.tcl:  global errorInfo errorCode
00-database-procs.tcl:global db_state
00-database-procs.tcl:global db_state
00-database-procs.tcl:# global db_state(handles) is a list of handles that
have been allocated.
00-database-procs.tcl:# global db_state(n_handles_used) is the number of
handles in this list that are

Methinks this could have bad side-effects, particularly if a thread without a
pool and without handles executes ns_eval.  The next invocation of any of the
db_* API could produce the uninitialized pool result 'nsdb0' (I knew I
remembered that from somewhere -- I've seen the nsdb0 result before when a
pool wasn't properly initialized (way back when the PostgreSQL driver was
being beta tested for PostgreSQL 6.2.1, and AOLserver was at 2.2)).

Maybe I'm wrong, but I did trace through all of that code, and the only way I
could see ns_pg_bind getting passed a table name of nsdb0 was through
something external to the thread changing the global state variable
'db_state'.  Now maybe I'm not grokking it correctly, but the proc
'db_with_handle' is mixing state between a global and an nsv (through a call
to db_nth_pool_name, which uses the nsv 'db_available_pools').

Again, maybe I'm off-base a little, but I went through the code the other day
(after Mohan's report of a driver issue, which isn't really a driver issue)
and determined that the code paths in AOLserver 3.x and AOLserver 4.x for
pool creation, handle availability and creation, and the various data
structures between the database driver, the pool API, and the handle API
hadn't changed in a significant way.

But this behavior of ns_eval could explain that problem, depending upon the
timing of its execution, as well as where the ns_eval was used.

So, when a patch for OpenACS that doesn't use ns_eval is ready, those of you
who have problems with the nsdb0 stuff, if yu could please determine whether
the elimination of ns_eval fixes it.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Tom Jackson]

Don Baccus wrote:

I would love to have time to contribute to AOLserver

It sounds like you just contributed 4 hours tracking down a bug.

Yes, that's my thinking, too.  An "ns_sync" tthat copies state and "ns_eval"
that works as it did in AOLserver3 would probably both be useful.


how about:
ns_interp sync
ns_interp eval ?
--Tom Jackson

--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Don Baccus]

On Friday 06 June 2003 08:03 am, Zoran Vasiljevic wrote:

> Nevertheles, to be really fair, there is some more work to be done
> under the hood to get this working. The problem is in 1/.
> Simple "interp create" won't work since script passed to ns_eval
> might contain ns_* commands which are not part of the virgin
> Tcl interp.

These get defined if you run the THREAD_INIT callbacks registered by various
modules to define their ns_* API commands, no?  Or are there others I'm not
aware of?  As I said, yesterday afternoon was the first time I looked at this
code so I don't pretend to understand all of it fully.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Zoran Vasiljevic]

On Friday 06 June 2003 16:12, Don Baccus wrote:
> On Friday 06 June 2003 02:53 am, Zoran Vasiljevic wrote:
> > On Friday 06 June 2003 11:48, you wrote:
> > > Zoran Vasiljevic wrote:
> > > > I would love to hear some other oppinions. But, I'm already thinking
> > > > about what we'd need to do so that both approaches are available.
> > >
> > > My simple guess would be that the easiest solution would be to
> > > 1/ create a temporary interpreter
> > > 2/ eval the initialization code in it
> > > 3/ eval the code entered in ns_eval
> > > 4/ grab the new initialization code
> >
> > Good point :)
> > Zoran
>
> Yes, this would be an easy spin-off of the existing code I believe.

Nevertheles, to be really fair, there is some more work to be done
under the hood to get this working. The problem is in 1/.
Simple "interp create" won't work since script passed to ns_eval
might contain ns_* commands which are not part of the virgin
Tcl interp. I will have to investigate what we need to do to get the
1/ run properly. When this is solved, the rest is trivial.

Zoran


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Don Baccus]

On Friday 06 June 2003 02:53 am, Zoran Vasiljevic wrote:
> On Friday 06 June 2003 11:48, you wrote:
> > Zoran Vasiljevic wrote:
> > > I would love to hear some other oppinions. But, I'm already thinking
> > > about what we'd need to do so that both approaches are available.
> >
> > My simple guess would be that the easiest solution would be to
> > 1/ create a temporary interpreter
> > 2/ eval the initialization code in it
> > 3/ eval the code entered in ns_eval
> > 4/ grab the new initialization code
>
> Good point :)
> Zoran

Yes, this would be an easy spin-off of the existing code I believe.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Don Baccus]

On Thursday 05 June 2003 11:36 pm, Zoran Vasiljevic wrote:

> This effect is not exactly stated in the docs, right, but it is the way
> the new mechanism (look at ns_ictl) is working, yes.
> The purpose was to enable people to sync-up interps at runtime
> allowing for dynamical load of packages and stuff, w/o bringing
> the server down or doing some custom tcl sourcing.

Yes, I did look at ns_ictl and "ns_ictl update" (in effect) is what gets run
after ns_eval copies all your namespaces to the server's interpreter
tcl.script (for those who haven't dug in the code it builds a script that
defines all procs and namespaces/variables with their current values and
stores it in tcl.script, then runs it when each interpreter is updated or
created)

> > One EVIL side effect of this is that some of the standard ns_* Tcl API is
> > implemented in Tcl, in some cases using global variables.  So, for
> > instance, I have a test case in which the following code:
> >
> > set form_size [ns_set size [ns_getform]]
>
> Well, this is kind of bad, I agree. Heh, "ns_evil", ... I like it :)

Kinda bad, indeed, dude!

> > This is ... non-intuitive.  Especially if one RTFMs and expects the
> > behavior to be at least someone like the behavior that's described ...
>
> So much has changed in 4.0... were all trying to keep all pieces
> fit together.
> BTW, the FM's would love to see volunteers that  would spend
> an hour or two with some of them :)

You spend two hours working on OpenACS documentation and I'll spend two hours
working on AOLserver docs, how's that? :)

I would love to have time to contribute to AOLserver (well, I did contribute
the virtual server additions to ns_cache and did lots of work on the postgres
driver once upon a time), but I don't I'm afraid.  Lack of time's the only
reason, though.

> > Now the one use of ns_eval in OpenACS that causes the above problem can
> > be fixed by simply switching to nsvs (probably a good idea anyway) but
> > the documentation for ns_eval should be changed, perhaps?  I have a hard
> > time seeing the new functionality being all that useful ...
>
> After some thinking, I came to conclusion that actually both
> functionalities are very useful. Sometimes I just want to sync-up the
> interps, for whatever reason, with just one hit (as what new ns_eval does).
> Sometimes I may want to run one single command in all interps not
> replicating the whole interp enchilada over and over (like the older one
> does).
>
> I would love to hear some other oppinions. But, I'm already thinking about
> what we'd need to do so that both approaches are available.

Yes, that's my thinking, too.  An "ns_sync" tthat copies state and "ns_eval"
that works as it did in AOLserver3 would probably both be useful.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Zoran Vasiljevic]

On Friday 06 June 2003 11:48, you wrote:
> Zoran Vasiljevic wrote:
> > I would love to hear some other oppinions. But, I'm already thinking
> > about what we'd need to do so that both approaches are available.
>
> My simple guess would be that the easiest solution would be to
> 1/ create a temporary interpreter
> 2/ eval the initialization code in it
> 3/ eval the code entered in ns_eval
> 4/ grab the new initialization code

Good point :)
Zoran


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Wojciech Kocjan]

Zoran Vasiljevic wrote:
I would love to hear some other oppinions. But, I'm already thinking about
what we'd need to do so that both approaches are available.
My simple guess would be that the easiest solution would be to
1/ create a temporary interpreter
2/ eval the initialization code in it
3/ eval the code entered in ns_eval
4/ grab the new initialization code
This way you should achieve the same effect as with ns_eval in 3.x
(since the new initialization code would not copy all the things in
current interpreter). Just my guess, though.
--
WK
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Zoran Vasiljevic]

On Friday 06 June 2003 04:28, you wrote:

> The implementation in AOLserver 4 is very, very different.  The script is
> executed then the ENTIRE set of namespaces and procs are saved to the
> server's "tcl.script" pointer.

This effect is not exactly stated in the docs, right, but it is the way
the new mechanism (look at ns_ictl) is working, yes.
The purpose was to enable people to sync-up interps at runtime
allowing for dynamical load of packages and stuff, w/o bringing
the server down or doing some custom tcl sourcing.

>
> This means that when interpreters are updated (as happens when an
> interpreter's created for a new thread, for instance) ALL of the global
> variables in the new thread have the values in the old thread.  ns_eval {
> ...script ... } , then, is really a "synch all interpreters" command that
> first evaluates the given script.

Yes, it is rather "sync all interpreters" and "in all threads" behaviour.

>
> One EVIL side effect of this is that some of the standard ns_* Tcl API is
> implemented in Tcl, in some cases using global variables.  So, for
> instance, I have a test case in which the following code:
>
> set form_size [ns_set size [ns_getform]]

Well, this is kind of bad, I agree. Heh, "ns_evil", ... I like it :)

>
> fails because another script has done an ns_eval and _ns_form was set in
> that thread to "t3".   In the failing thread [ns_getform] has never been
> called, yet it's seeing _ns_form with the value t3 - an ns_set which does
> not exist in its context, of course.
>
> This is ... non-intuitive.  Especially if one RTFMs and expects the
> behavior to be at least someone like the behavior that's described ...

So much has changed in 4.0... were all trying to keep all pieces
fit together.
BTW, the FM's would love to see volunteers that  would spend
an hour or two with some of them :)

>
> Now the one use of ns_eval in OpenACS that causes the above problem can be
> fixed by simply switching to nsvs (probably a good idea anyway) but the
> documentation for ns_eval should be changed, perhaps?  I have a hard time
> seeing the new functionality being all that useful ...

After some thinking, I came to conclusion that actually both functionalities
are very useful. Sometimes I just want to sync-up the interps, for whatever
reason, with just one hit (as what new ns_eval does). Sometimes I may want
to run one single command in all interps not replicating the whole interp
enchilada over and over (like the older one does).

I would love to hear some other oppinions. But, I'm already thinking about
what we'd need to do so that both approaches are available.

Cheers,
Zoran


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Mark AUFFLICK]

Although the ability to properly do what ns_eval used to at least claim todo
could be very useful - for instance I believe that would solve the problem
Peter Marklund hit when he was trying to allow the OpenACS package manager
to enable newly installed packages without a server re-start, which would
be a _very_good_thing_

just my 2c.

Don Baccus wrote:

  On Thursday 05 June 2003 07:36 pm, Nathan Folkman wrote:
  
  
We could rename the command to be "ns_evil". :-)

  
  
You've got my vote!

Actually ... as currently implemented it would probably be better to just
rename it "ns_synch" or the like.

global foo
set foo bar
ns_eval {}

is equivalent to

ns_eval {
   global foo
   set foo bar
}

In that both whomp on your entire global space and "foo" is available and set
to "bar" in both cases to other interps.

Just to shortcut you a bit, ns_eval is now in nsd/init.tcl where it calls
_save_namespaces:

proc ns_eval {args} {
set len [llength $args]

if {$len == 0} {
return
} elseif {$len == 1} {
set args [lindex $args 0]
}

set code [catch {uplevel 1 $args} result]

if {$code == 1} {
# TCL_ERROR: Dump this interp to avoid proc pollution.
ns_markfordelete
} else {
# Save this interp's namespaces for others.
_ns_savenamespaces
}

return -code $code $result
}

The old code first evaluated the script to make sure there were no errors then
set things up so other interps would run it ASAP.

I can see why the current approach is used ... there might be any number of
ns_evals run before the next update of an interp is done in the current
scheme.  Without immediately evaluating the script in all interps (so it can
be tossed and later replaced by the script attached to later ns_eval calls)
it's hard to see how the old semantics can be maintained.

Maybe it's just a bad idea and people should use nsvs that have proper locking
etc.  ns_eval could log a bold warning saying "I'm EVIL don't use me!" and I
wouldn't care :)


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/
  


--
Mark Aufflick
 e: [EMAIL PROTECTED]
 w: www.pumptheory.com
 p: +61 438 700 647






--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Don Baccus]

On Thursday 05 June 2003 07:36 pm, Nathan Folkman wrote:
> We could rename the command to be "ns_evil". :-)

You've got my vote!

Actually ... as currently implemented it would probably be better to just
rename it "ns_synch" or the like.

global foo
set foo bar
ns_eval {}

is equivalent to

ns_eval {
   global foo
   set foo bar
}

In that both whomp on your entire global space and "foo" is available and set
to "bar" in both cases to other interps.

Just to shortcut you a bit, ns_eval is now in nsd/init.tcl where it calls
_save_namespaces:

proc ns_eval {args} {
set len [llength $args]

if {$len == 0} {
return
} elseif {$len == 1} {
set args [lindex $args 0]
}

set code [catch {uplevel 1 $args} result]

if {$code == 1} {
# TCL_ERROR: Dump this interp to avoid proc pollution.
ns_markfordelete
} else {
# Save this interp's namespaces for others.
_ns_savenamespaces
}

return -code $code $result
}

The old code first evaluated the script to make sure there were no errors then
set things up so other interps would run it ASAP.

I can see why the current approach is used ... there might be any number of
ns_evals run before the next update of an interp is done in the current
scheme.  Without immediately evaluating the script in all interps (so it can
be tossed and later replaced by the script attached to later ns_eval calls)
it's hard to see how the old semantics can be maintained.

Maybe it's just a bad idea and people should use nsvs that have proper locking
etc.  ns_eval could log a bold warning saying "I'm EVIL don't use me!" and I
wouldn't care :)


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

Re: [AOLSERVER] ns_eval is EVIL in AOLserver 4

[Nathan Folkman]

We could rename the command to be "ns_evil". :-) Just kidding - we'll
take a look.

Don Baccus wrote:

 > And there are only two ns_evals in the entire OpenACS toolkit and
 > they'll be
 > easy to get rid of.


--
Nathan Folkman
Technical Mgr., AOLserver/NPE/NES
Web Services and Publishing


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/

[AOLSERVER] ns_eval is EVIL in AOLserver 4

[Don Baccus]

Here's the documentation on the aolserver.com website, which describes how it
works in AOLserver 3:

"ns_eval evaluates the Tcl passed in to this function. The Tcl is evaluated in
all the Tcl interpreters for this virtual server. You can use this command to
maintain global variables. For example, if you execute:

ns_eval set g 1

in one interpreter, later operations will see $g equal to 1 no matter what
interpreter they are assigned to. "

The implementation in AOLserver 4 is very, very different.  The script is
executed then the ENTIRE set of namespaces and procs are saved to the
server's "tcl.script" pointer.

This means that when interpreters are updated (as happens when an
interpreter's created for a new thread, for instance) ALL of the global
variables in the new thread have the values in the old thread.  ns_eval {
...script ... } , then, is really a "synch all interpreters" command that
first evaluates the given script.

One EVIL side effect of this is that some of the standard ns_* Tcl API is
implemented in Tcl, in some cases using global variables.  So, for instance,
I have a test case in which the following code:

set form_size [ns_set size [ns_getform]]

fails because another script has done an ns_eval and _ns_form was set in that
thread to "t3".   In the failing thread [ns_getform] has never been called,
yet it's seeing _ns_form with the value t3 - an ns_set which does not exist
in its context, of course.

This is ... non-intuitive.  Especially if one RTFMs and expects the behavior
to be at least someone like the behavior that's described ...

Now the one use of ns_eval in OpenACS that causes the above problem can be
fixed by simply switching to nsvs (probably a good idea anyway) but the
documentation for ns_eval should be changed, perhaps?  I have a hard time
seeing the new functionality being all that useful ...

If I sound annoyed it's because I just spent about four hours tracking down
why one certain operation in OpenACS was causing ns_getform to fail after an
ns_returnredirect.   On the bright side I've been through all of the
AOLserver thread code and the connection thread code so know all about how
thread init and create callbacks are registered and more stuff than I even
want to think about at the moment ...

And there are only two ns_evals in the entire OpenACS toolkit and they'll be
easy to get rid of.


--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list: http://www.aolserver.com/listserv.html
List information and options: http://listserv.aol.com/