nico wrote:

for now, pd tell me this: link error 0 dyld: /usr/local/bin/pd Undefined symbols: _Tcl_LinkVar

short: you have to link agains the tcl-libraries.

but: i am not really sure what you want to do. if you want to create a faster connection between the pd-core (the C-code) and the pd-gui (a small server in C and the tcl/tk interpreter) then you'll be out of luck, since the address spaces of the 2 processes will be protected against each other. (you cannot just peep into the data of another application; imagine the security hole)

Tcl_LinkVar should work on the pd-gui side (but that is almost certainly not what you want).

if you are writing something from scratch (like a tcl-interpreter as a pd-external) you will be lucky again.

of course i have no idea what i am writing about, so it might be all wrong.

mfg.asd.r IOhannes

nico wrote:

hi

what does mean link against tcl-librairies. my staring point was you "howto write an external", and you don't write anything about that ((((

well, the document is about "how to write an external" and not "how to write C-programs" (there are better books out there that cover this)

in the first line i've put: #include <tcl.h> #include "m_pd.h" but it doesn't seem to be enough

no it is not.

the header-files just tell the computer that there are other functions in the world out there which the compiler didn't knew before. they keep it from thinking that you are just inventing names. however, when you use these functions, the unit that executes your code (when running the external) needs to know what they actually do. thus you have to tell the computer, where it should look for a function like Tcl_LinkVar() (if it would go and search your entire harddisk for a function like Tcl_LinkVar() this would take ages): you normally do this in the link-process, where you tell the linker that it should consider certain files ("libraries") to look for functions it does not know.

therefore you have to link your external to the tcl-library. how you tell your linker to do this, depends on your linker, so you should read the documentation for your linker. wth gcc, you add libraries with the "-l" flag, so "ld -ltcl8.4 tclexternal.o tclexternal.pd_darwin" will link your "tclexternal.o" with "libtcl8.4.so" (or the like) to produce "tclexternal.pd_darwin"

mfg.a.sdr IOhannes

hi nico,

btw, if you want to run Tk, there would be a further difficulty of having to start a separate thread for the Tcl event loop.

I wonder if anybody has ever experimented with in-process pd-gui?

Krzysztof

nico wrote:

THAAAAAAAAANKS

...

-ltcl8.4

On Thu, Aug 25, 2005 at 06:42:54PM +0200, nico wrote:

hi, how are you...

...

btw, if you want to run Tk, there would be a further difficulty of having to start a separate thread for the Tcl event loop.

i've made a starkit wich run pd with nogui and interact with pd using [netsend] [netreceive] from pd parts and socket & socket -server from tcl part but, tk does not update correctly data it receives via socket (i believe it's because parsing proc invoke too many work)

my pd GUI works like this, at first my tries didnt work (was blocking the entire tk event loop). but eventually a combination of mathieu's emails and some tutorial circa tcl 7.3 worked..

you can get the code from cvs -d :pserver:anonymous@cvs.sf.net:cvsroot/pure-data co -r devel_0_39 pd/src/pd*tk* heres the relevant server bits:

variable pd_send
if {[catch {set pd_send [socket localhost 4400]}]} {set pd_send -1} {puts "connected $pd_send"}
catch {
set pd_receive [socket -server ::pd::receive_conn 4401]
}
proc receive_conn {s addr port} {
fileevent $s readable [list ::pd::receive $s]
fconfigure $s -buffering line -blocking 0
puts "connection from $addr"
}
proc receive {s} {
set l [gets $s]
if {[eof $s]} {
    close $s
} else {
    if {[catch {eval $l}]} {puts "error in: $l"}
    }
}
proc send {msg} {
variable pd_send
if {$pd_send ne -1} {

# puts "sending: $msg" puts $pd_send [concat $msg ;] flush $pd_send } }

so, i had i idea: i will make an external to link tcl variable with pd variable, without using network. is it a bad idea?

if you get an in-process interpreter thread running as an external, please post!, id love to try..

carmen

so, in your opinion, is it correct: Tcl_EvalFile at the creation of an object in order to source a tcl file containig a proc in pd a function like void tclvar_togui(Tcl_Interp *interp, t_floatarg f) { Tcl_Eval(interp, "fire 3"); return TCL_OK; } in pd in order to launch the tcl proc in another gui the same Tcl_EvalFile pd launch the tcl proc, the other gui display the proc result????

it seems weird, but can 2 gui can comunicate like that?

best regards nico