[PD] can't see objects Pd-0.40.3-extended-20071230-windowsxp-i386.exe
martin.peach at sympatico.ca
Mon Feb 25 15:18:36 CET 2008
Hans-Christoph Steiner wrote:
> On Feb 24, 2008, at 11:36 PM, Martin Peach wrote:
>> Hans-Christoph Steiner wrote:
>>> Ok, got a bit closer on this one, finally. It seems that all of the
>>> code is the same up thru tcl_mess() in t_tkcmd.c. Once the tcl data
>>> from sys_vgui() is sent to the tcl process and chopped up into
>>> distinct commands, tcl_mess() is used to send the command to the Tcl
>>> process ("tk_pdinterp" is the tcl process, "s" is the command):
>>> result = Tcl_Eval(tk_pdinterp, s);
>>> I tried to print out "s" here, but I couldn't get it to show up. It
>>> seems that stderr is a bit strange on Windows. My hunch is that
>>> something on Windows is eating the "$", and therefore causing this
>>> Anyone know a way to get this to show up on the Windows console:
>>> fprintf(stderr, "tcl_mess: %s\n", ms);
>> Try running pd from a .bat file.
>> Or fprint(stdout... instead.
> Using fprint(stdout... in the msys bash shell worked. It did not work
> in the CMD.EXE shell window, nothing shows up. Plus fprint(stderr...
> doesn't seem to work anywhere. Arg, Windows is a pain...
Windows tcl is a pain because it's not quite the same as unix tcl.
> So now, printing out the Tcl commands shows the "$" in "$text_color",
> etc. intact, so I guess it's dropping it in Tcl-space... on that note,
> I'm going to bed. Any ideas?
What it seemed like to me was that tcl thinks it's a different address
space so the variables defined in pd.tk are not recognized. If you could
get both ends to print out the name of their address space it might help.
More information about the Pd-list