I cc'ed the Pd-list since I think this is relevent there.
On Nov 29, 2010, at 8:40 PM, András Murányi wrote:
2010/11/29 András Murányi muranyia@gmail.com Hello HC,
i was just trying to pick this up, but i'm kinda confused with the new startup order. It seems at the moment of load_startup_plugins(), which is by the end of pdtk_pd_startup() we don't yet have a functional ::pdwindow::verbose to print on the console. (Also, the '---done with main---' message at the end of main doesn't appear on my console.)
Do you have an idea on this?
the "done with main" thing was just a debug message. So the verbose proc doesn't work in a plugin?
Plus (i couldn't go into it, but) it seems to me that startup plugins are run twice.
It seems this is because both $::sys_searchpath and $::sys_staticpath contains ~/pd-externals (where i keep these plugins). Is it my error that i've added it once to my patch list or is it like this for everyone? And - do you think a mechanism to prevent loading a plugin more than once is necessary?
Andras
Sounds like you have ~/pd-externals added as a path via the preferences. Its now part of the hard-coded sys_staticpath.
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
2010/11/30 Hans-Christoph Steiner hans@at.or.at
I cc'ed the Pd-list since I think this is relevent there.
On Nov 29, 2010, at 8:40 PM, András Murányi wrote:
2010/11/29 András Murányi muranyia@gmail.com
Hello HC,
i was just trying to pick this up, but i'm kinda confused with the new startup order. It seems at the moment of load_startup_plugins(), which is by the end of pdtk_pd_startup() we don't yet have a functional ::pdwindow::verbose to print on the console. (Also, the '---done with main---' message at the end of main doesn't appear on my console.)
Do you have an idea on this?
the "done with main" thing was just a debug message. So the verbose proc doesn't work in a plugin?
it doesn't - and imo it's strange that it doesn't work at the end of main{} either
Plus (i couldn't go into it, but) it seems to me that startup plugins are run twice.
It seems this is because both $::sys_searchpath and $::sys_staticpath contains ~/pd-externals (where i keep these plugins). Is it my error that i've added it once to my patch list or is it like this for everyone? And - do you think a mechanism to prevent loading a plugin more than once is necessary?
Sounds like you have ~/pd-externals added as a path via the preferences. Its now part of the hard-coded sys_staticpath.
Yes, that's the situation. I'm just worried that other people may have 'double' entries too, which could cause all kinds of weirdnesses in the future, not only with plugins. One of the following methods could be implemented: a) When sys_searchpath and sys_staticpath are concatenated (or even before) we filter out double entries b) We don't let the user add a folder to sys_searchpath which is already in sys_staticpath c) We just make sure that load_startup_plugins{} doesn't load the same plugin twice I'd recommend a)
Andras
On Nov 30, 2010, at 2:28 PM, András Murányi wrote:
2010/11/30 Hans-Christoph Steiner hans@at.or.at
I cc'ed the Pd-list since I think this is relevent there.
On Nov 29, 2010, at 8:40 PM, András Murányi wrote:
2010/11/29 András Murányi muranyia@gmail.com Hello HC,
i was just trying to pick this up, but i'm kinda confused with the new startup order. It seems at the moment of load_startup_plugins(), which is by the end of pdtk_pd_startup() we don't yet have a functional ::pdwindow::verbose to print on the console. (Also, the '---done with main---' message at the end of main doesn't appear on my console.)
Do you have an idea on this?
the "done with main" thing was just a debug message. So the verbose proc doesn't work in a plugin?
it doesn't - and imo it's strange that it doesn't work at the end of main{} either
Plus (i couldn't go into it, but) it seems to me that startup plugins are run twice.
It seems this is because both $::sys_searchpath and $::sys_staticpath contains ~/pd-externals (where i keep these plugins). Is it my error that i've added it once to my patch list or is it like this for everyone? And - do you think a mechanism to prevent loading a plugin more than once is necessary?
Sounds like you have ~/pd-externals added as a path via the preferences. Its now part of the hard-coded sys_staticpath.
Yes, that's the situation. I'm just worried that other people may have 'double' entries too, which could cause all kinds of weirdnesses in the future, not only with plugins. One of the following methods could be implemented: a) When sys_searchpath and sys_staticpath are concatenated (or even before) we filter out double entries b) We don't let the user add a folder to sys_searchpath which is already in sys_staticpath c) We just make sure that load_startup_plugins{} doesn't load the same plugin twice I'd recommend a)
Andras
That is a good point. I guess a) makes sense.
For c) I guess there should be some kind of array that stores the full path of a particular plugin once its been loaded, so then we can check and prevent double-loading.
.hc
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
2010/11/30 Hans-Christoph Steiner hans@at.or.at
On Nov 30, 2010, at 2:28 PM, András Murányi wrote:
2010/11/30 Hans-Christoph Steiner hans@at.or.at
I cc'ed the Pd-list since I think this is relevent there.
On Nov 29, 2010, at 8:40 PM, András Murányi wrote:
2010/11/29 András Murányi muranyia@gmail.com
Hello HC,
i was just trying to pick this up, but i'm kinda confused with the new startup order. It seems at the moment of load_startup_plugins(), which is by the end of pdtk_pd_startup() we don't yet have a functional ::pdwindow::verbose to print on the console. (Also, the '---done with main---' message at the end of main doesn't appear on my console.)
Do you have an idea on this?
the "done with main" thing was just a debug message. So the verbose proc doesn't work in a plugin?
it doesn't - and imo it's strange that it doesn't work at the end of main{} either
Plus (i couldn't go into it, but) it seems to me that startup plugins are run twice.
It seems this is because both $::sys_searchpath and $::sys_staticpath contains ~/pd-externals (where i keep these plugins). Is it my error that i've added it once to my patch list or is it like this for everyone? And - do you think a mechanism to prevent loading a plugin more than once is necessary?
Sounds like you have ~/pd-externals added as a path via the preferences. Its now part of the hard-coded sys_staticpath.
Yes, that's the situation. I'm just worried that other people may have 'double' entries too, which could cause all kinds of weirdnesses in the future, not only with plugins. One of the following methods could be implemented: a) When sys_searchpath and sys_staticpath are concatenated (or even before) we filter out double entries b) We don't let the user add a folder to sys_searchpath which is already in sys_staticpath c) We just make sure that load_startup_plugins{} doesn't load the same plugin twice I'd recommend a)
Andras
That is a good point. I guess a) makes sense.
treating only load_plugin_script{} could be done with something like this: pd-gui.tcl:625 << foreach pathdir [concat $::sys_searchpath $::sys_staticpath] {
foreach pathdir [lsort -unique [concat $::sys_searchpath
$::sys_staticpath]] { but i guess the C code uses the pathes often, too? then it would be better to unite them into a dupe-less single variable there, and use that everywhere
For c) I guess there should be some kind of array that stores the full path of a particular plugin once its been loaded, so then we can check and prevent double-loading.
...or plugins could check their objects are unused but i say let the 'server' do the check rather than the 'client'
Andras
On Nov 30, 2010, at 4:54 PM, András Murányi wrote:
2010/11/30 Hans-Christoph Steiner hans@at.or.at
On Nov 30, 2010, at 2:28 PM, András Murányi wrote:
2010/11/30 Hans-Christoph Steiner hans@at.or.at
I cc'ed the Pd-list since I think this is relevent there.
On Nov 29, 2010, at 8:40 PM, András Murányi wrote:
2010/11/29 András Murányi muranyia@gmail.com Hello HC,
i was just trying to pick this up, but i'm kinda confused with the new startup order. It seems at the moment of load_startup_plugins(), which is by the end of pdtk_pd_startup() we don't yet have a functional ::pdwindow::verbose to print on the console. (Also, the '---done with main---' message at the end of main doesn't appear on my console.)
Do you have an idea on this?
the "done with main" thing was just a debug message. So the verbose proc doesn't work in a plugin?
it doesn't - and imo it's strange that it doesn't work at the end of main{} either
Plus (i couldn't go into it, but) it seems to me that startup plugins are run twice.
It seems this is because both $::sys_searchpath and $::sys_staticpath contains ~/pd-externals (where i keep these plugins). Is it my error that i've added it once to my patch list or is it like this for everyone? And - do you think a mechanism to prevent loading a plugin more than once is necessary?
Sounds like you have ~/pd-externals added as a path via the preferences. Its now part of the hard-coded sys_staticpath.
Yes, that's the situation. I'm just worried that other people may have 'double' entries too, which could cause all kinds of weirdnesses in the future, not only with plugins. One of the following methods could be implemented: a) When sys_searchpath and sys_staticpath are concatenated (or even before) we filter out double entries b) We don't let the user add a folder to sys_searchpath which is already in sys_staticpath c) We just make sure that load_startup_plugins{} doesn't load the same plugin twice I'd recommend a)
Andras
That is a good point. I guess a) makes sense.
treating only load_plugin_script{} could be done with something like this: pd-gui.tcl:625 << foreach pathdir [concat $::sys_searchpath $::sys_staticpath] {
foreach pathdir [lsort -unique [concat $::sys_searchpath
$::sys_staticpath]] { but i guess the C code uses the pathes often, too? then it would be better to unite them into a dupe-less single variable there, and use that everywhere
For c) I guess there should be some kind of array that stores the full path of a particular plugin once its been loaded, so then we can check and prevent double-loading.
...or plugins could check their objects are unused but i say let the 'server' do the check rather than the 'client'
hehe, this is sounding good right now, let's wait and see what happens, and then fix according to the problems that arise. :-)
.hc
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
2010/11/30 Hans-Christoph Steiner hans@at.or.at
I cc'ed the Pd-list since I think this is relevent there.
On Nov 29, 2010, at 8:40 PM, András Murányi wrote:
2010/11/29 András Murányi muranyia@gmail.com
Hello HC,
i was just trying to pick this up, but i'm kinda confused with the new startup order. It seems at the moment of load_startup_plugins(), which is by the end of pdtk_pd_startup() we don't yet have a functional ::pdwindow::verbose to print on the console. (Also, the '---done with main---' message at the end of main doesn't appear on my console.)
Do you have an idea on this?
the "done with main" thing was just a debug message. So the verbose proc doesn't work in a plugin?
it doesn't - and imo it's strange that it doesn't work at the end of main{} either
Plus (i couldn't go into it, but) it seems to me that startup plugins are run twice.
It seems this is because both $::sys_searchpath and $::sys_staticpath contains ~/pd-externals (where i keep these plugins). Is it my error that i've added it once to my patch list or is it like this for everyone? And - do you think a mechanism to prevent loading a plugin more than once is necessary?
Sounds like you have ~/pd-externals added as a path via the preferences. Its now part of the hard-coded sys_staticpath.
Yes, that's the situation. I'm just worried that other people may have 'double' entries too, which could cause all kinds of weirdnesses in the future, not only with plugins. One of the following methods could be implemented: a) When sys_searchpath and sys_staticpath are concatenated (or even before) we filter out double entries b) We don't let the user add a folder to sys_searchpath which is already in sys_staticpath c) We just make sure that load_startup_plugins{} doesn't load the same plugin twice I'd recommend a)
Andras
That is a good point. I guess a) makes sense.
treating only load_plugin_script{} could be done with something like this: pd-gui.tcl:625 << foreach pathdir [concat $::sys_searchpath $::sys_staticpath] {
foreach pathdir [lsort -unique [concat $::sys_searchpath
$::sys_staticpath]] { but i guess the C code uses the pathes often, too? then it would be better to unite them into a dupe-less single variable there, and use that everywhere
For c) I guess there should be some kind of array that stores the full path of a particular plugin once its been loaded, so then we can check and prevent double-loading.
...or plugins could check their objects are unused but i say let the 'server' do the check rather than the 'client'
hehe, this is sounding good right now, let's wait and see what happens, and then fix according to the problems that arise. :-)
.hc
Pif (French cartoon) would say: "ONF!" :o)
Andras
-
András Murányi -
Hans-Christoph Steiner