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@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

_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Reply via email to