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

[Ulion]

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.


-- 
Ulion