Re: [IronPython] py to ip
Shri Borde ha scritto: See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for the details. Thank you Shri, i've done some try and this still work well: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433 Type help, copyright, credits or license for more information. import System System.Type.GetTypeFromProgID(DS.Channel) System.RuntimeType object at 0x002B [System.__ComObject] qq = System.Type.GetTypeFromProgID(DSA.Channel) System.Activator.CreateInstance( qq ) System.__ComObject (_Channel) object at 0x002C But now i've some question: - the GetTypeFromProgID method let me use an installed COM objec over the PC still running this ipy script. This don't use Interop i think If this is corerct i cannot in any way use remotley this object? Try to explain my issue: I'm writing a web application over a linux Server (A). Some financial data come from Thomson Datastream using this COM obj installed on a Windows Server (B). My purpose is to call this COM remotely from linux server. probably i'm doing somethin wrong but from ipy description i've understood this i possible. Thank's Glauco ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] py to ip
António Piteira ha scritto: I'm sorry, forget what I said... I have done AddReferenceToFile, my mistake. But still, what is the output? None, nothing happens. Seems that tlbimp hasnot worked well. how can i test my converted dll ? thank you Glauco ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Getting hold of a ClassDefinition within IronPython.Compiler.Ast.Statement.Transform()
Hi everyone, I am playing around and experimenting with new language features within IronPython (mainly out of academic interest), and I have been extending the IronPython compiler/interpreter for this purpose. However, please keep in mind that I am very new to this, and still don't quite know my way around the source. What I am wondering is, if there is a way to get hold of existing class definitions (IronPython.Compiler.Ast.ClassDefintion) (or something similar) from within the Transform method of a statement. Thanks in advance, Eyvind W. Axelsen. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
I should point out ahead of time that there's no mmap module in IronPython at the moment, and so memory-mapped ndarrays don't work yet -- although most of the usual numpy save/load bits do work, so you'll probably be fine (unless they're too big to fit in memory). Dan Shechter wrote: Here! I can't wait to use it with NumPy. I actually have a .NET C# assembly that does some really nasty low-level stuff like loading data from memory mapped files and wrapping them with IListT :) I can't wait to make Ironclad/Numpy blow up :) On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.com wrote: Hi all, Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on IronPython 2.0, and includes (alpha-level) support for numpy using our Ironclad project. We're releasing the beta tomorrow: this has a few performance problems (which are being addressed - many thanks to Dino Viehland for helping with this!) but is otherwise functionally complete. If you're interested in trying it out, drop me a line! Best regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.com +44 (0) 20 7253 6372 Win up to $17,000 for a spreadsheet: http://www.resolversystems.com/competition/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Shechter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Getting hold of a ClassDefinition within IronPython.Compiler.Ast.Statement.Transform()
What do you mean by 'existing'? Do you want the class definitions which the current statement is nested in? Do you want to get to an arbitrary class definition somewhere in the AST? Currently we don't maintain any of this but there's no reason you couldn't modify PythonAst.TransformToAst so that the AstGenerator held onto _body (along w/ the other places where we construct AstGenerators). From there you could make AstGenerator(AstGenerator parent, ...) hold onto the parent AstGenerator so you can walk up from an inner ast gen and get to the outer most one. If you want a parent class def you'll hit it as you're walking up the AstGenerator chtain. Or with the bodies in place you could find any ClassDefinition you want by walking down from the top ast gen. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Eyvind Axelsen Sent: Wednesday, February 04, 2009 1:59 AM To: Discussion of IronPython Subject: [IronPython] Getting hold of a ClassDefinition within IronPython.Compiler.Ast.Statement.Transform() Hi everyone, I am playing around and experimenting with new language features within IronPython (mainly out of academic interest), and I have been extending the IronPython compiler/interpreter for this purpose. However, please keep in mind that I am very new to this, and still don't quite know my way around the source. What I am wondering is, if there is a way to get hold of existing class definitions (IronPython.Compiler.Ast.ClassDefintion) (or something similar) from within the Transform method of a statement. Thanks in advance, Eyvind W. Axelsen. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] py to ip
I don't know much about remote COM (is that the same as DCOM?). IronPython supports invocation on OLEAUT objects. It has only minimal support for creating such objects (via. clr.AddReferenceToTypeLib), and otherwise relies on the user to create the object using the CLR (Type.GetTypeFromProgID) or other means. You can check if any of the Activator.CreateInstance overloads (http://msdn.microsoft.com/en-us/library/system.activator.createinstance.aspx) support remote COM. Furthermore, I doubt if Mono supports even local COM interop. If you can't do it from C# on Mono, you won't be able to do it from IronPython on Mono either. I think you will need to find COM adapters that allow you to access COM from Linux and use those... -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Glauco Uri Sent: Wednesday, February 04, 2009 12:49 AM To: Discussion of IronPython Subject: Re: [IronPython] py to ip Shri Borde ha scritto: See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for the details. Thank you Shri, i've done some try and this still work well: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433 Type help, copyright, credits or license for more information. import System System.Type.GetTypeFromProgID(DS.Channel) System.RuntimeType object at 0x002B [System.__ComObject] qq = System.Type.GetTypeFromProgID(DSA.Channel) System.Activator.CreateInstance( qq ) System.__ComObject (_Channel) object at 0x002C But now i've some question: - the GetTypeFromProgID method let me use an installed COM objec over the PC still running this ipy script. This don't use Interop i think If this is corerct i cannot in any way use remotley this object? Try to explain my issue: I'm writing a web application over a linux Server (A). Some financial data come from Thomson Datastream using this COM obj installed on a Windows Server (B). My purpose is to call this COM remotely from linux server. probably i'm doing somethin wrong but from ipy description i've understood this i possible. Thank's Glauco ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] py to ip
Glauco: 1) I don't recall using tlbimp to try to create an EXPorted COM Interop assembly. I may have my notes incorrect so double check against the tutorial. I used tlbexp to EXPort the COM Interop assembly into a .NET 2.0 output file. Here's my command line (note: you can get help from tlbexp for additional parameter inputs): D:\IronPython 2.0\SIEK\9.2_OTAClientd:\Program Files\Microsoft.NET\SDK\v2.0\Bin\TlbExp.exe d:\IronPython 2.0\SIEK\9.2_OTAClient\OTAClient.dll 2) I edited my \lib\site.py file and added the complete path to my converted output file, OTAClient.dll, at the path shown on the above command line. 3) I then was able to use clr to iPy import my correctly exported COM Interop Assembly file: import clr clr.AddReferenceToFile(OTAClientInterop.dll) from OTAClientInterop import * Shri Borde wrote: I don't know much about remote COM (is that the same as DCOM?). IronPython supports invocation on OLEAUT objects. It has only minimal support for creating such objects (via. clr.AddReferenceToTypeLib), and otherwise relies on the user to create the object using the CLR (Type.GetTypeFromProgID) or other means. You can check if any of the Activator.CreateInstance overloads (http://msdn.microsoft.com/en-us/library/system.activator.createinstance.aspx) support remote COM. Furthermore, I doubt if Mono supports even local COM interop. If you can't do it from C# on Mono, you won't be able to do it from IronPython on Mono either. I think you will need to find COM adapters that allow you to access COM from Linux and use those... -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Glauco Uri Sent: Wednesday, February 04, 2009 12:49 AM To: Discussion of IronPython Subject: Re: [IronPython] py to ip Shri Borde ha scritto: See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for the details. Thank you Shri, i've done some try and this still work well: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433 Type help, copyright, credits or license for more information. import System System.Type.GetTypeFromProgID(DS.Channel) System.RuntimeType object at 0x002B [System.__ComObject] qq = System.Type.GetTypeFromProgID(DSA.Channel) System.Activator.CreateInstance( qq ) System.__ComObject (_Channel) object at 0x002C But now i've some question: - the GetTypeFromProgID method let me use an installed COM objec over the PC still running this ipy script. This don't use Interop i think If this is corerct i cannot in any way use remotley this object? Try to explain my issue: I'm writing a web application over a linux Server (A). Some financial data come from Thomson Datastream using this COM obj installed on a Windows Server (B). My purpose is to call this COM remotely from linux server. probably i'm doing somethin wrong but from ipy description i've understood this i possible. Thank's Glauco ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
I know :) I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke. I did notice though that .NET 4.0 WIll have native support for mmap() through System.IO.MemoryMappedFiles... So perhaps IP 2.X will add that as well... On Wed, Feb 4, 2009 at 12:15 PM, William Reade will...@resolversystems.comwrote: I should point out ahead of time that there's no mmap module in IronPython at the moment, and so memory-mapped ndarrays don't work yet -- although most of the usual numpy save/load bits do work, so you'll probably be fine (unless they're too big to fit in memory). Dan Shechter wrote: Here! I can't wait to use it with NumPy. I actually have a .NET C# assembly that does some really nasty low-level stuff like loading data from memory mapped files and wrapping them with IListT :) I can't wait to make Ironclad/Numpy blow up :) On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.com wrote: Hi all, Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on IronPython 2.0, and includes (alpha-level) support for numpy using our Ironclad project. We're releasing the beta tomorrow: this has a few performance problems (which are being addressed - many thanks to Dino Viehland for helping with this!) but is otherwise functionally complete. If you're interested in trying it out, drop me a line! Best regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.com +44 (0) 20 7253 6372 Win up to $17,000 for a spreadsheet: http://www.resolversystems.com/competition/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Shechter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Shechter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
Current thinking is that IronPython 3k will be the 1st version that will take a dependency on .NET 4.0 so we’ll have to wait until then. Having to rely on P/Invoke is one of the main reasons we don’t have this yet (IronPython doesn’t have any p/invokes today and we’d like to avoid them if at possible). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dan Shechter Sent: Wednesday, February 04, 2009 1:04 PM To: Discussion of IronPython Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0 I know :) I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke. I did notice though that .NET 4.0 WIll have native support for mmap() through System.IO.MemoryMappedFiles... So perhaps IP 2.X will add that as well... On Wed, Feb 4, 2009 at 12:15 PM, William Reade will...@resolversystems.commailto:will...@resolversystems.com wrote: I should point out ahead of time that there's no mmap module in IronPython at the moment, and so memory-mapped ndarrays don't work yet -- although most of the usual numpy save/load bits do work, so you'll probably be fine (unless they're too big to fit in memory). Dan Shechter wrote: Here! I can't wait to use it with NumPy. I actually have a .NET C# assembly that does some really nasty low-level stuff like loading data from memory mapped files and wrapping them with IListT :) I can't wait to make Ironclad/Numpy blow up :) On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas giles.tho...@resolversystems.commailto:giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.commailto:giles.tho...@resolversystems.com wrote: Hi all, Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on IronPython 2.0, and includes (alpha-level) support for numpy using our Ironclad project. We're releasing the beta tomorrow: this has a few performance problems (which are being addressed - many thanks to Dino Viehland for helping with this!) but is otherwise functionally complete. If you're interested in trying it out, drop me a line! Best regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. giles.tho...@resolversystems.commailto:giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.commailto:giles.tho...@resolversystems.com +44 (0) 20 7253 6372 Win up to $17,000 for a spreadsheet: http://www.resolversystems.com/competition/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com mailto:Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Shechter. ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Shechter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
I think that is a great plan. Having no P/Invokes makes it much more platform agnostic. On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland di...@microsoft.com wrote: Current thinking is that IronPython 3k will be the 1st version that will take a dependency on .NET 4.0 so we'll have to wait until then. Having to rely on P/Invoke is one of the main reasons we don't have this yet (IronPython doesn't have any p/invokes today and we'd like to avoid them if at possible). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dan Shechter Sent: Wednesday, February 04, 2009 1:04 PM To: Discussion of IronPython Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0 I know :) I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke. I did notice though that .NET 4.0 WIll have native support for mmap() through System.IO.MemoryMappedFiles... So perhaps IP 2.X will add that as well... On Wed, Feb 4, 2009 at 12:15 PM, William Reade will...@resolversystems.com wrote: I should point out ahead of time that there's no mmap module in IronPython at the moment, and so memory-mapped ndarrays don't work yet -- although most of the usual numpy save/load bits do work, so you'll probably be fine (unless they're too big to fit in memory). Dan Shechter wrote: Here! I can't wait to use it with NumPy. I actually have a .NET C# assembly that does some really nasty low-level stuff like loading data from memory mapped files and wrapping them with IListT :) I can't wait to make Ironclad/Numpy blow up :) On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.com wrote: Hi all, Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on IronPython 2.0, and includes (alpha-level) support for numpy using our Ironclad project. We're releasing the beta tomorrow: this has a few performance problems (which are being addressed - many thanks to Dino Viehland for helping with this!) but is otherwise functionally complete. If you're interested in trying it out, drop me a line! Best regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.com +44 (0) 20 7253 6372 Win up to $17,000 for a spreadsheet: http://www.resolversystems.com/competition/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Shechter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Shechter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- slide-o-blog http://slide-o-blog.blogspot.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
I beg to differ... Ultimately all undelying clr's (ms/mono) rely heavily on p/invoking so it really boils down to who maintains the low-level bindings... Ultimately, without pinvokes you wouldn't be able to accomplish anything... If I was able to get mmap working on Linux/windows/macosx x86/x64 in one day then I'm sure it can't be that much of a problem... Beside managed runtimes like python/.net/java were never about being platform agnostic, just about being less platform specific... I believe the official term is: write once, debug everywhere... Shechter. On 04/02/2009, at 23:43, Slide slide.o@gmail.com wrote: I think that is a great plan. Having no P/Invokes makes it much more platform agnostic. On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland di...@microsoft.com wrote: Current thinking is that IronPython 3k will be the 1st version that will take a dependency on .NET 4.0 so we'll have to wait until then. Having to rely on P/Invoke is one of the main reasons we don't have this yet (IronPython doesn't have any p/invokes today and we'd like to avoid them if at possible). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dan Shechter Sent: Wednesday, February 04, 2009 1:04 PM To: Discussion of IronPython Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0 I know :) I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke. I did notice though that .NET 4.0 WIll have native support for mmap() through System.IO.MemoryMappedFiles... So perhaps IP 2.X will add that as well... On Wed, Feb 4, 2009 at 12:15 PM, William Reade will...@resolversystems.com wrote: I should point out ahead of time that there's no mmap module in IronPython at the moment, and so memory-mapped ndarrays don't work yet -- although most of the usual numpy save/load bits do work, so you'll probably be fine (unless they're too big to fit in memory). Dan Shechter wrote: Here! I can't wait to use it with NumPy. I actually have a .NET C# assembly that does some really nasty low- level stuff like loading data from memory mapped files and wrapping them with IListT :) I can't wait to make Ironclad/Numpy blow up :) On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.com wrote: Hi all, Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on IronPython 2.0, and includes (alpha-level) support for numpy using our Ironclad project. We're releasing the beta tomorrow: this has a few performance problems (which are being addressed - many thanks to Dino Viehland for helping with this!) but is otherwise functionally complete. If you're interested in trying it out, drop me a line! Best regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.com +44 (0) 20 7253 6372 Win up to $17,000 for a spreadsheet: http://www.resolversystems.com/competition/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Shechter. --- - ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Shechter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- slide-o-blog http://slide-o-blog.blogspot.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
That's true, but if the low-level bindings are in the framework itself, rather than a consumer of the framework, it does make it easier to port to other platforms which have the same API that wrap the low-level bindings at the framework level. On Wed, Feb 4, 2009 at 3:00 PM, Dan Shechter d...@houmus.org wrote: I beg to differ... Ultimately all undelying clr's (ms/mono) rely heavily on p/invoking so it really boils down to who maintains the low-level bindings... Ultimately, without pinvokes you wouldn't be able to accomplish anything... If I was able to get mmap working on Linux/windows/macosx x86/x64 in one day then I'm sure it can't be that much of a problem... Beside managed runtimes like python/.net/java were never about being platform agnostic, just about being less platform specific... I believe the official term is: write once, debug everywhere... Shechter. On 04/02/2009, at 23:43, Slide slide.o@gmail.com wrote: I think that is a great plan. Having no P/Invokes makes it much more platform agnostic. On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland di...@microsoft.com wrote: Current thinking is that IronPython 3k will be the 1st version that will take a dependency on .NET 4.0 so we'll have to wait until then. Having to rely on P/Invoke is one of the main reasons we don't have this yet (IronPython doesn't have any p/invokes today and we'd like to avoid them if at possible). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dan Shechter Sent: Wednesday, February 04, 2009 1:04 PM To: Discussion of IronPython Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0 I know :) I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke. I did notice though that .NET 4.0 WIll have native support for mmap() through System.IO.MemoryMappedFiles... So perhaps IP 2.X will add that as well... On Wed, Feb 4, 2009 at 12:15 PM, William Reade will...@resolversystems.com wrote: I should point out ahead of time that there's no mmap module in IronPython at the moment, and so memory-mapped ndarrays don't work yet -- although most of the usual numpy save/load bits do work, so you'll probably be fine (unless they're too big to fit in memory). Dan Shechter wrote: Here! I can't wait to use it with NumPy. I actually have a .NET C# assembly that does some really nasty low-level stuff like loading data from memory mapped files and wrapping them with IListT :) I can't wait to make Ironclad/Numpy blow up :) On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.com wrote: Hi all, Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on IronPython 2.0, and includes (alpha-level) support for numpy using our Ironclad project. We're releasing the beta tomorrow: this has a few performance problems (which are being addressed - many thanks to Dino Viehland for helping with this!) but is otherwise functionally complete. If you're interested in trying it out, drop me a line! Best regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.com +44 (0) 20 7253 6372 Win up to $17,000 for a spreadsheet: http://www.resolversystems.com/competition/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Shechter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Shechter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- slide-o-blog http://slide-o-blog.blogspot.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- slide-o-blog http://slide-o-blog.blogspot.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
Where make it easier is really make it an acceptable cost. While a feature may have taken just a day for you to implement Dan it also has on-going costs. Every feature inevitably has bugs and those bugs need to be fixed. If we need to implement both the feature from the Python side plus the underlying functionality it's only going to have a higher on-going cost. Even if the code is 100% bug free there's still on-going costs as the rest of the code base changes around it. And even if we were to resolve those and say we won't fix them there's still at least the cost of triaging those bugs. Also adding specific support for Linux or Mac OS/X APIs would imply that we should be testing those code paths on those platforms. Which means that our check-in infrastructure that validates and rejects check-ins will also need to be updated to run tests on Linux or Mac OS/X. Not to mention the potential distraction of Why didn't you support FreeBSD?, Where's my OS/2 support?, What about ReactOS? or someone else's favorite platform. Another additional consideration is that IronPython today is 100% safe security transparent code. That means when we need to ask the question Can IronPython be used to elevate permissions? the answer is simple - it's no. Once we introduce a P/Invoke, or any other unsafe code, we will then need to deal with Did that API that requires trust get implemented correct?. It's much easier to rely upon .NET getting the security right so we can focus on the problems that our users directly care about. So I'd say that one day quickly gets blown up into a lot of time most of which can be saved if we have the feature implemented for us in the platform we run on which happens to be .NET. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Slide Sent: Wednesday, February 04, 2009 2:13 PM To: Discussion of IronPython Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0 That's true, but if the low-level bindings are in the framework itself, rather than a consumer of the framework, it does make it easier to port to other platforms which have the same API that wrap the low-level bindings at the framework level. On Wed, Feb 4, 2009 at 3:00 PM, Dan Shechter d...@houmus.org wrote: I beg to differ... Ultimately all undelying clr's (ms/mono) rely heavily on p/invoking so it really boils down to who maintains the low-level bindings... Ultimately, without pinvokes you wouldn't be able to accomplish anything... If I was able to get mmap working on Linux/windows/macosx x86/x64 in one day then I'm sure it can't be that much of a problem... Beside managed runtimes like python/.net/java were never about being platform agnostic, just about being less platform specific... I believe the official term is: write once, debug everywhere... Shechter. On 04/02/2009, at 23:43, Slide slide.o@gmail.com wrote: I think that is a great plan. Having no P/Invokes makes it much more platform agnostic. On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland di...@microsoft.com wrote: Current thinking is that IronPython 3k will be the 1st version that will take a dependency on .NET 4.0 so we'll have to wait until then. Having to rely on P/Invoke is one of the main reasons we don't have this yet (IronPython doesn't have any p/invokes today and we'd like to avoid them if at possible). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dan Shechter Sent: Wednesday, February 04, 2009 1:04 PM To: Discussion of IronPython Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0 I know :) I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke. I did notice though that .NET 4.0 WIll have native support for mmap() through System.IO.MemoryMappedFiles... So perhaps IP 2.X will add that as well... On Wed, Feb 4, 2009 at 12:15 PM, William Reade will...@resolversystems.com wrote: I should point out ahead of time that there's no mmap module in IronPython at the moment, and so memory-mapped ndarrays don't work yet -- although most of the usual numpy save/load bits do work, so you'll probably be fine (unless they're too big to fit in memory). Dan Shechter wrote: Here! I can't wait to use it with NumPy. I actually have a .NET C# assembly that does some really nasty low-level stuff like loading data from memory mapped files and wrapping them with IListT :) I can't wait to make Ironclad/Numpy blow up :) On Tue, Feb 3, 2009 at 8:50 PM, Giles Thomas giles.tho...@resolversystems.com mailto:giles.tho...@resolversystems.com wrote: Hi all, Version 1.4 of Resolver One, our Pythonic spreadsheet, is based on IronPython 2.0, and includes (alpha-level) support for numpy using our Ironclad project. We're releasing the beta tomorrow: this has a few performance problems (which are
Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0
I'm sorry if I wasn't clear, but the IP team's stance on this is totally acceptable, I wasn't nudging anyone to do anything. Personally, I think that such improvements should go into IPCE or some other community type extensions project. As we stand today, IP doesn't really work flawlessly on Mac/Linux anyway. Patches need to be plugged for all kinds of quirks such as console support etc. Mind you, that we got into this state without any P/Invoking (referring back to Write once, debug everywhere) I don't expect anything coming off the IP team to work on anything other than MS.NET/SilverLight. It's up to the community to pick it up from there on. On Thu, Feb 5, 2009 at 1:06 AM, Dino Viehland di...@microsoft.com wrote: Where make it easier is really make it an acceptable cost. While a feature may have taken just a day for you to implement Dan it also has on-going costs. Every feature inevitably has bugs and those bugs need to be fixed. If we need to implement both the feature from the Python side plus the underlying functionality it's only going to have a higher on-going cost. Even if the code is 100% bug free there's still on-going costs as the rest of the code base changes around it. And even if we were to resolve those and say we won't fix them there's still at least the cost of triaging those bugs. Also adding specific support for Linux or Mac OS/X APIs would imply that we should be testing those code paths on those platforms. Which means that our check-in infrastructure that validates and rejects check-ins will also need to be updated to run tests on Linux or Mac OS/X. Not to mention the potential distraction of Why didn't you support FreeBSD?, Where's my OS/2 support?, What about ReactOS? or someone else's favorite platform. Another additional consideration is that IronPython today is 100% safe security transparent code. That means when we need to ask the question Can IronPython be used to elevate permissions? the answer is simple - it's no. Once we introduce a P/Invoke, or any other unsafe code, we will then need to deal with Did that API that requires trust get implemented correct?. It's much easier to rely upon .NET getting the security right so we can focus on the problems that our users directly care about. So I'd say that one day quickly gets blown up into a lot of time most of which can be saved if we have the feature implemented for us in the platform we run on which happens to be .NET. -Original Message- From: users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] On Behalf Of Slide Sent: Wednesday, February 04, 2009 2:13 PM To: Discussion of IronPython Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0 That's true, but if the low-level bindings are in the framework itself, rather than a consumer of the framework, it does make it easier to port to other platforms which have the same API that wrap the low-level bindings at the framework level. On Wed, Feb 4, 2009 at 3:00 PM, Dan Shechter d...@houmus.org wrote: I beg to differ... Ultimately all undelying clr's (ms/mono) rely heavily on p/invoking so it really boils down to who maintains the low-level bindings... Ultimately, without pinvokes you wouldn't be able to accomplish anything... If I was able to get mmap working on Linux/windows/macosx x86/x64 in one day then I'm sure it can't be that much of a problem... Beside managed runtimes like python/.net/java were never about being platform agnostic, just about being less platform specific... I believe the official term is: write once, debug everywhere... Shechter. On 04/02/2009, at 23:43, Slide slide.o@gmail.com wrote: I think that is a great plan. Having no P/Invokes makes it much more platform agnostic. On Wed, Feb 4, 2009 at 2:20 PM, Dino Viehland di...@microsoft.com wrote: Current thinking is that IronPython 3k will be the 1st version that will take a dependency on .NET 4.0 so we'll have to wait until then. Having to rely on P/Invoke is one of the main reasons we don't have this yet (IronPython doesn't have any p/invokes today and we'd like to avoid them if at possible). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dan Shechter Sent: Wednesday, February 04, 2009 1:04 PM To: Discussion of IronPython Subject: Re: [IronPython] Resolver One 1.4 beta - with IronPython 2.0 I know :) I have my own C# Assembly that does mmap() on Windows/Linux with PInvoke. I did notice though that .NET 4.0 WIll have native support for mmap() through System.IO.MemoryMappedFiles... So perhaps IP 2.X will add that as well... On Wed, Feb 4, 2009 at 12:15 PM, William Reade will...@resolversystems.com wrote: I should point out ahead of time that there's no mmap module in IronPython at the moment, and so memory-mapped ndarrays
