From iiyocc at gmail.com Fri May 6 18:56:35 2011 From: iiyocc at gmail.com (iiyo cc) Date: Fri, 6 May 2011 17:56:35 +0100 Subject: [IronPython] Problems running simple executable compiled with the pyc.py tool Message-ID: Hello, I keep coming up with the same problem when trying to run a compiled executable from the pyc.py tool. The error I'm getting is as follows: Unhandled Exception: System.IO.FileNotFoundException: The system cannon find > the file specified. (Exception from HRESULT: 0x80070002) > at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence > evidence) > at System.Reflection.Assembly.LoadFile(String path) > at PythonMain.Main() > My file is a simple Hello, World! program saved as Program.py with the following contents: print 'Hello, World!' > I use the following command line to compile: C:\IronPy\ipy C:\IronPy\Tools\Scripts\pyc.py Program.py /out:Program > /main:Program.py /target:exe > Note: I'm using the latest 2.7 release through the IronPython installer on a Windows 7 64bit system, the executables are built (Program.dll and Program.exe) successfully, yet won't run even when sitting in the same directory as all the dlls one can find in the IronPython distribution. I've also tried targeting the x64 platform specifically with pyc, but to no avail. Here's what my working directory looks like when the project is built: IronPython.dll, IronPython.Modules.dll, IronPython.Wpf.dll, > Microsoft.Dynamic.dll, Microsoft.Scripting.dll, > Microsoft.Scripting.Metadata.dll, Program.dll, Program.exe, Program.py > Hopefully someone knows what's going on, or if i'm doing something wrong. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Fri May 6 19:12:33 2011 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 6 May 2011 17:12:33 +0000 Subject: [IronPython] Problems running simple executable compiled with the pyc.py tool In-Reply-To: References: Message-ID: <6C7ABA8B4E309440B857D74348836F2E15138EF7@TK5EX14MBXC133.redmond.corp.microsoft.com> When running are Program.dll and Program.exe in the same location? The reason I ask is that Program.exe will change the CWD to where it is currently located and then it'll attempt to load Program.dll from that directory. That's the only thing that immediately comes to mind as having potential to break this for you. Also, did you install IronPython via the MSI or by downloading the binary zip file? I just tried this and it all seemed to work for me (I'm installed via the MSI so we can pick up the IronPython DLLs from the GAC): C:\Users\dinov > type test.py print('hi') 10:11:04.07 C:\Users\dinov > "C:\Program Files (x86)\IronPython 2.7\ipy.exe" "C:\Program Files (x86)\IronPython 2.7\Tools\Scripts\pyc.py" /target:exe /out:test /main:test.py test.py Input Files: test.py Output: test Target: ConsoleApplication Platform: ILOnly Machine: I386 Compiling... Saved to test 10:11:13.82 C:\Users\dinov > .\test.exe hi From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of iiyo cc Sent: Friday, May 06, 2011 9:57 AM To: users at lists.ironpython.com Subject: [IronPython] Problems running simple executable compiled with the pyc.py tool Hello, I keep coming up with the same problem when trying to run a compiled executable from the pyc.py tool. The error I'm getting is as follows: Unhandled Exception: System.IO.FileNotFoundException: The system cannon find the file specified. (Exception from HRESULT: 0x80070002) at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence evidence) at System.Reflection.Assembly.LoadFile(String path) at PythonMain.Main() My file is a simple Hello, World! program saved as Program.py with the following contents: print 'Hello, World!' I use the following command line to compile: C:\IronPy\ipy C:\IronPy\Tools\Scripts\pyc.py Program.py /out:Program /main:Program.py /target:exe Note: I'm using the latest 2.7 release through the IronPython installer on a Windows 7 64bit system, the executables are built (Program.dll and Program.exe) successfully, yet won't run even when sitting in the same directory as all the dlls one can find in the IronPython distribution. I've also tried targeting the x64 platform specifically with pyc, but to no avail. Here's what my working directory looks like when the project is built: IronPython.dll, IronPython.Modules.dll, IronPython.Wpf.dll, Microsoft.Dynamic.dll, Microsoft.Scripting.dll, Microsoft.Scripting.Metadata.dll, Program.dll, Program.exe, Program.py Hopefully someone knows what's going on, or if i'm doing something wrong. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iiyocc at gmail.com Fri May 6 20:01:48 2011 From: iiyocc at gmail.com (iiyo cc) Date: Fri, 6 May 2011 19:01:48 +0100 Subject: [IronPython] Problems running simple executable compiled with the pyc.py tool In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E15138EF7@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <6C7ABA8B4E309440B857D74348836F2E15138EF7@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: I followed your example, and it worked perfectly for me. I then realized it was my error all along - I assumed /out: could support directories (I had actually used /out:build\Program because of the batch file used to generate it), but this seems not to work in the way I'd imagined. Anyway, it's all working properly now. Thanks, and apologies for the stupidity! On Fri, May 6, 2011 at 6:12 PM, Dino Viehland wrote: > When running are Program.dll and Program.exe in the same location? The > reason I ask is that Program.exe will change the CWD to where it is > currently located and then it?ll attempt to load Program.dll from that > directory. That?s the only thing that immediately comes to mind as having > potential to break this for you. > > > > Also, did you install IronPython via the MSI or by downloading the binary > zip file? > > > > I just tried this and it all seemed to work for me (I?m installed via the > MSI so we can pick up the IronPython DLLs from the GAC): > > > > C:\Users\dinov > type test.py > > print('hi') > > 10:11:04.07 > > C:\Users\dinov > "C:\Program Files (x86)\IronPython 2.7\ipy.exe" > "C:\Program Files (x86)\IronPython 2.7\Tools\Scripts\pyc.py" /target:exe > /out:test /main:test.py test.py > > Input Files: > > test.py > > Output: > > test > > Target: > > ConsoleApplication > > Platform: > > ILOnly > > Machine: > > I386 > > Compiling... > > Saved to test > > > > 10:11:13.82 > > C:\Users\dinov > .\test.exe > > hi > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *iiyo cc > *Sent:* Friday, May 06, 2011 9:57 AM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Problems running simple executable compiled with > the pyc.py tool > > > > Hello, > > I keep coming up with the same problem when trying to run a compiled > executable from the pyc.py tool. The error I'm getting is as follows: > > Unhandled Exception: System.IO.FileNotFoundException: The system cannon > find the file specified. (Exception from HRESULT: 0x80070002) > at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence > evidence) > at System.Reflection.Assembly.LoadFile(String path) > at PythonMain.Main() > > > My file is a simple Hello, World! program saved as Program.py with the > following contents: > > print 'Hello, World!' > > > I use the following command line to compile: > > C:\IronPy\ipy C:\IronPy\Tools\Scripts\pyc.py Program.py /out:Program > /main:Program.py /target:exe > > > Note: I'm using the latest 2.7 release through the IronPython installer on > a Windows 7 64bit system, the executables are built (Program.dll and > Program.exe) successfully, yet won't run even when sitting in the same > directory as all the dlls one can find in the IronPython distribution. I've > also tried targeting the x64 platform specifically with pyc, but to no > avail. Here's what my working directory looks like when the project is > built: > > IronPython.dll, IronPython.Modules.dll, IronPython.Wpf.dll, > Microsoft.Dynamic.dll, Microsoft.Scripting.dll, > Microsoft.Scripting.Metadata.dll, Program.dll, Program.exe, Program.py > > > Hopefully someone knows what's going on, or if i'm doing something wrong. > Thanks. > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Fri May 6 20:04:26 2011 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 6 May 2011 18:04:26 +0000 Subject: [IronPython] Problems running simple executable compiled with the pyc.py tool In-Reply-To: References: <6C7ABA8B4E309440B857D74348836F2E15138EF7@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: <6C7ABA8B4E309440B857D74348836F2E151390DF@TK5EX14MBXC133.redmond.corp.microsoft.com> Feel free to open a bug on supporting directories - it seems pretty reasonable to expect that to work. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of iiyo cc Sent: Friday, May 06, 2011 11:02 AM To: Discussion of IronPython Subject: Re: [IronPython] Problems running simple executable compiled with the pyc.py tool I followed your example, and it worked perfectly for me. I then realized it was my error all along - I assumed /out: could support directories (I had actually used /out:build\Program because of the batch file used to generate it), but this seems not to work in the way I'd imagined. Anyway, it's all working properly now. Thanks, and apologies for the stupidity! On Fri, May 6, 2011 at 6:12 PM, Dino Viehland > wrote: When running are Program.dll and Program.exe in the same location? The reason I ask is that Program.exe will change the CWD to where it is currently located and then it'll attempt to load Program.dll from that directory. That's the only thing that immediately comes to mind as having potential to break this for you. Also, did you install IronPython via the MSI or by downloading the binary zip file? I just tried this and it all seemed to work for me (I'm installed via the MSI so we can pick up the IronPython DLLs from the GAC): C:\Users\dinov > type test.py print('hi') 10:11:04.07 C:\Users\dinov > "C:\Program Files (x86)\IronPython 2.7\ipy.exe" "C:\Program Files (x86)\IronPython 2.7\Tools\Scripts\pyc.py" /target:exe /out:test /main:test.py test.py Input Files: test.py Output: test Target: ConsoleApplication Platform: ILOnly Machine: I386 Compiling... Saved to test 10:11:13.82 C:\Users\dinov > .\test.exe hi From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of iiyo cc Sent: Friday, May 06, 2011 9:57 AM To: users at lists.ironpython.com Subject: [IronPython] Problems running simple executable compiled with the pyc.py tool Hello, I keep coming up with the same problem when trying to run a compiled executable from the pyc.py tool. The error I'm getting is as follows: Unhandled Exception: System.IO.FileNotFoundException: The system cannon find the file specified. (Exception from HRESULT: 0x80070002) at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence evidence) at System.Reflection.Assembly.LoadFile(String path) at PythonMain.Main() My file is a simple Hello, World! program saved as Program.py with the following contents: print 'Hello, World!' I use the following command line to compile: C:\IronPy\ipy C:\IronPy\Tools\Scripts\pyc.py Program.py /out:Program /main:Program.py /target:exe Note: I'm using the latest 2.7 release through the IronPython installer on a Windows 7 64bit system, the executables are built (Program.dll and Program.exe) successfully, yet won't run even when sitting in the same directory as all the dlls one can find in the IronPython distribution. I've also tried targeting the x64 platform specifically with pyc, but to no avail. Here's what my working directory looks like when the project is built: IronPython.dll, IronPython.Modules.dll, IronPython.Wpf.dll, Microsoft.Dynamic.dll, Microsoft.Scripting.dll, Microsoft.Scripting.Metadata.dll, Program.dll, Program.exe, Program.py Hopefully someone knows what's going on, or if i'm doing something wrong. Thanks. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From iiyocc at gmail.com Fri May 6 22:32:07 2011 From: iiyocc at gmail.com (iiyo cc) Date: Fri, 6 May 2011 21:32:07 +0100 Subject: [IronPython] Problems running simple executable compiled with the pyc.py tool In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E151390DF@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <6C7ABA8B4E309440B857D74348836F2E15138EF7@TK5EX14MBXC133.redmond.corp.microsoft.com> <6C7ABA8B4E309440B857D74348836F2E151390DF@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: Alright, I've come upon another problem, this time with using /target:winexe with a wpf type project. It seems to crash without any kind of error. I also noticed some curious things about the parameter order. Here's the sample source I used to test: wpf.py and wpf.xaml -> http://codepad.org/XRLF8OSc Compiling with: > "C:\Program Files (x86)\IronPython 2.7\ipy.exe" "C:\Program Files > (x86)\IronPython 2.7\Tools\Scripts\pyc.py" /out:wpf /target:winexe > /main:wpf.py wpf.py > For some reason, this will compile as a Console Application type Changing the order: > "C:\Program Files (x86)\IronPython 2.7\ipy.exe" "C:\Program Files > (x86)\IronPython 2.7\Tools\Scripts\pyc.py" /out:wpf /main:wpf.py > /target:winexe wpf.py > This compiles correctly, although it simply crashes on load. Any ideas? Is it possible to compile if using wpf? I'm lost here - enjoying IronPython, but its distribution sure is hell. > On Fri, May 6, 2011 at 7:04 PM, Dino Viehland wrote: > Feel free to open a bug on supporting directories ? it seems pretty > reasonable to expect that to work. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *iiyo cc > *Sent:* Friday, May 06, 2011 11:02 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Problems running simple executable compiled > with the pyc.py tool > > > > I followed your example, and it worked perfectly for me. I then realized it > was my error all along - I assumed /out: could support directories (I had > actually used /out:build\Program because of the batch file used to generate > it), but this seems not to work in the way I'd imagined. Anyway, it's all > working properly now. > > Thanks, and apologies for the stupidity! > > On Fri, May 6, 2011 at 6:12 PM, Dino Viehland wrote: > > When running are Program.dll and Program.exe in the same location? The > reason I ask is that Program.exe will change the CWD to where it is > currently located and then it?ll attempt to load Program.dll from that > directory. That?s the only thing that immediately comes to mind as having > potential to break this for you. > > > > Also, did you install IronPython via the MSI or by downloading the binary > zip file? > > > > I just tried this and it all seemed to work for me (I?m installed via the > MSI so we can pick up the IronPython DLLs from the GAC): > > > > C:\Users\dinov > type test.py > > print('hi') > > 10:11:04.07 > > C:\Users\dinov > "C:\Program Files (x86)\IronPython 2.7\ipy.exe" > "C:\Program Files (x86)\IronPython 2.7\Tools\Scripts\pyc.py" /target:exe > /out:test /main:test.py test.py > > Input Files: > > test.py > > Output: > > test > > Target: > > ConsoleApplication > > Platform: > > ILOnly > > Machine: > > I386 > > Compiling... > > Saved to test > > > > 10:11:13.82 > > C:\Users\dinov > .\test.exe > > hi > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *iiyo cc > *Sent:* Friday, May 06, 2011 9:57 AM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Problems running simple executable compiled with > the pyc.py tool > > > > Hello, > > I keep coming up with the same problem when trying to run a compiled > executable from the pyc.py tool. The error I'm getting is as follows: > > Unhandled Exception: System.IO.FileNotFoundException: The system cannon > find the file specified. (Exception from HRESULT: 0x80070002) > at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence > evidence) > at System.Reflection.Assembly.LoadFile(String path) > at PythonMain.Main() > > > My file is a simple Hello, World! program saved as Program.py with the > following contents: > > print 'Hello, World!' > > > I use the following command line to compile: > > C:\IronPy\ipy C:\IronPy\Tools\Scripts\pyc.py Program.py /out:Program > /main:Program.py /target:exe > > > Note: I'm using the latest 2.7 release through the IronPython installer on > a Windows 7 64bit system, the executables are built (Program.dll and > Program.exe) successfully, yet won't run even when sitting in the same > directory as all the dlls one can find in the IronPython distribution. I've > also tried targeting the x64 platform specifically with pyc, but to no > avail. Here's what my working directory looks like when the project is > built: > > IronPython.dll, IronPython.Modules.dll, IronPython.Wpf.dll, > Microsoft.Dynamic.dll, Microsoft.Scripting.dll, > Microsoft.Scripting.Metadata.dll, Program.dll, Program.exe, Program.py > > > Hopefully someone knows what's going on, or if i'm doing something wrong. > Thanks. > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Fri May 6 22:51:30 2011 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 6 May 2011 20:51:30 +0000 Subject: [IronPython] Problems running simple executable compiled with the pyc.py tool In-Reply-To: References: <6C7ABA8B4E309440B857D74348836F2E15138EF7@TK5EX14MBXC133.redmond.corp.microsoft.com> <6C7ABA8B4E309440B857D74348836F2E151390DF@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: <6C7ABA8B4E309440B857D74348836F2E151396FF@TK5EX14MBXC133.redmond.corp.microsoft.com> I see a couple of things going on here: The choice of wpf as your compiled name is unfortunate. When we execute your "import wpf" is actually just bringing in your own module rather than bringing in the real wpf module. But even if you change the name it's still broken because we don't pick up the IronPython.Wpf.dll which is in the DLLs directory of the IronPython install. I'm not exactly sure what the best fix for the latter issue is -we probably need to try looking into the registry, seeing where IronPython is installed, and adding any references to the DLLs directory there for compiled apps. Not sure if there's something better we could do though. But you can work around it easily enough, you just need to add: import clr clr.AddReference('IronPython.Wpf') before the import wpf and make sure that IronPython.Wpf.dll is in the same dir as your app (we don't GAC this DLL). Then compiling with this command line worked for me: "C:\Program Files (x86)\IronPython 2.7\ipy.exe" "C:\Program Files (x86)\IronPython 2.7\Tools\Scripts\pyc.py" /out:wpfx /main:wpfx.py wpfx.py /target:winexe The way I debugged this was I compiled as a normal EXE so I could see the stack trace when things went wrong. Once I got to this exception: Unhandled Exception: System.InvalidOperationException: The calling thread must be STA, because many UI components require this. at System.Windows.Input.InputManager..ctor() at System.Windows.Input.InputManager.GetCurrentInputManagerImpl() at System.Windows.Input.KeyboardNavigation..ctor() at System.Windows.FrameworkElement.EnsureFrameworkServices() at System.Windows.FrameworkElement..ctor() at System.Windows.Controls.Control..ctor() at System.Windows.Window..ctor() Then I switched back to compiling as a winexe. The argument parsing in pyc.py definitely sucks, it should probably be switched to using a std lib arg parser. Contributions are welcome if you'd like to improve any of this! From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of iiyo cc Sent: Friday, May 06, 2011 1:32 PM To: Discussion of IronPython Subject: Re: [IronPython] Problems running simple executable compiled with the pyc.py tool Alright, I've come upon another problem, this time with using /target:winexe with a wpf type project. It seems to crash without any kind of error. I also noticed some curious things about the parameter order. Here's the sample source I used to test: wpf.py and wpf.xaml -> http://codepad.org/XRLF8OSc Compiling with: "C:\Program Files (x86)\IronPython 2.7\ipy.exe" "C:\Program Files (x86)\IronPython 2.7\Tools\Scripts\pyc.py" /out:wpf /target:winexe /main:wpf.py wpf.py For some reason, this will compile as a Console Application type Changing the order: "C:\Program Files (x86)\IronPython 2.7\ipy.exe" "C:\Program Files (x86)\IronPython 2.7\Tools\Scripts\pyc.py" /out:wpf /main:wpf.py /target:winexe wpf.py This compiles correctly, although it simply crashes on load. Any ideas? Is it possible to compile if using wpf? I'm lost here - enjoying IronPython, but its distribution sure is hell. On Fri, May 6, 2011 at 7:04 PM, Dino Viehland > wrote: Feel free to open a bug on supporting directories - it seems pretty reasonable to expect that to work. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of iiyo cc Sent: Friday, May 06, 2011 11:02 AM To: Discussion of IronPython Subject: Re: [IronPython] Problems running simple executable compiled with the pyc.py tool I followed your example, and it worked perfectly for me. I then realized it was my error all along - I assumed /out: could support directories (I had actually used /out:build\Program because of the batch file used to generate it), but this seems not to work in the way I'd imagined. Anyway, it's all working properly now. Thanks, and apologies for the stupidity! On Fri, May 6, 2011 at 6:12 PM, Dino Viehland > wrote: When running are Program.dll and Program.exe in the same location? The reason I ask is that Program.exe will change the CWD to where it is currently located and then it'll attempt to load Program.dll from that directory. That's the only thing that immediately comes to mind as having potential to break this for you. Also, did you install IronPython via the MSI or by downloading the binary zip file? I just tried this and it all seemed to work for me (I'm installed via the MSI so we can pick up the IronPython DLLs from the GAC): C:\Users\dinov > type test.py print('hi') 10:11:04.07 C:\Users\dinov > "C:\Program Files (x86)\IronPython 2.7\ipy.exe" "C:\Program Files (x86)\IronPython 2.7\Tools\Scripts\pyc.py" /target:exe /out:test /main:test.py test.py Input Files: test.py Output: test Target: ConsoleApplication Platform: ILOnly Machine: I386 Compiling... Saved to test 10:11:13.82 C:\Users\dinov > .\test.exe hi From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of iiyo cc Sent: Friday, May 06, 2011 9:57 AM To: users at lists.ironpython.com Subject: [IronPython] Problems running simple executable compiled with the pyc.py tool Hello, I keep coming up with the same problem when trying to run a compiled executable from the pyc.py tool. The error I'm getting is as follows: Unhandled Exception: System.IO.FileNotFoundException: The system cannon find the file specified. (Exception from HRESULT: 0x80070002) at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence evidence) at System.Reflection.Assembly.LoadFile(String path) at PythonMain.Main() My file is a simple Hello, World! program saved as Program.py with the following contents: print 'Hello, World!' I use the following command line to compile: C:\IronPy\ipy C:\IronPy\Tools\Scripts\pyc.py Program.py /out:Program /main:Program.py /target:exe Note: I'm using the latest 2.7 release through the IronPython installer on a Windows 7 64bit system, the executables are built (Program.dll and Program.exe) successfully, yet won't run even when sitting in the same directory as all the dlls one can find in the IronPython distribution. I've also tried targeting the x64 platform specifically with pyc, but to no avail. Here's what my working directory looks like when the project is built: IronPython.dll, IronPython.Modules.dll, IronPython.Wpf.dll, Microsoft.Dynamic.dll, Microsoft.Scripting.dll, Microsoft.Scripting.Metadata.dll, Program.dll, Program.exe, Program.py Hopefully someone knows what's going on, or if i'm doing something wrong. Thanks. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.blank at gmail.com Fri May 6 23:12:56 2011 From: doug.blank at gmail.com (Doug Blank) Date: Fri, 6 May 2011 17:12:56 -0400 Subject: [IronPython] Extending Gtk.TextView Message-ID: Does anyone have an idea what this would mean, or how to fix it? >>> import Gtk >>> class MyTextView(Gtk.TextView): ...> pass >>> mtv = MyTextView() (pyjama:611): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.28.6/./gobject/gsignal.c:1549: signal "set_scroll_adjustments" already exists in the `GtkTextView' class ancestry -Doug From raghavendra.chandrashekara at gmail.com Sat May 7 02:26:22 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Fri, 6 May 2011 20:26:22 -0400 Subject: [IronPython] Compiling IronPython for .NET 3.5 Message-ID: Hi All, I am trying to compile IronPython for .NET Framework v 3.5. I have downloaded the source code from https://github.com/IronLanguages/main/zipball/ipy-2.7. After opening the IronPython solution file I tried to change the target framework to 3.5 in the IronPython project properties page. After doing this I got a message from VS 2010 that changing the target framework requires the project to be closed and then reopened, so I clicked Yes to confirm the change. However, when I opened the project properties again the framework version had reverted back to v 4.0. Am I doing something wrong? Please can anyone direct me as to how I should compile IronPython for .NET 3.5? Thanks, Raj -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Sat May 7 02:52:53 2011 From: dinov at microsoft.com (Dino Viehland) Date: Sat, 7 May 2011 00:52:53 +0000 Subject: [IronPython] Extending Gtk.TextView In-Reply-To: References: Message-ID: <6C7ABA8B4E309440B857D74348836F2E1513B037@TK5EX14MBXC133.redmond.corp.microsoft.com> Doug wrote: > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Doug Blank > Sent: Friday, May 06, 2011 2:13 PM > To: Discussion of IronPython > Subject: [IronPython] Extending Gtk.TextView > > Does anyone have an idea what this would mean, or how to fix it? > > >>> import Gtk > >>> class MyTextView(Gtk.TextView): > ...> pass > >>> mtv = MyTextView() > > (pyjama:611): GLib-GObject-WARNING **: > /build/buildd/glib2.0-2.28.6/./gobject/gsignal.c:1549: signal > "set_scroll_adjustments" already exists in the `GtkTextView' class ancestry > Does this happen if you just subclass Gtk.TextView from C#? We shouldn't be really doing anything special when we subclass (other than overriding every single virtual member). From Tomas.Matousek at microsoft.com Sat May 7 03:45:04 2011 From: Tomas.Matousek at microsoft.com (Tomas Matousek) Date: Sat, 7 May 2011 01:45:04 +0000 Subject: [IronPython] Compiling IronPython for .NET 3.5 In-Reply-To: References: Message-ID: <9597F4A19BFDB342B6E90963100C330827C935@SN2PRD0302MB113.namprd03.prod.outlook.com> Do not change any project settings. Just select build configuration "v2Debug" or "v2Release". The default configuration "Debug" builds for V4. Tomas From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Raghavendra Chandrashekara Sent: Friday, May 06, 2011 5:26 PM To: users at lists.ironpython.com Subject: [IronPython] Compiling IronPython for .NET 3.5 Hi All, I am trying to compile IronPython for .NET Framework v 3.5. I have downloaded the source code from https://github.com/IronLanguages/main/zipball/ipy-2.7. After opening the IronPython solution file I tried to change the target framework to 3.5 in the IronPython project properties page. After doing this I got a message from VS 2010 that changing the target framework requires the project to be closed and then reopened, so I clicked Yes to confirm the change. However, when I opened the project properties again the framework version had reverted back to v 4.0. Am I doing something wrong? Please can anyone direct me as to how I should compile IronPython for .NET 3.5? Thanks, Raj -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghavendra.chandrashekara at gmail.com Sat May 7 05:16:12 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Fri, 6 May 2011 23:16:12 -0400 Subject: [IronPython] Compiling IronPython for .NET 3.5 In-Reply-To: <9597F4A19BFDB342B6E90963100C330827C935@SN2PRD0302MB113.namprd03.prod.outlook.com> References: <9597F4A19BFDB342B6E90963100C330827C935@SN2PRD0302MB113.namprd03.prod.outlook.com> Message-ID: Hi Tomas, But there is no v2Debug or v2Release configuration. All I see is Debug, Release, Silverlight4Debug, and Silverlight4Release. Did I download the incorrect version of the source code? Thanks, Raj On Fri, May 6, 2011 at 9:45 PM, Tomas Matousek wrote: > Do not change any project settings. Just select build configuration > ?v2Debug? or ?v2Release?. The default configuration ?Debug? builds for V4. > > > > Tomas > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Raghavendra > Chandrashekara > *Sent:* Friday, May 06, 2011 5:26 PM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Compiling IronPython for .NET 3.5 > > > > Hi All, > > I am trying to compile IronPython for .NET Framework v 3.5. I have > downloaded the source code from > https://github.com/IronLanguages/main/zipball/ipy-2.7. After opening the > IronPython solution file I tried to change the target framework to 3.5 in > the IronPython project properties page. After doing this I got a message > from VS 2010 that changing the target framework requires the project to be > closed and then reopened, so I clicked Yes to confirm the change. However, > when I opened the project properties again the framework version had > reverted back to v 4.0. Am I doing something wrong? Please can anyone direct > me as to how I should compile IronPython for .NET 3.5? > > Thanks, > > Raj > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slide.o.mix at gmail.com Sat May 7 05:25:49 2011 From: slide.o.mix at gmail.com (Slide) Date: Fri, 6 May 2011 20:25:49 -0700 Subject: [IronPython] Compiling IronPython for .NET 3.5 In-Reply-To: References: <9597F4A19BFDB342B6E90963100C330827C935@SN2PRD0302MB113.namprd03.prod.outlook.com> Message-ID: You may need to get latest rather than the 2.7 snapshot. On May 6, 2011 8:16 PM, "Raghavendra Chandrashekara" < raghavendra.chandrashekara at gmail.com> wrote: > Hi Tomas, > > But there is no v2Debug or v2Release configuration. All I see is Debug, > Release, Silverlight4Debug, and Silverlight4Release. Did I download the > incorrect version of the source code? > > Thanks, > > Raj > > On Fri, May 6, 2011 at 9:45 PM, Tomas Matousek < Tomas.Matousek at microsoft.com >> wrote: > >> Do not change any project settings. Just select build configuration >> ?v2Debug? or ?v2Release?. The default configuration ?Debug? builds for V4. >> >> >> >> Tomas >> >> >> >> *From:* users-bounces at lists.ironpython.com [mailto: >> users-bounces at lists.ironpython.com] *On Behalf Of *Raghavendra >> Chandrashekara >> *Sent:* Friday, May 06, 2011 5:26 PM >> *To:* users at lists.ironpython.com >> *Subject:* [IronPython] Compiling IronPython for .NET 3.5 >> >> >> >> Hi All, >> >> I am trying to compile IronPython for .NET Framework v 3.5. I have >> downloaded the source code from >> https://github.com/IronLanguages/main/zipball/ipy-2.7. After opening the >> IronPython solution file I tried to change the target framework to 3.5 in >> the IronPython project properties page. After doing this I got a message >> from VS 2010 that changing the target framework requires the project to be >> closed and then reopened, so I clicked Yes to confirm the change. However, >> when I opened the project properties again the framework version had >> reverted back to v 4.0. Am I doing something wrong? Please can anyone direct >> me as to how I should compile IronPython for .NET 3.5? >> >> Thanks, >> >> Raj >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghavendra.chandrashekara at gmail.com Sat May 7 05:28:36 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Fri, 6 May 2011 23:28:36 -0400 Subject: [IronPython] Compiling IronPython for .NET 3.5 In-Reply-To: References: <9597F4A19BFDB342B6E90963100C330827C935@SN2PRD0302MB113.namprd03.prod.outlook.com> Message-ID: I was originally trying to build Solutions\IronPython.sln. I think I should have been building Solutions\Dlr.sln (which does contain configurations for v2Release and v2Debug). Is this the correct solution file I should be building? If so, then after doing a build I get the following errors: ------ Build started: Project: Microsoft.Scripting.Core, Configuration: v2Release Any CPU ------ Microsoft.Scripting.Core -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\Microsoft.Scripting.Core.dll ------ Build started: Project: Microsoft.Scripting.Metadata, Configuration: v2Release Any CPU ------ Microsoft.Scripting.Metadata -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\Microsoft.Scripting.Metadata.dll ------ Build started: Project: Cassini, Configuration: v2Release Any CPU ------ Cassini -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\Cassini.exe ------ Build started: Project: Microsoft.Scripting, Configuration: v2Release Any CPU ------ Microsoft.Scripting -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\Microsoft.Scripting.dll ------ Build started: Project: Microsoft.Dynamic, Configuration: v2Release Any CPU ------ Microsoft.Dynamic -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\Microsoft.Dynamic.dll ------ Build started: Project: Ruby (Languages\Ruby\Ruby), Configuration: v2Release Any CPU ------ Ruby -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\IronRuby.dll ------ Build started: Project: IronPython (Languages\IronPython\IronPython), Configuration: v2Release Any CPU ------ D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\Languages\IronPython\IronPython\Runtime\PythonTuple.cs(48,18): error CS0738: 'IronPython.Runtime.PythonTuple' does not implement interface member 'Microsoft.Scripting.Runtime.IExpressionSerializable.CreateExpression()'. 'IronPython.Runtime.PythonTuple.CreateExpression()' cannot implement 'Microsoft.Scripting.Runtime.IExpressionSerializable.CreateExpression()' because it does not have the matching return type of 'Microsoft.Scripting.Ast.Expression'. D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\Languages\IronPython\IronPython\Runtime\PythonTuple.cs(654,51): (Related location) Compile complete -- 1 errors, 0 warnings C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3267: The primary reference "System.Xaml", which is a framework assembly, could not be resolved in the currently targeted framework. ".NETFramework,Version=v3.5". To resolve this problem, either remove the reference "System.Xaml" or retarget your application to a framework version which contains "System.Xaml". ------ Build started: Project: IronRuby.Libraries, Configuration: v2Release Any CPU ------ IronRuby.Libraries -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\IronRuby.Libraries.dll ------ Build started: Project: IronPython.Modules, Configuration: v2Release Any CPU ------ error CS0006: Metadata file 'D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\IronPython.dll' could not be found Compile complete -- 1 errors, 0 warnings ------ Build started: Project: Ruby.WinConsole, Configuration: v2Release Any CPU ------ Ruby.WinConsole -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\irw.exe ------ Build started: Project: Ruby.ConsoleAny, Configuration: v2Release Any CPU ------ Ruby.ConsoleAny -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\ir64.exe ------ Build started: Project: IronPythonWindowAny, Configuration: v2Release Any CPU ------ error CS0006: Metadata file 'D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\IronPython.dll' could not be found Compile complete -- 1 errors, 0 warnings ------ Build started: Project: IronPythonConsoleAny, Configuration: v2Release Any CPU ------ error CS0006: Metadata file 'D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\IronPython.dll' could not be found Compile complete -- 1 errors, 0 warnings ------ Build started: Project: Ruby.WinConsoleAny, Configuration: v2Release Any CPU ------ Ruby.WinConsoleAny -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\irw64.exe ------ Build started: Project: IronRuby.Rack (Hosts\IronRuby.Rack\IronRuby.Rack), Configuration: v2Release Any CPU ------ IronRuby.Rack -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\IronRuby.Rack.dll ------ Build started: Project: ClassInitGenerator, Configuration: v2Release Any CPU ------ ClassInitGenerator -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\ClassInitGenerator.exe ------ Build started: Project: IronRuby.Tests, Configuration: v2Release Any CPU ------ IronRuby.Tests -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\IronRuby.Tests.exe ------ Build started: Project: Ruby.Console, Configuration: v2Release Any CPU ------ Ruby.Console -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\ir.exe ------ Build started: Project: IronPythonWindow, Configuration: v2Release Any CPU ------ error CS0006: Metadata file 'D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\IronPython.dll' could not be found Compile complete -- 1 errors, 0 warnings ------ Build started: Project: IronPythonTest, Configuration: v2Release Any CPU ------ error CS0006: Metadata file 'D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\IronPython.dll' could not be found Compile complete -- 1 errors, 0 warnings C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3267: The primary reference "Microsoft.CSharp", which is a framework assembly, could not be resolved in the currently targeted framework. ".NETFramework,Version=v3.5". To resolve this problem, either remove the reference "Microsoft.CSharp" or retarget your application to a framework version which contains "Microsoft.CSharp". C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3267: The primary reference "System.Xaml", which is a framework assembly, could not be resolved in the currently targeted framework. ".NETFramework,Version=v3.5". To resolve this problem, either remove the reference "System.Xaml" or retarget your application to a framework version which contains "System.Xaml". ------ Build started: Project: IronPythonConsole, Configuration: v2Release Any CPU ------ error CS0006: Metadata file 'D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\IronPython.dll' could not be found Compile complete -- 1 errors, 0 warnings ------ Build started: Project: Metadata, Configuration: v2Release Any CPU ------ Metadata -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\Metadata.exe ------ Build started: Project: IronRuby.Libraries.Yaml, Configuration: v2Release Any CPU ------ IronRuby.Libraries.Yaml -> D:\Downloads\Development\IronPython\IronLanguages-main-5c478d4\bin\v2Release\IronRuby.Libraries.Yaml.dll ------ Skipped Build: Project: Microsoft.Scripting.Silverlight, Configuration: Silverlight3Release Any CPU ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: RowanTest.Common, Configuration: v2Release Any CPU ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: HostingTest, Configuration: v2Release Any CPU ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: Chiron, Configuration: Silverlight3Release Any CPU ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: ClrAssembly, Configuration: v2Release Any CPU ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: TestInternalDLR, Configuration: v2Release Any CPU ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: IronPython.Wpf, Configuration: v2Release Any CPU ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: Microsoft.Scripting.AspNet, Configuration: v2Release Any CPU ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: sympl, Configuration: Release Any CPU ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: Hosting Scenarios, Configuration: Release Any CPU ------ Project not selected to build for this solution configuration ========== Build: 16 succeeded or up-to-date, 7 failed, 10 skipped ========== Is the configuration correct? Thanks, Raj On Fri, May 6, 2011 at 11:16 PM, Raghavendra Chandrashekara < raghavendra.chandrashekara at gmail.com> wrote: > Hi Tomas, > > But there is no v2Debug or v2Release configuration. All I see is Debug, > Release, Silverlight4Debug, and Silverlight4Release. Did I download the > incorrect version of the source code? > > Thanks, > > Raj > > On Fri, May 6, 2011 at 9:45 PM, Tomas Matousek < > Tomas.Matousek at microsoft.com> wrote: > >> Do not change any project settings. Just select build configuration >> ?v2Debug? or ?v2Release?. The default configuration ?Debug? builds for V4. >> >> >> >> Tomas >> >> >> >> *From:* users-bounces at lists.ironpython.com [mailto: >> users-bounces at lists.ironpython.com] *On Behalf Of *Raghavendra >> Chandrashekara >> *Sent:* Friday, May 06, 2011 5:26 PM >> *To:* users at lists.ironpython.com >> *Subject:* [IronPython] Compiling IronPython for .NET 3.5 >> >> >> >> Hi All, >> >> I am trying to compile IronPython for .NET Framework v 3.5. I have >> downloaded the source code from >> https://github.com/IronLanguages/main/zipball/ipy-2.7. After opening the >> IronPython solution file I tried to change the target framework to 3.5 in >> the IronPython project properties page. After doing this I got a message >> from VS 2010 that changing the target framework requires the project to be >> closed and then reopened, so I clicked Yes to confirm the change. However, >> when I opened the project properties again the framework version had >> reverted back to v 4.0. Am I doing something wrong? Please can anyone direct >> me as to how I should compile IronPython for .NET 3.5? >> >> Thanks, >> >> Raj >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghavendra.chandrashekara at gmail.com Sat May 7 06:03:01 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Sat, 7 May 2011 00:03:01 -0400 Subject: [IronPython] Compiling IronPython for .NET 3.5 In-Reply-To: References: <9597F4A19BFDB342B6E90963100C330827C935@SN2PRD0302MB113.namprd03.prod.outlook.com> Message-ID: Hi, I downloaded the latest snapshot from github and used the Solutions\Dlr.sln file to build the v2Release configuration. There were a couple of compilation errors, no Complex object in .NET 3.5, and no StringBuilder.Clear() method which were easy enough to get around. After the changes (I hope I didn't break anything) I was able to compile a set of dlls I can use. Now for some testing. Thanks for your help guys. Raj On Fri, May 6, 2011 at 11:25 PM, Slide wrote: > You may need to get latest rather than the 2.7 snapshot. > On May 6, 2011 8:16 PM, "Raghavendra Chandrashekara" < > raghavendra.chandrashekara at gmail.com> wrote: > > Hi Tomas, > > > > But there is no v2Debug or v2Release configuration. All I see is Debug, > > Release, Silverlight4Debug, and Silverlight4Release. Did I download the > > incorrect version of the source code? > > > > Thanks, > > > > Raj > > > > On Fri, May 6, 2011 at 9:45 PM, Tomas Matousek < > Tomas.Matousek at microsoft.com > >> wrote: > > > >> Do not change any project settings. Just select build configuration > >> ?v2Debug? or ?v2Release?. The default configuration ?Debug? builds for > V4. > >> > >> > >> > >> Tomas > >> > >> > >> > >> *From:* users-bounces at lists.ironpython.com [mailto: > >> users-bounces at lists.ironpython.com] *On Behalf Of *Raghavendra > >> Chandrashekara > >> *Sent:* Friday, May 06, 2011 5:26 PM > >> *To:* users at lists.ironpython.com > >> *Subject:* [IronPython] Compiling IronPython for .NET 3.5 > >> > >> > >> > >> Hi All, > >> > >> I am trying to compile IronPython for .NET Framework v 3.5. I have > >> downloaded the source code from > >> https://github.com/IronLanguages/main/zipball/ipy-2.7. After opening > the > >> IronPython solution file I tried to change the target framework to 3.5 > in > >> the IronPython project properties page. After doing this I got a message > >> from VS 2010 that changing the target framework requires the project to > be > >> closed and then reopened, so I clicked Yes to confirm the change. > However, > >> when I opened the project properties again the framework version had > >> reverted back to v 4.0. Am I doing something wrong? Please can anyone > direct > >> me as to how I should compile IronPython for .NET 3.5? > >> > >> Thanks, > >> > >> Raj > >> > >> _______________________________________________ > >> Users mailing list > >> Users at lists.ironpython.com > >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >> > >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghavendra.chandrashekara at gmail.com Wed May 11 02:30:03 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Tue, 10 May 2011 20:30:03 -0400 Subject: [IronPython] Cannot compile IronPythonTools Message-ID: Hi All, I downloaded the latest code from the git repository and tried to compile IronPythonTools.sln but I got the following error: D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronPythonTools\IronPythonTools.csproj : error : The project file 'D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronPythonTools\IronPythonTools.csproj' cannot be opened. The project type is not supported by this installation. D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronStudio\IronStudio.csproj : error : Unable to read the project file 'IronStudio.csproj'. D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronStudio\IronStudio.csproj(369,3): The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. Am I missing a component from VS 2010? Thanks for any help you can give. Raj -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed May 11 03:00:01 2011 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 11 May 2011 01:00:01 +0000 Subject: [IronPython] Cannot compile IronPythonTools In-Reply-To: References: Message-ID: <6C7ABA8B4E309440B857D74348836F2E15171774@TK5EX14MBXC133.redmond.corp.microsoft.com> You'll need to install the VS SDK (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5&displaylang=en) in addition to Visual Studio. The reason for that is because we use the SDK's project types to get things like a good debugging experience in the experimental hive (you can set IronPythonTools as your setup project and have it launch VS with F5 under the experimental hive. When building the extension automatically gets deployed to the experimental hive). From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Raghavendra Chandrashekara Sent: Tuesday, May 10, 2011 5:30 PM To: Discussion of IronPython Subject: [IronPython] Cannot compile IronPythonTools Hi All, I downloaded the latest code from the git repository and tried to compile IronPythonTools.sln but I got the following error: D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronPythonTools\IronPythonTools.csproj : error : The project file 'D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronPythonTools\IronPythonTools.csproj' cannot be opened. The project type is not supported by this installation. D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronStudio\IronStudio.csproj : error : Unable to read the project file 'IronStudio.csproj'. D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronStudio\IronStudio.csproj(369,3): The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. Am I missing a component from VS 2010? Thanks for any help you can give. Raj -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghavendra.chandrashekara at gmail.com Wed May 11 06:46:13 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Wed, 11 May 2011 00:46:13 -0400 Subject: [IronPython] Cannot compile IronPythonTools In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E15171774@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <6C7ABA8B4E309440B857D74348836F2E15171774@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: Thank you! That solved the problem. Raj On Tue, May 10, 2011 at 9:00 PM, Dino Viehland wrote: > You?ll need to install the VS SDK ( > http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5&displaylang=en) > in addition to Visual Studio. > > > > The reason for that is because we use the SDK?s project types to get things > like a good debugging experience in the experimental hive (you can set > IronPythonTools as your setup project and have it launch VS with F5 under > the experimental hive. When building the extension automatically gets > deployed to the experimental hive). > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Raghavendra > Chandrashekara > *Sent:* Tuesday, May 10, 2011 5:30 PM > *To:* Discussion of IronPython > *Subject:* [IronPython] Cannot compile IronPythonTools > > > > Hi All, > > I downloaded the latest code from the git repository and tried to compile > IronPythonTools.sln but I got the following error: > > D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronPythonTools\IronPythonTools.csproj > : error : The project file > 'D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronPythonTools\IronPythonTools.csproj' > cannot be opened. > > The project type is not supported by this installation. > > D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronStudio\IronStudio.csproj > : error : Unable to read the project file 'IronStudio.csproj'. > D:\Downloads\Development\IronPython\IronPythonSourceCode\Tools\IronStudio\IronStudio\IronStudio.csproj(369,3): > The imported project "C:\Program > Files\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets" > was not found. Confirm that the path in the declaration is correct, > and that the file exists on disk. > > Am I missing a component from VS 2010? Thanks for any help you can give. > > Raj > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Piotr.Nestorow at systemverification.com Wed May 11 09:42:43 2011 From: Piotr.Nestorow at systemverification.com (Piotr Nestorow) Date: Wed, 11 May 2011 09:42:43 +0200 Subject: [IronPython] IronPython in MS VisualStudio Message-ID: <90CF25803C44814EA1B29B33259679C601AEE45282@sr01259> Hi Sometimes IronPython ipy.exe needs some command line parameters in order to enable additional features (like sys._getframe supoport with -X:FullFrames). The question is then how to set this type of parameter for the IronPython engine in the MS VisualStudio (MS VS 2010) integration? Can anybody provide some step-by-step procedure for this? I've seen some references to the ScriptingRuntimeHelpers API by it's not clear to me how to apply this in the IronPython MS VS 2010 integration. Cheers Piotr Nestorow -------------- next part -------------- An HTML attachment was scrubbed... URL: From sj at comsulting.de Wed May 11 10:36:46 2011 From: sj at comsulting.de (=?ISO-8859-15?Q?Sven_J=F6rns?=) Date: Wed, 11 May 2011 10:36:46 +0200 Subject: [IronPython] How to make a Python class dotNet known? Message-ID: <4DCA4A9E.8010500@comsulting.de> Hi, the hosting system in the DLR seems to be responsible for IronPython classes to make known in the dotNet world. For me as a beginner in IronPython and Silverlight is not as easy to understand. How do I get in a pure iron python / Silverlight application (generated with sl.bat) the Python engine? My goal would be to create a code behind file. I would have more opportunities to program Silverlight IronPython. Thanks in advance for answering, greetings Sven From palla74 at gmail.com Wed May 11 12:01:58 2011 From: palla74 at gmail.com (Palla) Date: Wed, 11 May 2011 12:01:58 +0200 Subject: [IronPython] EuroPython: Early Bird will end in 2 days! Message-ID: Hi all, If you plan to attend, you could save quite a bit on registration fees! The end of Early bird is on May 12th, Friday, 23:59:59 CEST. We'd like to ask to you to forward this post to anyone that you feel may be interested. We have an amazing lineup of tutorials, events and talks. We have some excellent keynote speakers and a very complete partner program... but early bird registration ends in 2 days! Right now, you still get discounts on talks and tutorials so if you plan to attend Register Now: http://ep2011.europython.eu/registration/ While you are booking, remember to have a look at the partner program and our offer for a prepaid, data+voice+tethering SIM. We'd like to ask to you to forward this post to anyone that you feel may be interested. All the best, -- ->PALLA From wdines at longview.com Wed May 11 16:12:04 2011 From: wdines at longview.com (Bill Dines) Date: Wed, 11 May 2011 10:12:04 -0400 Subject: [IronPython] Users Digest, Vol 82, Issue 6 In-Reply-To: References: Message-ID: Hi, the hosting system in the DLR seems to be responsible for IronPython classes to make known in the dotNet world. For me as a beginner in IronPython and Silverlight is not as easy to understand. How do I get in a pure iron python / Silverlight application (generated with sl.bat) the Python engine? My goal would be to create a code behind file. I would have more opportunities to program Silverlight IronPython. Thanks in advance for answering, Greetings Sven Hi Sven, Finding out about how to get Silverlight and IronPython working together is quite tricky as the documentation is incomplete where it exists at all. I've been working on it for some time now and am starting to get an idea of what you can do. I am also using python as codebehind to Silverlight controls and pages so it's definitely possible. In fact Silverlight/python (or ruby) is a compelling combination that is in many ways superior to Silverlight/c#. I am surprised more people aren't pursuing it. I would suggest the best place to start would be to install PTVS (from http://pytools.codeplex.com/), which is more mature and robust than the VS tools included with ironpython. Note that you will need to uninstall the ironpython VS tools first. PTVS provides a Silverlight project template that lets you embed python scripts in an html page but I don't think this is really what you want. However you can create proper IronPython/Silverlight applications relatively easily, there is just no template or documentation for it for some reason. See the workaround suggested (by me:)) in this feature request: http://pytools.codeplex.com/workitem/34. Once you have that working you should be able to achieve python codebehind. I am doing it using some Silverlight plumbing that reads in .xaml files (using XamlReader.Load()) and then executes a codebehind .xaml.py file with the same name. You could do it with pure python though if you want. I have to be honest and say that it's probably not going to be especially easy if you are a beginner in both python and Silverlight because the documentation is so poor... Anyway, hope that helps a bit and good luck. Bill From dinov at microsoft.com Wed May 11 22:13:37 2011 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 11 May 2011 20:13:37 +0000 Subject: [IronPython] Python Tools for Visual Studio now accepting contributions Message-ID: <6C7ABA8B4E309440B857D74348836F2E15174F96@TK5EX14MBXC133.redmond.corp.microsoft.com> We've been in a difficult place with having two sets of tools for Visual Studio that both work with IronPython. Those are the existing IronPython Tools that shipped w/ 2.7 and the newer Python Tools for Visual Studio which are derived from the original IronPython code base. To make things more difficult we've been living in a world where you could contribute back to IronPython Tools but contributions weren't being accepted back to PTVS. That's obviously not the best environment for encouraging users to submit changes back and today I'm happy to announce that we've fixed this problem and we're now accepting contributions back to PTVS! If you're interested in contributing back feel free to fork PTVS (http://pytools.codeplex.com/SourceControl/network) and submit a pull request for your changes. Basic contribution guidelines are available here: http://pytools.codeplex.com/wikipage?title=Contributing%20to%20PTVS&version=1 and instructions for getting setup to build are available here: http://pytools.codeplex.com/wikipage?title=Build%20Instructions%20for%20PTVS -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Wed May 11 22:23:21 2011 From: jdhardy at gmail.com (Jeff Hardy) Date: Wed, 11 May 2011 13:23:21 -0700 Subject: [IronPython] Python Tools for Visual Studio now accepting contributions In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E15174F96@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <6C7ABA8B4E309440B857D74348836F2E15174F96@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: This is excellent news. I think the plan should now be to deprecate the IronPython tools and remove them from IronPython 3.0. They'll stay in future 2.7 releases, but perhaps they should be disabled by default to make installing PTVS easier? - Jeff On Wed, May 11, 2011 at 1:13 PM, Dino Viehland wrote: > We?ve been in a difficult place with having two sets of tools for Visual > Studio that both work with IronPython.? Those are the existing IronPython > Tools that shipped w/ 2.7 and the newer Python Tools for Visual Studio which > are derived from the original IronPython code base.? To make things more > difficult we?ve been living in a world where you could contribute back to > IronPython Tools but contributions weren?t being accepted back to PTVS. > That?s obviously not the best environment for encouraging users to submit > changes back and today I?m happy to announce that we?ve fixed this problem > and we?re now accepting contributions back to PTVS! > > > > If you?re interested in contributing back feel free to fork PTVS > (http://pytools.codeplex.com/SourceControl/network) and submit a pull > request for your changes.? Basic contribution guidelines are available here: > http://pytools.codeplex.com/wikipage?title=Contributing%20to%20PTVS&version=1 > and instructions for getting setup to build are available here: > http://pytools.codeplex.com/wikipage?title=Build%20Instructions%20for%20PTVS > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From dinov at microsoft.com Wed May 11 22:25:44 2011 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 11 May 2011 20:25:44 +0000 Subject: [IronPython] Python Tools for Visual Studio now accepting contributions In-Reply-To: References: <6C7ABA8B4E309440B857D74348836F2E15174F96@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: <6C7ABA8B4E309440B857D74348836F2E15175020@TK5EX14MBXC133.redmond.corp.microsoft.com> Jeff wrote: > This is excellent news. > > I think the plan should now be to deprecate the IronPython tools and > remove them from IronPython 3.0. They'll stay in future 2.7 releases, but > perhaps they should be disabled by default to make installing PTVS easier? That sounds like a good idea to me and it should be a pretty simple change. From rome at Wintellect.com Wed May 11 22:27:50 2011 From: rome at Wintellect.com (Keith Rome) Date: Wed, 11 May 2011 13:27:50 -0700 Subject: [IronPython] Python Tools for Visual Studio now accepting contributions In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E15175020@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <6C7ABA8B4E309440B857D74348836F2E15174F96@TK5EX14MBXC133.redmond.corp.microsoft.com> <6C7ABA8B4E309440B857D74348836F2E15175020@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: <7737799D90E55E4BB9C9F7E40D161E110E3303B4F1@VA3DIAXVS461.RED001.local> Please forgive my ignorance on this matter (I don't currently use any of the integrated VS functionality - have been working with embedding the runtime in an existing application), but what is the difference between "IronPython Tools" and "Python Tools for Visual Studio"? I was under the impression this was the same thing? Keith Rome Senior Consultant and Architect MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS Wintellect | 770.617.4016 | krome at wintellect.com www.wintellect.com -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, May 11, 2011 4:26 PM To: Discussion of IronPython Subject: Re: [IronPython] Python Tools for Visual Studio now accepting contributions Jeff wrote: > This is excellent news. > > I think the plan should now be to deprecate the IronPython tools and > remove them from IronPython 3.0. They'll stay in future 2.7 releases, > but perhaps they should be disabled by default to make installing PTVS easier? That sounds like a good idea to me and it should be a pretty simple change. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jdhardy at gmail.com Wed May 11 22:39:17 2011 From: jdhardy at gmail.com (Jeff Hardy) Date: Wed, 11 May 2011 13:39:17 -0700 Subject: [IronPython] Python Tools for Visual Studio now accepting contributions In-Reply-To: <7737799D90E55E4BB9C9F7E40D161E110E3303B4F1@VA3DIAXVS461.RED001.local> References: <6C7ABA8B4E309440B857D74348836F2E15174F96@TK5EX14MBXC133.redmond.corp.microsoft.com> <6C7ABA8B4E309440B857D74348836F2E15175020@TK5EX14MBXC133.redmond.corp.microsoft.com> <7737799D90E55E4BB9C9F7E40D161E110E3303B4F1@VA3DIAXVS461.RED001.local> Message-ID: The IronPython Tools (or "old" tools) are the original VS integration tools, developed when IronPython was still funded by MS. PTVS is a new set of Python (not IronPython-specific; they support CPython and IronPython, and some Jython and PyPy) tools Dino's working on for MS's Technical Computing group. Some of the features are HPC-specific (like MPI cluster debugging) but for the most part it's just a nice Python environment, and a lot more stable than the old tools. Dino, can the HPC stuff be split out for people who don't need it? PTVS is significantly better then the old tools and is also under active development, and now that they're accepting contributions it makes sense to me to retire the old tools and just get people to download PTVS (I doubt we'll bundle them, but instead have a big link next on the download page). - Jeff On Wed, May 11, 2011 at 1:27 PM, Keith Rome wrote: > Please forgive my ignorance on this matter (I don't currently use any of the integrated VS functionality - have been working with embedding the runtime in an existing application), but what is the difference between "IronPython Tools" and "Python Tools for Visual Studio"? I was under the impression this was the same thing? > > > Keith Rome > Senior Consultant and Architect > MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS > Wintellect | 770.617.4016 | krome at wintellect.com > www.wintellect.com > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Wednesday, May 11, 2011 4:26 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Python Tools for Visual Studio now accepting contributions > > > > Jeff wrote: >> This is excellent news. >> >> I think the plan should now be to deprecate the IronPython tools and >> remove them from IronPython 3.0. They'll stay in future 2.7 releases, >> but perhaps they should be disabled by default to make installing PTVS easier? > > That sounds like a good idea to me and it should be a pretty simple change. > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at microsoft.com Wed May 11 22:39:26 2011 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 11 May 2011 20:39:26 +0000 Subject: [IronPython] Python Tools for Visual Studio now accepting contributions In-Reply-To: <7737799D90E55E4BB9C9F7E40D161E110E3303B4F1@VA3DIAXVS461.RED001.local> References: <6C7ABA8B4E309440B857D74348836F2E15174F96@TK5EX14MBXC133.redmond.corp.microsoft.com> <6C7ABA8B4E309440B857D74348836F2E15175020@TK5EX14MBXC133.redmond.corp.microsoft.com> <7737799D90E55E4BB9C9F7E40D161E110E3303B4F1@VA3DIAXVS461.RED001.local> Message-ID: <6C7ABA8B4E309440B857D74348836F2E15175135@TK5EX14MBXC133.redmond.corp.microsoft.com> Keith wrote: > Please forgive my ignorance on this matter (I don't currently use any of the > integrated VS functionality - have been working with embedding the runtime > in an existing application), but what is the difference between "IronPython > Tools" and "Python Tools for Visual Studio"? I was under the impression this > was the same thing? IronPython Tools was the initial version that was undergoing development while Microsoft was still funding IronPython development. After we released IronPython back to the community I switched to a new team and started working on PTVS (using the IronPython Tools code base as a starting point). PTVS keeps all of the functionality that IpyTools had but adds: Support for CPython (and other Python implementations like Jython and PyPy) Support for multiple versions of Python (2.5 - 3.2) A Python specific debugger (instead of just using the .NET debugger) Profiling of CPython apps MPI projects and debugging There's probably some other new features that I'm missing. So it's basically a more general and better version of IpyTools but our core focus is on high performance computing scenarios where you'd like to use Python - but we're also making sure we just have a great Python development experience as well. From dinov at microsoft.com Wed May 11 22:42:46 2011 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 11 May 2011 20:42:46 +0000 Subject: [IronPython] Python Tools for Visual Studio now accepting contributions In-Reply-To: References: <6C7ABA8B4E309440B857D74348836F2E15174F96@TK5EX14MBXC133.redmond.corp.microsoft.com> <6C7ABA8B4E309440B857D74348836F2E15175020@TK5EX14MBXC133.redmond.corp.microsoft.com> <7737799D90E55E4BB9C9F7E40D161E110E3303B4F1@VA3DIAXVS461.RED001.local> Message-ID: <6C7ABA8B4E309440B857D74348836F2E15175195@TK5EX14MBXC133.redmond.corp.microsoft.com> Jeff wrote: > The IronPython Tools (or "old" tools) are the original VS integration tools, > developed when IronPython was still funded by MS. PTVS is a new set of > Python (not IronPython-specific; they support CPython and IronPython, and > some Jython and PyPy) tools Dino's working on for MS's Technical Computing > group. Some of the features are HPC-specific (like MPI cluster debugging) > but for the most part it's just a nice Python environment, and a lot more > stable than the old tools. > > Dino, can the HPC stuff be split out for people who don't need it? Not only can it be split out, it already is! :) It's in its own VS package already and when you install it's an optional component. That's basically a necessity because it depends upon the HPC SDK which we don't want to require everyone to have. It does mean if you're doing development on PTVS that you need to have the VS SDK installed or unload that project from the solution. > > PTVS is significantly better then the old tools and is also under active > development, and now that they're accepting contributions it makes sense > to me to retire the old tools and just get people to download PTVS (I doubt > we'll bundle them, but instead have a big link next on the download page). From davew252 at tx.rr.com Thu May 12 01:05:32 2011 From: davew252 at tx.rr.com (Dave Wald) Date: Wed, 11 May 2011 18:05:32 -0500 Subject: [IronPython] Python Tools for Visual Studio now accepting contributions In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E15175135@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <6C7ABA8B4E309440B857D74348836F2E15174F96@TK5EX14MBXC133.redmond.corp.microsoft.com> <6C7ABA8B4E309440B857D74348836F2E15175020@TK5EX14MBXC133.redmond.corp.microsoft.com> <7737799D90E55E4BB9C9F7E40D161E110E3303B4F1@VA3DIAXVS461.RED001.local> <6C7ABA8B4E309440B857D74348836F2E15175135@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: <4DCB163C.1020206@tx.rr.com> On 5/11/2011 3:39 PM, Dino Viehland wrote: > Keith wrote: >> Please forgive my ignorance on this matter (I don't currently use any of the >> integrated VS functionality - have been working with embedding the runtime >> in an existing application), but what is the difference between "IronPython >> Tools" and "Python Tools for Visual Studio"? I was under the impression this >> was the same thing? > IronPython Tools was the initial version that was undergoing development while > Microsoft was still funding IronPython development. After we released IronPython > back to the community I switched to a new team and started working on PTVS (using > the IronPython Tools code base as a starting point). PTVS keeps all of the functionality > that IpyTools had but adds: > Support for CPython (and other Python implementations like Jython and PyPy) > Support for multiple versions of Python (2.5 - 3.2) > A Python specific debugger (instead of just using the .NET debugger) > Profiling of CPython apps > MPI projects and debugging > > There's probably some other new features that I'm missing. So it's basically a more > general and better version of IpyTools but our core focus is on high performance > computing scenarios where you'd like to use Python - but we're also making sure > we just have a great Python development experience as well. > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > Dino, The new tools are awesome. Thanks again! (BTW, any idea yet when this one might be done? http://ironpython.codeplex.com/workitem/30379 ) Thanks, Dave From raghavendra.chandrashekara at gmail.com Thu May 12 01:49:46 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Wed, 11 May 2011 19:49:46 -0400 Subject: [IronPython] Intellisense with imported dlls Message-ID: Hi All, I added a couple of custom .NET dlls using the clr.AddReference() method in my program and I was expecting IronPython Tools for Visual Studio to be able to parse the imported dlls and provide intellisense for the imported classes. However I don't see any imported methods when I press either Ctrl + Space or the '.' key after a class object. Is there something extra I need to do? Thanks, Raj -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghavendra.chandrashekara at gmail.com Thu May 12 02:12:53 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Wed, 11 May 2011 20:12:53 -0400 Subject: [IronPython] Cannot compile IronPythonTools In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E15171774@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <6C7ABA8B4E309440B857D74348836F2E15171774@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: On Tue, May 10, 2011 at 9:00 PM, Dino Viehland wrote: > You?ll need to install the VS SDK ( > http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5&displaylang=en) > in addition to Visual Studio. > > > > The reason for that is because we use the SDK?s project types to get things > like a good debugging experience in the experimental hive (you can set > IronPythonTools as your setup project and have it launch VS with F5 under > the experimental hive. When building the extension automatically gets > deployed to the experimental hive). > > > One more question, how do I debug the IronPython tools? I have created the experimental hive using the command: CreateExpInstance.exe /Reset /VSInstance=10.0 /RootSuffix=Exp and then started the experimental instance of Visual Studio using: "C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" /RootSuffix Exp This starts an Experimental Instance of Visual Studio which I can see in the title bar. But when I set IronPythonTools as the startup project and press F5 I get a message saying that "A project with an Output Type of Class Library" cannot be started directly. Thanks, Raj -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghavendra.chandrashekara at gmail.com Thu May 12 02:43:24 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Wed, 11 May 2011 20:43:24 -0400 Subject: [IronPython] Cannot compile IronPythonTools In-Reply-To: References: <6C7ABA8B4E309440B857D74348836F2E15171774@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: Please ignore above question, I figured it out. In case some other new users want to debug IronPythonTools then I think the way to debug is the following: 1. Launch VS 2010 in normal mode and open IronPythonTools.sln 2. Set IronPythonTools as the startup project. 3. Open properties pages of IronPythonTools and select Debug tab. 4. Select "Start external program" radio button and put C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe in the text box next to the radio button. 5. Put /RootSuffix Exp in Command line arguments and press F5 to debug. Raj On Wed, May 11, 2011 at 8:12 PM, Raghavendra Chandrashekara < raghavendra.chandrashekara at gmail.com> wrote: > On Tue, May 10, 2011 at 9:00 PM, Dino Viehland wrote: > >> You?ll need to install the VS SDK ( >> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5&displaylang=en) >> in addition to Visual Studio. >> >> >> >> The reason for that is because we use the SDK?s project types to get >> things like a good debugging experience in the experimental hive (you can >> set IronPythonTools as your setup project and have it launch VS with F5 >> under the experimental hive. When building the extension automatically gets >> deployed to the experimental hive). >> >> >> > > One more question, how do I debug the IronPython tools? I have created the > experimental hive using the command: > > CreateExpInstance.exe /Reset /VSInstance=10.0 /RootSuffix=Exp > > and then started the experimental instance of Visual Studio using: > > "C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" > /RootSuffix Exp > > This starts an Experimental Instance of Visual Studio which I can see in > the title bar. But when I set IronPythonTools as the startup project and > press F5 I get a message saying that "A project with an Output Type of Class > Library" cannot be started directly. > > Thanks, > > Raj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu May 12 02:49:20 2011 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 May 2011 00:49:20 +0000 Subject: [IronPython] Cannot compile IronPythonTools In-Reply-To: References: <6C7ABA8B4E309440B857D74348836F2E15171774@TK5EX14MBXC133.redmond.corp.microsoft.com>, Message-ID: <6C7ABA8B4E309440B857D74348836F2E151769F1@TK5EX14MBXC133.redmond.corp.microsoft.com> You can go into project properties for IronPythonTools and on the debug settings choose launch external program. Then just add the same command line you used to launch under the exp hive and F5 will work. Sent from my Windows Phone ________________________________ From: Raghavendra Chandrashekara Sent: Wednesday, May 11, 2011 5:13 PM To: Discussion of IronPython Subject: Re: [IronPython] Cannot compile IronPythonTools On Tue, May 10, 2011 at 9:00 PM, Dino Viehland > wrote: You?ll need to install the VS SDK (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5&displaylang=en) in addition to Visual Studio. The reason for that is because we use the SDK?s project types to get things like a good debugging experience in the experimental hive (you can set IronPythonTools as your setup project and have it launch VS with F5 under the experimental hive. When building the extension automatically gets deployed to the experimental hive). One more question, how do I debug the IronPython tools? I have created the experimental hive using the command: CreateExpInstance.exe /Reset /VSInstance=10.0 /RootSuffix=Exp and then started the experimental instance of Visual Studio using: "C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" /RootSuffix Exp This starts an Experimental Instance of Visual Studio which I can see in the title bar. But when I set IronPythonTools as the startup project and press F5 I get a message saying that "A project with an Output Type of Class Library" cannot be started directly. Thanks, Raj -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu May 12 02:51:04 2011 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 May 2011 00:51:04 +0000 Subject: [IronPython] Intellisense with imported dlls In-Reply-To: References: Message-ID: <6C7ABA8B4E309440B857D74348836F2E15178A21@TK5EX14MBXC133.redmond.corp.microsoft.com> Where are the assemblies? Currently we'll only find assemblies in the gac. Sent from my Windows Phone ________________________________ From: Raghavendra Chandrashekara Sent: Wednesday, May 11, 2011 4:49 PM To: Discussion of IronPython Subject: [IronPython] Intellisense with imported dlls Hi All, I added a couple of custom .NET dlls using the clr.AddReference() method in my program and I was expecting IronPython Tools for Visual Studio to be able to parse the imported dlls and provide intellisense for the imported classes. However I don't see any imported methods when I press either Ctrl + Space or the '.' key after a class object. Is there something extra I need to do? Thanks, Raj -------------- next part -------------- An HTML attachment was scrubbed... URL: From raghavendra.chandrashekara at gmail.com Thu May 12 03:07:00 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Wed, 11 May 2011 21:07:00 -0400 Subject: [IronPython] Intellisense with imported dlls In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E15178A21@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <6C7ABA8B4E309440B857D74348836F2E15178A21@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: <087BFF09-4C74-47CD-8737-92C041D87568@gmail.com> Ah, I see. The referenced assemblies are in a sub-directory of my project. Would it be too difficult to add the list of assemblies in the Search Path directories of the project? I can try to change the IronPythonTools code to do this if you could give a hint as to where I should start. Thanks, Raj On 2011-05-11, at 20:51, Dino Viehland wrote: > Where are the assemblies? Currently we'll only find assemblies in the gac. > > Sent from my Windows Phone > From: Raghavendra Chandrashekara > Sent: Wednesday, May 11, 2011 4:49 PM > To: Discussion of IronPython > Subject: [IronPython] Intellisense with imported dlls > > Hi All, > > I added a couple of custom .NET dlls using the clr.AddReference() method in my program and I was expecting IronPython Tools for Visual Studio to be able to parse the imported dlls and provide intellisense for the imported classes. However I don't see any imported methods when I press either Ctrl + Space or the '.' key after a class object. Is there something extra I need to do? > > Thanks, > > Raj > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu May 12 03:21:45 2011 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 May 2011 01:21:45 +0000 Subject: [IronPython] Intellisense with imported dlls In-Reply-To: <087BFF09-4C74-47CD-8737-92C041D87568@gmail.com> References: <6C7ABA8B4E309440B857D74348836F2E15178A21@TK5EX14MBXC133.redmond.corp.microsoft.com> <087BFF09-4C74-47CD-8737-92C041D87568@gmail.com> Message-ID: <6C7ABA8B4E309440B857D74348836F2E15178B6C@TK5EX14MBXC133.redmond.corp.microsoft.com> Cool, this shouldn?t be too hard to fix. We load the assemblies in ProjectState.cs and it should just be a matter of flowing the VS project settings down to the analysis ProjectState class and then attempting to load the assemblies from there. If you?d like to fix it in PTVS, which I?d encourage you to do, it?s been moved to IronPythonInterpreter.cs. In PTVS it might be more difficult to flow in the VS project but you could update the IPythonInterpreter interface or IInterpreterState so that we either push down or allow pulling out the search paths. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Raghavendra Chandrashekara Sent: Wednesday, May 11, 2011 6:07 PM To: Discussion of IronPython Cc: Discussion of IronPython Subject: Re: [IronPython] Intellisense with imported dlls Ah, I see. The referenced assemblies are in a sub-directory of my project. Would it be too difficult to add the list of assemblies in the Search Path directories of the project? I can try to change the IronPythonTools code to do this if you could give a hint as to where I should start. Thanks, Raj On 2011-05-11, at 20:51, Dino Viehland > wrote: Where are the assemblies? Currently we'll only find assemblies in the gac. Sent from my Windows Phone ________________________________ From: Raghavendra Chandrashekara Sent: Wednesday, May 11, 2011 4:49 PM To: Discussion of IronPython Subject: [IronPython] Intellisense with imported dlls Hi All, I added a couple of custom .NET dlls using the clr.AddReference() method in my program and I was expecting IronPython Tools for Visual Studio to be able to parse the imported dlls and provide intellisense for the imported classes. However I don't see any imported methods when I press either Ctrl + Space or the '.' key after a class object. Is there something extra I need to do? Thanks, Raj _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdines at longview.com Thu May 12 10:05:59 2011 From: wdines at longview.com (Bill Dines) Date: Thu, 12 May 2011 04:05:59 -0400 Subject: [IronPython] Intellisense with imported dlls In-Reply-To: References: Message-ID: Hi Raj, You could try adding the .dlls to the GAC. I think this works with PTVS, but not sure if it works with the tools bundled with IP 2.7. If you are using the bundled tools it sounds like you should probably consider changing to PTVS anyway. FYI, I have added a feature request for PTVS for "add reference" to custom dlls when creating Silverlight python projects. It may be that work also needs to be done with .NET projects too. See here: http://pytools.codeplex.com/workitem/148. Bill Message: 8 Date: Wed, 11 May 2011 19:49:46 -0400 From: Raghavendra Chandrashekara To: Discussion of IronPython Subject: [IronPython] Intellisense with imported dlls Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi All, I added a couple of custom .NET dlls using the clr.AddReference() method in my program and I was expecting IronPython Tools for Visual Studio to be able to parse the imported dlls and provide intellisense for the imported classes. However I don't see any imported methods when I press either Ctrl + Space or the '.' key after a class object. Is there something extra I need to do? Thanks, Raj -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com End of Users Digest, Vol 82, Issue 8 ************************************ From dkottowk at yahoo.com Thu May 12 18:57:51 2011 From: dkottowk at yahoo.com (daniel kottow) Date: Thu, 12 May 2011 09:57:51 -0700 (PDT) Subject: [IronPython] clr.ImportExtensions are not available outside module ? Message-ID: <434216.75989.qm@web161714.mail.bf1.yahoo.com> Hi, Just as Dave Wald, I have also trying out the ImportExtensions methods which I personally find very useful, thank you for implementing. Everything is working fine on using 2.7 (and .net 4), but extension methods loaded by one module seem not available on another... I will stick to Dave's code exmaple: import clr clr.AddReference("System.Core") import System from System import Linq clr.ImportExtensions(Linq) class Product(object): def __init__(self, cat, id, qtyOnHand ): self.Cat = cat self.ID = id self.QtyOnHand = qtyOnHand self.Q = self.QtyOnHand If I put this into a file, lets say test.py and now use the module on the command line: >>> import test >>> products = [test.Product('food', i, 10) for i in range(3)] >>> >>> >>> products.Where Traceback (most recent call last): File "", line 1, in AttributeError: 'list' object has no attribute 'Where' The linq extensions are not available. I have to re-import them: >>> test.clr.ImportExtensions(test.Linq) >>> products.Where >>> Is this a current limitation, or should I be doing things differently ? Any help appreciated. Greetings, Daniel From dinov at microsoft.com Thu May 12 19:01:33 2011 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 May 2011 17:01:33 +0000 Subject: [IronPython] clr.ImportExtensions are not available outside module ? In-Reply-To: <434216.75989.qm@web161714.mail.bf1.yahoo.com> References: <434216.75989.qm@web161714.mail.bf1.yahoo.com> Message-ID: <6C7ABA8B4E309440B857D74348836F2E15179D1B@TK5EX14MBXC133.redmond.corp.microsoft.com> Daniel wrote: > Just as Dave Wald, I have also trying out the ImportExtensions methods > which I personally find very useful, thank you for implementing. Everything is > working fine on using 2.7 (and .net 4), but extension methods loaded by one > module seem not available on another... This is by design. It works similar to how "import clr" only effects the current module and how extension methods work in C# where they are scoped by file. So if you want extension methods available in a file you'll need to import them in that file. If they were globally scoped it would be easy for one module to break another by bringing in the 'wrong' extension methods. > > > I will stick to Dave's code exmaple: > > import clr > clr.AddReference("System.Core") > import System > from System import Linq > > clr.ImportExtensions(Linq) > > class Product(object): > def __init__(self, cat, id, qtyOnHand ): > self.Cat = cat > self.ID = id > self.QtyOnHand = qtyOnHand > self.Q = self.QtyOnHand > > If I put this into a file, lets say test.py and now use the module on the > command line: > > >>> import test > >>> products = [test.Product('food', i, 10) for i in range(3)] > >>> > >>> > >>> products.Where > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'list' object has no attribute 'Where' > > The linq extensions are not available. I have to re-import them: > > >>> test.clr.ImportExtensions(test.Linq) > >>> products.Where > > >>> > > Is this a current limitation, or should I be doing things differently ? > Any help appreciated. > > Greetings, > Daniel > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dkottowk at yahoo.com Thu May 12 20:32:31 2011 From: dkottowk at yahoo.com (daniel kottow) Date: Thu, 12 May 2011 11:32:31 -0700 (PDT) Subject: [IronPython] clr.ImportExtensions are not available outside module ? In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E15179D1B@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <434216.75989.qm@web161714.mail.bf1.yahoo.com> <6C7ABA8B4E309440B857D74348836F2E15179D1B@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: <739766.85517.qm@web161705.mail.bf1.yahoo.com> Ok. I am not sure what you mean by similar to import clr, though. Because in my example, clr is available from outside test; its just named test.clr... Let me give you another example which is closer on how I ran into this... Lets say you have in C#: --- iron.Example.cs namespace iron { public class Example { public Example() { } public int foo() { return 1; } } public static class ExampleExtension { public static int bar(this Example example) { return example.foo() + 1; } } } --- EOF Then I define an example.py to wrap this up: --- test.py import clr clr.AddReference("iron") import iron clr.ImportExtensions(iron.ExampleExtension) # lets use this just to test it out e = iron.Example() print e.foo() print e.bar() --- EOF now on my command line I get >>> import example 1 2 >>> ex = example.iron.Example() >>> ex.foo() 1 >>> ex.bar() Traceback (most recent call last): File "", line 1, in AttributeError: 'Example' object has no attribute 'bar' And so I don't find a nice way to wrap my C# functionality in just one python module, where I whish I could offer the extension methods just like any other method... or is my import strategy somehow flawed ? Greetings, Daniel namespace native { public class Example { } public static class ExampleExtension { public static void } add some extension methods to it, and then want to import everything in one python stub module. E.g. ----- Original Message ---- From: Dino Viehland To: Discussion of IronPython Sent: Thu, May 12, 2011 1:01:33 PM Subject: Re: [IronPython] clr.ImportExtensions are not available outside module ? Daniel wrote: > Just as Dave Wald, I have also trying out the ImportExtensions methods > which I personally find very useful, thank you for implementing. Everything is > working fine on using 2.7 (and .net 4), but extension methods loaded by one > module seem not available on another... This is by design. It works similar to how "import clr" only effects the current module and how extension methods work in C# where they are scoped by file. So if you want extension methods available in a file you'll need to import them in that file. If they were globally scoped it would be easy for one module to break another by bringing in the 'wrong' extension methods. > > > I will stick to Dave's code exmaple: > > import clr > clr.AddReference("System.Core") > import System > from System import Linq > > clr.ImportExtensions(Linq) > > class Product(object): > def __init__(self, cat, id, qtyOnHand ): > self.Cat = cat > self.ID = id > self.QtyOnHand = qtyOnHand > self.Q = self.QtyOnHand > > If I put this into a file, lets say test.py and now use the module on the > command line: > > >>> import test > >>> products = [test.Product('food', i, 10) for i in range(3)] > >>> > >>> > >>> products.Where > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'list' object has no attribute 'Where' > > The linq extensions are not available. I have to re-import them: > > >>> test.clr.ImportExtensions(test.Linq) > >>> products.Where > > >>> > > Is this a current limitation, or should I be doing things differently ? > Any help appreciated. > > Greetings, > Daniel > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Thu May 12 21:50:01 2011 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 May 2011 19:50:01 +0000 Subject: [IronPython] clr.ImportExtensions are not available outside module ? In-Reply-To: <739766.85517.qm@web161705.mail.bf1.yahoo.com> References: <434216.75989.qm@web161714.mail.bf1.yahoo.com> <6C7ABA8B4E309440B857D74348836F2E15179D1B@TK5EX14MBXC133.redmond.corp.microsoft.com> <739766.85517.qm@web161705.mail.bf1.yahoo.com> Message-ID: <6C7ABA8B4E309440B857D74348836F2E1517A240@TK5EX14MBXC133.redmond.corp.microsoft.com> Daniel wrote: > Ok. > I am not sure what you mean by similar to import clr, though. It's similar to import clr in that importing clr not only gives you the clr module but also makes .NET members available to the module which imported clr. For example before doing "import clr" calling .ToString() on an object will raise an AttributeError but afterwards it will call the .NET ToString method. If you'd like to provide a set of globally available extension methods specifically for IronPython users you could use ExtensionTypeAttribute (which is defined in the DLR outer layer). IronPython will look for that attribute declared on an assembly. The attribute will give a type to extend and a type to pull the extension methods from. All you need to do is load the assembly into the script runtime either via the hosting APIs or clr.AddReference. This was the mechanism we originally used to add the Python methods to the .NET types like string (we now hard code the types for Python rather reflecting over the types at startup, but the mechanism remains for backwards compat). > > Because in my example, clr is available from outside test; its just named > test.clr... > Let me give you another example which is closer on how I ran into this... > > Lets say you have in C#: > > --- iron.Example.cs > > namespace iron > { > public class Example > { > public Example() > { > } > > public int foo() > { > return 1; > } > } > > public static class ExampleExtension > { > public static int bar(this Example example) > { > return example.foo() + 1; > } > > } > } > > --- EOF > > Then I define an example.py to wrap this up: > > --- test.py > > import clr > clr.AddReference("iron") > import iron > clr.ImportExtensions(iron.ExampleExtension) > > # lets use this just to test it out > > e = iron.Example() > print e.foo() > print e.bar() > > --- EOF > > now on my command line I get > > >>> import example > 1 > 2 > >>> ex = example.iron.Example() > >>> ex.foo() > 1 > >>> ex.bar() > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'Example' object has no attribute 'bar' > > And so I don't find a nice way to wrap my C# functionality in just one python > module, > > where I whish I could offer the extension methods just like any other > method... > or is my import strategy somehow flawed ? > > Greetings, > Daniel > > > > > > namespace native > { > public class Example > { > } > > public static class ExampleExtension > { > public static void > } > > add some extension methods to it, and then want to import everything in > one > python stub module. E.g. > > > > > > ----- Original Message ---- > From: Dino Viehland > To: Discussion of IronPython > Sent: Thu, May 12, 2011 1:01:33 PM > Subject: Re: [IronPython] clr.ImportExtensions are not available outside > module > ? > > > > Daniel wrote: > > Just as Dave Wald, I have also trying out the ImportExtensions methods > > which I personally find very useful, thank you for implementing. Everything > is > > working fine on using 2.7 (and .net 4), but extension methods loaded by > one > > module seem not available on another... > > This is by design. It works similar to how "import clr" only effects the > current module > and how extension methods work in C# where they are scoped by file. So if > you > want extension methods available in a file you'll need to import them in that > file. > > If they were globally scoped it would be easy for one module to break > another by > bringing in the 'wrong' extension methods. > > > > > > > I will stick to Dave's code exmaple: > > > > import clr > > clr.AddReference("System.Core") > > import System > > from System import Linq > > > > clr.ImportExtensions(Linq) > > > > class Product(object): > > def __init__(self, cat, id, qtyOnHand ): > > self.Cat = cat > > self.ID = id > > self.QtyOnHand = qtyOnHand > > self.Q = self.QtyOnHand > > > > If I put this into a file, lets say test.py and now use the module on the > > command line: > > > > >>> import test > > >>> products = [test.Product('food', i, 10) for i in range(3)] > > >>> > > >>> > > >>> products.Where > > Traceback (most recent call last): > > File "", line 1, in > > AttributeError: 'list' object has no attribute 'Where' > > > > The linq extensions are not available. I have to re-import them: > > > > >>> test.clr.ImportExtensions(test.Linq) > > >>> products.Where > > > > >>> > > > > Is this a current limitation, or should I be doing things differently ? > > Any help appreciated. > > > > Greetings, > > Daniel > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From Piotr.Nestorow at systemverification.com Thu May 12 22:43:58 2011 From: Piotr.Nestorow at systemverification.com (Piotr Nestorow) Date: Thu, 12 May 2011 22:43:58 +0200 Subject: [IronPython] pytest results in unsupported PythonDictionary system error Message-ID: <90CF25803C44814EA1B29B33259679C601AEE45284@sr01259> Hi This is for IronPython 2.7 Pytest 2.0.3 installed in site-packages Running a test with pytest results in the following system error: SystemError: Unsupported param dictionary type: IronPython.Runtime.PythonDictionary Any ideas what the problem is? ---------------------------------------------- Here is the example and the error: class TestBasic: def test_01(self): for n in (2, 4, 6, 8, 10): yield self.n_greater_than_zero, n def n_greater_than_zero(self, n): assert n > 0 if __name__ == '__main__': import pytest pytest.main() C:\IronPython\ipy.exe .\test_001_dd.py Traceback (most recent call last): File ".\test_001_dd.py", line 11, in File "C:\IronPython\lib\site-packages\pytest.py", line 6, in File "C:\IronPython\lib\site-packages\_pytest\core.py", line 7, in File "C:\IronPython\lib\site-packages\py\__init__.py", line 19, in File "C:\IronPython\lib\site-packages\py\_apipkg.py", line 33, in initpkg SystemError: Unsupported param dictionary type: IronPython.Runtime.PythonDictionary ------------------------------------------- Cheers Piotr Nestorow From dinov at microsoft.com Thu May 12 23:08:13 2011 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 12 May 2011 21:08:13 +0000 Subject: [IronPython] pytest results in unsupported PythonDictionary system error In-Reply-To: <90CF25803C44814EA1B29B33259679C601AEE45284@sr01259> References: <90CF25803C44814EA1B29B33259679C601AEE45284@sr01259> Message-ID: <6C7ABA8B4E309440B857D74348836F2E1517A4C2@TK5EX14MBXC133.redmond.corp.microsoft.com> Piotr wrote: > Hi > > This is for IronPython 2.7 > Pytest 2.0.3 installed in site-packages > > Running a test with pytest results in the following system error: > SystemError: Unsupported param dictionary type: > IronPython.Runtime.PythonDictionary > > Any ideas what the problem is? > > ---------------------------------------------- > Here is the example and the error: > > class TestBasic: > def test_01(self): > for n in (2, 4, 6, 8, 10): > yield self.n_greater_than_zero, n > > def n_greater_than_zero(self, n): > assert n > 0 > > if __name__ == '__main__': > import pytest > pytest.main() > > C:\IronPython\ipy.exe .\test_001_dd.py > Traceback (most recent call last): > File ".\test_001_dd.py", line 11, in > File "C:\IronPython\lib\site-packages\pytest.py", line 6, in > File "C:\IronPython\lib\site-packages\_pytest\core.py", line 7, in > File "C:\IronPython\lib\site-packages\py\__init__.py", line 19, in > File "C:\IronPython\lib\site-packages\py\_apipkg.py", line 33, in initpkg > SystemError: Unsupported param dictionary type: > IronPython.Runtime.PythonDictionary Can you send the code in _apipkg.py on line 33 (and maybe some surrounding code)? Anyway, it sounds like a binder bug but that code might help create a simple repro. From raghavendra.chandrashekara at gmail.com Fri May 13 03:06:11 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Thu, 12 May 2011 21:06:11 -0400 Subject: [IronPython] Intellisense with imported dlls In-Reply-To: References: Message-ID: <6543E3ED-1019-4000-9A0D-8BB3C1738A10@gmail.com> Hi Bill, Thanks for the tip. This is what I'm doing for now. Raj On 2011-05-12, at 4:05 AM, "Bill Dines" wrote: > Hi Raj, > > You could try adding the .dlls to the GAC. I think this works with > PTVS, but not sure if it works with the tools bundled with IP 2.7. If > you are using the bundled tools it sounds like you should probably > consider changing to PTVS anyway. FYI, I have added a feature request > for PTVS for "add reference" to custom dlls when creating Silverlight > python projects. It may be that work also needs to be done with .NET > projects too. See here: http://pytools.codeplex.com/workitem/148. > > Bill > > > Message: 8 > Date: Wed, 11 May 2011 19:49:46 -0400 > From: Raghavendra Chandrashekara > > To: Discussion of IronPython > Subject: [IronPython] Intellisense with imported dlls > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > Hi All, > > I added a couple of custom .NET dlls using the clr.AddReference() method > in > my program and I was expecting IronPython Tools for Visual Studio to be > able > to parse the imported dlls and provide intellisense for the imported > classes. However I don't see any imported methods when I press either > Ctrl + > Space or the '.' key after a class object. Is there something extra I > need > to do? > > Thanks, > > Raj > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > 20110511/284b42e2/attachment.htm> > > ------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > End of Users Digest, Vol 82, Issue 8 > ************************************ > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From Piotr.Nestorow at systemverification.com Fri May 13 08:43:22 2011 From: Piotr.Nestorow at systemverification.com (Piotr Nestorow) Date: Fri, 13 May 2011 08:43:22 +0200 Subject: [IronPython] pytest results in unsupported PythonDictionary system error In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E1517A4C2@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <90CF25803C44814EA1B29B33259679C601AEE45284@sr01259>, <6C7ABA8B4E309440B857D74348836F2E1517A4C2@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: <90CF25803C44814EA1B29B33259679C601AEE45285@sr01259> The installed pytest and py are: pytest-2.0.3-py2.7, py-1.4.3-py2.7 I'm providing the relevant method from py-1.4.3-py27.egg/py/_apipkg.py: Line 33 is: mod = ApiModule(pkgname, exportdefs, implprefix=pkgname, attr=d) def initpkg(pkgname, exportdefs, attr=dict()): """ initialize given package from the export definitions. """ oldmod = sys.modules.get(pkgname) d = {} f = getattr(oldmod, '__file__', None) if f: f = os.path.abspath(f) d['__file__'] = f if hasattr(oldmod, '__version__'): d['__version__'] = oldmod.__version__ if hasattr(oldmod, '__loader__'): d['__loader__'] = oldmod.__loader__ if hasattr(oldmod, '__path__'): d['__path__'] = [os.path.abspath(p) for p in oldmod.__path__] if '__doc__' not in exportdefs and getattr(oldmod, '__doc__', None): d['__doc__'] = oldmod.__doc__ d.update(attr) if hasattr(oldmod, "__dict__"): oldmod.__dict__.update(d) mod = ApiModule(pkgname, exportdefs, implprefix=pkgname, attr=d) sys.modules[pkgname] = mod ________________________________________ Fr?n: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] för Dino Viehland [dinov at microsoft.com] Skickat: den 12 maj 2011 23:08 Till: Discussion of IronPython ?mne: Re: [IronPython] pytest results in unsupported PythonDictionary system error Piotr wrote: > Hi > > This is for IronPython 2.7 > Pytest 2.0.3 installed in site-packages > > Running a test with pytest results in the following system error: > SystemError: Unsupported param dictionary type: > IronPython.Runtime.PythonDictionary > > Any ideas what the problem is? > > ---------------------------------------------- > Here is the example and the error: > > class TestBasic: > def test_01(self): > for n in (2, 4, 6, 8, 10): > yield self.n_greater_than_zero, n > > def n_greater_than_zero(self, n): > assert n > 0 > > if __name__ == '__main__': > import pytest > pytest.main() > > C:\IronPython\ipy.exe .\test_001_dd.py > Traceback (most recent call last): > File ".\test_001_dd.py", line 11, in > File "C:\IronPython\lib\site-packages\pytest.py", line 6, in > File "C:\IronPython\lib\site-packages\_pytest\core.py", line 7, in > File "C:\IronPython\lib\site-packages\py\__init__.py", line 19, in > File "C:\IronPython\lib\site-packages\py\_apipkg.py", line 33, in initpkg > SystemError: Unsupported param dictionary type: > IronPython.Runtime.PythonDictionary Can you send the code in _apipkg.py on line 33 (and maybe some surrounding code)? Anyway, it sounds like a binder bug but that code might help create a simple repro. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dkottowk at yahoo.com Fri May 13 14:41:25 2011 From: dkottowk at yahoo.com (daniel kottow) Date: Fri, 13 May 2011 05:41:25 -0700 (PDT) Subject: [IronPython] clr.ImportExtensions are not available outside module ? In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E1517A240@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <434216.75989.qm@web161714.mail.bf1.yahoo.com> <6C7ABA8B4E309440B857D74348836F2E15179D1B@TK5EX14MBXC133.redmond.corp.microsoft.com> <739766.85517.qm@web161705.mail.bf1.yahoo.com> <6C7ABA8B4E309440B857D74348836F2E1517A240@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: <208919.65265.qm@web161719.mail.bf1.yahoo.com> Hello Dino, I don't think I want to delve into more complexity, thank you :-) What I was trying to say that, unfortunately, I do not see a way to encapsulate my extension methods written in C# so that a person doing only python does not have to worry about it - on the other hand, i reckon it is also not such a big deal to write some clr.ImportExtensions on the beginning of a module and then the developer *can* forget on how the methods got there. Btw, in order to use the methods interactively, I now start my session with "-i ironstuff" and everything is fine, i get my classes with their extension methods on the cmd line... very nice. Thank you for time. Daniel. ----- Original Message ---- From: Dino Viehland To: Discussion of IronPython Sent: Thu, May 12, 2011 3:50:01 PM Subject: Re: [IronPython] clr.ImportExtensions are not available outside module ? Daniel wrote: > Ok. > I am not sure what you mean by similar to import clr, though. It's similar to import clr in that importing clr not only gives you the clr module but also makes .NET members available to the module which imported clr. For example before doing "import clr" calling .ToString() on an object will raise an AttributeError but afterwards it will call the .NET ToString method. If you'd like to provide a set of globally available extension methods specifically for IronPython users you could use ExtensionTypeAttribute (which is defined in the DLR outer layer). IronPython will look for that attribute declared on an assembly. The attribute will give a type to extend and a type to pull the extension methods from. All you need to do is load the assembly into the script runtime either via the hosting APIs or clr.AddReference. This was the mechanism we originally used to add the Python methods to the .NET types like string (we now hard code the types for Python rather reflecting over the types at startup, but the mechanism remains for backwards compat). > > Because in my example, clr is available from outside test; its just named > test.clr... > Let me give you another example which is closer on how I ran into this... > > Lets say you have in C#: > > --- iron.Example.cs > > namespace iron > { > public class Example > { > public Example() > { > } > > public int foo() > { > return 1; > } > } > > public static class ExampleExtension > { > public static int bar(this Example example) > { > return example.foo() + 1; > } > > } > } > > --- EOF > > Then I define an example.py to wrap this up: > > --- test.py > > import clr > clr.AddReference("iron") > import iron > clr.ImportExtensions(iron.ExampleExtension) > > # lets use this just to test it out > > e = iron.Example() > print e.foo() > print e.bar() > > --- EOF > > now on my command line I get > > >>> import example > 1 > 2 > >>> ex = example.iron.Example() > >>> ex.foo() > 1 > >>> ex.bar() > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'Example' object has no attribute 'bar' > > And so I don't find a nice way to wrap my C# functionality in just one python > module, > > where I whish I could offer the extension methods just like any other > method... > or is my import strategy somehow flawed ? > > Greetings, > Daniel > > > > > > namespace native > { > public class Example > { > } > > public static class ExampleExtension > { > public static void > } > > add some extension methods to it, and then want to import everything in > one > python stub module. E.g. > > > > > > ----- Original Message ---- > From: Dino Viehland > To: Discussion of IronPython > Sent: Thu, May 12, 2011 1:01:33 PM > Subject: Re: [IronPython] clr.ImportExtensions are not available outside > module > ? > > > > Daniel wrote: > > Just as Dave Wald, I have also trying out the ImportExtensions methods > > which I personally find very useful, thank you for implementing. Everything > is > > working fine on using 2.7 (and .net 4), but extension methods loaded by > one > > module seem not available on another... > > This is by design. It works similar to how "import clr" only effects the > current module > and how extension methods work in C# where they are scoped by file. So if > you > want extension methods available in a file you'll need to import them in that > file. > > If they were globally scoped it would be easy for one module to break > another by > bringing in the 'wrong' extension methods. > > > > > > > I will stick to Dave's code exmaple: > > > > import clr > > clr.AddReference("System.Core") > > import System > > from System import Linq > > > > clr.ImportExtensions(Linq) > > > > class Product(object): > > def __init__(self, cat, id, qtyOnHand ): > > self.Cat = cat > > self.ID = id > > self.QtyOnHand = qtyOnHand > > self.Q = self.QtyOnHand > > > > If I put this into a file, lets say test.py and now use the module on the > > command line: > > > > >>> import test > > >>> products = [test.Product('food', i, 10) for i in range(3)] > > >>> > > >>> > > >>> products.Where > > Traceback (most recent call last): > > File "", line 1, in > > AttributeError: 'list' object has no attribute 'Where' > > > > The linq extensions are not available. I have to re-import them: > > > > >>> test.clr.ImportExtensions(test.Linq) > > >>> products.Where > > > > >>> > > > > Is this a current limitation, or should I be doing things differently ? > > Any help appreciated. > > > > Greetings, > > Daniel > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jdhardy at gmail.com Fri May 13 18:27:49 2011 From: jdhardy at gmail.com (Jeff Hardy) Date: Fri, 13 May 2011 09:27:49 -0700 Subject: [IronPython] clr.ImportExtensions are not available outside module ? In-Reply-To: <208919.65265.qm@web161719.mail.bf1.yahoo.com> References: <434216.75989.qm@web161714.mail.bf1.yahoo.com> <6C7ABA8B4E309440B857D74348836F2E15179D1B@TK5EX14MBXC133.redmond.corp.microsoft.com> <739766.85517.qm@web161705.mail.bf1.yahoo.com> <6C7ABA8B4E309440B857D74348836F2E1517A240@TK5EX14MBXC133.redmond.corp.microsoft.com> <208919.65265.qm@web161719.mail.bf1.yahoo.com> Message-ID: On Fri, May 13, 2011 at 5:41 AM, daniel kottow wrote: > What I was trying to say that, unfortunately, I do not see a way to encapsulate > my extension methods written in C# so that a person doing only python does not > have to worry about it - > on the other hand, i reckon it is also not such a big deal to write some > clr.ImportExtensions on the beginning of a module and then the developer *can* > forget on how the methods got there. Don't forget that Python is a dynamic language - you can add methods to the class after it's defined. You might have to inherit from the .NET class in Python, but then you can loop over the extension methods and add them to the Python class. It might be nice to have a clr.ImbueTypeWithExtensions(cls, extcls) method that did this, and made the extensions available everywhere, but it would have to be used with care. - Jeff From chadbr at slb.com Sun May 15 19:03:17 2011 From: chadbr at slb.com (Chad Brockman) Date: Sun, 15 May 2011 17:03:17 +0000 Subject: [IronPython] matplotlib anyone? Message-ID: <6451C9079312284DA83CCE202D0E903B3544988A@NL0230MBX09N1.DIR.slb.com> Is anyone aware of any efforts to allow usage of matplotlib from IronPython? http://matplotlib.sourceforge.net/ Thanks, -- Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.curtin at gmail.com Sun May 15 22:20:59 2011 From: brian.curtin at gmail.com (Brian Curtin) Date: Sun, 15 May 2011 15:20:59 -0500 Subject: [IronPython] matplotlib anyone? In-Reply-To: <6451C9079312284DA83CCE202D0E903B3544988A@NL0230MBX09N1.DIR.slb.com> References: <6451C9079312284DA83CCE202D0E903B3544988A@NL0230MBX09N1.DIR.slb.com> Message-ID: On Sun, May 15, 2011 at 12:03, Chad Brockman wrote: > Is anyone aware of any efforts to allow usage of matplotlib from > IronPython? > > > > http://matplotlib.sourceforge.net/ > I've never heard of any. I don't think any of the backends (tk, wx, Qt) work with IronPython, and they have a bunch of C extensions that would have to be handled as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From theller at ctypes.org Sun May 15 23:09:38 2011 From: theller at ctypes.org (Thomas Heller) Date: Sun, 15 May 2011 23:09:38 +0200 Subject: [IronPython] matplotlib anyone? Message-ID: Brian Curtin schrieb: >On Sun, May 15, 2011 at 12:03, Chad Brockman wrote: > >> Is anyone aware of any efforts to allow usage of matplotlib from >> IronPython? >> >> >> >> http://matplotlib.sourceforge.net/ >> > >I've never heard of any. I don't think any of the backends (tk, wx, Qt) work >with IronPython, and they have a bunch of C extensions that would have to be >handled as well. > >_______________________________________________ >Users mailing list >Users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From avinhan at gmail.com Mon May 16 07:27:37 2011 From: avinhan at gmail.com (Aravin) Date: Mon, 16 May 2011 10:57:37 +0530 Subject: [IronPython] matplotlib anyone? In-Reply-To: References: Message-ID: I was also looking into this for an application im developing. You can try it with IronClad. I wish there was a fully managed version for IronPython. Sho seems to have a graphing library similar to matplotlob. You can check that our and see On Mon, May 16, 2011 at 2:39 AM, Thomas Heller wrote: > > > Brian Curtin schrieb: > > >On Sun, May 15, 2011 at 12:03, Chad Brockman wrote: > > > >> Is anyone aware of any efforts to allow usage of matplotlib from > >> IronPython? > >> > >> > >> > >> http://matplotlib.sourceforge.net/ > >> > > > >I've never heard of any. I don't think any of the backends (tk, wx, Qt) > work > >with IronPython, and they have a bunch of C extensions that would have to > be > >handled as well. > > > >_______________________________________________ > >Users mailing list > >Users at lists.ironpython.com > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chadbr at slb.com Mon May 16 22:20:19 2011 From: chadbr at slb.com (Chad Brockman) Date: Mon, 16 May 2011 20:20:19 +0000 Subject: [IronPython] matplotlib anyone? Message-ID: <6451C9079312284DA83CCE202D0E903B35449B52@NL0230MBX09N1.DIR.slb.com> Yes, unfortunately IronClad appears to be all but dead. I've looked at Sho - but the charts are just the 2d MSCharts for .Net (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=130f7986-bf49-4fe5-9ca8-910ae6ea442c) I was hoping support for this might be part of the NumPy / SciPy port being done by Enthought - http://pytools.codeplex.com/wikipage?title=NumPy%20and%20SciPy%20for%20.Net Thanks -- Chad --------------- I was also looking into this for an application im developing. You can try it with IronClad. I wish there was a fully managed version for IronPython. Sho seems to have a graphing library similar to matplotlob. You can check that our and see On Mon, May 16, 2011 at 2:39 AM, Thomas Heller > wrote: > > > Brian Curtin > schrieb: > > >On Sun, May 15, 2011 at 12:03, Chad Brockman > wrote: > > > >> Is anyone aware of any efforts to allow usage of matplotlib from > >> IronPython? > >> > >> > >> > >> http://matplotlib.sourceforge.net/ > >> > > > >I've never heard of any. I don't think any of the backends (tk, wx, Qt) > work > >with IronPython, and they have a bunch of C extensions that would have to > be > >handled as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.blank at gmail.com Mon May 16 22:53:31 2011 From: doug.blank at gmail.com (Doug Blank) Date: Mon, 16 May 2011 16:53:31 -0400 Subject: [IronPython] matplotlib anyone? In-Reply-To: <6451C9079312284DA83CCE202D0E903B35449B52@NL0230MBX09N1.DIR.slb.com> References: <6451C9079312284DA83CCE202D0E903B35449B52@NL0230MBX09N1.DIR.slb.com> Message-ID: On Mon, May 16, 2011 at 4:20 PM, Chad Brockman wrote: > Yes, unfortunately IronClad appears to be all but dead. > > I?ve looked at Sho ? but the charts are just the 2d MSCharts for .Net > (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=130f7986-bf49-4fe5-9ca8-910ae6ea442c) > > I was hoping support for this might be part of the NumPy / SciPy port being > done by Enthought - > http://pytools.codeplex.com/wikipage?title=NumPy%20and%20SciPy%20for%20.Net > > Thanks -- Chad We will be working on either building or bundling a cross-platform, managed .DLL for use in .NET/Mono scripting languages over the next couple of years. Combined with .NET languages, we hope that it could be a replacement for scipy/matplotlib. We are just now in the planning stages; colleagues welcomed! -Doug > > > --------------- > > > > I was also looking into this for an application im developing. You can try > > it with IronClad. I wish there was a fully managed version for IronPython. > > Sho seems to have a graphing library similar to matplotlob. You can check > > that our and see > > > > On Mon, May 16, 2011 at 2:39 AM, Thomas Heller > wrote: > > > >> > >> > >> Brian Curtin schrieb: > >> > >> >On Sun, May 15, 2011 at 12:03, Chad Brockman wrote: > >> > > >> >>? Is anyone aware of any efforts to allow usage of matplotlib from > >> >> IronPython? > >> >> > >> >> > >> >> > >> >> http://matplotlib.sourceforge.net/ > >> >> > >> > > >> >I've never heard of any. I don't think any of the backends (tk, wx, Qt) > >> work > >> >with IronPython, and they have a bunch of C extensions that would have to > >> be > >> >handled as well. > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From zgramana at pottsconsultinggroup.com Tue May 17 23:33:59 2011 From: zgramana at pottsconsultinggroup.com (Zachary Gramana) Date: Tue, 17 May 2011 17:33:59 -0400 Subject: [IronPython] socket, _socket, and socket.py Message-ID: <4DD2E9C7.6020101@pottsconsultinggroup.com> Hi: I've been working on adapting Mercurial to run on IronPython 2.7, and ran into http://ironpython.codeplex.com/workitem/26852 which has stopped me from getting `hg clone` working over SSL. I noticed that for the ssl module, the IPY team mirrored the CPython pattern of placing the platform-specific code in the _ssl compiled module, and then wrapped the platform-independent around it in ssl.py (almost entirely shared with CPython 2.7). The socket module, however, does not. I admit I have a limited understanding of the code, but at first blush, it appears that adopting the _socket.cs/socket.py isn't out-of-the-question. Is there a story behind this, or am I missing something obvious to everyone else? The immediate benefit would be getting a free implementation of _socketobject, _dummy, and dup(); it also improves DRY conformance, and would help to limit behavioral differences with respect to other implementations. Thanks! Regards, Zack P.S. Any advice on tackling issue #26852 is very warmly appreciated. From curt at hagenlocher.org Tue May 17 23:58:32 2011 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 17 May 2011 14:58:32 -0700 Subject: [IronPython] socket, _socket, and socket.py In-Reply-To: <4DD2E9C7.6020101@pottsconsultinggroup.com> References: <4DD2E9C7.6020101@pottsconsultinggroup.com> Message-ID: Originally, we weren't allowed to redistribute the Python standard library with IronPython. So it made sense to implement the socket module directly. When IronPython started shipping the standard lib, it could have been changed, but never was. I think it makes sense to follow the CPython pattern. On Tue, May 17, 2011 at 2:33 PM, Zachary Gramana < zgramana at pottsconsultinggroup.com> wrote: > Hi: > > I've been working on adapting Mercurial to run on IronPython 2.7, and ran > into http://ironpython.codeplex.com/workitem/26852 which has stopped me > from getting `hg clone` working over SSL. > > I noticed that for the ssl module, the IPY team mirrored the CPython > pattern of placing the platform-specific code in the _ssl compiled module, > and then wrapped the platform-independent around it in ssl.py (almost > entirely shared with CPython 2.7). > > The socket module, however, does not. I admit I have a limited > understanding of the code, but at first blush, it appears that adopting the > _socket.cs/socket.py isn't out-of-the-question. Is there a story behind > this, or am I missing something obvious to everyone else? > > The immediate benefit would be getting a free implementation of > _socketobject, _dummy, and dup(); it also improves DRY conformance, and > would help to limit behavioral differences with respect to other > implementations. > > Thanks! > > Regards, > Zack > > P.S. Any advice on tackling issue #26852 is very warmly appreciated. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed May 18 00:06:47 2011 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 17 May 2011 22:06:47 +0000 Subject: [IronPython] socket, _socket, and socket.py In-Reply-To: References: <4DD2E9C7.6020101@pottsconsultinggroup.com> Message-ID: <6C7ABA8B4E309440B857D74348836F2E151DBA17@TK5EX14MBXC133.redmond.corp.microsoft.com> There is actually more of a story to this though - Cpython's socket.py relies upon reference counting for handling dup. See this comment from socket.py: # Wrapper around platform socket objects. This implements # a platform-independent dup() functionality. The # implementation currently relies on reference counting # to close the underlying socket object. class _socketobject(object): Because IronPython doesn't have a reference counting GC we cannot simply use socket.py. So someone would need to patch both IronPython and socket.py so this would work. For the record it looks like Jython also has a custom socket.py. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Tuesday, May 17, 2011 2:59 PM To: Discussion of IronPython Subject: Re: [IronPython] socket, _socket, and socket.py Originally, we weren't allowed to redistribute the Python standard library with IronPython. So it made sense to implement the socket module directly. When IronPython started shipping the standard lib, it could have been changed, but never was. I think it makes sense to follow the CPython pattern. On Tue, May 17, 2011 at 2:33 PM, Zachary Gramana > wrote: Hi: I've been working on adapting Mercurial to run on IronPython 2.7, and ran into http://ironpython.codeplex.com/workitem/26852 which has stopped me from getting `hg clone` working over SSL. I noticed that for the ssl module, the IPY team mirrored the CPython pattern of placing the platform-specific code in the _ssl compiled module, and then wrapped the platform-independent around it in ssl.py (almost entirely shared with CPython 2.7). The socket module, however, does not. I admit I have a limited understanding of the code, but at first blush, it appears that adopting the _socket.cs/socket.py isn't out-of-the-question. Is there a story behind this, or am I missing something obvious to everyone else? The immediate benefit would be getting a free implementation of _socketobject, _dummy, and dup(); it also improves DRY conformance, and would help to limit behavioral differences with respect to other implementations. Thanks! Regards, Zack P.S. Any advice on tackling issue #26852 is very warmly appreciated. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From zgramana at pottsconsultinggroup.com Wed May 18 00:19:53 2011 From: zgramana at pottsconsultinggroup.com (Zachary Gramana) Date: Tue, 17 May 2011 18:19:53 -0400 Subject: [IronPython] socket, _socket, and socket.py In-Reply-To: References: <4DD2E9C7.6020101@pottsconsultinggroup.com> Message-ID: <4DD2F489.7080302@pottsconsultinggroup.com> Thanks Curt. That's encouraging news to hear. I've noticed that some Python projects have a dependency on being able to standard library methods and types. For example, Mercurial replaces buffer() with their own fakebuffer(), but ipy socket reads still return the original buffer. I ended up patching around their monkey patch, which, understandably, they weren't too keen on importing back into their repo. An eventual move to _socket + socket.py wrapper could help improve compatibility with those projects. These type of hidden dependencies on vm-specific behaviors seem to the biggest source of issues I've come across so far (in 2.7, anyway). I'm continually amazed at how big of a step forward the team made from 2.6 -> 2.7 with respect to compatibility. On 5/17/2011 5:58 PM, Curt Hagenlocher wrote: > Originally, we weren't allowed to redistribute the Python standard > library with IronPython. So it made sense to implement the socket module > directly. When IronPython started shipping the standard lib, it could > have been changed, but never was. I think it makes sense to follow the > CPython pattern. > > On Tue, May 17, 2011 at 2:33 PM, Zachary Gramana > > wrote: > > Hi: > > I've been working on adapting Mercurial to run on IronPython 2.7, > and ran into http://ironpython.codeplex.com/workitem/26852 which has > stopped me from getting `hg clone` working over SSL. > > I noticed that for the ssl module, the IPY team mirrored the CPython > pattern of placing the platform-specific code in the _ssl compiled > module, and then wrapped the platform-independent around it in > ssl.py (almost entirely shared with CPython 2.7). > > The socket module, however, does not. I admit I have a limited > understanding of the code, but at first blush, it appears that > adopting the _socket.cs/socket.py isn't out-of-the-question. Is > there a story behind this, or am I missing something obvious to > everyone else? > > The immediate benefit would be getting a free implementation of > _socketobject, _dummy, and dup(); it also improves DRY conformance, > and would help to limit behavioral differences with respect to other > implementations. > > Thanks! > > Regards, > Zack > > P.S. Any advice on tackling issue #26852 is very warmly appreciated. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From zgramana at pottsconsultinggroup.com Wed May 18 00:38:18 2011 From: zgramana at pottsconsultinggroup.com (Zachary Gramana) Date: Tue, 17 May 2011 18:38:18 -0400 Subject: [IronPython] socket, _socket, and socket.py In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E151DBA17@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <4DD2E9C7.6020101@pottsconsultinggroup.com> <6C7ABA8B4E309440B857D74348836F2E151DBA17@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: <4DD2F8DA.6030108@pottsconsultinggroup.com> I noticed this, with a little disappointment. I also noticed that they implemented a sort of ersatz/platform agnostic reference tracking system in ssl.py. Seeing the _makefile_refs system got me thinking about the whole ssl.py/_ssl.pyd paradigm and sockets.cs, since I remembered you tackled this issue once before (or one very similar to it: http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004946.html). Perhaps something along the lines of _makefile_refs and GC.SuppressFinalize might get us closer? On 5/17/2011 6:06 PM, Dino Viehland wrote: > There is actually more of a story to this though ? Cpython?s socket.py > relies upon reference counting for handling dup. See this comment from > socket.py: > > # Wrapper around platform socket objects. This implements > > # a platform-independent dup() functionality. The > > # implementation currently relies on reference counting > > # to close the underlying socket object. > > class _socketobject(object): > > Because IronPython doesn?t have a reference counting GC we cannot simply > use socket.py. So someone would need to patch both IronPython and > socket.py so this would work. For the record it looks like Jython also > has a custom socket.py. > From raghavendra.chandrashekara at gmail.com Wed May 18 00:45:04 2011 From: raghavendra.chandrashekara at gmail.com (Raghavendra Chandrashekara) Date: Tue, 17 May 2011 18:45:04 -0400 Subject: [IronPython] Intellisense with imported dlls In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E15178B6C@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <6C7ABA8B4E309440B857D74348836F2E15178A21@TK5EX14MBXC133.redmond.corp.microsoft.com> <087BFF09-4C74-47CD-8737-92C041D87568@gmail.com> <6C7ABA8B4E309440B857D74348836F2E15178B6C@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: Thanks Dino for the hint. I've implemented the first method for IronPythonTools and submitted a pull request. Raj On Wed, May 11, 2011 at 9:21 PM, Dino Viehland wrote: > Cool, this shouldn?t be too hard to fix. We load the assemblies in > ProjectState.cs and it should just be a matter of flowing the VS project > settings down to the analysis ProjectState class and then attempting to load > the assemblies from there. > > > > If you?d like to fix it in PTVS, which I?d encourage you to do, it?s been > moved to IronPythonInterpreter.cs. In PTVS it might be more difficult to > flow in the VS project but you could update the IPythonInterpreter interface > or IInterpreterState so that we either push down or allow pulling out the > search paths. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Raghavendra > Chandrashekara > *Sent:* Wednesday, May 11, 2011 6:07 PM > *To:* Discussion of IronPython > *Cc:* Discussion of IronPython > *Subject:* Re: [IronPython] Intellisense with imported dlls > > > > Ah, I see. The referenced assemblies are in a sub-directory of my project. > Would it be too difficult to add the list of assemblies in the Search Path > directories of the project? I can try to change the IronPythonTools code to > do this if you could give a hint as to where I should start. > > > > Thanks, > > > > Raj > > > On 2011-05-11, at 20:51, Dino Viehland wrote: > > Where are the assemblies? Currently we'll only find assemblies in the > gac. > > Sent from my Windows Phone > ------------------------------ > > *From: *Raghavendra Chandrashekara > *Sent: *Wednesday, May 11, 2011 4:49 PM > *To: *Discussion of IronPython > *Subject: *[IronPython] Intellisense with imported dlls > > Hi All, > > I added a couple of custom .NET dlls using the clr.AddReference() method in > my program and I was expecting IronPython Tools for Visual Studio to be able > to parse the imported dlls and provide intellisense for the imported > classes. However I don't see any imported methods when I press either Ctrl + > Space or the '.' key after a class object. Is there something extra I need > to do? > > Thanks, > > Raj > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed May 18 00:48:13 2011 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 17 May 2011 22:48:13 +0000 Subject: [IronPython] socket, _socket, and socket.py In-Reply-To: <4DD2F8DA.6030108@pottsconsultinggroup.com> References: <4DD2E9C7.6020101@pottsconsultinggroup.com> <6C7ABA8B4E309440B857D74348836F2E151DBA17@TK5EX14MBXC133.redmond.corp.microsoft.com> <4DD2F8DA.6030108@pottsconsultinggroup.com> Message-ID: <6C7ABA8B4E309440B857D74348836F2E151DDB9E@TK5EX14MBXC133.redmond.corp.microsoft.com> I think manual ref count tracking (like _make_filerefs) + defining __del__ on the socket objects would fix it. But there may be issues w/ that - when we first encountered this I pinged python-dev and I recall Guido saying that there were problems getting anything else working on Windows. So there may be some oddity that prevents this from working but I don't know what that is off the top of my head. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Zachary Gramana > Sent: Tuesday, May 17, 2011 3:38 PM > To: Discussion of IronPython > Subject: Re: [IronPython] socket, _socket, and socket.py > > I noticed this, with a little disappointment. I also noticed that they > implemented a sort of ersatz/platform agnostic reference tracking system in > ssl.py. Seeing the _makefile_refs system got me thinking about the whole > ssl.py/_ssl.pyd paradigm and sockets.cs, since I remembered you tackled this > issue once before (or one very similar to it: > http://lists.ironpython.com/pipermail/users-ironpython.com/2007- > May/004946.html). > > Perhaps something along the lines of _makefile_refs and > GC.SuppressFinalize might get us closer? > > On 5/17/2011 6:06 PM, Dino Viehland wrote: > > There is actually more of a story to this though - Cpython's socket.py > > relies upon reference counting for handling dup. See this comment > > from > > socket.py: > > > > # Wrapper around platform socket objects. This implements > > > > # a platform-independent dup() functionality. The > > > > # implementation currently relies on reference counting > > > > # to close the underlying socket object. > > > > class _socketobject(object): > > > > Because IronPython doesn't have a reference counting GC we cannot > > simply use socket.py. So someone would need to patch both IronPython > > and socket.py so this would work. For the record it looks like Jython > > also has a custom socket.py. > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From curt at hagenlocher.org Wed May 18 01:58:09 2011 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 17 May 2011 16:58:09 -0700 Subject: [IronPython] socket, _socket, and socket.py In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E151DBA17@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <4DD2E9C7.6020101@pottsconsultinggroup.com> <6C7ABA8B4E309440B857D74348836F2E151DBA17@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: Ah, right, I'd forgotten that -- we would have had to have distributed a modified socket.py, and that was infeasible even after we were delivering the standard library. This feels like a place where IronPython could collaborate on a joint change with Jython and have the result distributed inside the standard library using a test for sys.platform. On Tue, May 17, 2011 at 3:06 PM, Dino Viehland wrote: > There is actually more of a story to this though ? Cpython?s socket.py > relies upon reference counting for handling dup. See this comment from > socket.py: > > > > # Wrapper around platform socket objects. This implements > > # a platform-independent dup() functionality. The > > # implementation currently relies on reference counting > > # to close the underlying socket object. > > class _socketobject(object): > > > > Because IronPython doesn?t have a reference counting GC we cannot simply > use socket.py. So someone would need to patch both IronPython and socket.py > so this would work. For the record it looks like Jython also has a custom > socket.py. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Curt Hagenlocher > *Sent:* Tuesday, May 17, 2011 2:59 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] socket, _socket, and socket.py > > > > Originally, we weren't allowed to redistribute the Python standard library > with IronPython. So it made sense to implement the socket module directly. > When IronPython started shipping the standard lib, it could have been > changed, but never was. I think it makes sense to follow the CPython > pattern. > > On Tue, May 17, 2011 at 2:33 PM, Zachary Gramana < > zgramana at pottsconsultinggroup.com> wrote: > > Hi: > > I've been working on adapting Mercurial to run on IronPython 2.7, and ran > into http://ironpython.codeplex.com/workitem/26852 which has stopped me > from getting `hg clone` working over SSL. > > I noticed that for the ssl module, the IPY team mirrored the CPython > pattern of placing the platform-specific code in the _ssl compiled module, > and then wrapped the platform-independent around it in ssl.py (almost > entirely shared with CPython 2.7). > > The socket module, however, does not. I admit I have a limited > understanding of the code, but at first blush, it appears that adopting the > _socket.cs/socket.py isn't out-of-the-question. Is there a story behind > this, or am I missing something obvious to everyone else? > > The immediate benefit would be getting a free implementation of > _socketobject, _dummy, and dup(); it also improves DRY conformance, and > would help to limit behavioral differences with respect to other > implementations. > > Thanks! > > Regards, > Zack > > P.S. Any advice on tackling issue #26852 is very warmly appreciated. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zgramana at pottsconsultinggroup.com Wed May 18 16:34:08 2011 From: zgramana at pottsconsultinggroup.com (Zachary Gramana) Date: Wed, 18 May 2011 10:34:08 -0400 Subject: [IronPython] socket, _socket, and socket.py In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E151DDB9E@TK5EX14MBXC133.redmond.corp.microsoft.com> References: <4DD2E9C7.6020101@pottsconsultinggroup.com> <6C7ABA8B4E309440B857D74348836F2E151DBA17@TK5EX14MBXC133.redmond.corp.microsoft.com> <4DD2F8DA.6030108@pottsconsultinggroup.com> <6C7ABA8B4E309440B857D74348836F2E151DDB9E@TK5EX14MBXC133.redmond.corp.microsoft.com> Message-ID: <4DD3D8E0.4080700@pottsconsultinggroup.com> That's good enough for me. I'm going to give it a go. On 5/17/2011 6:48 PM, Dino Viehland wrote: > I think manual ref count tracking (like _make_filerefs) + defining __del__ on the socket objects would fix it. But there may be issues w/ that - when we first encountered this I pinged python-dev and I recall Guido saying that there were problems getting anything else working on Windows. So there may be some oddity that prevents this from working but I don't know what that is off the top of my head. > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Zachary Gramana >> Sent: Tuesday, May 17, 2011 3:38 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] socket, _socket, and socket.py >> >> I noticed this, with a little disappointment. I also noticed that they >> implemented a sort of ersatz/platform agnostic reference tracking system in >> ssl.py. Seeing the _makefile_refs system got me thinking about the whole >> ssl.py/_ssl.pyd paradigm and sockets.cs, since I remembered you tackled this >> issue once before (or one very similar to it: >> http://lists.ironpython.com/pipermail/users-ironpython.com/2007- >> May/004946.html). >> >> Perhaps something along the lines of _makefile_refs and >> GC.SuppressFinalize might get us closer? >> >> On 5/17/2011 6:06 PM, Dino Viehland wrote: >>> There is actually more of a story to this though - Cpython's socket.py >>> relies upon reference counting for handling dup. See this comment >>> from >>> socket.py: >>> >>> # Wrapper around platform socket objects. This implements >>> >>> # a platform-independent dup() functionality. The >>> >>> # implementation currently relies on reference counting >>> >>> # to close the underlying socket object. >>> >>> class _socketobject(object): >>> >>> Because IronPython doesn't have a reference counting GC we cannot >>> simply use socket.py. So someone would need to patch both IronPython >>> and socket.py so this would work. For the record it looks like Jython >>> also has a custom socket.py. >>> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From wangzht at cpit.com.cn Mon May 23 05:33:10 2011 From: wangzht at cpit.com.cn (wangzhongtian) Date: Mon, 23 May 2011 11:33:10 +0800 Subject: [IronPython] =?gb2312?b?tPC4tDogVXNlcnMgRGlnZXN0LCBWb2wgODIsIElz?= =?gb2312?b?c3VlIDE3?= In-Reply-To: References: Message-ID: <002601cc18fa$23a6db10$6af49130$@com.cn> I want to access MSProject file(Project 2003) using IronPython 2.7 ,but it can't work ,There may be a bug .The Same code works well in Ipy 1.1. below is the code and error printed in ipy 2.7: ? import clr ? name1="Microsoft.Office.Interop.MSProject" ? clr.AddReferenceByPartialName(name1) ? import Microsoft.Office.Interop.MSProject as msproject ? w = msproject.ApplicationClass() ? w.Visible Traceback (most recent call last): File "", line 1, in NotImplementedError: The method or operation is not implemented. ? w.ActiveProject Traceback (most recent call last): File "", line 1, in NotImplementedError: The method or operation is not implemented. From intertricity at gmail.com Mon May 23 09:52:40 2011 From: intertricity at gmail.com (Intertricity) Date: Mon, 23 May 2011 00:52:40 -0700 (PDT) Subject: [IronPython] Issue reading an InternalDictionary, Overloads fails with 2147483647 arguments bug. Message-ID: I'm trying to read the keys of an InternalDictionary of a .Net dll I'm loading into IronPython. The library is libomv. I've googled for several hours now, and I can't seem to find a clear way to get around this. Here's the doc string on the ForEach I'm trying to use, I've referenced temp to the object in question to keep things short while I'm at the interpreter. >>> print temp.ForEach.__doc__ ForEach(self: InternalDictionary[UInt32, Avatar], action: Action[KeyValuePair[UI nt32, Avatar]]) Perform an on each key of an action: to perform ForEach(self: InternalDictionary[UInt32, Avatar], action: Action[UInt32]) Perform an on each key of an action: to perform ForEach(self: InternalDictionary[UInt32, Avatar], action: Action[Avatar]) Perform an on each key of an action: to perform And here's what happens when I try to use the Overloads method to solve overloading: >>> temp.ForEach.Overloads[Avatar](lambda x: x.FirstName) Traceback (most recent call last): File "", line 1, in TypeError: ForEach() takes at least 2147483647 arguments (1 given) >>> Anyone have a clue how to get this to work? I'm not too familiar with .Net, and got into it through IronPython, so I'm not sure what I could be doing wrong. From dinov at microsoft.com Mon May 23 18:56:21 2011 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 23 May 2011 16:56:21 +0000 Subject: [IronPython] Issue reading an InternalDictionary, Overloads fails with 2147483647 arguments bug. In-Reply-To: References: Message-ID: <6C7ABA8B4E309440B857D74348836F2E15BF42FE@TK5EX14MBXC292.redmond.corp.microsoft.com> I think your .Overloads needs to be: .Overloads[Action[Avatar]] Or maybe: .Overloads[InternalDictionary[UInt32, Avatar], Avatar] > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Intertricity > Sent: Monday, May 23, 2011 12:53 AM > To: users at lists.ironpython.com > Subject: [IronPython] Issue reading an InternalDictionary, Overloads fails > with 2147483647 arguments bug. > > I'm trying to read the keys of an InternalDictionary of a .Net dll I'm loading > into IronPython. The library is libomv. > > I've googled for several hours now, and I can't seem to find a clear way to get > around this. > Here's the doc string on the ForEach I'm trying to use, I've referenced temp > to the object in question to keep things short while I'm at the interpreter. > > >>> print temp.ForEach.__doc__ > ForEach(self: InternalDictionary[UInt32, Avatar], action: > Action[KeyValuePair[UI > nt32, Avatar]]) > Perform an on each key of an > > action: to perform > ForEach(self: InternalDictionary[UInt32, Avatar], action: > Action[UInt32]) > Perform an on each key of an > > action: to perform > ForEach(self: InternalDictionary[UInt32, Avatar], action: > Action[Avatar]) > Perform an on each key of an > > action: to perform > > > > And here's what happens when I try to use the Overloads method to solve > overloading: > > >>> temp.ForEach.Overloads[Avatar](lambda x: x.FirstName) > Traceback (most recent call last): > File "", line 1, in > TypeError: ForEach() takes at least 2147483647 arguments (1 given) > >>> > > Anyone have a clue how to get this to work? I'm not too familiar with .Net, > and got into it through IronPython, so I'm not sure what I could be doing > wrong. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From intertricity at gmail.com Tue May 24 02:55:29 2011 From: intertricity at gmail.com (Intertricity) Date: Mon, 23 May 2011 17:55:29 -0700 (PDT) Subject: [IronPython] Issue reading an InternalDictionary, Overloads fails with 2147483647 arguments bug. In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E15BF42FE@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <6C7ABA8B4E309440B857D74348836F2E15BF42FE@TK5EX14MBXC292.redmond.corp.microsoft.com> Message-ID: <0231ab5f-327e-48be-8f96-dc0fc87e104c@x1g2000yqb.googlegroups.com> Still get the same problem :\ although the Action[Avatar] one returns a NoneType instead of complaining about an insane number of arguments. ############# >>> temp.ForEach.Overloads[InternalDictionary[UInt32,Avatar],Avatar](lambda x: x .FirstName) Traceback (most recent call last): File "", line 1, in TypeError: ForEach() takes at least 2147483647 arguments (1 given) >>> ############# ############# >>> temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName) >>> dir(temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName)) ['Equals', 'GetHashCode', 'GetType', 'MemberwiseClone', 'ReferenceEquals', 'ToSt ring', '__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '_ _setattr__', '__sizeof__', '__str__', '__subclasshook__'] >>> type(temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName)) >>> ############# On May 23, 12:56?pm, Dino Viehland wrote: > I think your .Overloads needs to be: > > .Overloads[Action[Avatar]] > > Or maybe: > > .Overloads[InternalDictionary[UInt32, Avatar], Avatar] > > > > > > > > > > > -----Original Message----- > > From: users-boun... at lists.ironpython.com [mailto:users- > > boun... at lists.ironpython.com] On Behalf Of Intertricity > > Sent: Monday, May 23, 2011 12:53 AM > > To: us... at lists.ironpython.com > > Subject: [IronPython] Issue reading an InternalDictionary, Overloads fails > > with 2147483647 arguments bug. > > > I'm trying to read the keys of an InternalDictionary of a .Net dll I'm loading > > into IronPython. The library is libomv. > > > I've googled for several hours now, and I can't seem to find a clear way to get > > around this. > > Here's the doc string on the ForEach I'm trying to use, I've referenced temp > > to the object in question to keep things short while I'm at the interpreter. > > > >>> print temp.ForEach.__doc__ > > ForEach(self: InternalDictionary[UInt32, Avatar], action: > > Action[KeyValuePair[UI > > nt32, Avatar]]) > > ? ? Perform an ?on each key of an > > > ? ? action: to perform > > ForEach(self: InternalDictionary[UInt32, Avatar], action: > > Action[UInt32]) > > ? ? Perform an ?on each key of an > > > ? ? action: to perform > > ForEach(self: InternalDictionary[UInt32, Avatar], action: > > Action[Avatar]) > > ? ? Perform an ?on each key of an > > > ? ? action: to perform > > > And here's what happens when I try to use the Overloads method to solve > > overloading: > > > >>> temp.ForEach.Overloads[Avatar](lambda x: x.FirstName) > > Traceback (most recent call last): > > ? File "", line 1, in > > TypeError: ForEach() takes at least 2147483647 arguments (1 given) > > > Anyone have a clue how to get this to work? I'm not too familiar with .Net, > > and got into it through IronPython, so I'm not sure what I could be doing > > wrong. > > _______________________________________________ > > Users mailing list > > Us... at lists.ironpython.com > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Tue May 24 03:50:33 2011 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 24 May 2011 01:50:33 +0000 Subject: [IronPython] Issue reading an InternalDictionary, Overloads fails with 2147483647 arguments bug. In-Reply-To: <0231ab5f-327e-48be-8f96-dc0fc87e104c@x1g2000yqb.googlegroups.com> References: <6C7ABA8B4E309440B857D74348836F2E15BF42FE@TK5EX14MBXC292.redmond.corp.microsoft.com> <0231ab5f-327e-48be-8f96-dc0fc87e104c@x1g2000yqb.googlegroups.com> Message-ID: <6C7ABA8B4E309440B857D74348836F2E15BF561B@TK5EX14MBXC292.redmond.corp.microsoft.com> Sounds like Action[Avatar] is working then - it's just that the lambda isn't doing anything that you can see. If you change it to: l = [] temp.ForEach.Overloads[Action[Avatar]](lambda x: l.append(x.FirstName)) Then l should be populated with all the first names you're called with. > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Intertricity > Sent: Monday, May 23, 2011 5:55 PM > To: users at lists.ironpython.com > Subject: Re: [IronPython] Issue reading an InternalDictionary, Overloads fails > with 2147483647 arguments bug. > > Still get the same problem :\ although the Action[Avatar] one returns a > NoneType instead of complaining about an insane number of arguments. > > ############# > >>> temp.ForEach.Overloads[InternalDictionary[UInt32,Avatar],Avatar](lam > >>> bda x: x > .FirstName) > Traceback (most recent call last): > File "", line 1, in > TypeError: ForEach() takes at least 2147483647 arguments (1 given) > >>> > > ############# > ############# > >>> temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName) > >>> dir(temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName)) > ['Equals', 'GetHashCode', 'GetType', 'MemberwiseClone', 'ReferenceEquals', > 'ToSt ring', '__class__', '__delattr__', '__doc__', '__format__', > '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', > '__reduce_ex__', '__repr__', '_ _setattr__', '__sizeof__', '__str__', > '__subclasshook__'] > >>> type(temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName)) > > >>> > ############# > > > On May 23, 12:56?pm, Dino Viehland wrote: > > I think your .Overloads needs to be: > > > > .Overloads[Action[Avatar]] > > > > Or maybe: > > > > .Overloads[InternalDictionary[UInt32, Avatar], Avatar] > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: users-boun... at lists.ironpython.com [mailto:users- > > > boun... at lists.ironpython.com] On Behalf Of Intertricity > > > Sent: Monday, May 23, 2011 12:53 AM > > > To: us... at lists.ironpython.com > > > Subject: [IronPython] Issue reading an InternalDictionary, Overloads > > > fails with 2147483647 arguments bug. > > > > > I'm trying to read the keys of an InternalDictionary of a .Net dll > > > I'm loading into IronPython. The library is libomv. > > > > > I've googled for several hours now, and I can't seem to find a clear > > > way to get around this. > > > Here's the doc string on the ForEach I'm trying to use, I've > > > referenced temp to the object in question to keep things short while I'm > at the interpreter. > > > > > >>> print temp.ForEach.__doc__ > > > ForEach(self: InternalDictionary[UInt32, Avatar], action: > > > Action[KeyValuePair[UI > > > nt32, Avatar]]) > > > ? ? Perform an ?on each key of an > > > > > ? ? action: to perform > > > ForEach(self: InternalDictionary[UInt32, Avatar], action: > > > Action[UInt32]) > > > ? ? Perform an ?on each key of an > > > > > ? ? action: to perform > > > ForEach(self: InternalDictionary[UInt32, Avatar], action: > > > Action[Avatar]) > > > ? ? Perform an ?on each key of an > > > > > ? ? action: to perform > > > > > And here's what happens when I try to use the Overloads method to > > > solve > > > overloading: > > > > > >>> temp.ForEach.Overloads[Avatar](lambda x: x.FirstName) > > > Traceback (most recent call last): > > > ? File "", line 1, in > > > TypeError: ForEach() takes at least 2147483647 arguments (1 given) > > > > > Anyone have a clue how to get this to work? I'm not too familiar > > >with .Net, and got into it through IronPython, so I'm not sure what > > >I could be doing wrong. > > > _______________________________________________ > > > Users mailing list > > > Us... at lists.ironpython.com > > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > > Users mailing list > > Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/use > > rs-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From intertricity at gmail.com Tue May 24 05:11:29 2011 From: intertricity at gmail.com (Intertricity) Date: Mon, 23 May 2011 20:11:29 -0700 (PDT) Subject: [IronPython] Issue reading an InternalDictionary, Overloads fails with 2147483647 arguments bug. In-Reply-To: <6C7ABA8B4E309440B857D74348836F2E15BF561B@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <6C7ABA8B4E309440B857D74348836F2E15BF42FE@TK5EX14MBXC292.redmond.corp.microsoft.com> <0231ab5f-327e-48be-8f96-dc0fc87e104c@x1g2000yqb.googlegroups.com> <6C7ABA8B4E309440B857D74348836F2E15BF561B@TK5EX14MBXC292.redmond.corp.microsoft.com> Message-ID: <498fdb62-22d9-4cc6-a4f2-6bb623490943@v8g2000yqb.googlegroups.com> That did the trick! Thanks so much! On May 23, 9:50?pm, Dino Viehland wrote: > Sounds like Action[Avatar] is working then - it's just that the lambda isn't doing > anything that you can see. ?If you change it to: > > l = [] > temp.ForEach.Overloads[Action[Avatar]](lambda x: l.append(x.FirstName)) > > Then l should be populated with all the first names you're called with. ? > > > > > > > > > > > -----Original Message----- > > From: users-boun... at lists.ironpython.com [mailto:users- > > boun... at lists.ironpython.com] On Behalf Of Intertricity > > Sent: Monday, May 23, 2011 5:55 PM > > To: us... at lists.ironpython.com > > Subject: Re: [IronPython] Issue reading an InternalDictionary, Overloads fails > > with 2147483647 arguments bug. > > > Still get the same problem :\ although the Action[Avatar] one returns a > > NoneType instead of complaining about an insane number of arguments. > > > ############# > > >>> temp.ForEach.Overloads[InternalDictionary[UInt32,Avatar],Avatar](lam > > >>> bda x: x > > .FirstName) > > Traceback (most recent call last): > > ? File "", line 1, in > > TypeError: ForEach() takes at least 2147483647 arguments (1 given) > > > ############# > > ############# > > >>> temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName) > > >>> dir(temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName)) > > ['Equals', 'GetHashCode', 'GetType', 'MemberwiseClone', 'ReferenceEquals', > > 'ToSt ring', '__class__', '__delattr__', '__doc__', '__format__', > > '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', > > '__reduce_ex__', '__repr__', '_ _setattr__', '__sizeof__', '__str__', > > '__subclasshook__'] > > >>> type(temp.ForEach.Overloads[Action[Avatar]](lambda x: x.FirstName)) > > > > > ############# > > > On May 23, 12:56?pm, Dino Viehland wrote: > > > I think your .Overloads needs to be: > > > > .Overloads[Action[Avatar]] > > > > Or maybe: > > > > .Overloads[InternalDictionary[UInt32, Avatar], Avatar] > > > > > -----Original Message----- > > > > From: users-boun... at lists.ironpython.com [mailto:users- > > > > boun... at lists.ironpython.com] On Behalf Of Intertricity > > > > Sent: Monday, May 23, 2011 12:53 AM > > > > To: us... at lists.ironpython.com > > > > Subject: [IronPython] Issue reading an InternalDictionary, Overloads > > > > fails with 2147483647 arguments bug. > > > > > I'm trying to read the keys of an InternalDictionary of a .Net dll > > > > I'm loading into IronPython. The library is libomv. > > > > > I've googled for several hours now, and I can't seem to find a clear > > > > way to get around this. > > > > Here's the doc string on the ForEach I'm trying to use, I've > > > > referenced temp to the object in question to keep things short while I'm > > at the interpreter. > > > > > >>> print temp.ForEach.__doc__ > > > > ForEach(self: InternalDictionary[UInt32, Avatar], action: > > > > Action[KeyValuePair[UI > > > > nt32, Avatar]]) > > > > ? ? Perform an ?on each key of an > > > > > ? ? action: to perform > > > > ForEach(self: InternalDictionary[UInt32, Avatar], action: > > > > Action[UInt32]) > > > > ? ? Perform an ?on each key of an > > > > > ? ? action: to perform > > > > ForEach(self: InternalDictionary[UInt32, Avatar], action: > > > > Action[Avatar]) > > > > ? ? Perform an ?on each key of an > > > > > ? ? action: to perform > > > > > And here's what happens when I try to use the Overloads method to > > > > solve > > > > overloading: > > > > > >>> temp.ForEach.Overloads[Avatar](lambda x: x.FirstName) > > > > Traceback (most recent call last): > > > > ? File "", line 1, in > > > > TypeError: ForEach() takes at least 2147483647 arguments (1 given) > > > > > Anyone have a clue how to get this to work? I'm not too familiar > > > >with .Net, ?and got into it through IronPython, so I'm not sure what > > > >I could be doing ?wrong. > > > > _______________________________________________ > > > > Users mailing list > > > > Us... at lists.ironpython.com > > > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > > > Users mailing list > > > Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/use > > > rs-ironpython.com > > _______________________________________________ > > Users mailing list > > Us... at lists.ironpython.com > >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jdhardy at gmail.com Tue May 31 23:27:29 2011 From: jdhardy at gmail.com (Jeff Hardy) Date: Tue, 31 May 2011 14:27:29 -0700 Subject: [IronPython] Moving forward on 2.7.1 Message-ID: Hi all, I think it's about time to get 2.7.1 shipped. I don't have a timeline in mind, but I'd like it out by the end of June. There's a few new modules and some bug fixes as well, but I'd like to see some more bugs fixed. If there's anything in 2.7.0 that's blocking you and not already fixed, post it here and I'll adjust the priorities. I'm also going to update the stdlib to match CPython 2.7.1. After 2.7.1 I doubt I will be putting much effort into the 2.7 branch (3.0 is just more interesting), so if there's continued interest in future 2.7 releases, someone else will probably have to step up. - Jeff