Re: [IronPython] JScript Absent from Dynamic Silverlight
On 3/22/08 1:02 PM, Michael Foord [EMAIL PROTECTED] wrote: Michael Foord wrote: Jimmy Schementi wrote: [snip..] When I use Chiron to build apps that include the extended controls (!?) it fails because of the absence of the Microsoft.JScript.Runtime.dll. When I add this dll it succeeds but doesn't include the dll! Creepy! The extended controls definitely shouldn't depend on Microsoft.JScript.Runtime.dll! Can you send me a repro of that? John(s), any idea what the hell is going on here? I'm getting some more obscure oddness with Chiron - both under Windows and on the Mac. I'm not sure if it is reproducible though. I wonder if Chiron tried to reference the JScript binaries because the app directory had a '.js' file? That'd be it! If you don't have a AppManifest.xaml file in your app, it'll look at the extensions of all your script files to figure out which language assemblies to include in the XAP. If you do have an AppManifest.xaml, it'll just include the ones in there. In either case I have completely failed to get Chiron to do 'the right thing' with creating my 'xap' files and ended up building them by hand. That's crappy, sorry! I'm writing a blog-post to detail all the *features* of Chiron. Trust me, it's not as creepy as it seems. The pattern I used was to have 'Chiron.exe' (with all the assemblies etc that come from dynamicsilverlight.net which is the version I'm using) in a bin subdirectory. I was using it on Windows Vista and added the bin directory to the path. I would then invoke it in the following way: chiron /d:path/to/example/app /x:another/path/to/output It would create 'xap' files, but not put the assemblies *or* a manifest in them. I gave up trying to use it. So, /x is not the correct flag =) For python/ruby/jscript, you only need to flags below Dynamic Language Options ... the other ones are only really used by Visual Studio (don't ask =)). The correct flag is /z[ipdlr]. If you run Chiron like this: Chiron /d:path/to/example/app /z:another/path/to/output/app.xap It will generate app.xap with the correct assembles and AppManifest.xaml in it. That's great for 1-off xap generation. If you just want to work on an app and don't want to xap every-time, just run Chiron in the app directory like so: Chiron /w And it'll automatically xap a directory when you ask for directory.xap. Michael http://www.manning.com/foord ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com I thought the documentation in Chiron was good enough, but an accompanying blog post would have prevented a ton of frustration, I'm sure. Sorry about that again, and I'm get that blog post out asap. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Latest DLR Hosting Spec?
Is the file at http://compilerlab.members.winisp.net/dlr-spec-hosting.pdf still the latest publically-available version of the spec? The PDF was created on Jan 3, 08 but otherwise contains no versioning information. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] UI Automation and ControlTypeProperty
On Mar 24, 7:14 am, Shri Borde [EMAIL PROTECTED] wrote: UI Automation did have a problem with IronPython. Seehttp://blogs.msdn.com/shrib/archive/2008/03/24/ironpython-cannot-call I am not sure if the issue has been fixed yet by the UI Automation team. Or if you are running into that same issue or something else. So the problem is with the UI Automation? Is there a way to verify this comes from the same root cause? Should I submit the issue in the codeplex issue tracker? TIA, -- Marcel ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Sanity Check re. Legacy Python Code
Thanks for the info, Curt. Stupid of me - I didn't even stop to think about the issue of binary extensions. I absolutely need numpy! I'll track Ironclad's progress now that you've made me aware of it. Meanwhile, I'll think about using Python.Net in the interim, and just try to embed NLTK (GIL and all) in my C# app. --Gary _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Monday, March 24, 2008 3:59 PM To: Discussion of IronPython Subject: Re: [IronPython] Sanity Check re. Legacy Python Code As I understand it, the goal of IronPython is to support the running of that kind of application -- provided that it doesn't use any binary extensions[1]. The NTLK webpage is a bit vague on that count, suggesting that some users may require numpy and matplotlib. If you're not one of those users, you should give it a try! Of course, there's some chance that NLTK won't work correctly under 2.0b1; your reports in that regard will help all of us by driving IronPython closer to CPython compatibility. 1: but see also http://ironpython-urls.blogspot.com/2008/02/ironclad-01-released.html -- for which numpy support is an explicit goal On Mon, Mar 24, 2008 at 2:48 PM, Gary Kopp [EMAIL PROTECTED] wrote: Would I be correct in assuming that it is _not_ currently the intent that IronPython run arbitrary existing Python code? I am interested in making use of the Natural Language Toolkit (NLTK), a huge Python 2.5 application, in a .NET environment. Clearly, the most powerful approach would be to use IronPython, but I'm guessing (and please correct me if I'm wrong) that current limitations in the IronPython 2.0b1 implementation are likely to present many challenges in running/porting arbitrary legacy Python apps. My purpose in writing this is simply to find out whether I should even bother attempting such a feat. --Gary Kopp ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] http://codeplex.com/dynamicsilverlight
Spamming both the lists, http://www.codeplex.com/dynamicsilverlight has been updated to host the Silverlight2 Beta1 bits. We will be using it as Dynamic Silverlight's project site, so please report any Silverlight-specific bugs there. Next steps are to move more samples up to the site, and host them on http://dynamicsilverlight.net and http://silverlight.net. Also, if you'd like to have a Dynamic Silverlight app showcased on http://dynamicsilverlight.net and the CodePlex project, please post the app (links to zipped source code and the live app) to the Discussions tab on the project and we will host it for you! Let me know what else you'd like to see on the Dynamic Silverlight CodePlex project site. Thanks! ~Jimmy ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] UI Automation and ControlTypeProperty
If you can check if the failing API calls Assembly.GetCallingAssembly by placing a breakpoint in the debugger, that would be 99% confirmation that it is the same issue. Alternatively, you could change the C# code to use Reflection.Emit to create a method which invokes the UI Automation API. If this fails, it is the same bug. The bug affects all dynamic code (IronPython source code gets compiled to Reflection.Emit on the fly). I have pinged the UI Automation team to find out the status of the bug. You could open a bug in the IronPython tracker. Given that its most likely not an IronPython issue, we may not be able to get to it in time to unblock you. Thanks, Shri Want to work on IronPython, IronRuby, F#? Visit http://blogs.msdn.com/ironpython -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcel Sent: Monday, March 24, 2008 1:06 PM To: users@lists.ironpython.com Subject: Re: [IronPython] UI Automation and ControlTypeProperty On Mar 24, 7:14 am, Shri Borde [EMAIL PROTECTED] wrote: UI Automation did have a problem with IronPython. Seehttp://blogs.msdn.com/shrib/archive/2008/03/24/ironpython-cannot-call I am not sure if the issue has been fixed yet by the UI Automation team. Or if you are running into that same issue or something else. So the problem is with the UI Automation? Is there a way to verify this comes from the same root cause? Should I submit the issue in the codeplex issue tracker? TIA, -- Marcel ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
