<br><br><div class="gmail_quote">2009/10/26 Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org">guido@python.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Mon, Oct 26, 2009 at 2:47 AM, Michael Foord <<a href="mailto:fuzzyman@gmail.com">fuzzyman@gmail.com</a>> wrote:<br>
> Ironclad itself has binary compatibility with Python C extensions, they<br>
> don't need to be recompiled. It uses the .NET FFI (P/Invoke) to work with<br>
> these extensions and on the JVM would use its FFI.<br>
<br>
</div>Ok, but that assumes the C extensions are already compiled for CPython<br>
on that platform (presumably .NET). </blockquote><div><br><br>It uses the standard compiled binaries for CPython on Windows. Binary compatibility - so no need to compile a special version, just use the same binaries you use for CPython.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This sounds limiting, and hacky<br>
(need lots of faith in the DLL loader).</blockquote><div><br><br>It needs an *understanding* of the DLL loader sure. You seem to be relying a lot on faith these days (well - two emails today anyway).<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 I also assume that calls back<br>
into the CPython runtime are somehow intercepted and somewhat limited<br>
to what is reasonable to support in the .NET world -- unless you<br>
basically link all of CPython in and then you might as well just make<br>
RPCs to CPython...<br></blockquote><div><br><br>The CPython API is implemented so that calls to the API go through our code. This works in both directions (C extensions calling back into Python and Python calling into C extensions). Where the Python source code has C API functions that just call other functions we can reuse a lot of the CPython implementation, yes. This C code is running natively - it is *not* running on .NET, but where we need the bridge we use the FFI. <br>
<br>The API functions that, for example, create a new type create an IronPython type instead of a CPython type though. This is the whole raison d'etre of Ironclad.<br><br>It isn't limiting, what it gives you is the ability to use existing code that depends on C extensions without having to write your own wrapper layer or use RPC. So far there has been very little that has proved impossible with this approach.<br>
<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> My understanding is that Android now allows native code,<br>
<br>
</div>Theoretically, yes. I don't think it's a good use of the platform<br>
though, you get huge binaries, long startup times, and quite limited<br>
functionality. Check out "Android Scripting Environment".<br></blockquote><div><br>Right. *Most* Java code is not running on Android though (in the same way as most .NET code isn't running on .NET CE), so it could be useful if people wanted it.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> so if Dalvik has<br>
> the same FFI APIs and you can compile the Python extensions for it *and*<br>
> Jython runs on Dalvik (not currently the case I believe?)<br>
<br>
</div>Not yet, and not easy (the bytecode generator would have to be<br>
retargeted and probably a bunch of unsupported Java features would<br>
have to be worked around).<br>
<br>
Phones are slow and small...<br>
<div class="im"><br></div></blockquote><div><br><br>A lot of modern phones have 500mhz ARM processors and 128Mbyte RAM. Python was running on desktop devices a lot slower and 'smaller' not very long ago. :-)<br><br>
 [snip...]<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> The CoreCLR in Silverlight does run IronPython but because of the sandboxing<br>
> you can't call into native code, so you can't use Ironclad in the browser.<br>
<br>
> Despite the places where Ironclad doesn't work, *most* .NET code runs on<br>
> desktops or servers using the standard .NET framework - and this is where<br>
> Ironclad is used. Despite the variety of different JVMs this is an analogous<br>
> situation and I don't see why a port wouldn't be just as useful.<br>
<br>
</div>Why not just use CPython? At Google we mix Python and Java using RPCs<br>
intead of mixing runtimes. It works quite well.<br>
<div class="im"><br></div></blockquote><div><br>The use case for Resolver Systems (who created the Ironclad project) was that having written a programmable spreadsheet (desktop application) written in IronPython we had a lot of customers who wanted to use Numpy with it.<br>
<br>We could have told them to go away and write their own RPC layer. Instead we decided to solve the problem. :-)<br><br>With the Ironclad compatibility layer C extensions can be used without having to write an RPC layer and the data marshalling that involves. It works well... Other architectures (multi-process and RPC) may be suitable to some problems but it is nice to have the choice.<br>
<br>There are a couple of interesting aspects of Ironclad that might have wider applicability in the future. IronPython doesn't have a GIL and doesn't use reference counting for garbage collection, but Ironclad has to work with C extensions that use both.<br>
<br>If (for example) Unladen Swallow were to (eventually) be successful in removing the GIL and moved away from reference counting then it would be possible to retain binary API (ABI) compatibility with extensions written for 'standard' CPython.<br>
<br>The GIL is simply faked. IronPython code is not restricted by the GIL but only one code path into Ironclad can acquire the GIL at a time.<br><br>For reference counting we have a hybrid system keeping 'bridge' objects alive whilst the C extension has a reference to them but they may or may not be in use from the IronPython side. <br>
<br>All the best,<br><br><br>Michael<br> <br><br></div></div>-- <br><a href="http://www.ironpythoninaction.com/">http://www.ironpythoninaction.com/</a><br><br><br>