Jason Tackaberry wrote: > On Sun, 2008-02-17 at 21:37 +0100, Duncan Webb wrote: >> Sorry being think again, I don't get it. >> >> If a rpc method in the server is being called from a client why should I >> need to fix another method that is not obviously being used either by >> the server and definitely not by the client? > > I think we have been getting our wires crossed for the last several > emails. > > As I understand it, this is what's happening: > > 1. You're doing an RPC call > 2. The remote end returns what I assume is a TvProgram object. > 3. You are yielding the result, the TvProgram object, in a > coroutine > 4. The coroutine wrapper checks this result to see if it's > NotFinished (in order to decide if the coroutine needs to be > resumed later) > 5. As a result of this check, it implicitly calls TvProgram.__cmp__ > 6. TvProgram.__cmp__ expects only to be compared with other > TvProgram objects, and as a result blindly accesses the other > object's title attribute > 7. NotFinished does not have a title attribute. An exception is > raised. > > I think this is unambiguously a bug with TvProgram.__cmp__.
Yes the TvProgram.__cmp__() is clearly incorrect, as it only returns 0 or 1 and it only make sense to compare TvProgram objects with TvProgram objects, the __cmp__() was very broken :( Interestingly, the __cmp__ was being called by the TvGuide many many times just to determine if a program is equal to another program. I've fixed it be added an __eq__() and adding isinstance call in __eq__ and __cmp__. Having added __eq__() the TvGuide is now a little more responsive. > However I > have updated the coroutine code to check the object ids rather than > comparing them, so __cmp__ will be avoided. This is better anyway. Yes, it is very confusing getting errors in what appear to be unrelated methods. >> I must admit that I'm starting to think that kaa.coroutines are more >> trouble than they are worth. > > They're quite convenient things, I find. I'm still not certain you're > seeing them properly. But in they end, coroutines are just syntactic > sugar. If you prefer, you can always connect result handlers to > InProgress objects and break out the coroutine into smaller, regular > functions, and just chain them together into a state machine. My trouble is figuring out how to use them in the existing code, you need a pair of coroutines for them to be effective. But as you say I doubt that I'm seeing them correctly. Just about all the record_client calls are really quick (between 1/20 and 1/5 secs) and they are used in the user interface. So the rpc calls end up in the actions() methods of the plug-in interface and I don't think that these can be coroutines but this is something for me to try. The findNextProgramCo method does now work. Duncan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
