changing the interpreter namespace
Ahmad El Husseini
I think my question was not clear ...
"namespace eval " evaluates code in a namespace context .. What i want is
that i want to be able to set the interpreters namespace to be a namespace
other than "::" eg:
say i have this namespace defined
namespace eval example {
variable eg
}
i want to change the interpreter's namespace to "::example" so that if i
typed the following
% set eg "first example"
i will be accessing the ::example::eg and setting its value.
Ahmad
"Wolfgang S. Kechel" <wolfgan...@prs.de> wrote in message
news:39BF5DA3...@prs.de...
Ahmad El Husseini wrote:
>
> I am wondering if there is a neat way to evaluate commands in a namespace
> other than "::" while typing commands on the interpreter without the need
to
> use fully qualified names or importing commands to the global namespace.
> what i need to do is to change interpreter namespace from the global
> namespace "::" to some other namespace ..
>
> Ahmad
Try:
namespace eval ....
--
Wolfgang Kechel Phone: ++49-(0)6 11-17 31-611
Patzschke + Rasp Software AG Fax: ++49-(0)6 11-17 31-31
Bierstadter Straße 7 mailto:wolfgan...@prs.de
D-65189 Wiesbaden Web Site: http://www.prs.de
Jeffrey Hobbs
>
> I think my question was not clear ...
> "namespace eval " evaluates code in a namespace context .. What i want is
> that i want to be able to set the interpreters namespace to be a namespace
> other than "::" eg:
>
> say i have this namespace defined
>
> namespace eval example {
> variable eg
> }
>
> i want to change the interpreter's namespace to "::example" so that if i
> typed the following
> % set eg "first example"
> i will be accessing the ::example::eg and setting its value.
You can use tkcon:
http://www.purl.org/net/hobbs/tcl/script/tkcon/
and the 'Attach To Namespace' facility. Hmmm, I have a much newer
version locally if the one at the above site doesn't have the feature.
--
Jeffrey Hobbs The Tcl Guy
hobbs at ajubasolutions.com Ajuba Solutions (née Scriptics)
Bruce Edge
to globals in a specific namespace. I don't want to always have to specify the
namespace in front of every variable. Is it possible to a proc to always
execute in a given namespace?
Thanks, Bruce.
Ahmad El Husseini wrote:
>
> I think my question was not clear ...
> "namespace eval " evaluates code in a namespace context .. What i want is
> that i want to be able to set the interpreters namespace to be a namespace
> other than "::" eg:
>
> say i have this namespace defined
>
> namespace eval example {
> variable eg
> }
>
> i want to change the interpreter's namespace to "::example" so that if i
> typed the following
> % set eg "first example"
> i will be accessing the ::example::eg and setting its value.
>
> Ahmad
>
> "Wolfgang S. Kechel" <wolfgan...@prs.de> wrote in message
> news:39BF5DA3...@prs.de...
Andreas Kupries
"Ahmad El Husseini" <ah...@u.washington.edu> writes:
> I am wondering if there is a neat way to evaluate commands in a
> namespace other than "::" while typing commands on the interpreter
> without the need to use fully qualified names or importing commands
> to the global namespace. what i need to do is to change interpreter
> namespace from the global namespace "::" to some other namespace ..
Use TkCon from Jeff Hobbs and then use the 'attach to namespace'
feature.
--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------
Ahmad El Husseini
I am wondering if there is a neat way to evaluate commands in a namespace
other than "::" while typing commands on the interpreter without the need to
use fully qualified names or importing commands to the global namespace.
what i need to do is to change interpreter namespace from the global
namespace "::" to some other namespace ..
Ahmad
Wolfgang S. Kechel
Ahmad El Husseini
proc SetNamespace {{Namespace {}}} {
set prompt "% "
if {[namespace tail $Namespace] != ""} {
set prompt "([namespace tail $Namespace]) % "}
while {1} {
puts -nonewline $prompt
flush stdout
set cmd [gets stdin]
while {![info complete $cmd]} {
set cmd "$cmd\n[gets stdin]"}
catch {namespace eval $Namespace $cmd} result
if {$result != ""} {
puts $result}}}
are there any real efficiency problems in the above code ???
the tkcon provides many extra options and features that i really dont want
the users to have (i am assuming the users to be totally computer illitrates
and will just use the commands i am designing for them).
======
Ahmad
"Jeffrey Hobbs" <jeffre...@ajubasolutions.com> wrote in message
news:39BFDC2E...@ajubasolutions.com...
> Ahmad El Husseini wrote:
> >
> > I think my question was not clear ...
> > "namespace eval " evaluates code in a namespace context .. What i want
is
> > that i want to be able to set the interpreters namespace to be a
namespace
> > other than "::" eg:
> >
> > say i have this namespace defined
> >
> > namespace eval example {
> > variable eg
> > }
> >
> > i want to change the interpreter's namespace to "::example" so that if i
> > typed the following
> > % set eg "first example"
> > i will be accessing the ::example::eg and setting its value.
>
Don Porter
> proc SetNamespace {{Namespace {}}} {
> set prompt "% "
> if {[namespace tail $Namespace] != ""} {
> set prompt "([namespace tail $Namespace]) % "}
> while {1} {
> puts -nonewline $prompt
> flush stdout
> set cmd [gets stdin]
> while {![info complete $cmd]} {
> set cmd "$cmd\n[gets stdin]"}
> catch {namespace eval $Namespace $cmd} result
> if {$result != ""} {
> puts $result}}}
>
> are there any real efficiency problems in the above code ???
During a session with multiple [SetNamespace] evaluations, the
code above will keep nesting [while {1}] loops deeper and deeper.
Eventually you will reach Tcl's stack limits.
The evaluations of [gets] block, so this strategy will leave
event-handling (including GUI) unresponsive.
Both of those big problems can be resolved by replacing the above
with an event-driven approach triggered by [fileevent stdin readable].
Then, if you want, you can address more cosmetic shortcomings...
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Jeffrey Hobbs
>
> How about doing the following:
>
> proc SetNamespace {{Namespace {}}} {
> are there any real efficiency problems in the above code ???
> the users to have (i am assuming the users to be totally computer illitrates
> and will just use the commands i am designing for them).
Aside from what Don noted, perhaps you want to have them run in a
different interpreter, to hide whatever details it is you are trying
to hide by using namespaces. This multiple intrepreter model is
what tkcon does to prevent interference between the 100s of commands
tkcon needs, and the actual environment the user wants to test their
programs in (with the dozen or so exceptions for commands I think
users want in a console).
Jeffrey Hobbs
>
> Jeffrey Hobbs <jeffre...@ajubasolutions.com> wrote:
>
> > Aside from what Don noted, perhaps you want to have them run in a
> > different interpreter, to hide whatever details it is you are trying
> > to hide by using namespaces. This multiple intrepreter model is
> > what tkcon does to prevent interference between the 100s of commands
> > tkcon needs, and the actual environment the user wants to test their
> > programs in (with the dozen or so exceptions for commands I think
> > users want in a console).
>
>
> I've got an application where it would be nice to have multiple
> "tkwait variable" calls (i.e. in parallel not nested).
>
> Can this be achieved if the tkwaits are issued in separate interpreters?
My initial guess was yes, and a quick check with tkcon confirms that.
Steve Landers
> Aside from what Don noted, perhaps you want to have them run in a
> different interpreter, to hide whatever details it is you are trying
> to hide by using namespaces. This multiple intrepreter model is
> what tkcon does to prevent interference between the 100s of commands
> tkcon needs, and the actual environment the user wants to test their
> programs in (with the dozen or so exceptions for commands I think
> users want in a console).
on a related subject ...
I've got an application where it would be nice to have multiple
"tkwait variable" calls (i.e. in parallel not nested).
Can this be achieved if the tkwaits are issued in separate interpreters?
--
Steve Landers phone: +61 8 9313 6868
Digital Smarties fax: +61 8 9313 6077
Perth, Western Australia e-mail: st...@digital-smarties.com
Donal K. Fellows
writes
>I have a similar need too, I have a set of procedures that all need to refer
>to globals in a specific namespace. I don't want to always have to specify the
>namespace in front of every variable. Is it possible to a proc to always
>execute in a given namespace?
Easy! Create the procedure in that namespace whose variables you wish
to refer to, and then use [namespace export] and [namespace import] (or
[interp alias]) to put a reference to the command created wherever you
want.
Donal.
--
Donal K. Fellows (at home)
--
FOOLED you! Absorb EGO SHATTERING impulse rays, polyester poltroon!!
(WARNING: There is precisely one error in this message.)
Donal K. Fellows
<jeffre...@ajubasolutions.com> writes
>Steve Landers wrote:
>> I've got an application where it would be nice to have multiple
>> "tkwait variable" calls (i.e. in parallel not nested).
>>
>> Can this be achieved if the tkwaits are issued in separate interpreters?
>
They work, but only imperfectly (assuming an unthreaded Tcl.) The
problem is that there is only one (1) C stack, and all those [vwait]s
(which are [tkwait variable]s by another name) have got to fit on it.
Outer ones cannot terminate properly (and so have their corresponding
script continue to execute) without the inner event handlers, those that
started the nested waiting, finishing first.
The only workaround is to use fully event-oriented programming, or keep
the waiting for modal dialogs only. This is not always easy, but life
is like that sometimes... :^(