[jfcarroll]

Of the list of issue in the earlier post, I've resolved most.

As far as keyword processing goes, while SWIG doesn't support it, I managed to put it in a few key places where it seems to be used frequently. Namely:

xbmcaddon.Addon constructor
xbmcgui.ListItem constructor
xbmcgui.ListItem.setInfo
xbmcgui.ListItem.addContextMenuItems

xbmcgui.ListItem.setInfo will now handle any type passed in the dictionary infoLabels by converting all entry values to unicode strings.

The major remaining issue (that I know of) is that some scripts expect "os.getcwd" to return the directory the script is in. This is a general problem with running configure with --enable-external-python (setting #define USE_EXTERNAL_PYTHON) rather than my current implementation so I'd appreciate some comments on how best to address this.

Currently Apple Movie Trailers will run - as long as you start xbmc from within the ~/.xbmc/addons/plugin.video.apple.movie.trailers.lite/ directory (avoiding the above problem for this one script) and as long as you fix the few places other than those listed where the script expects to be able to use keywords in function calls.

Now I'm really looking for some feedback.

Thanks
Jim

[Robotica]

I think the folks from xbmc are the only one that could give you feedback about those very essential patches... Sorry that I can't help you.

[jmarshall]

Hi Jim,

Regarding the os.getcwd() that is something that the script IMO should NEVER be relying on. Reason is that in pure python it's not stable if the interpreter is running 2 different scripts - getcwd() is global and not per-thread. We currently have a wrapper just for making it threadsafe, which is just plain silly when you think about it.

Is there anywhere where a script actually needs to know it's current folder? I can't think of any, but if there is then XBMC providing that information directly seems sane enough to me.

Rest assured your work isn't being ignored - we're wrapping up Dharma at the moment and binary addons are the next immediate priority, which basically involves hooking up your work on SWiG and utilizing cpluff more in the way it was intended to load the appropriate libs etc.

Cheers,
Jonathan

[spiff]

jonathan, as i've informed jcarrol, i'm explicitly forcing use of getAddonInfo('path') instead of os.cwd on all pulls. we should have rooted out most usage in our repo by now.

[jmarshall]

Perfect

[jfcarroll]

Cool. This is a general problem with the hack used to get between python and the os. Overriding cwd was only one thing it did. It's also used for all "special://xxxxx" path translations. There's an xbmc module method ("translatePath") that does this and should be used explicitly by the scripts, rather than relying on a hacked os module in python to do the translation.

[Robotica]

can't wait to create some addons in other languages. This project is still alive?

[jfcarroll]

It's not dead. It needs a bit more before it's ready, including:

The TODO file contains:
--------------------------------------------------
- Clean up the Makefile.

- Fix the linking.

- std:tring should take None from Python. This will require changing the std_string.i typemap so that it understands XBMCAddon::String::nullString

- Better code comments.

- MS Windows

- SWIG java
---- Need to do a typemap for List/Arraylist <-> std::vector and Map/HashMap <-> std::map to support native groovy list/dict types.

- Figure out Window.setAnimations since there is a list of tuples passed in.

- A bad script causes the entire thing to exit. This is way to frequent and has several causes. First, the RuntimeError is probably not the right mapping for our exceptions. But we also frequently get the stupid message about the frame being left open when Py_EndInterpreter is called.
---- This is related to a bug in SWIG: http://sourceforge.net/tracker/?func=det...tid=101645
---- Temporary work around requires never calling Py_EndInterpreter when there is more than one currently open interpreter (which happens in multi-threaded scripts) and allowing the shutdown of Python itself to handle all of the cleanup.
--------------------------------------------------

Beyond that there's:

1) There's a method or two more that needs implementing
2) A means to plug in dynamically the support for other languages. I envision the dependency mechanism being used for this but I haven't worked out any details.
3) I'm waiting for feedback from the developers in case there's a significant change in direction they require - or they simply don't want it.

Thanks for your interest though. If you want to help me with any of these let me know. The git repository is identified in the first post.

Thanks
Jim

[jfcarroll]

*This was originally posted on another Thread. It makes more sense here so I moved it*

Another update.

Some of the updates:
1) There is a new xbmc fork in my git account. I will be deleting the previous repository at some point in the near future. The git url is: [email][email protected]:jimfcarroll/xbmc.git[/email] . This is in sync with the newly reshuffled codebase.
2) The build system is now consistent. You no longer need to hack the link line. Use "--enable-swigaddons" during configure.

Keep in mind there are still some issues:
1) The biggest problem is a bug in SWIG. I can't seem to get the SWIG guys to respond - or even tell me they're too busy. The bug report can be found here:

http://sourceforge.net/tracker/?func=det...tid=101645

Attached to the bug report is a well documented test case that reproduces the problem. If anyone that knows the native side of python well wants to help, PLEASE take a look.

Currently I've worked around the bug by preventing xbmc from ever calling Py_EndInterpreter whenever multiple interpreters get opened simultaneously (which only happens in multi-threaded scripts). This is a total hack but as long as Py_Finalize cleans up everything correctly it shouldn't cause any real issues.

2) Again, most scripts that wont run "out-of-the-box" have at least one of two possible problems:
a) SWIG doesn't support keywords. While I put it back in by hand for some of the places where many scripts assumed it would exist, in some cases the scripts will need to be modified.
b) Scripts can no longer assume that the python 'os' module can handle paths with the 'special://' prefix. They need to be translated explicitly in the scripts.

3) I need to do more testing on the reshuffled code base

Next steps:
I'm currently working on dynamically loading the scripting engine itself. This will mean that the core xbmc will not need to be compiled against python at all. The python support will be loaded dynamically when a script needs it. The dynamic library containing the python support will need to be built against python for the particular platform.

[Robotica]

Hi Jim,

I've seen lots of commits of you related to locking and threading. But your SWIG git seems idle... Is there an update on this project?

Thanks for all those efforts...

[jfcarroll]

Hey, thanks. Yeah. Believe it or not it's related - through a long string of dependencies. It's like a ball of twine; once you start pulling on a string you need to unravel the entire thing to put it back together again.

For several reasons I want the plugins to run outside of the xbmc process space. Unfortunately, 'fork' is not available on some of the platforms we build for so I need to use a system call. In order to do a system call I need a separate executable that the plugins run in. However, I need to either use, or duplicate, a bunch of xbmc code in the separate executable. In order to use the code (since I really don't want to duplicate it) I need to make it usable as a library. However, xbmc libraries, because of their history, currently have circular dependencies which make them inseparable from the other libraries. I need to fix the circular dependencies in a bunch of xbmc functionality. The most basic of these is threading. The next will be utilities. At that point I might have enough to move back to the separable plugin process.

[Robotica]

aha.. that clears a lot. It's a lot of work to have a separable plugin process to make multiple programming languages available in XBMC. But as I understand, XBMC core is revised a lot (in a very useful and positive way).

It never sounded easy in the first place ;-)

[garbear]

You, good sir, definitely have your work cut out for you (:

[Robotica]

I see you finished the threading part: 382 (PR)

Thanks! Great work...

[jfcarroll]

Waiting for eden.