[PD-dev] 0.43 omission: 'set-startup' and 'set-path'

[Hans-Christoph Steiner]

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.