Re: [IronPython] Disabling optimized methods
This isn't actually optimization but rather dynamic methods. You can use the -X:StaticMethods which will force all methods into types. But the consequence of this is if methods are getting dynamically defined (e.g. exex def foo(): pass) then we'll leak memory because the methods can never be freed. But it will make the typical CLR-style debugging possible. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Hardy Sent: Saturday, November 17, 2007 3:05 PM To: Discussion of IronPython Subject: [IronPython] Disabling optimized methods Hi, Is there a way to disable method optimizations? I tried setting ScriptDomainManager.Options.DebugCodeGeneration = true, but the debugger still shows Cannot evaluate expression because the code of the current method is optimized. for a large number of methods. I set the option before creating the engine, but maybe that's not enough? -Jeff ___ 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] DLR Hosting Spec
As I mentioned a couple of weeks ago we've been wrapping up work on designing the hosting APIs and just this past week we've started implementing the new hosting APIs. We'll be continuing this work off-and-on over the next few months so now is a great time to start collecting feedback on the design of the new APIs. One thing worth mentioning is the spec is incomplete, and the text that is there is not final. The conceptual introduction and the direction we're going is pretty solid. However, as we review the API reference sections in detail, as implementation feeds back on the design, and as we gather external feedback, we're updating the spec and code. The reason we're releasing this so early is to gather feedback on the design and functionality of the APIs. Any feedback you have would be appreciated. The new APIs will also start showing up incrementally in the next few releases of IronPython and the regular source drops of IronRuby. So soon you'll also be test out and experiment with the bits directly. This should give us plenty of time to take any feedback into consideration and update both the spec and code for the final DLR APIs. We look forward to any feedback you might have! You can grab the spec here: http://www.iunknown.com/files/dlr-spec-hosting.pdf If anyone would like a version in Word format we can send that so you can mark it up w/ track changes enabled :). ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Half the team OOF this week
Btw, half of our team is out this week for the Thanksgiving weekend. Dino is OOF starting Tuesday. So you may not get a prompt response this week. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Monday, November 19, 2007 4:16 PM To: Discussion of IronPython Subject: [IronPython] DLR Hosting Spec As I mentioned a couple of weeks ago we've been wrapping up work on designing the hosting APIs and just this past week we've started implementing the new hosting APIs. We'll be continuing this work off-and-on over the next few months so now is a great time to start collecting feedback on the design of the new APIs. One thing worth mentioning is the spec is incomplete, and the text that is there is not final. The conceptual introduction and the direction we're going is pretty solid. However, as we review the API reference sections in detail, as implementation feeds back on the design, and as we gather external feedback, we're updating the spec and code. The reason we're releasing this so early is to gather feedback on the design and functionality of the APIs. Any feedback you have would be appreciated. The new APIs will also start showing up incrementally in the next few releases of IronPython and the regular source drops of IronRuby. So soon you'll also be test out and experiment with the bits directly. This should give us plenty of time to take any feedback into consideration and update both the spec and code for the final DLR APIs. We look forward to any feedback you might have! You can grab the spec here: http://www.iunknown.com/files/dlr-spec-hosting.pdf If anyone would like a version in Word format we can send that so you can mark it up w/ track changes enabled :). ___ 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
Re: [IronPython] DLR Hosting Spec
2007/11/20, Dino Viehland [EMAIL PROTECTED]: We look forward to any feedback you might have! You can grab the spec here: http://www.iunknown.com/files/dlr-spec-hosting.pdf I think there are a lot of things to learn from Java. Java 6 introduced javax.script hosting API. http://java.sun.com/javase/6/docs/api/javax/script/package-summary.html For example, ScriptRuntime corresponds to Java's ScriptEngineManager. We can compare API to get scripting engine for the given language. DLR ScriptEngine GetEngine(string languageId) ScriptEngine GetEngineByFileExtension(string extension) javax.script ScriptEngine getEngineByName(String shortName) ScriptEngine getEngineByExtension(String extension) ScriptEngine getEngineByMimeType(String mimeType) Is getEngineByMimeType a good idea? Similar comparisons can be made for all other APIs too. -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
