Re: [PD-dev] 0.43 omission: 'set-startup' and 'set-path'
Hi, On Wed, Jul 21, 2010 at 09:09:59PM -0700, Miller Puckette wrote: [declare] sets a path local to the patch it's in. ... and to the abstractions used in the patch it's in, at least at the moment. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 omission: 'set-startup' and 'set-path'
On 22/07/10 05:09, Miller Puckette wrote: Oh yes, and -lib itself needs somehow to be made to work locally to the patch, but this is a huge issue I don't know how to deal with. At first glance it should be possible to have canvas-local objectmakers and have the put on load list put the absolute pathname of the dll instead of just the name, but maybe there are some libraries that simply cannot be dlopen()d more than once by the same executable due to clashing exported symbols or so? I don't know enough about dlopen() to say! I'm sorta working on this, but there are a whole nest of things all interconnected with each other: 1. paths and search order, currently it's roughly this afaict: a. search relative to patch b. search this patch's declared paths c. search relative to parents (a and b) d. search global paths 2. loader plugins currently plugins have to do their own searching which means it's not consistent with local first priorities (ie, foo.pd next to the patch is overriden by some random library) 3. libraries and import scopes/namespaces a. libraries can register multiple objects, which might nameclash b. import/declare should have a way to bring only certain names from a library into unqualified scope eg: [import Gem maxlib maxlib/scale] then [scale] would be from maxlib and [Gem/scale] and [maxlib/scale] would work too c. http://lists.puredata.info/pipermail/pd-dev/2010-07/015606.html section Clearer Error Messages explains more 4. abstractions kinda second class citizens because they can't register classes how about if an abstraction is found, it is registered magically? enabling caching, but what if the file is modified outside of pd? 5. efficiency checking 100 or more files for a failed object is excessive especially if this is repeated many times Claude -- http://claudiusmaximus.goto10.org ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 omission: 'set-startup' and 'set-path'
Ok, part of the confusion of this conversation comes from my not
seeing that sys_set_path and sys_set_startup are run before
pdtk_pd_startup in sys_startgui(). Forgive me, that's a frightening
long collection of #ifdefs... ;) So now I understand that your
startup procedure does set those things.
Part of what I was trying to do with the main proc in pd-gui.tcl is
have the GUI's whole startup procedure in one place as part of the
process of making pd and pd-gui more independent. the 'set-startup'
and 'set-path' messages to pd are part of that as well, allowing the
GUI to ask pd for things it needs when it needs them rather than
always relying on pd to send it.
So there is a kind of startup conversation that happens in the
beginning, right now the messages passed from pd to pd-gui are mostly
topical, only setting a specific thing. Then there is pdtk_pd_startup
and pd init which are big grabbags of stuff in a single message. I
think we should move away from the grabbag messages and make all the
messages direct, like set pd_whichmidiapi 4 (see addendum). Then
the pd-gui startup procedure can be based on when it has the info it
needs. If pd-gui can request that info, then it means that you can
set the pd-gui startup procedure in Tcl only, not needing to rely on
pd for the startup order.
In order for that to happen, Tcl needs to be able to request that info
and know when it has received a reply. With a single process, you get
that built-in with a function call. We need to create that over the
network socket. The best way I've found so far is to send a request
like 'pd set-startup' then vwait for the reply. Perhaps this bit
should be formalized into an API.
So I don't really have a problem leaving out the new messages to pd,
but I think that we should not be slipping back into making more of pd-
gui's startup in pd, and that's what sticking all that stuff in
pdtk_pd_startup does. That said, I don't see way to have the original
startup work without adding some kind of message to 'pd'.
(also, looking at it again, pd_path really should be called
sys_searchpath, since that's what its called in C).
---
(addendum)
---
here are the messages that are sent when pd and pd-gui startup
pd--pd-gui
set pd_whichmidiapi 4
set ::pd_path {}
set ::startup_flags {}
set ::startup_libraries {}
pdtk_pd_startup 0 43 0 {test1} {} {} {Monaco} normal
set pd_whichmidiapi 4
set pd_whichapi 4
pd-gui--pd
pd init /Users/hans/code/pure-data/git.pure-data/src 0
8 5 10
9 6 11
10 6 13
12 7 15
14 8 17
16 10 20
18 11 22
24 14 30
30 18 37
36 22 45
;
.hc
On Jul 21, 2010, at 11:45 PM, Hans-Christoph Steiner wrote:
On Jul 21, 2010, at 11:23 PM, Miller Puckette wrote:
Right about the lappend thing -- but if the whole thing goes into a
single
message it can break buffer size limits in Pd (that's the reason I
broke it
up).
Yeah... I'll see what I can come up with tomorrow.
I think the values can stay insync unless pd somehow is initiating
changes
outside the dialog mechanism -- and I'd suggest not doing that for
other
reasons.
Sure, but pd-gui needs to get those values from pd to start with.
Otherwise they are blank until the dialogs are opened. There are
multiple ways of keeping this in sync. One would be having anything
that needs those values send 'pd set-path' and 'pd set-startup'
before they need them. Another would be to have the functions in pd
that set this send the updated info to the GUI whenever they are
called.
OTOH, the path is always the global path, not the one belonging to
any
specific patch - so it's probably useless to the gui anyway, hmm.
Things like [declare] can set the global path, IIRC. ::pd_path
and ::pd_startup are not useless in pd-gui, they are used for
loading GUI plugins and building the Help Browser based on installed
libraries, and could be used in a lot of other things.
.hc
On Wed, Jul 21, 2010 at 11:16:20PM -0400, Hans-Christoph Steiner
wrote:
Yeah, I just realized that problem with the lappend looking at the
code, the solution is to make set-path and set-startup build up the
whole string in C space, then send it in a single
sys_vgui(set ::pd_path ...). I'm going to dig into this and
IOhannes' jack/network startup troubles tomorrow.
The plugins can of course access those variables whenever, but if
they
are blank and/or not in sync with the values that 'pd' has, they are
not very useful. The problem with the head of git is that ::pd_path
and ::pd_startup are only ever set when you open their respective
dialog panels. As far as I can tell, they are not set to the same
values that 'pd' has as part of the startup procedure.
.hc
On Jul 21,
Re: [PD-dev] 0.43 omission: 'set-startup' and 'set-path'
OTOH, the path is always the global path, not the one belonging to any specific patch - so it's probably useless to the gui anyway, hmm. Things like [declare] can set the global path, IIRC. ::pd_path and ::pd_startup are not useless in pd-gui, they are used for loading GUI plugins and building the Help Browser based on installed libraries, and could be used in a lot of other things. .hc [declare] sets a path local to the patch it's in. There might have to be changes in declare allowing abstractions to change the path even without having the owning patch change (this is the subject of much comfusion and worry :) [declare] also loads 'libraries', which are then global. Probably when that happens it would be apropriate for pd to throw the info up to the gui (but not via the startup variable -- that would need to reflect only what's there by default when starting Pd afresh). Oh yes, and -lib itself needs somehow to be made to work locally to the patch, but this is a huge issue I don't know how to deal with. cheers M ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 omission: 'set-startup' and 'set-path'
Hi Hans -- the vwait line didn't seem correct to me (could return right after Pd says to clear pd_path, before the other messages bubble up to append the various directories to it). I ended up fixing Pd to volunteer the path and startup stuff before sending pdtk_pd_startup so that none of the tcl side of things should be needed any longer. OTOH if you were planning to send pd set-startup etc at some later point in the tcl code, this would need to be supported in Pd...(?) cheers Miller On Fri, Jul 16, 2010 at 03:58:24PM -0400, Hans-Christoph Steiner wrote: Hey Miller, I just noticed that you left out a key part of pd-gui-rewrite in 0.43. There is the 'set-startup' and 'set-path' messages which allows pd-gui to get the state of those things without having to open the respective preference dialog panels. The changes are in m_glob.c and s_path.c, as well as these lines in pd-gui.tcl: pdsend pd set-startup ;# get ::startup_libraries and ::startup_flags lists pdsend pd set-path;# get the ::pd_path list vwait ::pd_path ;# wait for 'pd' to respond .hc We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 omission: 'set-startup' and 'set-path'
Yeah, I added the pd set-startup, etc. stuff to m_glob.c and s_path.c. Regardless of the startup procedure, I think pd-gui should be able to request state from pd so it can stay in sync. A dialog shouldn't be required to get this info. This is akin to IOhannes' idea that pd-gui's state should be settable by pd at any point while running. Then it makes sense to reuse the same procedure for getting the state in the startup procedure, rather than having a custom method for only the startup procedure. .hc On Jul 16, 2010, at 10:59 PM, Miller Puckette wrote: Hi Hans -- the vwait line didn't seem correct to me (could return right after Pd says to clear pd_path, before the other messages bubble up to append the various directories to it). I ended up fixing Pd to volunteer the path and startup stuff before sending pdtk_pd_startup so that none of the tcl side of things should be needed any longer. OTOH if you were planning to send pd set-startup etc at some later point in the tcl code, this would need to be supported in Pd...(?) cheers Miller On Fri, Jul 16, 2010 at 03:58:24PM -0400, Hans-Christoph Steiner wrote: Hey Miller, I just noticed that you left out a key part of pd-gui-rewrite in 0.43. There is the 'set-startup' and 'set-path' messages which allows pd-gui to get the state of those things without having to open the respective preference dialog panels. The changes are in m_glob.c and s_path.c, as well as these lines in pd-gui.tcl: pdsend pd set-startup ;# get ::startup_libraries and ::startup_flags lists pdsend pd set-path;# get the ::pd_path list vwait ::pd_path ;# wait for 'pd' to respond .hc We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
