[PD-dev] 0.43 omission: 'set-startup' and 'set-path'
Hans-Christoph Steiner
hans at at.or.at
Thu Jul 22 23:21:33 CEST 2010
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, 2010, at 10:59 PM, Miller Puckette wrote:
>>>
>>>> I meant to keep it on dev -- must have hit the wrong flavor of
>>>> 'reply' by
>>>> accident, will try to remember to CC dev back in.
>>>>
>>>> I think pd_path is sent to tcl when pd starts up, and then
>>>> afterward
>>>> any changes to it are initiated by the gui (which can then simply
>>>> store
>>>> the new value it sends down to Pd, if it's going to need it for
>>>> anything).
>>>> This is all OK unless there's some mechanism I don't know about for
>>>> changing
>>>> the path from within pd (in which case I'd propose that pd send the
>>>> new
>>>> value up to the GUI on its own initiative).
>>>>
>>>> Ditto the 'startup' path -- pd volunteers it at startup so the GUI
>>>> always
>>>> knows what it is.
>>>>
>>>> Problem with waiting for pd_path is that pd sends the path up in a
>>>> sequence
>>>> of messages like:
>>>>
>>>> set ::pd_path {}
>>>> lappend ::pd_path {foo}
>>>>
>>>> and you have no way of ascertaining which 'lappend' terminates the
>>>> sequence so
>>>> that ::pd_path is now correct. In my version, when you see
>>>> "pdtk_pd_startup"
>>>> you know that ::pd_path and ::startup_libraries are no longer
>>>> going to get
>>>> any lappends.
>>>>
>>>> Unless I'm really missing something, plugins (or anyone else) can
>>>> access
>>>> ::pd_path and ::startup_libraries at will, no?
>>>>
>>>> cheers
>>>> Miller
>>>>
>>>>
>>>> On Wed, Jul 21, 2010 at 10:28:01PM -0400, Hans-Christoph Steiner
>>>> wrote:
>>>>>
>>>>> Quick question, do you prefer to keep this off pd-dev? I'd
>>>>> prefer it
>>>>> on the list so others can weigh in.
>>>>>
>>>>> Removing the set-startup almost completely breaks the loading of
>>>>> plugins, for example. pd_path is also used in the Help Browser so
>>>>> that
>>>>> it will display all libraries that are installed anywhere in the
>>>>> path. It also means that plugins can't search the path like 'pd'
>>>>> can,
>>>>> so things like a installed class browser plugin would no longer be
>>>>> possible.
>>>>>
>>>>> I am not married to the implementation, but I do see the
>>>>> functionality
>>>>> as essential. I don't see the difference between waiting on
>>>>> "pdtk_pd_startup" to be sent via a network socket, or waiting the
>>>>> contents of pd_path being sent over the same network socket. You
>>>>> can
>>>>> even set pd_path to blank and that will trigger the vwait
>>>>> properly.
>>>>> So your current startup procedure relies on:
>>>>>
>>>>> sys_vgui("pdtk_pd_startup %d %d %d {%s} %s %s {%s} %s\n",
>>>>>
>>>>> the pd-gui-rewrite/0.43 startup procedure relies on:
>>>>>
>>>>> sys_gui("set ::pd_path {}\n");
>>>>>
>>>>> Seems pretty close to me.
>>>>>
>>>>> .hc
>>>>>
>>>>> On Jul 21, 2010, at 9:54 PM, Miller Puckette wrote:
>>>>>
>>>>>> Hmm -- the only place I saw set-startup was in the startup tcl
>>>>>> code --
>>>>>> which I think could have only been called once. Is there an
>>>>>> easy-
>>>>>> to-
>>>>>> exhibit
>>>>>> problem in the code in sf/git (or is the problem in another
>>>>>> branch
>>>>>> somewhere?)
>>>>>>
>>>>>> Anyhow I'm just about sure there's no way code could work
>>>>>> robustly
>>>>>> waiting on
>>>>>> pd_path... some other means of syncing would be needed.
>>>>>
>>>>>>
>>>>>> cheers
>>>>>> M
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 21, 2010 at 04:21:00PM -0400, Hans-Christoph Steiner
>>>>>> wrote:
>>>>>>>
>>>>>>> Its already being actively used in the GUI rewrite, which is
>>>>>>> currently
>>>>>>> somewhat broken without it. I think the only client for that
>>>>>>> message
>>>>>>> really would be pd-gui, and I'd happily do the work to change
>>>>>>> it if
>>>>>>> need
>>>>>>> be. That's a much better option than omitting it.
>>>>>>>
>>>>>>> .hc
>>>>>>>
>>>>>>> Miller Puckette wrote:
>>>>>>>> My usual strategy on stuff like this is wait until someone is
>>>>>>>> actively
>>>>>>>> using it - because one's guess as to how the feature should
>>>>>>>> work
>>>>>>>> is never
>>>>>>>> how it's really needed when the time comes and then you're
>>>>>>>> stuck
>>>>>>>> maintaining
>>>>>>>> two different versions of the same thing :)
>>>>>>>>
>>>>>>>> M
>>>>>>>>
>>>>>>>> On Sat, Jul 17, 2010 at 12:15:30AM -0400, Hans-Christoph
>>>>>>>> Steiner
>>>>>>>> wrote:
>>>>>>>>> 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 at 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
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------------
>>>>>
>>>>> "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
>>>
>>>
>>>
>>> ----------------------------------------------------------------------------
>>>
>>> The arc of history bends towards justice. - Dr. Martin Luther
>>> King, Jr.
>>>
>
>
>
> ----------------------------------------------------------------------------
>
> I spent 33 years and four months in active military service and
> during that period I spent most of my time as a high class muscle
> man for Big Business, for Wall Street and the bankers. -
> General Smedley Butler
>
>
----------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
More information about the Pd-dev
mailing list