Re: [IronPython] Roadmap and updates
This was my original response to Max: With regard to WinForms, my recent roadmap post was specifically talking to the integration of IPy into the WinForms designer, not into WinForms itself. You can write IPy 2.0 apps right now that use WinForms, you just have to do it by hand as of right now. The technology that we're cutting adrift (to use your term) is the CodeDom parser that's used by the WinForms designer in the VSX sample. The CodeDom model assumes static typing, which obviously doesn't mesh well with IronPython. We end up doing some tricks to embed type information into the generated python code so we can recreate the types when we round trip between code and designer views. My understanding (Dino?) is that we built that code only for WinForms integration support, we're the only MS language that has a CodeDom parser, and the code is not something we're interested in maintaining in the long term. However, while we have cut the CodeDom parser code, there are other ways of integrating into the WinForms designer. Neither VB nor C# use the CodeDom parser method today, even though obviously both are statically typed. I don't know what the other integration options are personally, but we will be investigating them so that when we ship our production quality VS integration for IPy, we will have WinForms designer support. I'm sorry if that wasn't clear in my blog post. As soon as we have a better idea on our WinForms integration strategy, we'll make sure to talk about it. As for MS cutting the WinForms model loose, I think we're encouraging folks to move to WPF, but given the sheer amount of WinForms code out there I have a hard time imagining them cutting support for it. Harry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Max R. Yaffe Sent: Monday, August 04, 2008 7:06 PM To: users@lists.ironpython.com Subject: [IronPython] Roadmap and updates Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, however, seems to deprecate WinForms. I'm worried that IronPython and Microsoft are going to cut WinForms adrift just when I'm about to make a major investment in it. This might be the best approach for Microsoft because it seems the community is mainly interested in pictures, sounds, and the web. But I need something more classical. I'd appreciate your comments and direction. Max Yaffe Gamry Instruments, Inc. ___ 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] Roadmap and updates
Harry Pierson wrote: [...] As for MS cutting the WinForms model loose, I think we're encouraging folks to move to WPF, but given the sheer amount of WinForms code out there I have a hard time imagining them cutting support for it. And in fact IIRC .NET 2.0 SP1 included at least one new winforms controls. Michael Harry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Max R. Yaffe Sent: Monday, August 04, 2008 7:06 PM To: users@lists.ironpython.com Subject: [IronPython] Roadmap and updates Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, however, seems to deprecate WinForms. I'm worried that IronPython and Microsoft are going to cut WinForms adrift just when I'm about to make a major investment in it. This might be the best approach for Microsoft because it seems the community is mainly interested in pictures, sounds, and the web. But I need something more classical. I'd appreciate your comments and direction. Max Yaffe Gamry Instruments, Inc. ___ 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 -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Roadmap and updates
FYI one thing that might help on the debugging side is the -X:ExceptionDetail command line option to ipy.exe. This is particular useful if you're getting something like a NullReferenceException or IndexError's because usually it leads right to the culprit. In this case that displays this stack trace: at IronPython.Runtime.Operations.PythonTypeOps.CallWorker(CodeContext context, PythonType dt, IAttributesCollection kwArgs, Object[] args) in C:\Product\3\Merlin\Main\Languages\IronPython\IronPytho n\Runtime\Operations\PythonTypeOps.cs:line 97 at IronPython.Runtime.Types.PythonType.Call(CodeContext context, IAttributesCollection kwArgs, Object[] args) in C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Runtime\Types\PythonType.cs :line 272 at _stub_$37##27(Closure , CallSite , CodeContext , Object , String , Object , Object ) at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] ) at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line 272 at System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up dateDelegates.Generated.cs:line 55 at _stub_$36##26(Closure , CallSite , CodeContext , Object , String , Object , Object ) at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] ) at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line 272 at System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up dateDelegates.Generated.cs:line 55 at module$20$9.module$20(Closure , Scope , LanguageContext ) in stdin:line 7 at Microsoft.Scripting.ScriptCode.InvokeTarget(LambdaExpression code, Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line 88 at Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression code, Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\OptimizedScriptCode.cs:line 71 at Microsoft.Scripting.ScriptCode.Run(Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line 80 at IronPython.Hosting.PythonCommandLine.c__DisplayClass1.RunOneInteractionb__0() in C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Hosting\PythonCommandLine.cs:line 370 IndexError: Index was outside the bounds of the array. As you can see the top of the stack is the CallWorker and the problem here is that we're just not putting the arg name in the right index in the array. So something like that might be obvious enough to fix w/o a repro - or it might be pretty easy for us to come up w/ a repro ourselves when we see the call stack. If we had instead been throwing the exception from one of the _stub_ methods then we'd definitely need a repro as that's generated code and it's not immediately obvious what is going on. Anyway, this bug appears to be trivial fixed so it'll be in the next release. Thanks for the bug report and easy repro! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sylvain Hellegouarch Sent: Tuesday, August 05, 2008 12:05 AM To: [EMAIL PROTECTED]; Discussion of IronPython Subject: Re: [IronPython] Roadmap and updates Hi, Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese
Re: [IronPython] Roadmap and updates
There's really two reasons. The first is that we try to match CPython for our output including our error messages. The second is that the exception is usually triggered from user code and that can be understood by looking at the stack trace w/o a bunch of internal Python implementation details being show. Enabling it for betas might make sense but we intend to only have 1 more beta release so I'm not sure how much value that would add right now and it might cause confusion as we switch between the two modes. It'd also prevent people from reporting errors about the error reporting :) But if there was a strong desire to see that we could consider it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sylvain Hellegouarch Sent: Wednesday, August 06, 2008 1:53 PM To: Discussion of IronPython Subject: Re: [IronPython] Roadmap and updates Thanks Dino. I'll keep the flag in mind for the future. One question for my curioristy, why not reporting the whole exception by default? If I were to run production code and that an error occurred I would like to know the context but might not afford to run the code again. At least it would make sense while IP is in beta to have it enabled IMO. Thanks also for getting this bug fixed, that'll put one step closer to get Kamaelia working which would be fantastic as I've written a bunch of code like XMPP client library using it. That'd be fun to have it working on IP. Thanks again, - Sylvain FYI one thing that might help on the debugging side is the -X:ExceptionDetail command line option to ipy.exe. This is particular useful if you're getting something like a NullReferenceException or IndexError's because usually it leads right to the culprit. In this case that displays this stack trace: at IronPython.Runtime.Operations.PythonTypeOps.CallWorker(CodeContext context, PythonType dt, IAttributesCollection kwArgs, Object[] args) in C:\Product\3\Merlin\Main\Languages\IronPython\IronPytho n\Runtime\Operations\PythonTypeOps.cs:line 97 at IronPython.Runtime.Types.PythonType.Call(CodeContext context, IAttributesCollection kwArgs, Object[] args) in C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Runtime\Types\PythonType.cs :line 272 at _stub_$37##27(Closure , CallSite , CodeContext , Object , String , Object , Object ) at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] ) at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line 272 at System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up dateDelegates.Generated.cs:line 55 at _stub_$36##26(Closure , CallSite , CodeContext , Object , String , Object , Object ) at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] ) at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line 272 at System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up dateDelegates.Generated.cs:line 55 at module$20$9.module$20(Closure , Scope , LanguageContext ) in stdin:line 7 at Microsoft.Scripting.ScriptCode.InvokeTarget(LambdaExpression code, Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line 88 at Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression code, Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\OptimizedScriptCode.cs:line 71 at Microsoft.Scripting.ScriptCode.Run(Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line 80 at IronPython.Hosting.PythonCommandLine.c__DisplayClass1.RunOneInteractionb__0() in C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Hosting\PythonCommandLine.cs:line 370 IndexError: Index was outside the bounds of the array. As you can see the top of the stack is the CallWorker and the problem here is that we're just not putting the arg name in the right index in the array. So something like that might be obvious enough to fix w/o a repro - or it might be pretty easy for us to come up w/ a repro ourselves when we see the call stack. If we had instead been throwing the exception from one of the _stub_ methods then we'd definitely need a repro as that's generated code and it's not immediately obvious what is going on. Anyway, this bug appears to be trivial fixed so it'll be in the next release. Thanks for the bug report and easy repro! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sylvain
Re: [IronPython] Roadmap and updates
Hi, Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, however, seems to deprecate WinForms. I'm worried that IronPython and Microsoft are going to cut WinForms adrift just when I'm about to make a major investment in it. This might be the best approach for Microsoft because it seems the community is mainly interested in pictures, sounds, and the web. But I need something more classical. I'd appreciate your comments and direction. I will not comment on the state of Silverlight or XAML as I don't use them but I've been using the PyQt4+Python2.5 combination for some time and it's been working great. My main concern with IronPython at this stage is its inability to offer a clear view of its capacity to support pure Python libraries. I keep running in shortcomings or bugs [1] that make me nervous about investing time in IP when using existing pure Python libraries. I do understand IP is still in beta and bugs are expected at this stage but not having an up-to-date grid of what is officially implemented, supported, worked on is rather frustrating. In other words, if you start from scratch then IP+.NET is a solid choice but if you already have a large bunch of Python code I would personally be very careful as you might end up having to spend quite a lot of time in debugging the reason why your code isn't working as expected, opening tickets on CodePlex and never hearing about their progress again until they are potentially fixed. I do not want to sound like I downplay the IP team work, not at all, but the lack of visibility is not playing in their favor in my opinion. Writing code is one thing, giving recurrent feedback is sometimes worth more ;) I believe IP is worth the interest but keep in mind the product is still rather a long way. - Sylvain [1] http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17561 It might not sound like it but that bug was quite hard to track down because of the rather poor traceback information provided by IP as well as the fact that the IndexError, though a consequence of the bug, wasn't immediate to correlate back to the bug itself. -- Sylvain Hellegouarch http://www.defuze.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Roadmap and updates
I do not want to sound like I downplay the IP team work, not at all, but the lack of visibility is not playing in their favor in my opinion. Writing code is one thing, giving recurrent feedback is sometimes worth more ;) I wanted to reiterate that I don't downplay the IP team's work. They've been very responsive and friendly to the community. However, visibility is sometimes lacking (mind you like many other large OSS projects ;)). I do realize as well that if I don't ask questions, I won't have answers... - Sylvain -- Sylvain Hellegouarch http://www.defuze.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Roadmap and updates
Giles Thomas wrote: Curt Hagenlocher wrote: Until then, you can always do what I understand Resolver Systems did: save your forms as C# and manually copy the generated code into your Python classes. The initialization code is so generic and predictable that you don't have to do much more than lop the semicolons off the ends of the lines. Not quite - we generate C# base classes from Visual Studio, then write IronPython subclasses to add the behaviour. This means that we can always edit the forms in the designer - and because the generated code is in C# no-one feels tempted to tinker with it... As Giles says, all the actual behaviour is implemented in Python - we just use the designer for the layout. Michael Cheers, Giles -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.ironpython.info/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Roadmap and updates
Curt Hagenlocher wrote: Until then, you can always do what I understand Resolver Systems did: save your forms as C# and manually copy the generated code into your Python classes. The initialization code is so generic and predictable that you don't have to do much more than lop the semicolons off the ends of the lines. Not quite - we generate C# base classes from Visual Studio, then write IronPython subclasses to add the behaviour. Cheers, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Roadmap and updates
On Tue, Aug 5, 2008 at 3:33 AM, Giles Thomas [EMAIL PROTECTED] wrote: Curt Hagenlocher wrote: Until then, you can always do what I understand Resolver Systems did: save your forms as C# and manually copy the generated code into your Python classes. The initialization code is so generic and predictable that you don't have to do much more than lop the semicolons off the ends of the lines. Not quite - we generate C# base classes from Visual Studio, then write IronPython subclasses to add the behaviour. Thanks for the clarification. I was misremembering the quoted mail at http://www.mail-archive.com/[EMAIL PROTECTED]/msg00451.html . -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Roadmap and updates
Yeah, regarding the bugs... We do have a current backlog (~50) of untriaged bugs. We're continuing to go through them and hopefully we'll make good progress at our team meeting on Friday. Our plan for 2.0 is to fix all Medium High Priority bugs on CodePlex so that's the key thing to watch as we flip bugs from Proposed - Active. In particular the bug you referenced in your earlier post is likely to be rated high/medium - it's a core Python language compat issue and we usually prioritize those. Also questions are great - I have a list of things to blog about but responding to questions is always much easier :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sylvain Hellegouarch Sent: Tuesday, August 05, 2008 12:24 AM To: Discussion of IronPython Subject: Re: [IronPython] Roadmap and updates I do not want to sound like I downplay the IP team work, not at all, but the lack of visibility is not playing in their favor in my opinion. Writing code is one thing, giving recurrent feedback is sometimes worth more ;) I wanted to reiterate that I don't downplay the IP team's work. They've been very responsive and friendly to the community. However, visibility is sometimes lacking (mind you like many other large OSS projects ;)). I do realize as well that if I don't ask questions, I won't have answers... - Sylvain -- Sylvain Hellegouarch http://www.defuze.org ___ 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] Roadmap and updates
Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, however, seems to deprecate WinForms. I'm worried that IronPython and Microsoft are going to cut WinForms adrift just when I'm about to make a major investment in it. This might be the best approach for Microsoft because it seems the community is mainly interested in pictures, sounds, and the web. But I need something more classical. I'd appreciate your comments and direction. Max Yaffe Gamry Instruments, Inc. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Roadmap and updates
XAML is really just an XML-based object persistence format. It's not directly tied to the display technology that it's mostly used for, which is WPF or Windows Presentation Foundation. It's really WPF that should be compared to Windows Forms -- you can use WPF without writing a single line of XAML (or having the designer write it on your behalf). If you're used to using the Win32 API or a thin wrapper over it like MFC, then Windows Forms is a lot closer to what you know already. That's because Windows Forms itself is a (somewhat thicker) wrapper over the same Win32 API. By contrast, WPF is a UI framework that's been redesigned from the ground up. Individual elements on a WPF window aren't represented by an window handle; there's only one HWND at the top which effectively provides a blank canvas for WPF to draw on. There are probably hundreds of thousands of applications built on USER32.DLL and/or Windows Forms. The odds that Microsoft abandons all of these applications are pretty low -- it is the applications, after all, that make the platform what it is. And although WPF is in many respects a much better-to-develop-for architecture than Windows Forms, it also isn't perhaps quite as mature -- and there are a few things that are still more easily done using Windows Forms than WPF, particularly in a line-of-business-style application. With respect to IronPython, we don't have much to say about the platform as a whole. You can execute just about any .NET code from within IronPython -- whether that's Windows Forms, WPF, WCF, WF, Managed DirectX or the CLR-based technologies that are just being invented now. So as long as Windows Forms exists, you'll be able to use it from IronPython. If your specific concern is related solely to Harry's comment about the Visual Studio integration work being more difficult for the Windows Forms designer than for the WPF designer, then I think you've read a little too much into what he said. Our intent is to support the Windows Forms designer. It may be that -- due to its quirks -- we're not able to do so in the early previews of the work, but I don't think that any of us would consider the integration done if it was WPF-only. Until then, you can always do what I understand Resolver Systems did: save your forms as C# and manually copy the generated code into your Python classes. The initialization code is so generic and predictable that you don't have to do much more than lop the semicolons off the ends of the lines. Disclaimer: I am a Microsoft employee, but I have absolutely no inside knowledge on any of the topics I've written on here other than those related directly to IronPython. On Mon, Aug 4, 2008 at 7:06 PM, Max R. Yaffe [EMAIL PROTECTED] wrote: Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, however, seems to deprecate WinForms. I'm worried that IronPython and Microsoft are going to cut WinForms adrift just when I'm about to make a major investment in it. This might be the best approach for Microsoft because it seems the community is mainly interested in pictures, sounds, and the web. But I need something more classical. I'd appreciate your comments and direction. Max Yaffe Gamry Instruments, Inc. ___ 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] Roadmap and updates
Max R. Yaffe wrote: Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, however, seems to deprecate WinForms. I'm worried that IronPython and Microsoft are going to cut WinForms adrift just when I'm about to make a major investment in it. This might be the best approach for Microsoft because it seems the community is mainly interested in pictures, sounds, and the web. But I need something more classical. I'd appreciate your comments and direction. Max Yaffe Gamry Instruments, Inc. I am wondering why you haven't looked at WPF, Windows Presentation Foundation, and IronPython. You can develop your interface in WPF without using XAML and IronPython will eventually be compatible with Cpython 2.5. Howard ___ 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] Roadmap and updates
- Curt Hagenlocher [EMAIL PROTECTED] wrote: The initialization code is so generic and predictable that you don't have to do much more than lop the semicolons off the ends of the lines. Of course, you don't even have to do that as Python allows semicolons on the ends :) Another way to answer your question, Max, is that Mono supports WinForms too. We are working on a similar project, but I think IronPython + WinForms is where we will be for a few years. But, we aren't writing our base libraries in Python anymore, but C#. That way it still looks the same in Python, but the the other DLR languages can use them too. And you can use other alternate operating systems. I predict that there will be a huge number of DLR languages in the next few years, and your uses can switch languages while keeping the base libraries, if you write in C#. -Doug Disclaimer: I am a Microsoft employee, but I have absolutely no inside knowledge on any of the topics I've written on here other than those related directly to IronPython. On Mon, Aug 4, 2008 at 7:06 PM, Max R. Yaffe [EMAIL PROTECTED] wrote: Note: I originally wrote this to Harry Pierson directly who asked that I post it publically. I hope it doesn't come off as too inflamatory. Harry - Thanks for the roadmap and the latest update. It clarifies a particular issue that I'm having with deciding whether to adopt Iron Python and .Net for that matter. My particular application is a scientific instrument control and data analysis package. It runs on Windows now using various older MS technologies (dating back to Windows 2.3!). It will not need to run from a web browser, mainly because of the requirements for instrument control. The application is highly scripted using a dynamic language of my own devising derived from Smalltalk and remarkably similar to Python. I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my technology. However, I wanted to see what Microsoft had to offer. WinForms + Python seems to be the best fit for my technology because of the need to manipulate data tables and my desire to avoid the web. Silverlight just doesn't offer me any advantage and seems to be directed at pretty pictures and sounds. It also doesn't seem to handle the kinds of user/data interaction I need. XAML also doesn't seem to offer any advantage for my code, or if it does, it certainly isn't clear what it might be other than a YAOUHD (yet another obese, unreadable HTML derivative). Your roadmap, however, seems to deprecate WinForms. I'm worried that IronPython and Microsoft are going to cut WinForms adrift just when I'm about to make a major investment in it. This might be the best approach for Microsoft because it seems the community is mainly interested in pictures, sounds, and the web. But I need something more classical. I'd appreciate your comments and direction. Max Yaffe Gamry Instruments, Inc. ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
