Hi all,
two small questions: Q1: suppose I'm working on an external: start pd, load it, control its behaviour, destroy it, change the code, recompile it, replace it *in the same session of PD*: is this supposed to crash pd? This happens to me, and the external debugging process means open/close pd million times (number varies according to coding skills ;-) Are there shortcuts to this?
Q2: If I have two externals with the same name, one in the same directory of the opened patch (which contains an instantiation of it) and the other in the pd search path, which one is loaded?
Thanks guys,
Alberto Zin
Hi Alberto,
Q1: suppose I'm working on an external: start pd, load it, control its behaviour, destroy it, change the code, recompile it, replace it *in the same session of PD*: is this supposed to crash pd? This happens to me, and the external debugging process means open/close pd million times (number varies according to coding skills ;-) Are there shortcuts to this?
it won't crash pd, because once an object (with a certain name) is
loaded, it won't be loaded again in the same session. The code stays
active until you restart pd. The OS will decide if you can replace
the binary file of the external object in use. I think Windows
doesn't allow that.
Q2: If I have two externals with the same name, one in the same directory of the opened patch (which contains an instantiation of it) and the other in the pd search path, which one is loaded?
you can use -verbose to see the search order. I think the one in the
patcher dir is loaded first, but i'm just guessing....
greetings, Thomas
-- Thomas Grill http://grrrr.org
On Mon, 11 Sep 2006, Thomas Grill wrote:
Hi Alberto,
Q1: suppose I'm working on an external: start pd, load it, control its behaviour, destroy it, change the code, recompile it, replace it *in the same session of PD*: is this supposed to crash pd?
it won't crash pd, because once an object (with a certain name) is loaded, it won't be loaded again in the same session. The code stays active until you restart pd. The OS will decide if you can replace the binary file of the external object in use. I think Windows doesn't allow that.
It *can* crash pd. dlopen() uses mmap(), which transparently reads the file from disk. What matters is whether the same inode is reused. If you overwrite the file using gcc, it uses open() in O_TRUNC mode, so the same inode is reused, and a crash may occur. If another program, say cp or mv, removes the old filename before doing open(), or uses link() or rename(), then the file is not overwritten, only the filename, so that pd still uses the old file even though that file lost its name.
correct me if I'm wrong... but I'm sure I've seen pd crash when doing "make". I believe it depends on whether you use "make install" or load the external directly from where it was compiled.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
This happens to me, and the external debugging process means open/close pd million times (number varies according to coding skills ;-) Are there shortcuts to this?
one further note.... you should actually use a debugger (like gdb,
ddd or IDE-integrated ones like Xcode or MSVC) to analyze your code.
You can start pd in it, with the respective command-line options. It
will save you a lot of time, once you are used to it.
greetings, Thomas
-- Thomas Grill http://grrrr.org
-
alberto.zin＠poste.it -
Mathieu Bouchard -
Thomas Grill