jemptymethod <
jempty...@gmail.com> wrote:
> First of all if the following is considered bad etiquette in this
> group let me know, but I've posted the meat of this already here:
>
https://stackoverflow.com/q/48971272/34806 I don't know how much
> crossover there is between here and there, and it's probably gotten
> as many views there as it will. If however this is frowned on I
> won't do it anymore
Referencing somewhere else isn't frowned upon. But it is preferable if
your posting here was mostly self contained (then we don't have to go
searching elsewhere for valuable information). In your case, it looks
like you've included just enough details.
> Within the same file I am trying to launch a server and a client with
> the following code:
>
> set port [tatu::startServer "" "" $tatu::options]
>
> set deskmlRunner {
> set viewer [file join $::starkit::topdir .. .. gui bin deskmlviewer.exe]
> #puts "$viewer http://localhost:$port"
> exec $viewer "http://localhost:$port"
> }
>
> after 1 $deskmlRunner
> vwait forever
Your code is sound, but your 'concept' is what has a flaw.
The 'exec' command asks the host OS to execute something. You
reference the ::starkit global above, implying you have packed this
executable into a starkit and are trying to run it from inside the
starkit itself.
This *will not work*. The host OS has no visibility to find or access
any files inside the starkit. This is because all of the files inside
the starkit are visible only because Tcl's file I/O handling takes care
of working out "is inside starkit" vs. "is in host OS filesystem" *for
Tcl code only*. The host OS, however, does not use Tcl's file I/O
handling routines, and so it can not see inside the starkit.
If you want to launch an executable that is stored inside a starkit,
you have to first use Tcl to copy it out of the starkit into a file in
the host OS's filesystem, and then launch that copy in the host OS's
filesystem.
> A) Is it possible to launch a server and client from the same
> interpreter as I'm attempting?
Yes, provided of course that both are event driven. Trying to do this
with one or both of them non-event driven will not work well.
> Might it be worth for me then to maybe try something using interp?
If you want to learn to use multiple interp's yes. But your issue is
not with client and server in same interp, but with a missunderstanding
of how the starkit virtual filesystem works. So multiple interps will
not help the issue you seem to be presenting here now.
> If at all possible I'd like to keep this all within the starkit
> (which the reader might have discerned from the reference to
> "$::starkit::topdir")
You can, but you *must* copy out any executables (and any required
*.dll files) to host OS accessible file(s) before you can launch them
using the host OS.
> B) Alternatively I could run a starkit within a starkit and maybe use
> an embedded tclkitsh that will launch the starkit also check for a
> scratch file with the port number that I could have the starkit
> output (or can a starkit return a value?) But then would I possibly
> run into the same issue, if it's even the issue, regarding trying to
> run the server and client from the same interpreter?
Still won't work, this would still try to ask the host OS to reach
inside the starkit and find a file inside, which it *cannot* do.