Comments on jimmy.thinking: Embedding IronPython in Silverlight - Importing

from System.Net import WebClient url="http://...

2011-10-21T00:47:00.866-07:00

from System.Net import WebClient
url="http://example.com/xxx.mp3"
filename="billy111.mp3"
WebClient().DownloadFile(url, filename)
=========================================
AttributeError: 'WebClient' object has no attribute 'DownloadFile'

i have a question. what is attributeError?

what should i do? please tell me.

from south.korea

email : logostri123@naver.com

>>> Isn't this an interpreter problem...

2010-01-12T14:37:45.779-08:00

>>> Isn't this an interpreter problem?

Well, it's not something IronPython can address; it's a VM problem. The CLR does not support "continuations", which are what you're explaining ... pause the execution of a thread (lifting the current state), change that thread's instruction pointer (bring in it's state), and then at some point resuming execution at the original fork.

Without this there is no way to write a procedular (synchronous) import hook in Silverlight which runs on the UI thread (just like JavaScript), without hanging the UI thread. Not hanging the UI thread is importnant, since Silverlight runs in the same process as Firefox and IE, so the entire browser, including all tabs running in the browser, will hang. In Chrome all plugins run in a different process, but Chrome is extremely sensitive to processes not responding, and it will tear down a blocked plugin process very agressively.

However, you could write this asynchronously, but it doesn't look very Pythonic.

downloading_import 'foo', on_complete
def on_complete(module)
module.bar() # equivalent to foo.bar()
# rest of your program

You can also imagine running the Python code on a background thread to start, and when the import begins immediately dispatching the download to the UI thread, stopping the user-code background thread, and when the download is completed restarting the background thread. However, changing the thread user-code runs on would make writing Python code more painful, since it would require an explicit dispatch to the UI thread for all UI manipulations.

>>> Not sure what to make
>>> with script tags?
It's just a simpler application model for Python browser apps.

>>> I suppose neither interactive nor Prism style applications
>>> are feasible right now using the DLR. So what is precisely
>>> the selling point? Wasn't interactivity one of yours on your
>>> own blog?

What made you come to that conclusion? The DLR lets you treat everything as a string, and you can download things as much as you want, but no asynchronous activities can happen while running user-code; user-code blocks until it finishes, as there is no way to interrupt (unless you run on another thread like I suggested above).

What exactly do you want to do that you don't think is possible with the DLR?

Isn't this an interpreter problem? I don't...

2009-12-20T02:09:56.014-08:00

Isn't this an interpreter problem? I don't see why the interpreter can't pause on import. The UI might be frozen or creates a wait indicator - something I do consider for my own app. This should be easier than doing general interrupts of the interpreter which doesn't work either right now.

Not sure what to make with script tags? I suppose neither interactive nor Prism style applications are feasible right now using the DLR. So what is precisely the selling point? Wasn't interactivity one of yours on your own blog?

@kayschluehr we already support this with the new ...

2009-12-04T18:18:34.249-08:00

@kayschluehr we already support this with the new script-tags feature. The decision to use script-tags was because you need a list of files to download when the page starts --- you cannot pause the execution of the script to asynchronously download something, and then resume execution (the CLR does not support continuations). Async downloading is required because all downloading in the browser is done on the UI thread.

For more documentation about this, read: http://ironruby.com/browser/sl-back-to-just-text.pdf

This quite naturally raises the question of module...

2009-11-15T00:13:15.713-08:00

This quite naturally raises the question of modules/scripts not living in the xap file containing also the DLR?

It might be possible ( I haven't checked this ) to write import hooks used to load scripts from remote URLs but this would be out of touch with the DLR and its API which standardizes access beyond individual languages. Moreover each application developer had to create their own import infrastructure supplement - something I'd like to avoid if I can.