[MPlayer-dev-eng] [PATCH] vo_macosx.m - test proxy messages

[Ulion]

2007/11/25, Ulion <ulion2002 at gmail.com>:
> 2007/11/25, Chris Welton <electrostatic_1 at yahoo.com>:
> >
> > --- Chris Welton <electrostatic_1 at yahoo.com> wrote:
> >
> > >
> > > --- Ulion <ulion2002 at gmail.com> wrote:
> > >
> > > > 2007/11/25, Chris Welton
> > > > <electrostatic_1 at yahoo.com>:
> > > > > Just because there is a registered connection
> > > > named
> > > > > "mplayerosx" with a proxy object does not mean
> > > we
> > > > > should assume it will respond to our messages.
> > > >
> > > > shared-buffer mode of mplayer vo_macosx only used
> > > by
> > > > MPlayer OS X, why
> > > > you think this? If for remove all warning
> > > messages,
> > > > maybe we should
> > > > set a proxy protocol for it instead of the
> > > > obj_msgSend call, it looks
> > > > a low level work of Cocoa which already be done
> > > > under the framework I
> > > > think.
> > > >
> > > > >
> > > > > This patch asks it before pushing data.
> > > >
> > > > As I said, I think the Cocoa already check that,
> > > if
> > > > obj not accept
> > > > some call, it will print error log and keep going.
> > > >
> > > > >
> > > > > Also removes redundant id to type
> > > > NSAutoReleasePool
> > > >
> > > > Is it necessary?
> > > >
> > > > --
> > > > Ulion
> > > > _______________________________________________
> > > > MPlayer-dev-eng mailing list
> > > > MPlayer-dev-eng at mplayerhq.hu
> > > >
> > >
> > http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> > > >
> > >
> > > As for the autorelease pool, yes it is somewhat
> > > necessary, as you are leaving the other one pointing
> > > to an object which no longer exists. You could set
> > > that object to nil and then make a new one, but
> > > there
> > > is no real need to. One works fine.
> > >
> > > As for whether proxy automatically checks, I don't
> > > know, but I do know other objects don't.. I'll test
> > > it.
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > ____________________________________________________________________________________
> > > Be a better pen pal.
> > > Text or chat with friends inside Yahoo! Mail. See
> > > how.  http://overview.mail.yahoo.com/
> > > _______________________________________________
> > > MPlayer-dev-eng mailing list
> > > MPlayer-dev-eng at mplayerhq.hu
> > >
> > http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> > >
> >
> > Nope, as per usual, it doesn't test, it crashes
> > hard...
> > I arbitrarily added
> >
> >   [mplayerosxProxy whackaMole];
> >
> > and got this...
> >
> > Nov 25 07:06:28 powerbook-g4-17 crashdump[25510]:
> > mplayer crashed
> > Nov 25 07:06:31 powerbook-g4-17 crashdump[25510]:
> > crash report written to:
> > /Users/chrisw/Library/Logs/CrashReporter/mplayer.crash.log
> > -------------------------------------------------------
> > 007-11-25 07:06:26.761 mplayer[25509] An uncaught
> > exception was raised
> > 2007-11-25 07:06:26.761 mplayer[25509] *** -[NSProxy
> > doesNotRecognizeSelector:whackaMole] called!
> > 2007-11-25 07:06:26.761 mplayer[25509] *** Uncaught
> > exception: <NSInvalidArgumentException> *** -[NSProxy
> > doesNotRecognizeSelector:whackaMole] called!
> > 2007-11-25 07:06:28.616 MPlayer OSX PPC[25507]
> > Abnormal playback error. mplayer returned error code:
> > 5
>
> OK, it will crash if remote object does not support your method, but
> as I said, the shared-buffer mode only works with MPlayer OS X,
> there's no reason to assume it is working with another program, if it
> did, crash is an acceptable result as I see, it suppose not work with
> other frontends unless the frontends support the interface(protocol)
> the proxy be called. Or may be we should try to set protocol for the
> proxy to see whether things going to better.

Now I wrote a patch to use protocol and remove all warnings and check
whether remote object support out messages:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-November/055166.html

Try it to see whether that meet your needs, and thanks for your
suggestion of code.

-- 
Ulion