Re: [Audacity-devel] Scripting improvements committed

[Michael C. <mc...@gm...>]

Hi Leland,

Thanks for looking into this.

I haven't been able to build with the new mac project from xcode -
mod-script-pipe gives the error:

I've tried messing around with the "Mach-O Type" to no avail.  Any ideas?

My mac build breaks with:
Ld "/Users/apple/cvscheckouts/audacity/mac/build/Debug
Static/modules/mod-script-pipe.so" normal ppc
<snip>
/Developer/usr/bin/../libexec/gcc/powerpc-apple-darwin8/4.0.1/ld:
-single_module or -multi_module flags can only be used when -dylib is also
specified
collect2: ld returned 1 exit status



On Wed, Jun 3, 2009 at 8:30 PM, Dan Horgan <da...@go...> wrote:

> On Wed, Jun 03, 2009 at 01:29:17AM -0400, Michael Chinen wrote:
> > <SNIP>
> >
> > If I understand it correctly, you only will have one command being
> executed
> > at a time.
> > So it is okay to block the script thread while the previous command is
> being
> > executed by the main thread (assuming the input will be buffered on the
> pipe
> > - I'm not knowledgeable about the pipe part.)  This simple structure will
> > also prevent the creation of new XCommandEvents.
> >
> > Also, have you looked at wxCondition (or the pthreads version)?  It seems
> > like the right idea since it will make the script wait until a previous
> one
> > finishes:
> > http://docs.wxwidgets.org/stable/wx_wxcondition.html#wxcondition
> >
> > You could have two wxConditions belong to the AppCommandEvent - one to
> > unblock the script thread after the command has been finished, and
> another
> > to keep the XCommandEvent around (before it gets deleted) so that the
> Script
> > thread can access it's member variables to get a message out to send to
> the
> > script.  The first wxCondition would have its Wait called on the script
> > thread, and Broadcast() on the main thread (in Apply.)  The other
> > wxCondition wuld have its Wait() in Apply(), and Broadcast() on the
> > scripting thread.  I don't think this would cause any deadlocks.
>
> Thanks, this sounds like a good approach. One thing I'm hesitant about
> though is storing the wxConditions in the event - firstly I don't want
> to have to worry about what happens to the events behind the scenes
> (copying etc), and secondly keeping them separate might be useful later
> on in case we want to change things to allow unprompted 'responses'
> (i.e. script waits until notified that certain event has occurred in the
> app).  The alternative at the moment would probably be putting them in
> ScriptCommandRelay, which currently means making them static.
>
> Anyway, I presume it is ok to block the main thread briefly in order to
> make
> sure the script thread is not accessing the shared data, rather than
> losing responses?
>
> >
> > I put a little time in to look at the script, and to try to get it
> working
> > with audacity, but I think mod-script-pipe isn't compiling to a library
> yet
> > for mac.  Or am I mistaken?   For starters I modified it to recognize mac
> > machines.
>
> Hopefully Leland's update has sorted this out...
>
>
> Thanks,
> Dan
>