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
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)
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...
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
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.
>
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 |
|______________________________________________________________________|
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).
My initial guess was yes, and a quick check with tkcon confirms that.
> 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
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.)
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... :^(