Re: [IronPython] IronPython @ PyCon 2011
Jonathan Hartley and I will be flying the Resolver Systems flag... On 07/03/2011 16:42, Jeff Hardy wrote: I'll be there, and so will Dino (with something very cool to show off). Anybody else? - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas giles.tho...@resolversystems.com +44 (0) 20 3051 2751 Dirigible: a programmable cloud spreadsheet http://projectdirigible.com/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] numpy / IronClad?
On 01/03/2011 22:42, Jeff Hardy wrote: As for IronClad, I'm not sure - it doesn't look like it, and I'm not sure Resolver is still using IronPython. Just to clarify -- we're still using IronPython for Resolver One, our Windows desktop app. Our new (currently in beta) web-based programmable cloud spreadsheet, Dirigible, is based on CPython. We've not updated Ironclad for a while, but it's under an MIT license, so presumably it could be rolled into IronPython -- we'd certainly be happy to see that happen, though we're a bit resource-constrained at the moment and couldn't play a significant role in the work. Regards, Giles -- Giles Thomas giles.tho...@resolversystems.com +44 (0) 20 3051 2751 Dirigible: a programmable cloud spreadsheet http://projectdirigible.com/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcing IronPython 2.6.1 RC1
David, A big thank you to you and all of the IP team for this; the import speed enhancement is particularly welcome. We'll try it out in Resolver One and report back to the list. Regards, Giles On 10/02/2010 21:55, David DiCato wrote: Hello Python Community, We're pleased to announce the release of IronPython 2.6.1 RC1. This version of IronPython makes great strides in stability and compatibility, including a considerable number of targeted bugfixes. Because this is our largest servicing release to date, and due to our decision against incrementing the assembly version numbers, it is important that we get everything right. To this end, we present our first-ever RC for a minor dot release. Of course, your feedback is imperative to the quality of this release, so we'd love to hear from you! IronPython 2.6.1 comes in two flavors -- one that runs on top of .NET 4.0 RC, and one that runs on any other framework starting with .NET 2.0 SP1. They can be downloaded here: - IronPython 2.6.1 RC1 for .NET 2.0 SP1: http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=40144 - IronPython 2.6.1 RC1 for .NET 4.0 RC: http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=40146 Note: The .NET Framework 4.0 RC is required for the latter release and can be downloaded at http://www.microsoft.com/downloads/details.aspx?FamilyID=a9ef9a95-58d2-4e51-a4b7-bea3cc6962cbdisplaylang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=a9ef9a95-58d2-4e51-a4b7-bea3cc6962cbdisplaylang=en IronPython 2.6.1 RC1 includes fixes for well over 50 bugs, large and small. Ctypes has had a number of significant updates, including union support, variant_bool, and wintypes. Another focus has been on sys.settrace, making debugging more reliable. For example, sys.settrace now returns the correct frame, supports tracing through modules, and no longer interferes with import os. Other notable fixes include thread-safe importing, and the missing error code in _winreg exception. In addition, we've made a substantial improvement in import time. Not only does this reduce startup time, but can speed up the importing of large, definition-heavy modules by up to 50%. As you might imagine, the .NET 4.0 flavor of IronPython 2.6.1 RC1 has a few of its own changes designed for better interoperability with the framework. These include fixing some errors with Func and better runtime isolation when similarly-named assemblies in different locations are loaded in multiple engines. In addition, both the .NET 2.0 and .NET 4.0 builds support the new .NET 4.0 IStructuralEquatable and IStructuralComparable interfaces and maps them to the appropriate operations (__eq__, __hash__, __gt__, etc.). In the case of .NET 4.0, this replaces IValueEquality as the gold standard for defining equality in an interop-friendly manner. In the .NET 2.0 build, these interfaces are copied so that their use can be phased in while retaining IValueEquality for backwards compatibility. Special thanks to Albert Szilvasy, cendalc, clovery, egonw_, essey, fabiofz, igalse, jazzcat, jlunder, laughingboy, marten_range, László de Almásy, lbaker, Lukas Cenovsky, pl6306, roinet, sanxiyn, Thomas Heller, vernondcole, and Wolfram for reporting issues. Happy Scripting! - The IronPython Team ___ 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] [ANN]: IronPython 2.6 final
Congratulations! We have a release of Resolver One based on IronPython 2.6 that is almost ready to go, and hope to get that into beta shortly. Dino Viehland wrote: Hello Python Community, We're proud to announce the release of IronPython 2.6 final. This is a major release with improvements across all areas of IronPython and can be downloaded from http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12482. Significant changes include: · Updating the language and standard library to match CPython 2.6 · Improved .NET integration · Updating to the latest version of the DLR · Adding previously missing CPython features and fixing bugs · Performance improvements in particular startup time improvements Python 2.6 support includes a large number of new features which include support for the new bytes and byte array types (PEP 3112 http://www.python.org/dev/peps/pep-3112/), decorators for classes (PEP 3129 http://www.python.org/dev/peps/pep-3129/), advanced string formatting (PEP 3101 http://www.python.org/dev/peps/pep-3101/) which will feel familiar to .NET users and integrates nicely with IFormattable, print as a function (PEP 3105 http://www.python.org/dev/peps/pep-3105/), Abstract Base Classes (PEP 3119 http://www.python.org/dev/peps/pep-3119/), support for binary literals, along with lots of other minor features and changes. IronPython also continues to improve .NET integration in this release. We've added the __clrtype__ method http://ironpython.net/ironpython/documentation/dotnet/dotnet.html#clrtype to types which enables deep integration via meta-classes with the .NET type system. There are also a number of smaller changes such as supporting IDisposable in for loops http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24503 matching the behavior of other .NET languages. This release also includes the latest version of the DLR and fixes a number of issues related to cross-language dynamic interop. Not to be left out there's improvements in Silverlight integration by supporting Python code in HTML script tags http://ironpython.net/browser/sl-back-to-just-text.pdf. We've also continued to improve Python compatibility by adding missing features and fixing bugs. In this release we've added support for the ctypes http://docs.python.org/library/ctypes.html module which provides interop with native code in a compatible way across Python implementations. We've also implemented sys.settrace to provide support for the pdb http://docs.python.org/library/pdb.html module and other Python debuggers. This release also changes how we support sys._getframe: a fully working version is now available by a command line option; when not enabled sys._getframe doesn't exist at all. This release also fixes over 400 bugs removing a large number of smaller incompatibilities. As always we've also continued to improve performance, and this release primarily focuses on improving startup time. The IronPython installer now pre-compiles (ngens) IronPython during installation on both 32-bit and 64-bit platforms. Modules are now interpreted initially and hot functions are compiled for faster import times. A number of other code paths that used to involve runtime code generation have been optimized to be contained within the pre-compiled IronPython binaries. We've also made a number of smaller changes which improve performance in other areas such as adding constant folding. Finally we'd like to thank everyone who reported issues and helped make this a better release: Anders M. Mikkelsen, Dan Eloff, Zachc, yamakox, vernondcole, VAks, tscottw, tonyandrewmeyer, tomwright, TomasMatousek, tkamiya, timers, srivatsn, sopeajw, saveenr, sanxiyn, rridge, ronniemaor, quirogaco, pythonfoo, pysunil, pm100, pl6306, paulfelix, orestis, olegt, oldman, NDHUMuscle, mycall, mmaly, mmacdonaldssfcu, maplpro, luntain, llaske, lbaker, Lawouach, laurionb, laughingboy, kurhan, kuno, kowenswp, klrohe, kevgu, jmesserly, jlunder, jdhardy, jbevain, jackeyoo, hhonisch, gz, gjones, fwereade, deadalusai, daveremy, Seo Sanghyeon, CurtHagenlocher, chaghi, cgravill, cartman, bobarnso, atifaziz, ashcor, alvanet, Helmut, fuzzyman, fabiofz, Eloff, RuiDC, Kevin Chu, Kyle Howland-Rose egonw, davec, dungen, dsblank, cjacobs, dmajnemer, leppie, Mark Rees, soulfry, tatwright, ufechner and wilberforce. Thank you for your continued support of IronPython. The IronPython Team ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas giles.tho...@resolversystems.com +44 (0) 20 7253 6372 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
[IronPython] London Financial Python Users Group
Hi all, If you're based in or visiting London, and have an interest in using (Iron)Python for financial software, you might want to come to the next meeting of the London Financial Python Users Group! The time: Monday 14 December 2009 at 7pm The place: MWB Regent Street, Liberty House 222 Regent Street, London W1B 5TR We've got a couple of lightning talks lined up (I'll be talking about Resolver One, IronPython, and Ironclad) but if you're interested in giving one yourself then drop Didrik Pinte a line at dpi...@enthought.com mailto:dpi...@enthought.com. There's a (very minimal) Wiki page about the Users Group here: http://wiki.python.org/moin/LondonFinancialPythonUserGroup Cheers, Giles -- Giles Thomas giles.tho...@resolversystems.com +44 (0) 20 7253 6372 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] ANN: Resolver One version 1.7 released
Dino Viehland wrote: Congratulations on another release! Just out of curiosity did you move to 2.0.3 for this release or is it still 2.0.2 based? Thanks! We stuck with 2.0.2 for this release. Cheers, Giles -- Giles Thomas giles.tho...@resolversystems.com +44 (0) 20 7253 6372 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Default install location and site-packages
Dino Viehland wrote: But it seems like CPython is the one who's doing something wrong here. Another data point; easy_install under CPython using Vista with UAC switched on tries to escalate permissions as you would expect -- the normal grey screen, please enter an administrator's details thing -- and then happily installs the egg under C:\PythonXX\lib\site-packages, owned by Administrator, with no read permissions for anyone else. So you then have to go and find it and manually change the permissions if you want to use it. Somewhat orthogonal, but it does make it sound rather like the setup with CPython is accidental rather than by deliberate choice. Cheers, Giles -- Giles Thomas giles.tho...@resolversystems.com +44 (0) 20 7253 6372 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Default install location and site-packages
Michael Foord wrote: (I'm honestly not sure how creating a writable directory is a security issue?) I suspect people are thinking of an attack where an untrusted user installs a package that looks like a normal one, but actually does something nefarious like install a rootkit (and perhaps does what the package is meant to do as well). If the administrator then uses the package, the machine is compromised. Cheers, Giles -- Giles Thomas giles.tho...@resolversystems.com +44 (0) 20 7253 6372 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] ANN: Resolver One version 1.6.5 released
We are proud to announce the release of Resolver One, version 1.6.5. Resolver One is a Windows-based spreadsheet that integrates IronPython deeply into its recalculation loop, making the models you build more reliable and more maintainable. It's also still (we think) the largest IronPython application in the world, with 56,000 lines of code backed up by 176,000 lines of unit and functional tests. For versions 1.6 and 1.6.5, we've made it easier for people to share their spreadsheets. A new free player version means you can pass your work on to other people, and they can use it without having to buy anything, while a new Resolverlib makes calling your spreadsheets from IronPython programs as easy as calling a function. You can read more about Resolver One here: http://www.resolversystems.com/products/resolver-one/ We have a 31-day free trial version, so if you would like to take a look, you can download it from our website: http://www.resolversystems.com/download/ If you want to use Resolver One in an Open Source project, we offer free licenses for that: http://www.resolversystems.com/opensource/ Best regards, Giles -- Giles Thomas giles.tho...@resolversystems.com +44 (0) 20 7253 6372 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] ANN: Resolver One 1.5 released
We are proud to announce the release of Resolver One, version 1.5. Resolver One is a Windows-based spreadsheet that integrates IronPython deeply into its recalculation loop, making the models you build more reliable and more maintainable. For version 1.5, we've added a console; this new command-line window gives you a way to interact with your spreadsheet using Python statements. Here's a screencast showing why this is worth doing: http://www.resolversystems.com/screencasts/console/ We have a 31-day free trial version, so if you would like to take a look, you can download it from our website: http://www.resolversystems.com/download/ If you want to use Resolver One in an Open Source project, we offer free licenses for that: http://www.resolversystems.com/opensource/ Many thanks for the ongoing work of the IronPython team to build the platform that makes this all possible! Best regards, Giles -- Giles Thomas 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 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcing IronPython 2.6 Alpha 1
Dave, This is great news, congratulations to the IP team on this release! We'll do a test-port of Resolver One early next week and will reply to the list with any issues we find. Cheers, Giles Dave Fugate wrote: Hello Python Community, We’re pleased to announce the release of IronPython 2.6 Alpha 1. As you might imagine, this release is all about supporting new CPython 2.6 features such as the ‘bytes’ and ‘bytearray’ types (PEP 3112), decorators for classes (PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET version required for this release is the same as IronPython 2.0; namely .NET 2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release only a couple Alphas and Betas of IronPython 2.6. As such, it’s key that we get your feedback on the release(s) quickly to incorporate requested changes. Besides CPython 2.6 features, another significant change in this release is that ipy.exe now uses “adaptive compilation” by default. Adaptive compilation is a technique in which IronPython: 1. Interprets and executes Python method calls up to /N/ times for a given method. If you’re only going to execute a method a few times, it’s typically faster to interpret the method instead of compiling and executing it 2. Compiles and executes the Python method call on the /N+1/ invocation of the method. Compilation of a Python method is a heavyweight operation, but we can reuse the result for subsequent invocations 3. Reuses the previously compiled method for new calls to the Python method. This operation is much faster than interpreting the method call as the method was already compiled in the previous step The reason for this change is that it provides a nice performance gain for Python code containing lots of functions/methods that only get called a few times. All this said, this feature is still undergoing active development and as a consequence some Python scripts may actually run slower with it turned on. For this reason, our old default mode of running Python scripts is still available by passing the –O or -D flags to ipy.exe. Any feedback on how this new feature affects your IronPython applications performance-wise would be greatly appreciated. There’s also a few minor changes since IronPython 2.0.1 that are worth calling out here: · IronPython.msi now installs NGEN’ed binaries by default · IronPython.msi now offers a little more selection with respect to what you’d like to install. For example, Silverlight templates are optional · The default installation location of IronPython.msi no longer indicates whether the 2.6 release is an Alpha, Beta, or a patched release. Future IronPython 2.6 installations will replace previous 2.6 releases which will be uninstalled automatically · The -X:PreferComInteropAssembly flag has been removed. All COM interop is now done through normal COM dispatch You can download IronPython 2.6 Alpha 1 at: http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22982 The IronPython Team ___ 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] Released prototype Excel add-in making it easy to create Python add-ins
IronPython in a spreadsheet? Terrible idea, it'll never work ;-) Cheers, Giles -- Giles Thomas 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 Thomas P. Boesen wrote: Hi, I am thinking about creating an Excel add-in that makes it very easy to create Excel macros / add-ins using Python (IronPython) Any feedback about the idea will be greatly appreciated. I have made a prototype of this add-in available here: http://www.xefion.com/en/discoveryscript.html The add-in would be free, although not open-source. It takes quite a bit of “plumbing” to get COM add-ins running within Excel. My add-in would look for Python scripts in a specific directory and automatically create Excel menu-items for all the scripts in that directory. Hence, to get started the user just has to create a one-line Python script and store this script in the designated folder, then he can run the script from Excel. There will be various other options, for example shared network locations with scripts and connecting Excel events (e.g. OpenDoc or SaveDoc) to scripts based on their names. Later versions might also work with other Office programs (e.g. Word). The download-page mentioned above contains a description of feature candidates. :-) Thomas P. Boesen ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas 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 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Resolver One 1.4 beta - with IronPython 2.0
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 +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 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcing IronPython 2.0
Thirded, well done to all! James Matthews wrote: I agree, I am now downloading and installing it!! On Wed, Dec 10, 2008 at 11:53 PM, Sylvain Hellegouarch [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Congratulations to everyone who made it happen. That's fantastic news :) - Sylvain Dave Fugate a écrit : Hello Python Community, The IronPython and Dynamic Language Runtime teams are proud to announce the release of IronPython 2.0 final. IronPython 2.0 is the culmination of nearly two years worth of work resulting in a CPython 2.5 compatible release on .NET 2.0 SP1. By far, the biggest change to 2.0 is that our 1.1 codebase was refactored to run on top of the Dynamic Language Runtime http://www.codeplex.com/dlr. With this we automatically get improvements in many feature areas such as better .NET interop support and hosting Python from managed code. There have been many other major improvements as well. The most notable are: · An MSI installer for Windows platforms which includes parts of the CPython 2.5 standard library · IronPython assemblies targeting Silverlight and tools such as Chiron to improve the Silverlight dynamic development experience · The addition of more C-based standard modules such as /cmath/ and /_winreg/ · Significant improvements in importing compatibility and features · Distribution of IronPython under the Microsoft Public License which has been approved by OSI · Performance improvements. On that note, a new Wiki page has been created for IronPython performance reports - see http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IronPython%20Performance · Over 500 bugs have been closed in 2.0. 453 of these were reported on CodePlex · Support for precompilation of Python source files into a single dll This seems like an opportune time to remind everyone that we fix bugs based on the number of votes they have on CodePlex. As we're planning on releasing IronPython 2.0.1 fairly soon, please vote for your favorite bugs at http://www.codeplex.com/IronPython/WorkItem/AdvancedList.aspx to help ensure they get fixed in time for the next release. We'd like to extend our gratitude to everyone in the IronPython community who reported bugs thereby making this a better release: milind, romank, chadaustin, sjmachin, davidfraser, TimothyFitz, drewid, sanxiyn, bashmohandes, pobrien, perhaps, haypo, Undebtedly, ayarrow, tscottw_cp, rope, arman0, eshaish, nivaldo, fuzzyman, CurtHagenlocher, Eloff, brucec, py_sunil, jacobg23, mziller, beaugunderson, gbraad, Oceanborn, tarlano, jbevain, glchapman, anthonybaxter, jdhardy, jjlee, haibo, doubleyewdee, jackeyoo, whit537, sdahlbac, PeteHufnagel, jtenney, nriley, junfeng, grizlupo, rridge, lewisle, JoelBondurant, johnplatt, lthompson, debackerl, googen, tscottw, VoteFw, leppie, Qvin, heyssion2, CriGoT, baxeno, sbergman, Laurion, luntain, oldman, christmas, 05031972, kevgu, wilberforce, Korbinian, lclj, sorokerr, Eriol, tatwright, ais, TraumaPony, pelikhan, asafk, felixpollan, srid, atifaziz, vernondcole, fwereade, zpy, yanne, facorreia, Daneel, zvikag, psykotic, Cavingdeep, BEaton, sborde, orbital56, fbourgeois, antont, krosavcheg, ktc1, awilkins, ben2004uk, paulfelix, axl, JeffreySax, Lawouach, and KKI. You can download IronPython 2.0 at: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=8365 The IronPython Team BTW Updates to the IronPython 1.0 samples will be released shortly. Stay tuned to the IronPython mailing list for details. ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.goldwatches.com/ http://www.jewelerslounge.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] Announcing IronPython 2.0 Release Candidate 1
· 18333decoding of 'unicode_internal' strings is
broken
· 18350Innacuracy in float representation (causing pickle
problems)
· 18517-X:ExceptionDetail behaves differently depending
upon the OS (or CLR minor version)
· 18523Case insensitive ipy.exe tab completion
broken
· 18524COM methods don't work on x64 platforms
· 18575Compiling modules with cyclic imports inside a
package fails
· 18576compiling a package with sub-packages doesnt
preserve the hierarchy.
· 18639COM methods can't correctly be used as Python dict
keys under -X:PreferComInteropAssembly
· 18728hmac module broken
· 18747Regular expression repeat qualifier {m,n} does not
work if lower bound is omitted
We'd like to thank everyone in the community who reported these bugs:
sanxiyn, Michael Foord, jtenney, yanne, zpy, atifaziz, srid, Eloff,
Korbinian, sdahlbac and baxeno.
These bugs were reported internally and closed:
· 409568 test_parrot fails under -X:Interpret (Debug binaries
on 64-bit platforms) w/ StackOverflowException
· 436524 __perf_getmember.py broken by merged SNAP job
(changeset 435597)
· 497193 tf changeset 533300 caused 60% perf degrade in
IronPython startup time
You can download IronPython 2.0 RC1 at:
http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=17404
The IronPython Team
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
Giles Thomas
MD CTO, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Try out Resolver One! http://www.resolversystems.com/get-it/
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Resolver One 1.2 released
We are proud to announce the release of Resolver One, version 1.2 - still (we think) the largest IronPython application in the world, now running at 38,000 lines of production code backed up by 150,000 lines of unit and functional tests. Resolver One is a Rapid Application Development tool for analysing and presenting business data, using a familiar spreadsheet interface but with a powerful IronPython-based scripting capability that allows you to insert your own code directly into the recalculation loop. This version's headline feature is a new function called RunWorkbook that allows you to call one spreadsheet from another, passing in parameters and pulling out results - just like functions, but without having to code the function by hand. We've also added a whole bunch of usability enhancements - the full (long!) changelist is up on our website, or you can see a screencast: http://www.resolversystems.com/screencasts/release-1.2 It's free for non-commercial use, so if you would like to take a look, you can download it from our website: http://www.resolversystems.com/get-it/ (registration no longer required). Best regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 1.1.2
Dave,
Congratulations on getting from RC1 to release without any need for
bugfix builds :-)
We're just about to release version 1.2 of Resolver One, so we'll port
our codebase over to IP 1.1.2 as soon as that's out of the door.
Regards, and thanks!
Giles
Dave Fugate wrote:
Hello IronPython Community,
It's been several weeks since we released IronPython 1.1.2 RC1 and
this build does not appear to have caused any new issues. As a result
I'm pleased to announce the release of IronPython 1.1.2.
IronPython v1.1.2 is a minor update in which we fixed the most
requested CodePlex bugs and also a handful of trivial bugs. In total
twenty-one bugs have been resolved for 1.1.2. It's worth noting that
this included the implementation of the _winreg CPython module and a
few performance improvements in targeted areas. Please also note that
there are two potentially breaking changes in this release:
* · nt.unlink will now throw an exception if the file doesn't exist,
as it does in CPython
* · The signature of IronPython.Runtime.Operations.Ops.Id() has
changed and it now returns an object instead of long. This maps to the
id() function in Python. Note that there is no change for Python
caused by this and only code which is directly calling Ops.Id from a
statically typed language like C# or VB will be affected.
The following CodePlex Work Items were closed:
· 16368 1.1.2: nt.access is missing
· 16402 1.1.2: implement _winreg module
· 15105 1.1.2: endpos is zero in IronPython 1.1.1
· 16335 1.1.2: Event handlers can cause circular references and leak
memory
· 16337 1.1.2: Trivial: Implement float.__lt__(float)
· 16338 1.1.2: Using lambda in class definition will add lambda$..
into the
· 16342 1.1.2: calling base class __call__ invokes constructor instead
· 16343 1.1.2: problem with __slots__ and __init__ in new-style classes
· 16347 1.1.2: Trivial: popen shouldn't open new window
· 16348 1.1.2: Removes the inexistent file did not throw OSError in IP
· 16350 1.1.2: int() doesn't convert representable longs to int
· 16351 1.1.2: dict.update doesn't take keyword arguments - differs
from CPython
· 16353 1.1.2: Trivial: int('0x20', 16) fails to parse, long too
· 16355 1.1.2: unpacking single element tuples in for-statement,
listcomp and generator
· 16356 1.1.2: socket.getnameinfo(...) broken under Vista
· 16360 1.1.2: Class with slots and getattr not compatible
· 16363 1.1.2: Can't call method w/ nullable as 1st argument w/
greater than 5 arguments
· 16364 1.1.2: Backport fix for compiled regular expressions
· 16365 1.1.2: Tuple hashing improvements
· 16366 1.1.2: PyCF_DONT_IMPLY_DEDENT support in compile
· 16749 1.1.2 (Trivial): Modifier of
PythonEngine.DefaultCompilerContext(..)
We'd like to thank everyone in the community who contributed to these
bugs: Ronnie Maor, jackeyoo, sanxiyn, Michael Foord, Kamil
Dworakowski, lthompson, romank, Jeff Brown, rridge, David Fraser,
pobrien, ebaklund.
You can download IronPython 1.1.2 from
http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=IronPythonReleaseId=11275
http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=IronPythonReleaseId=11275.
The IronPython Team
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
Giles Thomas
MD CTO, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Try out Resolver One! http://www.resolversystems.com/get-it/
(Free registration required)
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Roadmap and updates
Curt Hagenlocher wrote: Until then, you can always do what I understand Resolver Systems did: save your forms as C# and manually copy the generated code into your Python classes. The initialization code is so generic and predictable that you don't have to do much more than lop the semicolons off the ends of the lines. Not quite - we generate C# base classes from Visual Studio, then write IronPython subclasses to add the behaviour. Cheers, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Creating Excel Add-in with Iron Python
Hi Todd, I don't know if you came across us in your googling, but we have a spreadsheet (free for non-commercial use) that you can script in IronPython. It's not Excel - we like to think it's better :-) - but hopefully it will be useful for you. There's a description here http://www.resolversystems.com/products/resolver-one/ and you can download it from http://www.resolversystems.com/get-it/ Best regards, Giles Todd Page wrote: Hi guys, Just starting to get into IronPython and have been poking around for the last few days; but I'm hoping someone can help. Basically, I want to take some python (IronPython) code, compile it to a dll (or xll?) and have it function like an add-in for excel. So, I could code functions in python and just call them as worksheet functions in excel. This is greatly preferable to writing VBA!! Can anyone point me in the right direction? After days of googling all I seem to have is 10-12 open tabs and still no concrete answer. Any help is appreciated, thanks! twp ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython Code Coverage - any options?
Hi Carl, Unfortunately we've not yet found a code coverage tool we can use - though to be honest, we've not done much in-depth searching since Michael posted on the topic. Best regards, Giles Carl Trachte wrote: Hello, I just did a Google search and found Michael Foord's blog post on coverage tools, among other things test related: http://www.voidspace.org.uk/python/weblog/arch_d7_2006_06_17.shtml Has anything else come up since then? Does (if I can ask) Resolver use a code coverage tool? I'm just getting started testing with unitttest and I'd like to gauge my progress as I implement testing in more of my code. Thanks a ton for any information you can provide. Carl T. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Resolver One 1.1
Curt, Thanks! And many thanks to everyone on the IP team for producing such a solid platform, we're really enjoying working with it. Best regards, Giles Curt Hagenlocher wrote: Congratulations to the Resolver One folks on the most recent release! http://www.resolversystems.com/news/?p=61 I've just come back from helping out with the Dynamic Languages booth at TechEd, and it was very gratifying to be able to prove to people that IronPython is a real product by naming a shipping application which is implemented with it. -- Curt Hagenlocher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
Would it be hugely tricky to get it working in IP 1.1 as well as 2.0, do you think? I'm imagining some kind of --target:1.1 flag to the tool. Michael Foord wrote: Curt Hagenlocher wrote: On Feb 4, 2008 11:07 AM, Michael Foord [EMAIL PROTECTED] wrote: Curt Hagenlocher wrote: The assemblies call into the IronPython engine (version 2) to load and execute the script. Currently, the script is loaded from the file system, but I'd eventually like to support embedding any required scripts as resources in the assembly, so that the whole thing can be distributed as a single neat package. Great - you beat me to it. :-) If you make this open source then I'll be happy to help on it. I'm thinking of putting it on Codeplex. Be warned that I prefer ILGenerator to CodeDOM, probably because I'm reliving the glory years of assembly language programming. 6502 4eva! :) Ouch. :-) Although in my case it was 68000 forever (truly beautiful CPU - based appreciated inside an Amiga). I'd love to learn more about generating IL - although it does make the learning curve steeper (I have tinkered but nothing more). The current implementation is written in Python. I would recommend leaving it in Python unless you have compelling reasons to rewrite... I'm sure you will - but when you get it up on CodeDOM post an announcement here so that I can blog about it. This is great news as it fills one 'missing piece of the puzzle' when it comes to integrating IronPython with other .NET languages. Michael -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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 -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
Curt Hagenlocher wrote: I can't imagine that this would be a problem. It's been a while since I played with the hosting-level interfaces of 1.1, but I seem to recall that (at the level in question) they're largely isomorphic with what's currently in 2.0. Excellent - that's what I thought. I'd love to add that once it's online. Cheers, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Resolver One 1.0 released
Hi all, We are proud to announce the release of Resolver One, version 1.0 - the largest IronPython application in the world, we think, at 30,000 lines of production code backed up by 110,000 lines of unit and functional tests. Resolver One is a Rapid Application Development tool for analysing and presenting business data using a familiar spreadsheet interface, combined with a powerful IronPython-based scripting capability that allows you to insert your own code directly into the recalculation loop. It's free for non-commercial use (and for the introductory period quite cheap for commercial use :-), so if you would like to take a look, you can download it from our website (free registration required): http://www.resolversystems.com/get-it/ Best regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 Try out Resolver One! http://www.resolversystems.com/get-it/ (Free registration required) 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] ANNOUNCE: Resolver One public Beta now live
We're proud to announce that today Resolver One, our flagship application, entered its public Beta phase. It can be downloaded from http://www.resolversystems.com/download/ (free registration required), and we would very much welcome feedback from the Python community. Resolver One is a Rapid Application Development tool for analysing and presenting business data using a familiar spreadsheet interface - or, to put it another way, it is a mash-up of a spreadsheet and an IDE. As you enter formulae on the grid, it writes the equivalent IronPython code for you. As you add your own IronPython code, the grid is updated. This allows you to build applications that are much more complex but better-structured than a traditional spreadsheet, much more quickly than you could if you were using a regular programming language. You can then export the code and re-use it elsewhere in your own programs. It's primarily targetted at heavy users of number-crunching software, such as financial firms and the biotech industry, but we use it internally for all kinds of scripts, so we think any Python programmer will be able to do fun stuff with it. If you're interested in taking a look, please do download it or drop us a line! Best regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Linux Support
It's worth mentioning that there is a project to get CPython C extensions working under IronPython: http://groups.google.com/group/c-extensions-for-ironpython/ The list is quiet at the moment, but work is going on... hopefully we'll have something more to report soon. Cheers, Giles Michael Foord wrote: Evan Klitzke wrote: Hi all, I've been looking at IronPython a bit lately as an alternative to CPython. I've had some difficulties, however, getting it working on Linux. I've just spent a few minutes trying to get it running under mono, and I haven't been that impressed. Among various problems: Hello Evan, Linux and Mono support is through the FePy project. http://fepy.sourceforge.net It addresses the build concerns you raise and provides some modules that don't come with the standard IronPython build. You can't use CPython extensions (the ones written in C anyway) with IronPython though, and should look for .NET equivalents. All the best, Michael http://www.manning.com/foord ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Curt Hagenlocher wrote: Hypothetically, you could muck about with the unmanaged interfaces to the managed code execution engine and pull in the information that way. How much of the MSCOREE-exposed functionality does Mono implement? Mind you, I don't actually think this is a good idea. It does sound risky. Perhaps just going with a struct as lupus suggested is the simplest cross-platform solution, even if it does require an initialisation function of some sort. Cheers, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] My takes on C Extensions for IronPython
Seo Sanghyeon wrote: The discussion is getting very confusing, It is indeed! The good news is that this part is already developed, debugged, and pretty much finished -- for Python 2.3 to 2.6, and for wide and narrow unicode builds of Python. Get it here (~ 1600 lines): http://pythonnet.svn.sourceforge.net/svnroot/pythonnet/trunk/pythonnet/src/runtime/runtime.cs Assuming that ZPL (which is OSI-certified) is okay, it would be strange not to use this. I'm a bit confused here... Unless I'm completely misunderstanding the code, it looks like it's a set of DllImports allowing you to access the CPython C extensions API from managed code. This let's you write managed code that extends CPython - which I assume is the Python.NET developers' intention - but we're trying to write unmanaged code to extend IronPython. Am I missing some obvious way in which we could use it? I guess it would work as a template to follow when writing the equivalent for calling into IronPython...? Regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Paolo Molaro wrote: You can use a struct that contains all the needed delegates and pass that on the p/invoke call. I guess that's a bit cleaner, as is Curt's COM version. But I was really hoping to be able to avoid the init call from the managed side entirely. Regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Paolo Molaro wrote: or 3, the easiest of all: using function pointers in the C code which the runtimes will generate automatically when passing a delegate to a p/invoked method. Besides being trivial compared to both 1 and 2, it works on Mono and it works on the MS CLR. I'm glad you mentioned that; we use it in our P/Invoked code (for the callback when iteration over windows), and it works just fine; I was beginning to worry that it might not work on Mono. A question - if we were trying to produce something that, at a source level, looked like the CPython extensions API, is there any easy way that we could get that to be able to call back to IronPython? I can imagine something like an init() function on the managed side that could pass a number of delegates over to the unmanaged code so that they could be called back at a later point, but is there a more elegant solution? Cheers, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Curt Hagenlocher wrote: On 10/17/07, *Paolo Molaro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: As python extensions use a C API, I don't see how Managed C++ would provide source compatibility. Managed C++ would be an ill-advided method, IMHO. [...] You'd have two components: the C API headers and some C code (this is required in any case) is the first. Then you need an assembly that translates from the C API to the IronPython model. You can write this in nice C# + a few dllimports or with the ugly managed C++ (assuming managed C++ can actually consume the python headers). MC++ lets you create a single module that contains both normal machine code and MSIL, and takes care of the transitions between the two. There's no reason you can't compile the existing C code and link it directly with the MC++ wrapper -- which is exactly what I originally meant. Curt - how does MC++ relate to using P/Invoke? That is, is it P/Invoke plus some clever packaging stuff to allow you to produce a single assembly with both machine code and MSIL, or is there more to it than that? Or is it something completely different? Regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Davy Mitchell wrote: Are Resolver Users looking to reuse their existing code in spreadsheets or just have the same facilities? If the latter then SWIG for Dotnet seems a better option than COM and is more Mono friendly. I think having the same facilities is vital, but having the same interface is very important. If I understand it correctly, the problem with SWIG is that it relies on there already existing a solid, well-designed C API which can be wrapped - which is the case for NumPy, but isn't for C extensions in general AFAIK. Regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Announcement: Project to get some CPython C extensions running under IronPython
Sounds like I misunderstood you too, then :-) Paolo Molaro wrote: On 10/17/07 Giles Thomas wrote: I must admit I'd also misunderstood how a MC++ option would work, in the same way as Paolo Molaro, but this sounds really useful. Is there any I don't think I misunderstood anything:) I said that there are two modules, the C one and the one that bridges the C code to the ironpython world. That the two modules can be combined into the same binary image doesn't change the fact that they are two different things, it's just an implementation detail. Thanks! lupus -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [python] Re: Announcement: Project to get some CPythonCextensions running under IronPython
I've set up a Google Group for the project; if you're interested in participating, you can sign up here: http://groups.google.com/group/c-extensions-for-ironpython/ Thanks, Giles Giles Thomas wrote: In an appropriately Pythonesque manner, this is getting very silly :-) Let's go for C Extensions for IronPython. I'll set up a mailing list and post the details here. Regards, Giles Michael Foord wrote: Personally, I like the name C Extensions for IronPython. It's descriptive. CexFIP Cex for IronPython ?? :-) Michael Joe ___ 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 -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Announcement: Project to get some CPython C extensions running under IronPython
At Resolver Systems, we started building our core products with the view that most of our clients would want to use them to connect spreadsheet data and designs, Python code, and .NET objects. This was the right decision; lots of people do want to do just that, and we've been working with them so far. However, as we've spoken to more potential clients over the last months, we've learned something new - that there's a lot of interest out there in using a tool like Resolver One to plug together not just spreadsheets, Python and .NET, but also the existing CPython C extensions. Solving the general problem - plugging an arbitrary C extension into IronPython - is a huge project, and we're not even sure we could work out *how much work it is* without a lot of investigation. What we intend to do is to solve a specific problem, to integrate just one extension, and to use that project as a testbed to examine the possibilities for getting other extensions working - and perhaps, in the long term, solving the general problem. We think that any solution like this will be valuable not just to us, but to the IronPython community as a whole. And so, we want to make it Open Source. Right now, we'd particularly like to hear from people about the following: * Who wants to get involved? We're really keen on working with people on this. * Which module should we go for? NumPy looks like a good start, as it gives us a start on getting SciPy working. But perhaps there are better choices. * Should this be a new project, or should we be talking to other people about getting it into other projects? * Which license? If we're to work on it with a view to building it into Resolver One, then it will need to be commercial-software-friendly. Apart from that - we have no view. * What is the best architecture? We're thinking of this as being a bit of C# managed code to interface with the C extension, and a thin Python wrapper on top. The module's existing C extension and Python code would sandwich this layer. Let us know if this is a silly idea :-) * Is there anything else we should be thinking about to get this started? Regards, Giles -- Giles Thomas MD CTO, Resolver Systems Ltd. [EMAIL PROTECTED] +44 (0) 20 7253 6372 We're hiring! http://www.resolversystems.com/jobs/ 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Future handling of op_Implicit
Thanks, Dino - I've voted on the bug, thanks for pointing me in that direction. It would be great to be able to avoid writing C# for this. Regards, Giles Dino Viehland wrote: I believe we're going to get better at this in the future. For starters there are currently some code paths which are missing the checks for the implicit conversions - for example if you define an implicit conversion to string we won't respect it all (in either v1.x or v2.x right now). This is because we have a fast path which isn't checking for the implicit conversion. Additionally it would be fairly easy for us to expose this out via some other mechanism for when we're not doing the right thing. For example we could either leave the op_Implicit methods on the type which defines them or maybe we could move them onto the type which we want to do the conversion from (e.g. add a ToFoo onto Bar when Foo defines an implicit operator for conversion from Foo to Bar). I believe w/ the 1st option we can get into trouble w/ overloads that only differ by return types but the 2nd option may be less problematic. But obviously we've got to do a better job of enabling this basic CLS consumption scenario w/o forcing you to use C#. We've also run into this internally recently as a fundamental DLR concept. That's how we discovered the issues w/ string conversions :). If you haven't already vote on bug #11278 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=11278) please do and we'll look at doing this sooner rather than later. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giles Thomas Sent: Thursday, July 05, 2007 8:43 AM To: Discussion of IronPython Subject: [IronPython] Future handling of op_Implicit Hi, I guess we're going to have to use C# to work around the lack of op_Implicit support in the short term, but I'm interested in knowing about the IP team's plans for handling conversion operators going forward. Here's our situation; we have a highly-scriptable application, and our clients want to be able to call their own .NET libraries from their scripts. However, their libraries make heavy use of the implicit casts, so that they can (for example) have a method that takes an instance of C1, but pass it a C2 and rely on C1's op_Implicit(C2) to handle the conversion. This works fine for them when using other .NET languages, but of course doesn't work in IronPython. I must admit that I don't really know what IP could do with this kind of code; if I understand correctly, op_Implicit(x) in (say) C# is dispatched based on the type of the variable x rather then the type of the object to which it is a reference, and of course variable type in that sense is not a meaningful concept in a dynamic language. What should IronPython do? Is this a case where people are going to have to write more code if they want to use a dynamic language? Regards, Giles -- Giles Thomas [EMAIL PROTECTED] +44 (0) 20 7253 6372 Resolver Systems Ltd 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas [EMAIL PROTECTED] +44 (0) 20 7253 6372 Resolver Systems Ltd 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] op_Implicit - workarounds to avoid C# code?
Hi all,
I am working with a C# library that has two classes with no inheritance
relationship, Class1 and Class2, where Class2 has an op_Implicit that
allows you to construct an instance of it from an instance of Class1.
In the same library there is a method Class3.TheMethod, which takes an
instance of Class2. There is C# code for this below.
I have an instance of Class1, c1, and I want to be able to call it in
IronPython with an instance of Class2 that has been created using the
op_Implicit; C# code that does this is also below.
So far I've had no luck; I understand that op_Implicit isn't very well
supported in IP currently, but any workarounds that avoid having to drop
into C# would be much appreciated.
I've tried getting it to work two ways - again, IP code is below:
* Doing it directly with C3.TheMethod(c1) just says expected
Class2, got Class1, as you would expect.
* Trying the trick that Dino Viehland suggested on 22 June, which
involves putting the instance into a generic list parameterised to
hold instances of Class2 just moves the problem to the call to
list.Add.
Am I missing something? If not, can anyone think of any other
workarounds? Or am I just going to have to grit my teeth and drop into
C#?
Regards,
Giles
--
Giles Thomas
[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Resolver Systems Ltd
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
C# library code:
=
namespace OpImplicitTest
{
public class Class1
{
public int value;
public Class1(int value)
{
this.value = value;
}
}
public class Class2
{
public int otherValue;
private Class2(int value)
{
this.otherValue = value;
}
public static implicit operator Class2(Class1 c)
{
return new Class2(c.value);
}
}
public class Class3
{
public void TheMethod(Class2 c2)
{
Console.Out.WriteLine(c2.otherValue);
}
}
}
C# library code:
=
Class1 c1 = new Class1(23);
Class3 c3 = new Class3();
c3.TheMethod(c1);
IP code
=
import clr
clr.AddReference('OpImplicitTest')
from OpImplicitTest import Class1, Class2, Class3
c3 = Class3()
c1 = Class1(23)
# Try calling it directly as per the C# - this blows up
c3.TheMethod(c1)
# Try Dino's workaround...
from System.Collections.Generic import List
l = List[Class2]()
# ...and this blows up.
l.Add(c1)
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] IronPython internships!
Resolver Systems are offering two internships in software development, based in London, for the Summer of 2007. These are designed for students looking for work over their Summer vacations. We are a software company, building a new kind of numerical analysis system, using IronPython and the .NET framework in an Agile development environment. Interns will be fully-fledged members of the development team for the duration of their stay - we follow the XP practice of pair programming, so mentoring will be continuous and intense, giving an excellent start in professional software engineering for those who want to make it their career. We're interested in hearing from anyone studying for a degree in numerate subject. Salary is £1,333 per calendar month; you should be able to work for at least 10 weeks over the course of the summer. Precise dates are negotiable. Please apply by email, including a CV, to [EMAIL PROTECTED] Regards, Giles -- Giles Thomas [EMAIL PROTECTED] +44 (0) 20 7253 6372 Resolver Systems Ltd 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Bug in handling of keyword arguments for __call__
Excellent - thanks, Dino. We have workarounds for our specific uses in
the meantime.
Regards,
Giles
Dino Viehland wrote:
They're certainly very similar but I'm not entirely certain if they're
the same (although they may be). In the other bug type.__call__ is a
type object which isn't right. If we were picking up type.__call__
instead of F.__call__ then I'd expect a different exception (as
type.__call__ is a type, and types are callable w/ kw-args). I won't
be certain until I look at it closer but I would expect that we're
looking up the wrong thing when we do the call on f but I'm not sure
where we'd be getting the wrong thing from.
The good news is both of these are fixed in some internal (post v1.1)
builds but the bad news is those aren't on CodePlex yet.
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Andrew
*Sent:* Wednesday, February 14, 2007 10:54 AM
*To:* Discussion of IronPython
*Subject:* Re: [IronPython] Bug in handling of keyword arguments for
__call__
It seems that this refers to Item # 7594:
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7594
2007/2/14, Giles Thomas [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Many thanks, Dino. This might be of use when debugging:
IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
class F(object):
... def __call__(self, *args, **kwargs):
... print F.__call__(%s, %s) % (args, kwargs)
...
print F.__call__
class '__main__.F'
Dino Viehland wrote:
Thanks for the bug report. I've opened bug #8246 to track this (
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8246).
-Original Message-
From: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]] On Behalf Of Giles Thomas
Sent: Wednesday, February 14, 2007 7:17 AM
To: Discussion of IronPython
Subject: [IronPython] Bug in handling of keyword arguments for __call__
Hi,
It looks like there's a problem with calling a callable object using the
** dictionary-unpacking syntax for keyword arguments. Here's a
minimal repro.
In CPython:
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
class F(object):
... def __call__(self, *args, **kwargs):
... print args, kwargs
...
f = F()
f(*(1,), **{'a' : 23})
(1,) {'a': 23}
In IP 1.0.1 (also checked against 1.1 alpha):
-
IronPython 1.0 (1.0.61005.1977 ) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
class F(object):
... def __call__(self, *args, **kwargs):
... print args, kwargs
...
f = F()
f(*(1,), **{'a' : 23})
Traceback (most recent call last):
File , line 0, in stdin##23
Exception: this object is not callable with keyword parameters
-
Regards,
Giles
--
Giles Thomas
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Resolver Systems Ltd
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
___
users mailing list
users@lists.ironpython.com mailto:users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
Giles Thomas
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Resolver Systems Ltd
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
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
Giles Thomas
[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Resolver Systems Ltd
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Bug in handling of keyword arguments for __call__
Hi,
It looks like there's a problem with calling a callable object using the
** dictionary-unpacking syntax for keyword arguments. Here's a
minimal repro.
In CPython:
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
class F(object):
... def __call__(self, *args, **kwargs):
... print args, kwargs
...
f = F()
f(*(1,), **{'a' : 23})
(1,) {'a': 23}
In IP 1.0.1 (also checked against 1.1 alpha):
-
IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
class F(object):
... def __call__(self, *args, **kwargs):
... print args, kwargs
...
f = F()
f(*(1,), **{'a' : 23})
Traceback (most recent call last):
File , line 0, in stdin##23
Exception: this object is not callable with keyword parameters
-
Regards,
Giles
--
Giles Thomas
[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Resolver Systems Ltd
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Bug in handling of keyword arguments for __call__
Many thanks, Dino. This might be of use when debugging:
IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
class F(object):
... def __call__(self, *args, **kwargs):
... print F.__call__(%s, %s) % (args, kwargs)
...
print F.__call__
class '__main__.F'
Dino Viehland wrote:
Thanks for the bug report. I've opened bug #8246 to track this
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8246).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giles Thomas
Sent: Wednesday, February 14, 2007 7:17 AM
To: Discussion of IronPython
Subject: [IronPython] Bug in handling of keyword arguments for __call__
Hi,
It looks like there's a problem with calling a callable object using the
** dictionary-unpacking syntax for keyword arguments. Here's a
minimal repro.
In CPython:
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
class F(object):
... def __call__(self, *args, **kwargs):
... print args, kwargs
...
f = F()
f(*(1,), **{'a' : 23})
(1,) {'a': 23}
In IP 1.0.1 (also checked against 1.1 alpha):
-
IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
class F(object):
... def __call__(self, *args, **kwargs):
... print args, kwargs
...
f = F()
f(*(1,), **{'a' : 23})
Traceback (most recent call last):
File , line 0, in stdin##23
Exception: this object is not callable with keyword parameters
-
Regards,
Giles
--
Giles Thomas
[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Resolver Systems Ltd
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
Giles Thomas
[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Resolver Systems Ltd
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79
Registered in England and Wales as company number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Is any one use IronPython in your project?
Kevien Lee wrote: Hi, Now ,Ironpython had release some time,but i want to konw is any one use IronPython in your project? Absolutely. At Resolver Systems, we're building a new desktop application for .NET. When we started, back in November 2005, we knew that we wanted our users to be able to write Python scripts to run within the app, so we decided to use IronPython as an embedded scripting language. We were about to start cutting code for the main body of our application in C#, but we decided to try an experiment. We had found IronPython a very productive language to work in while we were evaluating it, so we decided to start writing our core application itself in it. Our plan was to see how far we got, and then to switch to C# when we hit whatever limits IP had. We've now been using it for a year, and - with a couple of tiny exceptions, mostly involving calls down into unmanaged code - we haven't hit those limits yet. I would say about 95% of our codebase in terms of lines of code - and 99% in terms of functionality - is IronPython. As a dynamic language ,what it will bring us some advantage for project,which the advantage C#,VB.net couldn't have? As a long-time Java coder who's been working in IP for a year now, I would say that Python is just easier to program in; you have to spend less time trying to work out how to express the algorithms and structures you want to write, at least in part because there is less code to write when you don't have to put in typing information everywhere. On the other hand, we are an Extreme Programming shop, so we write tests for all of our code; I'm not sure how comfortable I'd be with the lack of type-safety without that. Regards, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Very strange problem with ExecuteFile
When the attached test.py is executed using ExecuteFile (sample .cs file also attached), we get the following exception: System.InvalidProgramException: Common Language Runtime detected an invalid program. The problem does not occur under the IP Console (which I guess doesn't use ExecuteFile). My best guess is that the problem occurs when the complexity of the parse tree exceeds some particular limit. Does anyone have any ideas for a workaround or a fix? This one is causing us serious problems, so any thoughts would be much appreciated. Regards, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c = d a.b.c
Re: [IronPython] Very strange problem with ExecuteFile
Martin, We don't see the same problem in the IronPython console; is this because it is executing the file somehow differently - perhaps line-by-line, maintaining a context dictionary? Regards, Giles Martin Maly wrote: I believe in this case the exception is result of what seems to be a CLR limitation. The code (in this case one static method) IronPython needs to generate to handle this input is too big and CLR/Jit then throws invalid program exception. The only workaround I am aware of is to split the code up to multiple functions. Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giles Thomas Sent: Wednesday, November 22, 2006 6:07 AM To: Discussion of IronPython Subject: [IronPython] Very strange problem with ExecuteFile When the attached test.py is executed using ExecuteFile (sample .cs file also attached), we get the following exception: System.InvalidProgramException: Common Language Runtime detected an invalid program. The problem does not occur under the IP Console (which I guess doesn't use ExecuteFile). My best guess is that the problem occurs when the complexity of the parse tree exceeds some particular limit. Does anyone have any ideas for a workaround or a fix? This one is causing us serious problems, so any thoughts would be much appreciated. Regards, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas Resolver Systems [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Very strange problem with ExecuteFile
Thanks, that makes sense. The code we have that was showing the problem is auto-generated, so we should be able to get our generator to split it up into smaller chunks and execute them separately. Regards, Giles Martin Maly wrote: Exactly. In console, each statement is compiled into its own CLR method so you won't hit this problem. Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giles Thomas Sent: Wednesday, November 22, 2006 8:12 AM To: Discussion of IronPython Subject: Re: [IronPython] Very strange problem with ExecuteFile Martin, We don't see the same problem in the IronPython console; is this because it is executing the file somehow differently - perhaps line-by-line, maintaining a context dictionary? Regards, Giles Martin Maly wrote: I believe in this case the exception is result of what seems to be a CLR limitation. The code (in this case one static method) IronPython needs to generate to handle this input is too big and CLR/Jit then throws invalid program exception. The only workaround I am aware of is to split the code up to multiple functions. Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giles Thomas Sent: Wednesday, November 22, 2006 6:07 AM To: Discussion of IronPython Subject: [IronPython] Very strange problem with ExecuteFile When the attached test.py is executed using ExecuteFile (sample .cs file also attached), we get the following exception: System.InvalidProgramException: Common Language Runtime detected an invalid program. The problem does not occur under the IP Console (which I guess doesn't use ExecuteFile). My best guess is that the problem occurs when the complexity of the parse tree exceeds some particular limit. Does anyone have any ideas for a workaround or a fix? This one is causing us serious problems, so any thoughts would be much appreciated. Regards, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Giles Thomas Resolver Systems [EMAIL PROTECTED] ___ 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 -- Giles Thomas Resolver Systems [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Mono, ironPython and WinForms
Thanks, Seo - I'll give it another go and will report any results to the list. Cheers, Giles 2006/11/13, Giles Thomas [EMAIL PROTECTED]: Seo, Does that extend to support for WinForms 2.0? Last time I tried running one of my .NET apps under Mono, it could not find the System.Windows.Forms 2.0.0.0 DLL. I may well have been missing something obvious, however. Mono includes System.Windows.Forms 2.0.0.0 DLL too. I am not sure why you had problems. -- Giles Thomas Resolver Systems [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Mono, ironPython and WinForms
Seo, Does that extend to support for WinForms 2.0? Last time I tried running one of my .NET apps under Mono, it could not find the System.Windows.Forms 2.0.0.0 DLL. I may well have been missing something obvious, however. Regards, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] Sanghyeon Seo wrote: 2006/11/12, Robert Smithson [EMAIL PROTECTED]: I read that Mono now has - some - support for WinForms. Has anyone gotten this working? And does this mean that we'll be able to use IronPython to produce some nice cross-platform apps? I'd say Mono has *good* support for WinForms. Of course, numerous people have it working. And yes, it does mean that one will be able to use IronPython to produce cross-platform GUI apps. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Direct3D demo
Dave, Thanks for the reply. When I run the demo using the August SDK, I get a message saying "This pre-release version of DirectX has expired, please upgrade to the latest version from http://www.microsoft.com/directx" It looks like one of my colleagues has had more luck with an October SDK, so perhaps the demo could be updated to support that? Regarding XNA - I thought it was C#-only, but I guess I was wrong... does this mean that people will be able to write for the Xbox in IP? Regards, Giles Dave Fugate wrote: At the moment there has been no decision on whether we will downgrade this example to be compatible with an earlier version of managed DirectX or migrate it to use XNA. If we take the latter option, I suspect we'll wait until the final XNA assemblies are released (i.e., they're still currently beta). In the meantime, are you unable to run the Direct3D sample with the August DirectX SDK for some reason? I checked the link to the August SDK download page from the tutorial and that seems to still be available for download. From: [EMAIL PROTECTED] [[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] [[EMAIL PROTECTED]] Sent: Friday, October 27, 2006 8:14 AM To: Discussion of IronPython Subject: [IronPython] Direct3D demo Hi, Is there going to be an updated version of the Direct3D demo now that the DirectX SDK to which it points has expired? Regards, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] ___ 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 -- Giles Thomas Resolver Systems [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [ANN] IronPython 1.0 released today!
On behalf of all of us at Resolver, congratulations! Many thanks to everyone on the IP team for making such a great product. All the best for future releases. Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] Jim Hugunin wrote: I'm extremely happy to announce that we have released IronPython 1.0 today! http://www.codeplex.com/IronPython I started work on IronPython almost 3 years ago. My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages. I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages. About 9 years ago I'd built an implementation of Python that ran on the JVM originally called JPython and later shortened to Jython. This implementation ran a little slower than the native C-based implementation of Python (CPython), but it was easily fast enough and stable enough for production use - testified to by the large number of Java projects that incorporate Jython today. I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM. My plan was to take a couple of weeks to build a prototype implementation of Python on the CLR and then to use that work to write a short pithy article called, Why the CLR is a terrible platform for dynamic languages. My plans quickly changed as I worked on the prototype, because I found that Python could run extremely well on the CLR - in many cases noticeably faster than the C-based implementation. For the standard pystone benchmark, IronPython on the CLR was about 1.7x faster than the C-based implementation. The more time I spent working on IronPython and with the CLR, the more excited I became about its potential to finally deliver on the vision of a single common platform for a broad range of languages. At that same time, I was invited to come out to Microsoft to present IronPython and to talk with members of the CLR team about technical issues that I was running into. I had a great time that day working through these issues with a group of really smart people who all had a deep understanding of virtual machines and language implementation. After much reflection, I decided to join the CLR team at Microsoft where I could work with the platform to make it an even better target for dynamic languages and be able to have interesting technical discussions like that every day. The first few months at Microsoft were a challenge as I learned what was involved in working at a large company. However, once the initial hurdle was over I started experiencing the things that motivated me to come here in the first place. The team working on dynamic languages in general and IronPython in particular began to grow and I got to have those great technical discussions again about both how to make IronPython as good as it could be and how to make the CLR an even better platform. We began to take advantage of the great new features for dynamic languages already shipping in .NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure. We were also able to release IronPython publicly from Microsoft with a BSD-style license. In the agile spirit of the project, we put out a new release of IronPython once every three weeks (on average) over the course of the project. This helped us connect well with our daring early adopters and receive and incorporate their feedback to make IronPython better. We've had countless excellent discussions on the mailing list on everything from supporting value types to calling overloaded methods. Without the drive and input of our users, IronPython would be a much weaker project. IronPython is about bringing together two worlds. The key value in IronPython is that it is both a true implementation of Python and is seamlessly integrated with the .NET platform. Most features were easy and natural choices where the language and the platform fit together with almost no work. However, there were challenges from the obvious cases like exception type hierarchies to the somewhat esoteric challenges concerning different methods on strings. We spent long days and sometimes weeks looking for the best answers to these challenging problems and in the end I think that we have stayed true to both Python and .NET. To drive our Python compatibility, we run a large portion of the standard Python regression test suite in addition to a large custom test suite we added that runs IronPython and CPython side-by-side to test for identical behavior whenever possible. Despite all of this work, there will still be differences between IronPython 1.0 and CPython. The most obvious difference is that IronPython
[IronPython] Beta 9 __getitem__
Hi, We've found what looks like a difference between IronPython and CPython's parsing of argument lists for square brackets. This is a change from Beta 8, which behaved in the same way as CPython. CPython: Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. class GetItemTest(object): ... def __getitem__(self, key): ... return key ... m = GetItemTest() print m[8,6] (8, 6) IronPython: IronPython 1.0.2385 (Beta) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. class GetItemTest(object): ... def __getitem__(self, key): ... return key ... m = GetItemTest() print m[8,6] Traceback (most recent call last): File , line 0, in stdin##16 TypeError: __getitem__() takes exactly 2 arguments (3 given) Regards, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] who is using ironpython in projects ?
Hi Dino, Is there any chance you could add a simple link to the up-to-date site before then? It leads to some confusion when, say, we tell someone interested in joining our team that one of the technologies we use is IronPython, and they then discover from the first result from a Google search that it hasn't been updated since July 2004... Regards, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] Dino Viehland wrote: Yes, we're aware of this - Current plan is to update the webpage before 1.0 final. Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Friday, April 21, 2006 1:36 AM To: Discussion of IronPython Subject: Re: [IronPython] who is using ironpython in projects ? 胡 杨 wrote: in python's web site, we can see a Success Stories link (http://www.python.org/about/success/), I wonder who is using ironpython in their project. ResolverSystems are currently (and happily) developing a new project with IronPython - however the IronPython homepage ( http://www.ironpython.com/ ) is *seriously* outdated and misleading, so *any* improvement (even a redirect) would be a good thing... Michael Foord 雅虎1G免费邮箱百分百防垃圾信 http://cn.mail.yahoo.com 雅虎助手-搜索、杀毒、防骚扰 http://cn.zs.yahoo.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 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Possible bug with exec(code, dict) when using lambdas
Hi all,
It looks like there may still be outstanding problems with exec(code,
dict) in beta 3; while the context in the dictionary is available to
normal code, anything deferred into a function can't see it.
An example might clarify:
IronPython 1.0.2237 (Beta) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
context = {}
exec(a = 1, context)
exec(print a, context)
1
exec(b = lambda x : x + a, context)
exec(c = b(5), context)
Traceback (most recent call last):
File , line 0, in input##105
File , line 0, in exec##106
File , line 0, in lambda
You get the same problem if you use a regular function rather than a lambda:
context = {}
exec(a = 1, context)
exec(def b(x): return x + a, context)
exec(c = b(5), context)
Traceback (most recent call last):
File , line 0, in input##80
File , line 0, in exec##81
File , line 0, in b
NameError: name 'a' not defined
The same code executes as expected in CPython.
Hope this is of some help to someone!
Cheers,
Giles
--
Giles Thomas
Resolver Systems
[EMAIL PROTECTED]
We're hiring! http://www.resolversystems.com/jobs/
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Issues with methods as event handlers?
Dino, That makes sense, thanks for the clarification. Regards, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] We're hiring! http://www.resolversystems.com/jobs/ Dino Viehland wrote: Another option that should work is: class ClickListener: def trigger(self, source, args): print ... a = ClickListener() b = a.trigger triggerButton.Click += b triggerButton.Click -= b What you're experiencing is the fact that trigger is actually just a callable object. When you do a.trigger you get a new bound method object that is different from the bound method object you get back when you do the -=. We should see if there's a way for us to fix this to match expecations so I'll go ahead and make sure we get the bug filed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giles Thomas Sent: Wednesday, February 01, 2006 11:10 AM To: Discussion of IronPython Subject: [IronPython] Issues with methods as event handlers? Hi all, When we use bound methods as Windows Forms event handlers, we can't detach them. Functions work OK. To see the problem, run up the attached button_method.py using IronPythonConsole; if you click on the Trigger button, you'll see a log message in the console saying that the trigger method has been called. Click on the Remove button to remove the event handler, and then click on the Trigger button again - you'll still get the log message. So the event handler was not detached correctly. By contrast, if you do the same thing using button_function.py, you will see that once you have clicked on Remove, the Trigger button's handler will be correctly detached, so further clicks on that button will not generate log messages. We've tested against beta 2, beta 1, and 0.9.5 (which latter doesn't display the button labels but otherwise behaves as described above). Hope this helps someone :-) Cheers, Giles ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Issues with methods as event handlers?
Hi all, When we use bound methods as Windows Forms event handlers, we can't detach them. Functions work OK. To see the problem, run up the attached button_method.py using IronPythonConsole; if you click on the Trigger button, you'll see a log message in the console saying that the trigger method has been called. Click on the Remove button to remove the event handler, and then click on the Trigger button again - you'll still get the log message. So the event handler was not detached correctly. By contrast, if you do the same thing using button_function.py, you will see that once you have clicked on Remove, the Trigger button's handler will be correctly detached, so further clicks on that button will not generate log messages. We've tested against beta 2, beta 1, and 0.9.5 (which latter doesn't display the button labels but otherwise behaves as described above). Hope this helps someone :-) Cheers, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] We're hiring! http://www.resolversystems.com/jobs/ import sys sys.LoadAssemblyByName(System.Windows.Forms) from System.Windows.Forms import * class ClickListener: def trigger(self, source, args): print clickListener called: , self.trigger clickListener = ClickListener() print Checking method equality: , clickListener.trigger == clickListener.trigger triggerButton = Button(Text = Trigger) triggerButton.Dock = DockStyle.Top triggerButton.Click += clickListener.trigger removeButton = Button(Text = Remove) removeButton.Dock = DockStyle.Bottom def remove(source, args): print Removing , clickListener.trigger triggerButton.Click -= clickListener.trigger removeButton.Click += remove form = Form() form.Controls.Add(triggerButton) form.Controls.Add(removeButton) Application.Run(form) import sys sys.LoadAssemblyByName(System.Windows.Forms) from System.Windows.Forms import * def click(source, args): print clickListener called: , click print Checking method equality: , click == click triggerButton = Button(Text = Trigger) triggerButton.Dock = DockStyle.Top triggerButton.Click += click removeButton = Button(Text = Remove) removeButton.Dock = DockStyle.Bottom def remove(source, args): print Removing , click triggerButton.Click -= click removeButton.Click += remove form = Form() form.Controls.Add(triggerButton) form.Controls.Add(removeButton) Application.Run(form) ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Trying to set methods on built-in classes fails silently
Hi, I suspect it's not something anyone's likely to come across often, but if you try to rebind a method on a built-in class, no exception will be thrown but it will not be changed. An example: You can rebind methods on regular classes easily: --- class C: ... def m(self): ... return 2 ... c = C() c.m() 2 def n(): ... return 3 ... c.m = n c.m() 3 --- However, when you try to do this with a CLR class there's no warning, but it doesn't work: --- f = Form() f.ToString() 'System.Windows.Forms.Form, Text: ' def newToString(): ... return Hello, world! ... f.ToString = newToString f.ToString() 'System.Windows.Forms.Form, Text: ' f.ToString == newToString False --- The behaviour when you try to set arbitrary attributes on the built-in classes is nicer, I think: --- f.foobar = 23 Traceback (most recent call last): at shell TypeError: can't set arbitrary attributes on built-in type System.Windows.Forms.Form --- I've confirmed this in the beta and in 0.9.5 (I hasten to add that I'm not recommending rebinding methods as standard practive...) Cheers, Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] We're hiring! http://www.resolversystems.com/jobs/ ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Lists of instances of classes
Hi, We've found what looks like a bug in list comparison: --- IronPython 1.0.2190 (Beta) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. class C: ... pass ... c1 = C() c2 = C() [c1, c2] == [c2, c1] True [c1] == [c2] True c1 == c2 False - Confirmed in 0.9.5, 0.9.6, and 1.0.2190 There is a horrible hack to work around it: - str([c1, c2]) == str([c2, c1]) False - Cheers, Giles ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Lists of instances of classes
Some more discoveries, following on from the below: --- class D: ... pass ... d1 = D() [c1, c2, c1] == [c1, c2, d1] True class E: ... def __init__(self): ... pass ... e1 = E() [c1, c2, c1] == [c1, c2, e1] True e1.foo = bar [c1, c2, c1] == [c1, c2, e1] True --- Looks like it's just assuming all objects are identical. Regards, Giles Giles Thomas wrote: Hi, We've found what looks like a bug in list comparison: --- IronPython 1.0.2190 (Beta) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. class C: ... pass ... c1 = C() c2 = C() [c1, c2] == [c2, c1] True [c1] == [c2] True c1 == c2 False - Confirmed in 0.9.5, 0.9.6, and 1.0.2190 There is a horrible hack to work around it: - str([c1, c2]) == str([c2, c1]) False - Cheers, Giles ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython IDE
Hi Aaron, Thanks for the pointer. Is there any simple documentation on setting this up once you've downloaded it? Cheers, Giles Aaron Marten wrote: Hi Giles, I'm on the Visual Studio SDK team here at Microsoft. In co-operation with the IronPython team, we're currently working on integrating IronPython into Visual Studio as a sample to ship in our SDK. We've just released a CTP with the first version of this here: http://affiliate.vsipmembers.com/downloads/41/UserFileDownload.ashx I also blogged a bit about the Dec CTP release of the Visual Studio SDK here: http://blogs.msdn.com/aaronmar/archive/2005/12/09/502202.aspx Note that right now, the integration code is in an incomplete state, but we do have the beginnings of a project system and language service working. Note that right now, the integration is only available as a preview sample in the Visual Studio SDK, so you'll have to agree to our license to get the code. Thanks! Aaron Marten (Microsoft) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giles Thomas Sent: Thursday, December 08, 2005 9:34 AM To: Discussion of IronPython Subject: [IronPython] IronPython IDE Hi all, Another question - what are people using to edit/debug IronPython code? My most recent projects have all been with Java using IntelliJ, and I've only just moved over to .NET. I'm told that Visual Studio 2005 is a good IDE - but it appears that it only supports C# and Visual Basic. Right now I'm using TextPad with a Python syntax highlighing configuration file, but if there's anything better out there - or if my understanding wrt VS2005 is wrong - then I'd love to hear about it! Cheers, Giles ___ 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
[IronPython] NUnit with IronPython
Hi, Has anyone got IronPython to work with NUnit? The thing that's blocking me is how to associate the TestFixture attribute with the class and the Test attribute with the methods. I suspect I may be missing something fundamental... Regards, Giles ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
