From sum.ergo.code at gmail.com Mon Jan 1 00:00:39 2007 From: sum.ergo.code at gmail.com (Patrick O'Brien) Date: Sun, 31 Dec 2006 17:00:39 -0600 Subject: [IronPython] Python Command Line Compiler issues and questions Message-ID: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> If you compile a python module using PYC and run the resulting executable, the module name is no longer '__main__' and so you cannot make use of the popular idiom: if __name__ == '__main__': If you don't use that idiom it makes it impossible to unit test any functions in your main module because running the unit tests imports the module and runs the main code. The alternative is to have the main module be as small as possible and put the bulk of the functionality into other modules that get imported by the main module. Which would be fine if there was a way to include those modules in the resulting exe created by PYC, but that doesn't seem to happen for me. Which means the .py files would have to ship as well as the .exe and the two .dll files (IronMath.dll and IronPython.dll). And substituting a .pyo file does not work, so what would ship in my app is the source code and for this particular app that would not be a good thing. The PYC program lets you specify multiple .py files, but I don't understand what that means. One file can be marked as main, which is what gets executed. What I don't understand is how the other .py files get used. The one example of this in the documentation was not terribly helpful for me. Anyone have any suggestions? Did I miss something in my understanding of PYC? How are others packaging their IronPython apps for distribution to customers? -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Jan 1 00:11:04 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 31 Dec 2006 23:11:04 +0000 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> Message-ID: <45984388.1080106@voidspace.org.uk> Patrick O'Brien wrote: > If you compile a python module using PYC and run the resulting executable, > the module name is no longer '__main__' and so you cannot make use of the > popular idiom: > > if __name__ == '__main__': > > If you don't use that idiom it makes it impossible to unit test any > functions in your main module because running the unit tests imports the > module and runs the main code. The alternative is to have the main module > be as small as possible and put the bulk of the functionality into other > modules that get imported by the main module. Which would be fine if there > was a way to include those modules in the resulting exe created by PYC, but > that doesn't seem to happen for me. Which means the .py files would > have to > ship as well as the .exe and the two .dll files (IronMath.dll and > IronPython.dll). And substituting a .pyo file does not work, so what would > ship in my app is the source code and for this particular app that would > not > be a good thing. > > The PYC program lets you specify multiple .py files, but I don't understand > what that means. One file can be marked as main, which is what gets > executed. What I don't understand is how the other .py files get used. > The > one example of this in the documentation was not terribly helpful for me. > > Anyone have any suggestions? Did I miss something in my understanding of > PYC? How are others packaging their IronPython apps for distribution to > customers? > We asked about IronPython supporting compiling Python modules so that they can be imported from, and were told that it probably wouldn't make it into IronPython 1.X. That means (my understanding) that PYC can only be used for compiling a single script with no dependencies (unless you're happy about shipping those dependencies as source files). Luckily for us at Resolver, I think we're happy to ship source files. If you're not happy with this you'll need to resort to other means for obfuscation (like encryption of source where the decryption is in the compiled part). This will confound casual observers, but IL is easily (relatively) decompiled and so will not stop the determined attacker from breaking your encryption. Michael http://www.voidspace.org.uk/python/articles.shtml > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.409 / Virus Database: 268.16.0/610 - Release Date: 30/12/2006 From sanxiyn at gmail.com Mon Jan 1 01:26:36 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 1 Jan 2007 09:26:36 +0900 Subject: [IronPython] Pyflakes on IronPython In-Reply-To: <4597F67D.7070309@voidspace.org.uk> References: <5b0248170612302041o6bc06babw700d05fff16e26bd@mail.gmail.com> <4597F67D.7070309@voidspace.org.uk> Message-ID: <5b0248170612311626i7224ba61x84edc965d8120b5d@mail.gmail.com> 2007/1/1, Michael Foord : > Can we use this without compiling Fepy ourselves ? > > We'd rather use the Microsoft DLLs (just so we don't have to move > IronPython sources into version control). Are there external files we > could use to add the AST support to IronPython ? > > I checked out the SVN repository, but it wasn't obvious from browsing > the files so I thought I'd ask. All codes are contained in the single file, fepy/ast.py. https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/fepy/ast.py To use without FePy, you would need to replace "compiler.parse()" calls with "ast.parse()" instead. IIRC, there's only one such place in case of Pyflakes. -- Seo Sanghyeon From mark.john.rees at gmail.com Mon Jan 1 02:45:56 2007 From: mark.john.rees at gmail.com (Mark Rees) Date: Mon, 1 Jan 2007 12:45:56 +1100 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <45984388.1080106@voidspace.org.uk> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> Message-ID: I have a simple IronPython script that will compile an IronPython executable with multiple source files http://hex-dump.googlecode.com/svn/trunk/ironpython-gdata-tutorial/tut03/makeexe.py and to handle the "if __name__ == '__main__':" idom you just need to change it to: if __name__ == '__main__' or __name__ == sys.executable: It's discussed in this post: http://hex-dump.blogspot.com/2006/08/deploying-gdata-reader-as-executable.html Mark On 1/1/07, Michael Foord wrote: > > Patrick O'Brien wrote: > > If you compile a python module using PYC and run the resulting > executable, > > the module name is no longer '__main__' and so you cannot make use of > the > > popular idiom: > > > > if __name__ == '__main__': > > > > If you don't use that idiom it makes it impossible to unit test any > > functions in your main module because running the unit tests imports the > > module and runs the main code. The alternative is to have the main > module > > be as small as possible and put the bulk of the functionality into other > > modules that get imported by the main module. Which would be fine if > there > > was a way to include those modules in the resulting exe created by PYC, > but > > that doesn't seem to happen for me. Which means the .py files would > > have to > > ship as well as the .exe and the two .dll files (IronMath.dll and > > IronPython.dll). And substituting a .pyo file does not work, so what > would > > ship in my app is the source code and for this particular app that would > > not > > be a good thing. > > > > The PYC program lets you specify multiple .py files, but I don't > understand > > what that means. One file can be marked as main, which is what gets > > executed. What I don't understand is how the other .py files get used. > > The > > one example of this in the documentation was not terribly helpful for > me. > > > > Anyone have any suggestions? Did I miss something in my understanding > of > > PYC? How are others packaging their IronPython apps for distribution to > > customers? > > > > We asked about IronPython supporting compiling Python modules so that > they can be imported from, and were told that it probably wouldn't make > it into IronPython 1.X. > > That means (my understanding) that PYC can only be used for compiling a > single script with no dependencies (unless you're happy about shipping > those dependencies as source files). > > Luckily for us at Resolver, I think we're happy to ship source files. If > you're not happy with this you'll need to resort to other means for > obfuscation (like encryption of source where the decryption is in the > compiled part). This will confound casual observers, but IL is easily > (relatively) decompiled and so will not stop the determined attacker > from breaking your encryption. > > Michael > http://www.voidspace.org.uk/python/articles.shtml > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > users mailing list > > users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > ------------------------------------------------------------------------ > > > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.409 / Virus Database: 268.16.0/610 - Release Date: > 30/12/2006 > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Mon Jan 1 09:25:09 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 1 Jan 2007 17:25:09 +0900 Subject: [IronPython] IronPython article on Japanese Open Source Magazine Message-ID: <5b0248170701010025u2a0b8af3k658c84aae917c394@mail.gmail.com> I came across this page today. http://osmag.jp/magazine/2007/200701.html The page title, "??????????? 2007/1", would translate to "Open Source Magazine 2007/1". It seems to have a section titled "????", or "Special program", which includes an article: .NET????Windows????Python?? Visual Studio?IronPython?Win??????? That would translate to: New Python environment on Windows which can use .NET Let's create a Win app with Visual Studio and IronPython This is very interesting, and apparently there are people interested in IronPython in Japan, but we don't hear much from them here. I guess they are afraid of English? That's a pity... -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Mon Jan 1 17:20:02 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 01 Jan 2007 16:20:02 +0000 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> Message-ID: <459934B2.8010309@voidspace.org.uk> Mark Rees wrote: > I have a simple IronPython script that will compile an IronPython > executable > with multiple source files > > http://hex-dump.googlecode.com/svn/trunk/ironpython-gdata-tutorial/tut03/makeexe.py > > > and to handle the "if __name__ == '__main__':" idom you just need to change > it to: > > if __name__ == '__main__' or __name__ == sys.executable: > > It's discussed in this post: > http://hex-dump.blogspot.com/2006/08/deploying-gdata-reader-as-executable.html > Ahh... cool. I've had a play with makeexe.py, it's very nice. You can compile multiple Python files (including imports) into a single executable. The difficulty we had was with maintaining our package structure. We want import semantics like 'from Main.Something import Something', which didn't seem to work with PYC. It *does* seem to work (initial experiments) with makeexe.py, which is cool. (I included the empty 'package/__init__.py' file in the arguments to makeexe.py.) We were intending to ship source code with our application (which has various advantages for us - our target market includes programmers in business environments), but we have an issue with startup time - mainly caused by the parsing of the Python files. Precompilation could solve that. Hmmm.... Michael Foord http://www.voidspace.org.uk/python/index.shtml > > Mark > > > > On 1/1/07, Michael Foord wrote: >> >> Patrick O'Brien wrote: >> > If you compile a python module using PYC and run the resulting >> executable, >> > the module name is no longer '__main__' and so you cannot make use of >> the >> > popular idiom: >> > >> > if __name__ == '__main__': >> > >> > If you don't use that idiom it makes it impossible to unit test any >> > functions in your main module because running the unit tests imports >> the >> > module and runs the main code. The alternative is to have the main >> module >> > be as small as possible and put the bulk of the functionality into >> other >> > modules that get imported by the main module. Which would be fine if >> there >> > was a way to include those modules in the resulting exe created by PYC, >> but >> > that doesn't seem to happen for me. Which means the .py files would >> > have to >> > ship as well as the .exe and the two .dll files (IronMath.dll and >> > IronPython.dll). And substituting a .pyo file does not work, so what >> would >> > ship in my app is the source code and for this particular app that >> would >> > not >> > be a good thing. >> > >> > The PYC program lets you specify multiple .py files, but I don't >> understand >> > what that means. One file can be marked as main, which is what gets >> > executed. What I don't understand is how the other .py files get used. >> > The >> > one example of this in the documentation was not terribly helpful for >> me. >> > >> > Anyone have any suggestions? Did I miss something in my understanding >> of >> > PYC? How are others packaging their IronPython apps for >> distribution to >> > customers? >> > >> >> We asked about IronPython supporting compiling Python modules so that >> they can be imported from, and were told that it probably wouldn't make >> it into IronPython 1.X. >> >> That means (my understanding) that PYC can only be used for compiling a >> single script with no dependencies (unless you're happy about shipping >> those dependencies as source files). >> >> Luckily for us at Resolver, I think we're happy to ship source files. If >> you're not happy with this you'll need to resort to other means for >> obfuscation (like encryption of source where the decryption is in the >> compiled part). This will confound casual observers, but IL is easily >> (relatively) decompiled and so will not stop the determined attacker >> from breaking your encryption. >> >> Michael >> http://www.voidspace.org.uk/python/articles.shtml >> >> > >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > users mailing list >> > users at lists.ironpython.com >> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > >> > >> > >> ------------------------------------------------------------------------ >> > >> > No virus found in this incoming message. >> > Checked by AVG Free Edition. >> > Version: 7.1.409 / Virus Database: 268.16.0/610 - Release Date: >> 30/12/2006 >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.409 / Virus Database: 268.16.1/611 - Release Date: 31/12/2006 From sum.ergo.code at gmail.com Mon Jan 1 18:10:37 2007 From: sum.ergo.code at gmail.com (Patrick O'Brien) Date: Mon, 1 Jan 2007 11:10:37 -0600 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <459934B2.8010309@voidspace.org.uk> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> <459934B2.8010309@voidspace.org.uk> Message-ID: <1d39a8340701010910u65f13522ncb54a45f37b8f2bd@mail.gmail.com> > > I've had a play with makeexe.py, it's very nice. > > You can compile multiple Python files (including imports) into a single > executable. > > The difficulty we had was with maintaining our package structure. We > want import semantics like 'from Main.Something import Something', which > didn't seem to work with PYC. > > It *does* seem to work (initial experiments) with makeexe.py, which is > cool. (I included the empty 'package/__init__.py' file in the arguments > to makeexe.py.) I'm still confused because makeexe doesn't appear to be that different from PYC. They both rely on Hosting.PythonCompiler, and while they pass a different number of arguments to the PythonCompiler, the difference doesn't seem significant based on my perusal of the PythonCompiler.cs source code. I'm still not clear on what it means to supply multiple source files to the PythonCompiler. Can anyone explain what happens to the other source files? If imports of those modules are supposed to work directly from the resulting exe, without the original .py files, I haven't been able to get that to work. Hmm, take that back. I just tried with makeexe.py and it works as expected - normal python import without having to have the original .py file available. So I guess the real question is why this isn't working in PYC. Sounds like a bug to me... Thanks, Mark and Michael. Now I'm much closer to the solution I was hoping for. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabio.pliger at siavr.it Tue Jan 2 10:15:15 2007 From: fabio.pliger at siavr.it (fabio.pliger) Date: Tue, 02 Jan 2007 10:15:15 +0100 Subject: [IronPython] Pyflakes on IronPython In-Reply-To: <5b0248170612302041o6bc06babw700d05fff16e26bd@mail.gmail.com> References: <5b0248170612302041o6bc06babw700d05fff16e26bd@mail.gmail.com> Message-ID: Great! Just want to post an apreciation note to Seo for the work he is doing! It's is amazing! Big cheers! Fabio -----Original Message----- From: "Sanghyeon Seo" To: "Discussion of IronPython" Date: Sun, 31 Dec 2006 13:41:20 +0900 Subject: [***SPAM*** Punteggio: 17.5/11.0] [IronPython] Pyflakes on IronPython On June 22, Michael Foord wrote: "At Resolver we are looking into tools that we can use to provide simple code hygiene checks. Check we're not shadowing built-in names, check for unneeded import statements and unused variables; that sort of thing. I know of three Python modules that do this. They all fail unredeemably on IronPython: (snip) Pyflakes: Uses compiler.parse." This is also CodePlex issue #563, titled "Support for Code Quality Tools". http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=563 [http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=563] In the release note of IPCE r5, I wrote: "Experimental AST support." For those who don't know, compiler.parse() returns AST, so they are the same thing. I am happy to announce that FePy's AST support got out of experimental status, and is now mature enough to run Pyflakes without much trouble. Actually, I ran it over FePy libraries and fixed a couple of unused .NET imports! This is done by "AST transform", which transforms AST made of subclasses of IronPython.Compiler.Ast.Node to AST made of subclasses of Python's compiler.ast.Node. Technical details will be discussed in the separate mail. Here's a demo: tinuviel at debian:~/svn/fepy$ ipy /usr/bin/pyflakes trunk/lib trunk/lib/_pth_support.py:116: 'sitecustomize' imported but unused trunk/lib/socket.py:222: 'ssl' imported but unused trunk/lib/socket.py:227: '_fileobject' imported but unused (These warnings are all true, but sitecustomize import is for the side effect, and ssl/_fileobject is part of external API.) Enjoy! -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com [http://lists.ironpython.com/listinfo.cgi/users-ironpython.com] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvm_cop at spamcop.net Tue Jan 2 17:25:58 2007 From: jvm_cop at spamcop.net (J. Merrill) Date: Tue, 02 Jan 2007 11:25:58 -0500 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <459934B2.8010309@voidspace.org.uk> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> <459934B2.8010309@voidspace.org.uk> Message-ID: <7.0.1.0.2.20070102112345.0794f430@wheresmymailserver.com> Now you only have to check if any of the .py files have a later date than the .EXE you built, and (p)re-compile in that case. Excellent! At 11:20 AM 1/1/2007, Michael Foord wrote (in part) >Mark Rees wrote: (in part) >> I have a simple IronPython script that will compile an IronPython >> executable with multiple source files >> >> http://hex-dump.googlecode.com/svn/trunk/ironpython-gdata-tutorial/tut03/makeexe.py >> [snip] > >Ahh... cool. > >I've had a play with makeexe.py, it's very nice. [snip] >We were intending to ship source code with our application (which has >various advantages for us - our target market includes programmers in >business environments), but we have an issue with startup time - mainly >caused by the parsing of the Python files. Precompilation could solve that. > >Hmmm.... > >Michael Foord J. Merrill / Analytical Software Corp From sum.ergo.code at gmail.com Wed Jan 3 14:12:32 2007 From: sum.ergo.code at gmail.com (Patrick O'Brien) Date: Wed, 3 Jan 2007 07:12:32 -0600 Subject: [IronPython] IpyUnit unit testing module In-Reply-To: <20061230091938305.GMIB.7129.emta103.odn.ne.jp@mta103.odn.ne.jp> References: <20061230091938305.GMIB.7129.emta103.odn.ne.jp@mta103.odn.ne.jp> Message-ID: <1d39a8340701030512g2f43fcb3l88ecbd8ea09d6e78@mail.gmail.com> On 12/30/06, Ryan Ginstrom wrote: > > Hello all: > > I've started using IronPython on a new desktop application, and I am > really > enjoying it. One thing I missed, though, was an easy-to-use unit testing > framework. I'm very new to both .NET and IronPython, but I made a first > stab > at writing a unit testing module. > Why not use the unittest that comes with CPython? It seems to work fine for me under IP. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From daftspaniel at gmail.com Wed Jan 3 14:22:49 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Wed, 3 Jan 2007 13:22:49 +0000 Subject: [IronPython] taylayout release Message-ID: <20253b0c0701030522x5a2dcf7s3be24ea6d8e5a013@mail.gmail.com> Happy 2007 Everyone, Early Developers Release Of TayLayout http://code.google.com/p/taylayout/downloads/list Unzip, cd to that dir and run slidenet.py or demo.py which are the sample applications. Some equally early docs exist at http://docs.google.com/View?docid=dd59dk39_2jh3xf9 There's loads I want to do with this little module but would love some feedback hence the early release. I have not tested yet on Mono. Also sorry but my website/blog will be down for a while more. If anyone else want to blog about this please do !! :-) Cheers, Davy Mitchell From fuzzyman at voidspace.org.uk Wed Jan 3 14:29:52 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 03 Jan 2007 13:29:52 +0000 Subject: [IronPython] IpyUnit unit testing module In-Reply-To: <1d39a8340701030512g2f43fcb3l88ecbd8ea09d6e78@mail.gmail.com> References: <20061230091938305.GMIB.7129.emta103.odn.ne.jp@mta103.odn.ne.jp> <1d39a8340701030512g2f43fcb3l88ecbd8ea09d6e78@mail.gmail.com> Message-ID: <459BAFD0.4000102@voidspace.org.uk> Patrick O'Brien wrote: > On 12/30/06, *Ryan Ginstrom* > wrote: > > Hello all: > > I've started using IronPython on a new desktop application, and I > am really > enjoying it. One thing I missed, though, was an easy-to-use unit > testing > framework. I'm very new to both .NET and IronPython, but I made a > first stab > at writing a unit testing module. > > > Why not use the unittest that comes with CPython? It seems to work > fine for me under IP. > Agreed. We use unittest as the basis of our test framework. Michael http://www.voidspace.org.uk/python/articles.shtml > -- > Patrick K. O'Brien > Orbtech http://www.orbtech.com > Schevo http://www.schevo.org > Louie http://www.pylouie.org > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From ygutfreund at draper.com Wed Jan 3 15:45:26 2007 From: ygutfreund at draper.com (Gutfreund, Yechezkal) Date: Wed, 03 Jan 2007 09:45:26 -0500 Subject: [IronPython] Solved: JavaScript -> Python COM without COMVisible Message-ID: <98B94F0758D7394CA057AE4898CBC85E02980983@exchbk1.draper.com> A while back, I asked for advise in this group about how I could communicate from Microsoft Virtual Earth (VE) back to a python app in which it was embedded. VE needs to run in a WebBrowser control. I was able to do this by creating at XAML file, with the Browser control, and then to wrap all of this in IronPython with the avalon.py include. Calling JavaScript from python is simple (.invokeScript()) but the other direction was hard. With your advice. I have gotton the following paradigm to work (which uses an C# interceptor that fires events that are trapped by python). JavaScript: window.external.dispatchString("shell", "mapClicked", "something|Something|Something"); // first item is module name, second is function, and third a | seperated list of arguments (a refinement of this is to use xml, or there are some introspection techniques in C# that are fairly heady, but can also be used. But there are real problems in sending simple arrays straight to C# via interop). C#: namespace IPyTools { [ComVisible(true)] public class PyArgs : EventArgs { public string module; public string function; public object[] args; public PyArgs(string module, string function, object[] args) { this.module = module; this.function = function; this.args = args; } } [ComVisible(true)] public class Interceptor { public delegate void IHandler(object source, PyArgs e); public event IHandler iPyEvents; public void dispatch(string module, string function, params object[]fArgs) { PyArgs e = null; if (iPyEvents != null) { e = new PyArgs(module, function, fArgs); iPyEvents(this, e); } } public void dispatchString(string module, string function, string strArgs) { if (strArgs == "") { dispatch(module, function); return; } object[] fArgs = strArgs.Split('|'); dispatch(module, function, fArgs); } } } Python: i = IPyTools.Interceptor() i.iPyEvents += dispatcher wb.ObjectForScripting = i def dispatcher(who, e): callee = sys.modules[e.module].__dict__[e.function] apply(callee, e.args) def mapClicked(style, cLat, cLong, mLat, mLong, zoom): print "mapClicked: " print " style:", style print " center:", cLat +","+ cLong print " mouse:", mLat +","+ mLong print " zoom:", zoom Dr. Yechezkal Gutfreund Tactical ISR Department Draper Laboratory 555 Technology Square, MS-77 Cambridge, MA 02139 +1-617-258-4206 ygutfreund at draper.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbk.lists at gmail.com Wed Jan 3 21:25:34 2007 From: mbk.lists at gmail.com (Mike Krell) Date: Wed, 3 Jan 2007 13:25:34 -0700 Subject: [IronPython] [Python-3000] What's the point of annotations? In-Reply-To: <5.1.1.6.0.20070103125604.02807198@sparrow.telecommunity.com> References: <5.1.1.6.0.20070102132113.02a5a968@sparrow.telecommunity.com> <5.1.1.6.0.20070102141711.0279fbd0@sparrow.telecommunity.com> <5.1.1.6.0.20070102185639.02920e70@sparrow.telecommunity.com> <5.1.1.6.0.20070103125604.02807198@sparrow.telecommunity.com> Message-ID: > Also, now that you remind me of it, IronPython could use [annotations] for C# overloads. FWIW, the IronPython folks are looking for a CPython-compatible syntax for specifying .net attributes. Function decorators (plus class decorators) don't cover all the use cases because so many different entities can be the target of a .net attribute. Whether the proposed annotations help "enough" is a question for those above my pay grade, i.e., I haven't been paying enough attention :-) Cf. several related threads on the ironpython mailing list -- e.g., http://lists.ironpython.com/pipermail/users-ironpython.com/2006-September/003497.html Mike From dinov at exchange.microsoft.com Thu Jan 4 22:06:36 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 4 Jan 2007 13:06:36 -0800 Subject: [IronPython] Exposing C++/CLI template classes to ironpython In-Reply-To: <20061231171516.66620@gmx.net> References: <20061231171516.66620@gmx.net> Message-ID: <7AD436E4270DD54A94238001769C2227561A3E5393@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Unfortunately you can't the CPython extension libraries w/ IronPython. You could do it w/ templates instead of macros and force the instantiation of the generic public class like: template class NativeData { public: T foo; }; template public ref class GenericData { private: NativeData *data; }; public ref class GDI : GenericData {}; public ref class GDC : GenericData {}; That seems to export both the GenericData and GenericData types (even if GDI/GDC are private) though maybe there's a better way to force the GenericData type to get exported. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of "Bernhard M?der" Sent: Sunday, December 31, 2006 9:15 AM To: users at lists.ironpython.com Subject: [IronPython] Exposing C++/CLI template classes to ironpython Hello all I'm starting to work with ironpython and have successfully exported some .NET classes into an extension library. Now I'm trying to get some C++ template classes to work with ironpython. I'm doing something like this: // This is our C++ class. template struct cpp_klass { T foo() { return T(); } } // This wraps the class for a specific T public ref class klass_uint8 { typedef cpp_klass klass_t; klass_t * _klass; klass_uint8() : _klass(new klass_t()) {}; ~klass_uint8() {delete _klass;} unsigned char foo() { return _klass.foo(); } }; This works but has do be done for each version of T. I'm about to write a big macro that does it for all cpp_class versions, but don't think this will be a nice solution... Is there a better way to do it? Or would it be possible to load CPython extension DLLs with ironpython? If yes, I could use boost.python to get the exports done. Thanks for any help! cheers Bernhard -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Thu Jan 4 22:48:04 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 4 Jan 2007 13:48:04 -0800 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <459934B2.8010309@voidspace.org.uk> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> <459934B2.8010309@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C2227561A3E53D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I am surprised one is behaving different. It works for me w/ pyc if I keep the package directory on the path, but if I don't then it breaks. I'm curious did you include all of your individual package files, or just __init__.py? And were the packages on your path? -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, January 01, 2007 8:20 AM To: Discussion of IronPython Subject: Re: [IronPython] Python Command Line Compiler issues and questions Mark Rees wrote: > I have a simple IronPython script that will compile an IronPython > executable > with multiple source files > > http://hex-dump.googlecode.com/svn/trunk/ironpython-gdata-tutorial/tut03/makeexe.py > > and to handle the "if __name__ == '__main__':" idom you just need to change > it to: > > if __name__ == '__main__' or __name__ == sys.executable: > > It's discussed in this post: > http://hex-dump.blogspot.com/2006/08/deploying-gdata-reader-as-executable.html > Ahh... cool. I've had a play with makeexe.py, it's very nice. You can compile multiple Python files (including imports) into a single executable. The difficulty we had was with maintaining our package structure. We want import semantics like 'from Main.Something import Something', which didn't seem to work with PYC. It *does* seem to work (initial experiments) with makeexe.py, which is cool. (I included the empty 'package/__init__.py' file in the arguments to makeexe.py.) We were intending to ship source code with our application (which has various advantages for us - our target market includes programmers in business environments), but we have an issue with startup time - mainly caused by the parsing of the Python files. Precompilation could solve that. Hmmm.... Michael Foord http://www.voidspace.org.uk/python/index.shtml > > Mark > > > > On 1/1/07, Michael Foord wrote: >> >> Patrick O'Brien wrote: >> > If you compile a python module using PYC and run the resulting >> executable, >> > the module name is no longer '__main__' and so you cannot make use of >> the >> > popular idiom: >> > >> > if __name__ == '__main__': >> > >> > If you don't use that idiom it makes it impossible to unit test any >> > functions in your main module because running the unit tests imports >> the >> > module and runs the main code. The alternative is to have the main >> module >> > be as small as possible and put the bulk of the functionality into >> other >> > modules that get imported by the main module. Which would be fine if >> there >> > was a way to include those modules in the resulting exe created by PYC, >> but >> > that doesn't seem to happen for me. Which means the .py files would >> > have to >> > ship as well as the .exe and the two .dll files (IronMath.dll and >> > IronPython.dll). And substituting a .pyo file does not work, so what >> would >> > ship in my app is the source code and for this particular app that >> would >> > not >> > be a good thing. >> > >> > The PYC program lets you specify multiple .py files, but I don't >> understand >> > what that means. One file can be marked as main, which is what gets >> > executed. What I don't understand is how the other .py files get used. >> > The >> > one example of this in the documentation was not terribly helpful for >> me. >> > >> > Anyone have any suggestions? Did I miss something in my understanding >> of >> > PYC? How are others packaging their IronPython apps for >> distribution to >> > customers? >> > >> >> We asked about IronPython supporting compiling Python modules so that >> they can be imported from, and were told that it probably wouldn't make >> it into IronPython 1.X. >> >> That means (my understanding) that PYC can only be used for compiling a >> single script with no dependencies (unless you're happy about shipping >> those dependencies as source files). >> >> Luckily for us at Resolver, I think we're happy to ship source files. If >> you're not happy with this you'll need to resort to other means for >> obfuscation (like encryption of source where the decryption is in the >> compiled part). This will confound casual observers, but IL is easily >> (relatively) decompiled and so will not stop the determined attacker >> from breaking your encryption. >> >> Michael >> http://www.voidspace.org.uk/python/articles.shtml >> >> > >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > users mailing list >> > users at lists.ironpython.com >> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > >> > >> > >> ------------------------------------------------------------------------ >> > >> > No virus found in this incoming message. >> > Checked by AVG Free Edition. >> > Version: 7.1.409 / Virus Database: 268.16.0/610 - Release Date: >> 30/12/2006 >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.409 / Virus Database: 268.16.1/611 - Release Date: 31/12/2006 _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Thu Jan 4 22:58:13 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 04 Jan 2007 21:58:13 +0000 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <7AD436E4270DD54A94238001769C2227561A3E53D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> <459934B2.8010309@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227561A3E53D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <459D7875.5090808@voidspace.org.uk> Dino Viehland wrote: > I am surprised one is behaving different. It works for me w/ pyc if I keep the package directory on the path, but if I don't then it breaks. > > I'm curious did you include all of your individual package files, or just __init__.py? And were the packages on your path? > It was a colleague of mine who tried this, but another user (in this thread) did report the same problem. Michael http://www.voidspace.org.uk/ironpython/index.shtml > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, January 01, 2007 8:20 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Python Command Line Compiler issues and questions > > Mark Rees wrote: >> I have a simple IronPython script that will compile an IronPython >> executable >> with multiple source files >> >> http://hex-dump.googlecode.com/svn/trunk/ironpython-gdata-tutorial/tut03/makeexe.py > >> and to handle the "if __name__ == '__main__':" idom you just need to change >> it to: >> >> if __name__ == '__main__' or __name__ == sys.executable: >> >> It's discussed in this post: >> http://hex-dump.blogspot.com/2006/08/deploying-gdata-reader-as-executable.html >> > > Ahh... cool. > > I've had a play with makeexe.py, it's very nice. > > You can compile multiple Python files (including imports) into a single > executable. > > The difficulty we had was with maintaining our package structure. We > want import semantics like 'from Main.Something import Something', which > didn't seem to work with PYC. > > It *does* seem to work (initial experiments) with makeexe.py, which is > cool. (I included the empty 'package/__init__.py' file in the arguments > to makeexe.py.) > > We were intending to ship source code with our application (which has > various advantages for us - our target market includes programmers in > business environments), but we have an issue with startup time - mainly > caused by the parsing of the Python files. Precompilation could solve that. > > Hmmm.... > > Michael Foord > http://www.voidspace.org.uk/python/index.shtml > >> Mark >> >> >> >> On 1/1/07, Michael Foord wrote: >>> Patrick O'Brien wrote: >>>> If you compile a python module using PYC and run the resulting >>> executable, >>>> the module name is no longer '__main__' and so you cannot make use of >>> the >>>> popular idiom: >>>> >>>> if __name__ == '__main__': >>>> >>>> If you don't use that idiom it makes it impossible to unit test any >>>> functions in your main module because running the unit tests imports >>> the >>>> module and runs the main code. The alternative is to have the main >>> module >>>> be as small as possible and put the bulk of the functionality into >>> other >>>> modules that get imported by the main module. Which would be fine if >>> there >>>> was a way to include those modules in the resulting exe created by PYC, >>> but >>>> that doesn't seem to happen for me. Which means the .py files would >>>> have to >>>> ship as well as the .exe and the two .dll files (IronMath.dll and >>>> IronPython.dll). And substituting a .pyo file does not work, so what >>> would >>>> ship in my app is the source code and for this particular app that >>> would >>>> not >>>> be a good thing. >>>> >>>> The PYC program lets you specify multiple .py files, but I don't >>> understand >>>> what that means. One file can be marked as main, which is what gets >>>> executed. What I don't understand is how the other .py files get used. >>>> The >>>> one example of this in the documentation was not terribly helpful for >>> me. >>>> Anyone have any suggestions? Did I miss something in my understanding >>> of >>>> PYC? How are others packaging their IronPython apps for >>> distribution to >>>> customers? >>>> >>> We asked about IronPython supporting compiling Python modules so that >>> they can be imported from, and were told that it probably wouldn't make >>> it into IronPython 1.X. >>> >>> That means (my understanding) that PYC can only be used for compiling a >>> single script with no dependencies (unless you're happy about shipping >>> those dependencies as source files). >>> >>> Luckily for us at Resolver, I think we're happy to ship source files. If >>> you're not happy with this you'll need to resort to other means for >>> obfuscation (like encryption of source where the decryption is in the >>> compiled part). This will confound casual observers, but IL is easily >>> (relatively) decompiled and so will not stop the determined attacker >>> from breaking your encryption. >>> >>> Michael >>> http://www.voidspace.org.uk/python/articles.shtml >>> >>>> >>> ------------------------------------------------------------------------ >>>> _______________________________________________ >>>> users mailing list >>>> users at lists.ironpython.com >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>>> >>>> >>>> >>> ------------------------------------------------------------------------ >>>> No virus found in this incoming message. >>>> Checked by AVG Free Edition. >>>> Version: 7.1.409 / Virus Database: 268.16.0/610 - Release Date: >>> 30/12/2006 >>> >>> _______________________________________________ >>> users mailing list >>> users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> ------------------------------------------------------------------------ >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.1.409 / Virus Database: 268.16.1/611 - Release Date: 31/12/2006 > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From sum.ergo.code at gmail.com Thu Jan 4 23:14:08 2007 From: sum.ergo.code at gmail.com (Patrick O'Brien) Date: Thu, 4 Jan 2007 16:14:08 -0600 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <7AD436E4270DD54A94238001769C2227561A3E53D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> <459934B2.8010309@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227561A3E53D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <1d39a8340701041414i36d9dc8bk19f4f5cb7ae7c250@mail.gmail.com> On 1/4/07, Dino Viehland wrote: > > I am surprised one is behaving different. It works for me w/ pyc if I > keep the package directory on the path, but if I don't then it breaks. > > I'm curious did you include all of your individual package files, or just > __init__.py? And were the packages on your path? > In my case I didn't have a package, merely an extra Python module, imported from the local directory. Something like the following: main.py ====== import extra print extra.foo() extra.py ====== def foo(): return "Hello" Does that make sense? Can you duplicate the problem? If not, I can create a real example for you. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Thu Jan 4 23:23:35 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 4 Jan 2007 14:23:35 -0800 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <1d39a8340701041414i36d9dc8bk19f4f5cb7ae7c250@mail.gmail.com> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> <459934B2.8010309@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227561A3E53D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <1d39a8340701041414i36d9dc8bk19f4f5cb7ae7c250@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227561A3E53FC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> That works for me, I did it a little differently, but basically the same: a: import b print 'hello' b.foo() b: print 'goodbye' def foo(): print 42 >ipy pyc.py /target:exe /main:a.py b.py ... >a.exe goodbye hello 42 That works even if a.py and b.py aren't available after the compilation. What I thought wasn't working w/ pyc, but maybe was working w/ the simpler one, was the more complex case involving packages: a: import b.c b.c.d() c\ __init__.py: d.py: def d(): print 42 I can compile a.py w/ c\__init__.py and get something that "works" but it works only if I run it from the directory that contains c. It works because we just re-compile d.py on the fly. But removing c causes it to break again. Unfortunately I don't think the compiler understands packages right now and it's something we should add to the to-do list. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Patrick O'Brien Sent: Thursday, January 04, 2007 2:14 PM To: Discussion of IronPython Subject: Re: [IronPython] Python Command Line Compiler issues and questions On 1/4/07, Dino Viehland > wrote: I am surprised one is behaving different. It works for me w/ pyc if I keep the package directory on the path, but if I don't then it breaks. I'm curious did you include all of your individual package files, or just __init__.py? And were the packages on your path? In my case I didn't have a package, merely an extra Python module, imported from the local directory. Something like the following: main.py ====== import extra print extra.foo() extra.py ====== def foo(): return "Hello" Does that make sense? Can you duplicate the problem? If not, I can create a real example for you. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Jan 4 23:38:51 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 04 Jan 2007 22:38:51 +0000 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <7AD436E4270DD54A94238001769C2227561A3E53FC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> <459934B2.8010309@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227561A3E53D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <1d39a8340701041414i36d9dc8bk19f4f5cb7ae7c250@mail.gmail.com> <7AD436E4270DD54A94238001769C2227561A3E53FC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <459D81FB.20208@voidspace.org.uk> Dino Viehland wrote: > That works for me, I did it a little differently, but basically the same: > > a: > import b > print 'hello' > b.foo() > > b: > print 'goodbye' > def foo(): print 42 > >> ipy pyc.py /target:exe /main:a.py b.py > ... > >> a.exe > goodbye > hello > 42 > > That works even if a.py and b.py aren't available after the compilation. What I thought wasn't working w/ pyc, but maybe was working w/ the simpler one, was the more complex case involving packages: > > a: > import b.c > b.c.d() > > c\ > __init__.py: > d.py: > def d(): print 42 > > I can compile a.py w/ c\__init__.py and get something that "works" but it works only if I run it from the directory that contains c. It works because we just re-compile d.py on the fly. But removing c causes it to break again. Unfortunately I don't think the compiler understands packages right now and it's something we should add to the to-do list. > I thought it worked with makeexe.py, but renaming the package causes the executable to fail. Oh well. We would really like this to work. Michael http://www.voidspace.org.uk/ironpython/index.shtml > > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Patrick O'Brien > Sent: Thursday, January 04, 2007 2:14 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Python Command Line Compiler issues and questions > > On 1/4/07, Dino Viehland > wrote: > I am surprised one is behaving different. It works for me w/ pyc if I keep the package directory on the path, but if I don't then it breaks. > > I'm curious did you include all of your individual package files, or just __init__.py? And were the packages on your path? > > In my case I didn't have a package, merely an extra Python module, imported from the local directory. Something like the following: > > main.py > ====== > > import extra > > print extra.foo() > > > extra.py > ====== > > def foo(): > return "Hello" > > > Does that make sense? Can you duplicate the problem? If not, I can create a real example for you. > > -- > Patrick K. O'Brien > Orbtech http://www.orbtech.com > Schevo http://www.schevo.org > Louie http://www.pylouie.org > > > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.410 / Virus Database: 268.16.5/616 - Release Date: 04/01/2007 From sum.ergo.code at gmail.com Thu Jan 4 23:50:16 2007 From: sum.ergo.code at gmail.com (Patrick O'Brien) Date: Thu, 4 Jan 2007 16:50:16 -0600 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <7AD436E4270DD54A94238001769C2227561A3E53FC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> <459934B2.8010309@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227561A3E53D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <1d39a8340701041414i36d9dc8bk19f4f5cb7ae7c250@mail.gmail.com> <7AD436E4270DD54A94238001769C2227561A3E53FC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <1d39a8340701041450s41e4ceb4yc9385075d52caf92@mail.gmail.com> On 1/4/07, Dino Viehland wrote: > > That works for me, I did it a little differently, but basically the same: > I apologize. I just tried to reproduce the problem I was having and found a mistake in the batch file I had created to send the right options to PYC. So it is true that for non-Python-package files the PYC works as advertised and the problems I reported previously were my own doing. Sorry for the false alarm. Chalk that one up to working in a new environment without enough sleep. :-) -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Thu Jan 4 23:52:16 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 4 Jan 2007 14:52:16 -0800 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <459D81FB.20208@voidspace.org.uk> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> <459934B2.8010309@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227561A3E53D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <1d39a8340701041414i36d9dc8bk19f4f5cb7ae7c250@mail.gmail.com> <7AD436E4270DD54A94238001769C2227561A3E53FC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <459D81FB.20208@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C2227561A3E5426@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I've opened CodePlex bug 7011 for this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7011). Feel free to vote on it to raise its visibility! :). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, January 04, 2007 2:39 PM To: Discussion of IronPython Subject: Re: [IronPython] Python Command Line Compiler issues and questions Dino Viehland wrote: > That works for me, I did it a little differently, but basically the same: > > a: > import b > print 'hello' > b.foo() > > b: > print 'goodbye' > def foo(): print 42 > >> ipy pyc.py /target:exe /main:a.py b.py > ... > >> a.exe > goodbye > hello > 42 > > That works even if a.py and b.py aren't available after the compilation. What I thought wasn't working w/ pyc, but maybe was working w/ the simpler one, was the more complex case involving packages: > > a: > import b.c > b.c.d() > > c\ > __init__.py: > d.py: > def d(): print 42 > > I can compile a.py w/ c\__init__.py and get something that "works" but it works only if I run it from the directory that contains c. It works because we just re-compile d.py on the fly. But removing c causes it to break again. Unfortunately I don't think the compiler understands packages right now and it's something we should add to the to-do list. > I thought it worked with makeexe.py, but renaming the package causes the executable to fail. Oh well. We would really like this to work. Michael http://www.voidspace.org.uk/ironpython/index.shtml > > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Patrick O'Brien > Sent: Thursday, January 04, 2007 2:14 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Python Command Line Compiler issues and questions > > On 1/4/07, Dino Viehland > wrote: > I am surprised one is behaving different. It works for me w/ pyc if I keep the package directory on the path, but if I don't then it breaks. > > I'm curious did you include all of your individual package files, or just __init__.py? And were the packages on your path? > > In my case I didn't have a package, merely an extra Python module, imported from the local directory. Something like the following: > > main.py > ====== > > import extra > > print extra.foo() > > > extra.py > ====== > > def foo(): > return "Hello" > > > Does that make sense? Can you duplicate the problem? If not, I can create a real example for you. > > -- > Patrick K. O'Brien > Orbtech http://www.orbtech.com > Schevo http://www.schevo.org > Louie http://www.pylouie.org > > > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.410 / Virus Database: 268.16.5/616 - Release Date: 04/01/2007 _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sum.ergo.code at gmail.com Thu Jan 4 23:54:01 2007 From: sum.ergo.code at gmail.com (Patrick O'Brien) Date: Thu, 4 Jan 2007 16:54:01 -0600 Subject: [IronPython] Python Command Line Compiler issues and questions In-Reply-To: <459D81FB.20208@voidspace.org.uk> References: <1d39a8340612311500j1e7225e3v696137a5d3d729b6@mail.gmail.com> <45984388.1080106@voidspace.org.uk> <459934B2.8010309@voidspace.org.uk> <7AD436E4270DD54A94238001769C2227561A3E53D0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <1d39a8340701041414i36d9dc8bk19f4f5cb7ae7c250@mail.gmail.com> <7AD436E4270DD54A94238001769C2227561A3E53FC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <459D81FB.20208@voidspace.org.uk> Message-ID: <1d39a8340701041454k68ce9af3saf969419a142eb60@mail.gmail.com> On 1/4/07, Michael Foord wrote: > I thought it worked with makeexe.py, but renaming the package causes the > executable to fail. Oh well. > That's actually good to hear because makeexe is really just pyc with fewer options - the basic mechanism is identical. Should make it easier for someone to find the root of the problem. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.muirhead at resolversystems.com Fri Jan 5 11:06:00 2007 From: christian.muirhead at resolversystems.com (Christian Muirhead) Date: Fri, 05 Jan 2007 12:06:00 +0200 Subject: [IronPython] import * in exec Message-ID: <459E2308.1050409@resolversystems.com> Hi - We have a case where we'd like to be able to use "from lib import *" in some code that is exec-ed with a context dictionary. This doesn't appear to work in IronPython: ipy: (func1 is defined in lib.py) >>> ctx = {} >>> exec("from lib import *", ctx) >>> ctx {} >>> func1 cpython: >>> ctx = {} >>> exec("from lib import *", ctx) >>> ctx {massive amount of stuff, including names defined in lib} >>> func1 Traceback (most recent call last): File "", line 1, in func1 NameError: name 'func1' is not defined Thanks, Christian -- Christian Muirhead Resolver Systems christian.muirhead at resolversystems.com Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. From daftspaniel at gmail.com Fri Jan 5 14:38:32 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Fri, 5 Jan 2007 13:38:32 +0000 Subject: [IronPython] Bug? Message-ID: <20253b0c0701050538y4dc0e512ubba3be54419f3606@mail.gmail.com> In the example below, hello is printed but there is no error for the call on the non-existent method. Is this something to do with the timer thread? Cheers, Davy import clr clr.AddReference('System.Windows.Forms') clr.AddReference('System.Drawing') from System import * from System.Drawing import * from System.Drawing.Drawing2D import * from System.Windows.Forms import Application, Button, Form, Label, TextBox, FolderBrowserDialog, Timer, FormWindowState, FormBorderStyle,ImageLayout, MenuStrip, ToolStripMenuItem, ToolStripItem from System.Timers import Timer class ScreenForm(Form): def __init__(self): Form.__init__(self) self.Change = Timer() self.Change.Elapsed += self.ChangeTick self.Change.Interval = 3000 self.Change.Enabled = True def Closeform(self, s, e): self.Change.Enabled = False self.Close() def ChangeTick(self, s, e): print "hello!" self.UpdatePicture() Application.EnableVisualStyles() form = ScreenForm() Application.Run(form) -- Davy Mitchell Blog - http://www.latedecember.com/sites/personal/davy/ Mood News - BBC News Headlines Auto-Classified as Good, Bad or Neutral. http://www.latedecember.com/sites/moodnews/ From fuzzyman at voidspace.org.uk Fri Jan 5 15:17:08 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 05 Jan 2007 14:17:08 +0000 Subject: [IronPython] Case Sensitive Imports Message-ID: <459E5DE4.1040607@voidspace.org.uk> Hello all, I don't recall seeing an email about this, but that would surprise me: so sorry if this is a known issue. (Although I don't see it in the 'differences' document.) IronPython is case-insensitive with regards to imports, whereas CPython is not. To reproduce, create a file in the current directory called 'fiddler.py'. In IronPython do 'import Fiddler' and it will succeed. If you then do 'Fiddler.__file__' it reports that the filename has an uppercase 'F' ! This is quite a change in import semantics and will bite if you have files with similar names in different places on 'sys.path'. Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml From haiboluo at exchange.microsoft.com Fri Jan 5 18:33:15 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Fri, 5 Jan 2007 09:33:15 -0800 Subject: [IronPython] import * in exec In-Reply-To: <459E2308.1050409@resolversystems.com> References: <459E2308.1050409@resolversystems.com> Message-ID: Should be fixed in latest 1.1 alpha (http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=161). The issue is same as http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=5755 Thanks for reporting this. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Christian Muirhead Sent: Friday, January 05, 2007 2:06 AM To: users at lists.ironpython.com Subject: [IronPython] import * in exec Hi - We have a case where we'd like to be able to use "from lib import *" in some code that is exec-ed with a context dictionary. This doesn't appear to work in IronPython: ipy: (func1 is defined in lib.py) >>> ctx = {} >>> exec("from lib import *", ctx) >>> ctx {} >>> func1 cpython: >>> ctx = {} >>> exec("from lib import *", ctx) >>> ctx {massive amount of stuff, including names defined in lib} >>> func1 Traceback (most recent call last): File "", line 1, in func1 NameError: name 'func1' is not defined Thanks, Christian -- Christian Muirhead Resolver Systems christian.muirhead at resolversystems.com Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Fri Jan 5 19:47:10 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 5 Jan 2007 10:47:10 -0800 Subject: [IronPython] Bug? In-Reply-To: <20253b0c0701050538y4dc0e512ubba3be54419f3606@mail.gmail.com> References: <20253b0c0701050538y4dc0e512ubba3be54419f3606@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227561A3E5600@DF-GRTDANE-MSG.exchange.corp.microsoft.com> The System.Timers.Timer class will swallow all exceptions from the timer causing this to happen (and apparently has no way to report those to the user). You could use either System.Windows.Forms.Timer or System.Threading.Timer to avoid that problem assuming there isn't some functionality from System.Timers.Timer that you actually need. Then the unhandled exception will cause Watson to be invoked like a normal CLR app. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Friday, January 05, 2007 5:39 AM To: Discussion of IronPython Subject: [IronPython] Bug? In the example below, hello is printed but there is no error for the call on the non-existent method. Is this something to do with the timer thread? Cheers, Davy import clr clr.AddReference('System.Windows.Forms') clr.AddReference('System.Drawing') from System import * from System.Drawing import * from System.Drawing.Drawing2D import * from System.Windows.Forms import Application, Button, Form, Label, TextBox, FolderBrowserDialog, Timer, FormWindowState, FormBorderStyle,ImageLayout, MenuStrip, ToolStripMenuItem, ToolStripItem from System.Timers import Timer class ScreenForm(Form): def __init__(self): Form.__init__(self) self.Change = Timer() self.Change.Elapsed += self.ChangeTick self.Change.Interval = 3000 self.Change.Enabled = True def Closeform(self, s, e): self.Change.Enabled = False self.Close() def ChangeTick(self, s, e): print "hello!" self.UpdatePicture() Application.EnableVisualStyles() form = ScreenForm() Application.Run(form) -- Davy Mitchell Blog - http://www.latedecember.com/sites/personal/davy/ Mood News - BBC News Headlines Auto-Classified as Good, Bad or Neutral. http://www.latedecember.com/sites/moodnews/ _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From curt at hagenlocher.org Sat Jan 6 00:20:47 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 5 Jan 2007 15:20:47 -0800 Subject: [IronPython] Case Sensitive Imports In-Reply-To: <459E5DE4.1040607@voidspace.org.uk> References: <459E5DE4.1040607@voidspace.org.uk> Message-ID: On 1/5/07, Michael Foord wrote: > > IronPython is case-insensitive with regards to imports, whereas CPython > is not. I'm going to guess that this is platform-specific, and that you happen to be running CPython on a filesystem that's not case-sensitive. -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sat Jan 6 00:22:26 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 05 Jan 2007 23:22:26 +0000 Subject: [IronPython] Case Sensitive Imports In-Reply-To: References: <459E5DE4.1040607@voidspace.org.uk> Message-ID: <459EDDB2.4010201@voidspace.org.uk> Curt Hagenlocher wrote: > On 1/5/07, Michael Foord wrote: >> >> IronPython is case-insensitive with regards to imports, whereas CPython >> is not. > > > I'm going to guess that this is platform-specific, and that you happen > to be > running CPython on a filesystem that's not case-sensitive. > Which does not happen when I run the same code on a case-insensitive file system under CPython... hence the email. :-) Michael http://www.voidspace.org.uk/ironpython/index.shtml > -- > Curt Hagenlocher > curt at hagenlocher.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.410 / Virus Database: 268.16.6/617 - Release Date: 05/01/2007 From curt at hagenlocher.org Sat Jan 6 00:26:29 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 5 Jan 2007 15:26:29 -0800 Subject: [IronPython] Case Sensitive Imports In-Reply-To: <459EDDB2.4010201@voidspace.org.uk> References: <459E5DE4.1040607@voidspace.org.uk> <459EDDB2.4010201@voidspace.org.uk> Message-ID: On 1/5/07, Michael Foord wrote: > > Curt Hagenlocher wrote: > > > > I'm going to guess that this is platform-specific, and that you happen > > to be running CPython on a filesystem that's not case-sensitive. > > Which does not happen when I run the same code on a case-insensitive > file system under CPython... hence the email. :-) Doh! I read what you wrote backwards :( -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Sat Jan 6 00:30:32 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 5 Jan 2007 15:30:32 -0800 Subject: [IronPython] Case Sensitive Imports In-Reply-To: <459EDDB2.4010201@voidspace.org.uk> References: <459E5DE4.1040607@voidspace.org.uk> <459EDDB2.4010201@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C2227561A3E5773@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Yep, definitely a bug... I've opened CodePlex Work Item 7050 for this (and tentatively marked it for v1.1, I think it should be an easy fix). http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7050 Thanks for reporting this! -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, January 05, 2007 3:22 PM To: Discussion of IronPython Subject: Re: [IronPython] Case Sensitive Imports Curt Hagenlocher wrote: > On 1/5/07, Michael Foord wrote: >> >> IronPython is case-insensitive with regards to imports, whereas CPython >> is not. > > > I'm going to guess that this is platform-specific, and that you happen > to be > running CPython on a filesystem that's not case-sensitive. > Which does not happen when I run the same code on a case-insensitive file system under CPython... hence the email. :-) Michael http://www.voidspace.org.uk/ironpython/index.shtml > -- > Curt Hagenlocher > curt at hagenlocher.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.410 / Virus Database: 268.16.6/617 - Release Date: 05/01/2007 _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Sat Jan 6 01:23:39 2007 From: fuzzyman at voidspace.org.uk (fuzzyman at voidspace.org.uk) Date: Sat, 6 Jan 2007 00:23:39 +0000 Subject: [IronPython] Profiling IronPython Message-ID: <20070106002338.SUSQ219.aamtaout01-winn.ispmail.ntl.com@[192.168.1.100]> {ran_emo} There's a new (short) article on profiling IronPython code : * `Profiling IronPython `_ It shows a couple of example timers for use in profiling for the purposes of optimising IronPython code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sat Jan 6 01:58:17 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 06 Jan 2007 00:58:17 +0000 Subject: [IronPython] Traceback Stack Bugs Message-ID: <459EF429.8070202@voidspace.org.uk> Hello team, Whilst optimising Resolver we discovered a bug in the handling of traceback objects with IronPython. The following code behaves differently under IronPython and CPython : import sys def extract_tb(): tb = sys.exc_info()[2] stackInfo = [] while tb: f = tb.tb_frame lineno = tb.tb_lineno co = f.f_code filename = co.co_filename stackInfo.append((filename, lineno)) tb = tb.tb_next return stackInfo try: raise ValueError('stuff') except: print extract_tb() try: raise ValueError('stuff') except: print extract_tb() Under IronPython : [] [] Under CPython : [('C:\\Python Projects\\modules in progress\\ironpython\\tracebackBug.py', 15)] [('C:\\Python Projects\\modules in progress\\ironpython\\tracebackBug.py', 20)] If you exec a compiled code object which raises an exception (instead of directly raising the error) the CPython traceback starts with the Python code, whereas the IronPython traceback starts with the code object and goes no further back. (So a different bug...) The bug I was actually trying to expose is that in Resolver we were finding that the traceback objects were not being cleared out - the stack (using the extract_tb function above) was getting longer and longer. Adding an explicit sys.clear_exc() solved our problem, but it foxed us for a while. Unfortunately I can't reproduce this bug easily - but you can see that something screwy is going on. Michael http://www.voidspace.org.uk/ironpython/index.shtml From haiboluo at exchange.microsoft.com Sat Jan 6 02:01:26 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Fri, 5 Jan 2007 17:01:26 -0800 Subject: [IronPython] Traceback Stack Bugs In-Reply-To: <459EF429.8070202@voidspace.org.uk> References: <459EF429.8070202@voidspace.org.uk> Message-ID: This is related to http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=2912. We are currently working on it. Thanks for reporting this. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, January 05, 2007 4:58 PM To: Discussion of IronPython Subject: [IronPython] Traceback Stack Bugs Hello team, Whilst optimising Resolver we discovered a bug in the handling of traceback objects with IronPython. The following code behaves differently under IronPython and CPython : import sys def extract_tb(): tb = sys.exc_info()[2] stackInfo = [] while tb: f = tb.tb_frame lineno = tb.tb_lineno co = f.f_code filename = co.co_filename stackInfo.append((filename, lineno)) tb = tb.tb_next return stackInfo try: raise ValueError('stuff') except: print extract_tb() try: raise ValueError('stuff') except: print extract_tb() Under IronPython : [] [] Under CPython : [('C:\\Python Projects\\modules in progress\\ironpython\\tracebackBug.py', 15)] [('C:\\Python Projects\\modules in progress\\ironpython\\tracebackBug.py', 20)] If you exec a compiled code object which raises an exception (instead of directly raising the error) the CPython traceback starts with the Python code, whereas the IronPython traceback starts with the code object and goes no further back. (So a different bug...) The bug I was actually trying to expose is that in Resolver we were finding that the traceback objects were not being cleared out - the stack (using the extract_tb function above) was getting longer and longer. Adding an explicit sys.clear_exc() solved our problem, but it foxed us for a while. Unfortunately I can't reproduce this bug easily - but you can see that something screwy is going on. Michael http://www.voidspace.org.uk/ironpython/index.shtml _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Sat Jan 6 13:28:28 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 06 Jan 2007 12:28:28 +0000 Subject: [IronPython] Traceback Stack Bugs In-Reply-To: References: <459EF429.8070202@voidspace.org.uk> Message-ID: <459F95EC.9030000@voidspace.org.uk> Haibo Luo wrote: > This is related to http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=2912. We are currently working on it. > Cool. Is this the same bug as the following : Code : import sys def extract_tb(): tb = sys.exc_info()[2] stackInfo = [] while tb: f = tb.tb_frame lineno = tb.tb_lineno co = f.f_code filename = co.co_filename stackInfo.append((filename, lineno)) tb = tb.tb_next return stackInfo code = """ raise NameError('An Error') """ codeobj = compile(code, '', 'exec') try: exec(codeobj, {}) except: print extract_tb() CPython output : [('c:\\Python Projects\\modules in progress\\ironpython\\tracebackBug.py', 20), ('', 2)] IronPython output : [('', 2)] I still can't reproduce the bug we found with Resolver where the traceback stack would grow and grow... Michael http://www.voidspace.org.uk/ironpython/index.shtml > Thanks for reporting this. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, January 05, 2007 4:58 PM > To: Discussion of IronPython > Subject: [IronPython] Traceback Stack Bugs > > Hello team, > > Whilst optimising Resolver we discovered a bug in the handling of > traceback objects with IronPython. > > The following code behaves differently under IronPython and CPython : > > import sys > def extract_tb(): > tb = sys.exc_info()[2] > stackInfo = [] > while tb: > f = tb.tb_frame > lineno = tb.tb_lineno > co = f.f_code > filename = co.co_filename > stackInfo.append((filename, lineno)) > tb = tb.tb_next > return stackInfo > > try: > raise ValueError('stuff') > except: > print extract_tb() > > try: > raise ValueError('stuff') > except: > print extract_tb() > > > Under IronPython : > > [] > [] > > > Under CPython : > > [('C:\\Python Projects\\modules in > progress\\ironpython\\tracebackBug.py', 15)] > [('C:\\Python Projects\\modules in > progress\\ironpython\\tracebackBug.py', 20)] > > If you exec a compiled code object which raises an exception (instead of > directly raising the error) the CPython traceback starts with the Python > code, whereas the IronPython traceback starts with the code object and > goes no further back. (So a different bug...) > > The bug I was actually trying to expose is that in Resolver we were > finding that the traceback objects were not being cleared out - the > stack (using the extract_tb function above) was getting longer and > longer. Adding an explicit sys.clear_exc() solved our problem, but it > foxed us for a while. > > Unfortunately I can't reproduce this bug easily - but you can see that > something screwy is going on. > > Michael > http://www.voidspace.org.uk/ironpython/index.shtml > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From slide.o.mix at gmail.com Sun Jan 7 02:58:53 2007 From: slide.o.mix at gmail.com (slide) Date: Sat, 06 Jan 2007 18:58:53 -0700 Subject: [IronPython] C Extensions In-Reply-To: <459EF429.8070202@voidspace.org.uk> References: <459EF429.8070202@voidspace.org.uk> Message-ID: <1168135133.4256.2.camel@springfield.meanies> As it has come up on the list several times, I was wondering if anyone had given any thought to implementing an interface such that C extensions could be used with FePy I know that FePy would have to implement and export (and do some other magic) the C registration functions, etc that the C extensions call. On Windows specifically, I can envision that the import table of the C extension would need to be modified to not rely on libpython, as well as redirecting the addresses of the imported Python API functions to FePy functions which do the same thing, seems somewhat complicated to me. Is it even feasible to do? slide From sanxiyn at gmail.com Sun Jan 7 09:45:17 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sun, 7 Jan 2007 17:45:17 +0900 Subject: [IronPython] C Extensions In-Reply-To: <1168135133.4256.2.camel@springfield.meanies> References: <459EF429.8070202@voidspace.org.uk> <1168135133.4256.2.camel@springfield.meanies> Message-ID: <5b0248170701070045w3c2389ffwaa54475f106fa408@mail.gmail.com> 2007/1/7, slide : > As it has come up on the list several times, I was wondering if anyone > had given any thought to implementing an interface such that C > extensions could be used with FePy I know that FePy would have to > implement and export (and do some other magic) the C registration > functions, etc that the C extensions call. On Windows specifically, I > can envision that the import table of the C extension would need to be > modified to not rely on libpython, as well as redirecting the addresses > of the imported Python API functions to FePy functions which do the same > thing, seems somewhat complicated to me. Is it even feasible to do? If I understood correctly, Phalanger (PHP implementation for .NET) does something similar to support PHP's C extensions, so I think it's certainly possible. That doesn't mean it would be easy in any way. No, I don't have slightest idea how to implement it. -- Seo Sanghyeon From daftspaniel at gmail.com Sun Jan 7 14:21:01 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Sun, 7 Jan 2007 13:21:01 +0000 Subject: [IronPython] Bug? In-Reply-To: <7AD436E4270DD54A94238001769C2227561A3E5600@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <20253b0c0701050538y4dc0e512ubba3be54419f3606@mail.gmail.com> <7AD436E4270DD54A94238001769C2227561A3E5600@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <20253b0c0701070521l7a8c2e9buc9734e425d12584e@mail.gmail.com> On 1/5/07, Dino Viehland wrote: > The System.Timers.Timer class will swallow all exceptions from the timer >causing this to happen (and apparently has no way to report those to the user). Thanks Dino for the explanation - long term I will switch to Forms.Timer. Cheers, Davy -- Davy Mitchell Blog - http://www.latedecember.com/sites/personal/davy/ Mood News - BBC News Headlines Auto-Classified as Good, Bad or Neutral. http://www.latedecember.com/sites/moodnews/ taylayout for IronPython - http://code.google.com/p/taylayout/ From slide.o.mix at gmail.com Sun Jan 7 14:53:26 2007 From: slide.o.mix at gmail.com (Slide) Date: Sun, 7 Jan 2007 06:53:26 -0700 Subject: [IronPython] C Extensions In-Reply-To: <5b0248170701070045w3c2389ffwaa54475f106fa408@mail.gmail.com> References: <459EF429.8070202@voidspace.org.uk> <1168135133.4256.2.camel@springfield.meanies> <5b0248170701070045w3c2389ffwaa54475f106fa408@mail.gmail.com> Message-ID: On 1/7/07, Sanghyeon Seo wrote: > 2007/1/7, slide : > > As it has come up on the list several times, I was wondering if anyone > > had given any thought to implementing an interface such that C > > extensions could be used with FePy I know that FePy would have to > > implement and export (and do some other magic) the C registration > > functions, etc that the C extensions call. On Windows specifically, I > > can envision that the import table of the C extension would need to be > > modified to not rely on libpython, as well as redirecting the addresses > > of the imported Python API functions to FePy functions which do the same > > thing, seems somewhat complicated to me. Is it even feasible to do? > > If I understood correctly, Phalanger (PHP implementation for .NET) does > something similar to support PHP's C extensions, so I think it's certainly > possible. That doesn't mean it would be easy in any way. > > No, I don't have slightest idea how to implement it. > > -- > Seo Sanghyeon It looks like Phalanger uses CLI/C++ to interact with C/C++ extensions. At this point that would restrict its usage to Windows, but I guess it might be a good start. slide From kfarmer at thuban.org Mon Jan 8 10:54:20 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 8 Jan 2007 01:54:20 -0800 Subject: [IronPython] C Extensions Message-ID: This might be somewhat interesting: http://blogs.msdn.com/jmstall/archive/2007/01/06/Typesafe-GetProcAddress.aspx Of course, it might entail certain security permissions, so may not be useful in certain cases. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Slide Sent: Sunday, January 07, 2007 5:53 AM To: Discussion of IronPython Subject: Re: [IronPython] C Extensions On 1/7/07, Sanghyeon Seo wrote: > 2007/1/7, slide : > > As it has come up on the list several times, I was wondering if anyone > > had given any thought to implementing an interface such that C > > extensions could be used with FePy I know that FePy would have to > > implement and export (and do some other magic) the C registration > > functions, etc that the C extensions call. On Windows specifically, I > > can envision that the import table of the C extension would need to be > > modified to not rely on libpython, as well as redirecting the addresses > > of the imported Python API functions to FePy functions which do the same > > thing, seems somewhat complicated to me. Is it even feasible to do? > > If I understood correctly, Phalanger (PHP implementation for .NET) does > something similar to support PHP's C extensions, so I think it's certainly > possible. That doesn't mean it would be easy in any way. > > No, I don't have slightest idea how to implement it. > > -- > Seo Sanghyeon It looks like Phalanger uses CLI/C++ to interact with C/C++ extensions. At this point that would restrict its usage to Windows, but I guess it might be a good start. slide _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dwoogle at gmail.com Mon Jan 8 15:55:00 2007 From: dwoogle at gmail.com (dwelden) Date: Mon, 08 Jan 2007 14:55:00 -0000 Subject: [IronPython] C Extensions In-Reply-To: <1168135133.4256.2.camel@springfield.meanies> References: <459EF429.8070202@voidspace.org.uk> <1168135133.4256.2.camel@springfield.meanies> Message-ID: <1168268100.161496.47580@51g2000cwl.googlegroups.com> SWIG can generate wrappers for C#. Perhaps that could form the foundation for C module wrapping for FePy. On Jan 6, 7:58 pm, slide wrote: > As it has come up on the list several times, I was wondering if anyone > had given any thought to implementing an interface such that C > extensions could be used with FePy I know that FePy would have to > implement and export (and do some other magic) the C registration > functions, etc that the C extensions call. On Windows specifically, I > can envision that the import table of the C extension would need to be > modified to not rely on libpython, as well as redirecting the addresses > of the imported Python API functions to FePy functions which do the same > thing, seems somewhat complicated to me. Is it even feasible to do? > > slide > > _______________________________________________ > users mailing list > u... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com From slide.o.mix at gmail.com Mon Jan 8 16:09:43 2007 From: slide.o.mix at gmail.com (Slide) Date: Mon, 8 Jan 2007 08:09:43 -0700 Subject: [IronPython] C Extensions In-Reply-To: <1168268100.161496.47580@51g2000cwl.googlegroups.com> References: <459EF429.8070202@voidspace.org.uk> <1168135133.4256.2.camel@springfield.meanies> <1168268100.161496.47580@51g2000cwl.googlegroups.com> Message-ID: I think the main issue with C extensions, is that they call back into the Python runtime library to register themselves, this would have to be intercepted by FePy in order for things to work correctly. slide On 1/8/07, dwelden wrote: > SWIG can generate wrappers for C#. Perhaps that could form the > foundation for C module wrapping for FePy. > > On Jan 6, 7:58 pm, slide wrote: > > As it has come up on the list several times, I was wondering if anyone > > had given any thought to implementing an interface such that C > > extensions could be used with FePy I know that FePy would have to > > implement and export (and do some other magic) the C registration > > functions, etc that the C extensions call. On Windows specifically, I > > can envision that the import table of the C extension would need to be > > modified to not rely on libpython, as well as redirecting the addresses > > of the imported Python API functions to FePy functions which do the same > > thing, seems somewhat complicated to me. Is it even feasible to do? > > > > slide > > > > _______________________________________________ > > users mailing list > > u... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at exchange.microsoft.com Mon Jan 8 19:06:44 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 8 Jan 2007 10:06:44 -0800 Subject: [IronPython] C Extensions In-Reply-To: References: <459EF429.8070202@voidspace.org.uk> <1168135133.4256.2.camel@springfield.meanies> <1168268100.161496.47580@51g2000cwl.googlegroups.com> Message-ID: <7AD436E4270DD54A94238001769C2227597B606C59@DF-GRTDANE-MSG.exchange.corp.microsoft.com> This part isn't so bad - you'd just need to have a library which has all the same exports as Python that the C extension would call into instead of calling into the real Python. The wrapper library would then translate the C Python extension interface into calls into the IronPython runtime. I think the real difficult part is that the C extensions don't always do operations via function calls to opaque blocks of data. Instead the libraries directly expose memory (e.g. the ref count field which is a macro) and the C extensions directly access that memory. So somehow that needs to be dealt with. One option would be to re-build the C extension against a new version of the header files that don't directly access memory (if it's only ref counting that might be real easy). Another option might be to use SEH & only hand out memory to the C extension that is read-only and then handle & continue the exceptions on writes. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Slide Sent: Monday, January 08, 2007 7:10 AM To: Discussion of IronPython Subject: Re: [IronPython] C Extensions I think the main issue with C extensions, is that they call back into the Python runtime library to register themselves, this would have to be intercepted by FePy in order for things to work correctly. slide On 1/8/07, dwelden wrote: > SWIG can generate wrappers for C#. Perhaps that could form the > foundation for C module wrapping for FePy. > > On Jan 6, 7:58 pm, slide wrote: > > As it has come up on the list several times, I was wondering if anyone > > had given any thought to implementing an interface such that C > > extensions could be used with FePy I know that FePy would have to > > implement and export (and do some other magic) the C registration > > functions, etc that the C extensions call. On Windows specifically, I > > can envision that the import table of the C extension would need to be > > modified to not rely on libpython, as well as redirecting the addresses > > of the imported Python API functions to FePy functions which do the same > > thing, seems somewhat complicated to me. Is it even feasible to do? > > > > slide > > > > _______________________________________________ > > users mailing list > > u... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From illium37 at yahoo.com Mon Jan 8 23:35:24 2007 From: illium37 at yahoo.com (illium) Date: Mon, 8 Jan 2007 14:35:24 -0800 (PST) Subject: [IronPython] IronPython vs Cpython import speeds. Message-ID: <20070108223524.9316.qmail@web53803.mail.yahoo.com> Hi, I'm in the process of porting a project from CPython to IronPython. This is my first time using IronPython, so I'm not completely sure what to expect. After getting over the inital configuration hurdles, I got my program to execute normally within IronPython, and moved on to performance testing, attempting to feel all warm and fuzzy about how much faster my code was running in shiny new IronPtyhon. However, I immediately noticed a major difference, to the worse, in speed performance between the two engines. In order to isolate the problem I started adding time stamp traces into the code, and found that the majority of the perfomance loss was occuring during import calls. So I made this little test file, importspeedtest.py: import time print time.time() import sys, os, string, re print time.time() Then made this little batch file to compare them... importspeedtest.bat: @echo IronPython @echo ---------- @echo %time% @c:\IronPython\ipy.exe c:\PythonSourceFiles\importspeedtest.py @echo %time% @echo ---------- @echo Python 2.5 @echo ---------- @echo %time% @c:\Python25\python.exe c:\PythonSourceFiles\importspeedtest.py @echo %time% @echo ---------- The results: IronPython ---------- 14:23:55.09 63303863036.3 63303863037.5 14:23:57.73 ---------- Python 2.5 ---------- 14:23:57.80 1168295037.9 1168295037.91 14:23:57.91 ---------- The total execution time in IronPython was 2.64 seconds, and in CPython was .09 seconds. The amount of time to execute the line "import sys, os, string, re" in IronPython was 1.2 seconds, and in CPython .01 seconds. In actual use in my project I found that start to finish, with the overhead of launching the embedded engine, loading and executeing the source file, doing the processing on my sample data, and exiting, using IronPython it took 5 seconds, with 2 seconds of that time being the import calls, while the same process/code using Python 2.5 completed in only 1.5 seconds round trip, with .02 seconds used for the import calls. So.. on to my question: Is this normal, or am I doing something wrong? Is there a way to optimize my code for faster loading in IronPython? Any assistance/insight would be greatly appreciated, as I really want to move over to IronPython, so that I can embedd it into my c# app, instead of calling it via the commandline as I'm currently doing with CPython. But this kind of performance loss makes it unusable at the moment. Thanks, Troy Howard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dinov at exchange.microsoft.com Tue Jan 9 00:13:51 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 8 Jan 2007 15:13:51 -0800 Subject: [IronPython] IronPython vs Cpython import speeds. In-Reply-To: <20070108223524.9316.qmail@web53803.mail.yahoo.com> References: <20070108223524.9316.qmail@web53803.mail.yahoo.com> Message-ID: <7AD436E4270DD54A94238001769C2227597B606EB9@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Unfortunately import speed is one of the areas where CPython is drastically faster than IronPython. The primary reason for this is that we will compile all the modules that get imported during importation which slows things down. One possible work around is to use the pyc tutorial although that's known to not work with packages. Also you can vote on this bug (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=358) which will enable us caching the modules on disk (like CPython caches .pyc files) so that import time will be greatly improved. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of illium Sent: Monday, January 08, 2007 2:35 PM To: users at lists.ironpython.com Subject: [IronPython] IronPython vs Cpython import speeds. Hi, I'm in the process of porting a project from CPython to IronPython. This is my first time using IronPython, so I'm not completely sure what to expect. After getting over the inital configuration hurdles, I got my program to execute normally within IronPython, and moved on to performance testing, attempting to feel all warm and fuzzy about how much faster my code was running in shiny new IronPtyhon. However, I immediately noticed a major difference, to the worse, in speed performance between the two engines. In order to isolate the problem I started adding time stamp traces into the code, and found that the majority of the perfomance loss was occuring during import calls. So I made this little test file, importspeedtest.py: import time print time.time() import sys, os, string, re print time.time() Then made this little batch file to compare them... importspeedtest.bat: @echo IronPython @echo ---------- @echo %time% @c:\IronPython\ipy.exe c:\PythonSourceFiles\importspeedtest.py @echo %time% @echo ---------- @echo Python 2.5 @echo ---------- @echo %time% @c:\Python25\python.exe c:\PythonSourceFiles\importspeedtest.py @echo %time% @echo ---------- The results: IronPython ---------- 14:23:55.09 63303863036.3 63303863037.5 14:23:57.73 ---------- Python 2.5 ---------- 14:23:57.80 1168295037.9 1168295037.91 14:23:57.91 ---------- The total execution time in IronPython was 2.64 seconds, and in CPython was .09 seconds. The amount of time to execute the line "import sys, os, string, re" in IronPython was 1.2 seconds, and in CPython .01 seconds. In actual use in my project I found that start to finish, with the overhead of launching the embedded engine, loading and executeing the source file, doing the processing on my sample data, and exiting, using IronPython it took 5 seconds, with 2 seconds of that time being the import calls, while the same process/code using Python 2.5 completed in only 1.5 seconds round trip, with .02 seconds used for the import calls. So.. on to my question: Is this normal, or am I doing something wrong? Is there a way to optimize my code for faster loading in IronPython? Any assistance/insight would be greatly appreciated, as I really want to move over to IronPython, so that I can embedd it into my c# app, instead of calling it via the commandline as I'm currently doing with CPython. But this kind of performance loss makes it unusable at the moment. Thanks, Troy Howard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Tue Jan 9 04:29:21 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 9 Jan 2007 12:29:21 +0900 Subject: [IronPython] IronPython question on German newsgroup Message-ID: <5b0248170701081929u1ac44f56x32ab3a60f7f29f44@mail.gmail.com> Someone who speaks German may want to reply to this: http://groups.google.com/group/de.comp.lang.python/browse_thread/thread/33ab9d8fd0c978e7 If machine translation is any help, OP wants to convert string to array of bytes. Okay, may I repeat my feature request to have clr.GetString and clr.GetBytes? (Last sent Oct 2006.) -- Seo Sanghyeon From fdarweesh at gmail.com Tue Jan 9 11:54:48 2007 From: fdarweesh at gmail.com (Feraas Darweesh) Date: Tue, 9 Jan 2007 14:54:48 +0400 Subject: [IronPython] Welcome to the "users" mailing list In-Reply-To: References: Message-ID: <644e498e0701090254n632a5193j971dd880c93e8c1e@mail.gmail.com> Hello: The finally statment always gives me an error, can any one help me on this #- ==== sample code def Divide(self): try: result = x / y except ZeroDivisionError: print "division by zero!" Divide(self): try: result = x / y except ZeroDivisionError: print "division by zero!" except ZeroDivisionError: else: print "result is", result finally: print "executing finally clause" # === ending of the code === Note: I'm using VS2005 as IDE Best Regards From sanxiyn at gmail.com Tue Jan 9 12:11:26 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 9 Jan 2007 20:11:26 +0900 Subject: [IronPython] Welcome to the "users" mailing list In-Reply-To: <644e498e0701090254n632a5193j971dd880c93e8c1e@mail.gmail.com> References: <644e498e0701090254n632a5193j971dd880c93e8c1e@mail.gmail.com> Message-ID: <5b0248170701090311x1b5cc81em4a898fe7f43de69@mail.gmail.com> 2007/1/9, Feraas Darweesh : > The finally statment always gives me an error, can any one help me on this What error do you get? (The code you pasted is surely in error. Why do you have "Divide(self)" tacked after print statement, for example?) Also, it is (correctly) a SyntaxError to use both except and finally in Python 2.4. Use -X:Python25 to get 2.5 behaviour. -- Seo Sanghyeon From fdarweesh at gmail.com Tue Jan 9 12:55:04 2007 From: fdarweesh at gmail.com (Feraas Darweesh) Date: Tue, 9 Jan 2007 15:55:04 +0400 Subject: [IronPython] Welcome to the "users" mailing list In-Reply-To: <5b0248170701090311x1b5cc81em4a898fe7f43de69@mail.gmail.com> References: <644e498e0701090254n632a5193j971dd880c93e8c1e@mail.gmail.com> <5b0248170701090311x1b5cc81em4a898fe7f43de69@mail.gmail.com> Message-ID: <644e498e0701090355m1756dcbdrb1d27111a3dc16d@mail.gmail.com> Sorry this duplication happened after changing the message format # === start === def Divide(self,x,y): try: result = x / y except ZeroDivisionError: MessageBox.Show("division by zero!") else: MessageBox.Show("result is "+result.ToString()) finally: MessageBox.Show("This Is Finally Statment") # === End ==== On 1/9/07, Sanghyeon Seo wrote: > 2007/1/9, Feraas Darweesh : > > The finally statment always gives me an error, can any one help me on this > > What error do you get? (The code you pasted is surely in error. Why do you > have "Divide(self)" tacked after print statement, for example?) > > Also, it is (correctly) a SyntaxError to use both except and finally > in Python 2.4. > Use -X:Python25 to get 2.5 behaviour. > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at exchange.microsoft.com Tue Jan 9 20:28:21 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 9 Jan 2007 11:28:21 -0800 Subject: [IronPython] IronPython question on German newsgroup In-Reply-To: <5b0248170701081929u1ac44f56x32ab3a60f7f29f44@mail.gmail.com> References: <5b0248170701081929u1ac44f56x32ab3a60f7f29f44@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C2227597B607158@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks for staying on top of this feature request. I've gone ahead and opened work item #7159 for this. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Monday, January 08, 2007 7:29 PM To: Discussion of IronPython Subject: [IronPython] IronPython question on German newsgroup Someone who speaks German may want to reply to this: http://groups.google.com/group/de.comp.lang.python/browse_thread/thread/33ab9d8fd0c978e7 If machine translation is any help, OP wants to convert string to array of bytes. Okay, may I repeat my feature request to have clr.GetString and clr.GetBytes? (Last sent Oct 2006.) -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From xmlhacker at gmail.com Wed Jan 10 19:47:49 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Wed, 10 Jan 2007 11:47:49 -0700 Subject: [IronPython] C Extensions In-Reply-To: <1168268100.161496.47580@51g2000cwl.googlegroups.com> References: <459EF429.8070202@voidspace.org.uk> <1168135133.4256.2.camel@springfield.meanies> <1168268100.161496.47580@51g2000cwl.googlegroups.com> Message-ID: On 1/8/07, dwelden wrote: > > SWIG can generate wrappers for C#. Perhaps that could form the > foundation for C module wrapping for FePy. SWIG would be by far and beyond the easiest way to get from point A to point B in regards to integrating C-based Python extension libraries into the IronPython mix. It uses P/Invoke, but with full access to the source coupled with the fact that the CPython extension libraries can be built on every major platform, then there really isn't any platform specific issues to worry about. Worth making note of, [via the News section @ http://www.swig.org/] *2006/11/13* SWIG-1.3.30 has been released. This release adds support for R > and directors for C# amongst a round of bug fixes. via http://www.swig.org/Doc1.3/CSharp.html#csharp_directors The SWIG directors feature adds extra code to the generated C# proxy classes > that enable these classes to be used in cross-language polymorphism. > Essentially, it enables unmanaged C++ code to call back into managed code > for virtual methods so that a C# class can derive from a wrapped C++ class. While this would be of no direct assistance to a C-based library, and therefore the CPython extension libraries, it does provide some nice functionality for C++/C# developers to interact with one another, so it seemed worth mentioning none-the-less. Also worth noting: As of Beta 1 of Phalanger 2.0, there is direct support for Mono. Not sure how much support is actually provided, or how they went about integrating the support that is provided, but none-the-less, its there and might be worth taking a look at in regards to reusing some of their code base. http://www.codeplex.com/Phalanger/Release/ProjectReleases.aspx -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfugate at microsoft.com Thu Jan 11 00:33:50 2007 From: dfugate at microsoft.com (Dave Fugate) Date: Wed, 10 Jan 2007 15:33:50 -0800 Subject: [IronPython] Dynamic Web Service Helpers Sample Message-ID: <7346A825E148B049A9AD1D3ED46A2D910CC7FA0DAF@NA-EXMSG-C106.redmond.corp.microsoft.com> We're happy to announce the release of another sample, Dynamic Web Service Helpers, which shows how web services can be consumed from IronPython in an easy-to-use manner. The sample can be downloaded from http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=47 (IronPython-1.0.1-Samples-WebServices.zip) and details on what's provided can be found at http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title=Samples . Have fun! The IronPython Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Thu Jan 11 01:53:14 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 11 Jan 2007 09:53:14 +0900 Subject: [IronPython] Dynamic Web Service Helpers Sample In-Reply-To: <7346A825E148B049A9AD1D3ED46A2D910CC7FA0DAF@NA-EXMSG-C106.redmond.corp.microsoft.com> References: <7346A825E148B049A9AD1D3ED46A2D910CC7FA0DAF@NA-EXMSG-C106.redmond.corp.microsoft.com> Message-ID: <5b0248170701101653n730d31f8yc571309358c10123@mail.gmail.com> 2007/1/11, Dave Fugate : > We're happy to announce the release of another sample, Dynamic Web Service > Helpers, which shows how web services can be consumed from IronPython in an > easy-to-use manner. The sample can be downloaded from > http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=47 > (IronPython-1.0.1-Samples-WebServices.zip) and details on > what's provided can be found at > http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title=Samples For Mono users: This sample does not contain a makefile, but you can build using a Visual Studio 2005 solution file. Mono now provides xbuild which works like msbuild. xbuild is not complete, but it's complete enough to build this sample. (As of Mono 1.2.2.) If your Mono environment doesn't have xbuild or you want to build manually, following line should do: gmcs -t:library -r:IronPython.dll -r:System.Web.dll -r:System.Web.Services.dll -recurse:sources/*.cs RSS sample runs, others involving WSDL don't. I'm not sure why. Worth investigating. -- Seo Sanghyeon From NoNuschk at gmx.net Thu Jan 11 21:00:40 2007 From: NoNuschk at gmx.net (=?iso-8859-1?Q?=22Bernhard_M=E4der=22?=) Date: Thu, 11 Jan 2007 21:00:40 +0100 Subject: [IronPython] Exposing C++/CLI template classes to ironpython In-Reply-To: <7AD436E4270DD54A94238001769C2227561A3E5393@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <20061231171516.66620@gmx.net> <7AD436E4270DD54A94238001769C2227561A3E5393@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <20070111200040.89500@gmx.net> Thanks for the answer! -------- Original-Nachricht -------- Datum: Thu, 4 Jan 2007 13:06:36 -0800 Von: Dino Viehland An: Discussion of IronPython Betreff: Re: [IronPython] Exposing C++/CLI template classes to ironpython > Unfortunately you can't the CPython extension libraries w/ IronPython. > You could do it w/ templates instead of macros and force the instantiation of > the generic public class like: > > template class NativeData { > public: > T foo; > }; > > template public ref class GenericData { > private: > NativeData *data; > }; > > public ref class GDI : GenericData {}; > public ref class GDC : GenericData {}; > > That seems to export both the GenericData and GenericData types > (even if GDI/GDC are private) though maybe there's a better way to force > the GenericData type to get exported. You're right, it's definitely a good thing to NOT use macros. :-) I'm now doing something similar to the scheme you provided. But I need to have additional marshalling stuff to get from the wrapper back to the native classes (and vice-versa). This tends to lead to quite some boilerplate code, but I'm willing to take that. Three more questings though: 1) In your example, GenericData<> only exports those functions that are declared virtual or used somewhere in the code. I guess that's something C++/CLI specific, but is there a way to circumvent this? 2) The [Pythonname] attribute doesn't seem to work for me. When, e.g., I'm deriving from ISequence, the AddSequence() method does not become __add__ in python. What can possibly go wrong there? Are these attributes even intended as public interfaces? 3) Is there an easy way to add free standing functions? Currently, I'm doing this by either adding delegates, using a callable object or creating static methods in a class. Delegates are very difficult to use in a generic way and static methods are difficult to separate into different compiler-units, so I'm mostly using callable objects. Thanks! Bernhard -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From xmlhacker at gmail.com Thu Jan 11 22:56:23 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Thu, 11 Jan 2007 14:56:23 -0700 Subject: [IronPython] Dynamic Web Service Helpers Sample In-Reply-To: <7346A825E148B049A9AD1D3ED46A2D910CC7FA0DAF@NA-EXMSG-C106.redmond.corp.microsoft.com> References: <7346A825E148B049A9AD1D3ED46A2D910CC7FA0DAF@NA-EXMSG-C106.redmond.corp.microsoft.com> Message-ID: Oh, *VERY* nice! This exact subject came up in an IRC discussion in which frustration was being expressed in regards to using SOAP with standard Python. I suggested they look into using IP with the .NET WS-* stack, but came up with only a handful of samples to point him towards. This will help. Thanks! On 1/10/07, Dave Fugate wrote: > > We're happy to announce the release of another sample, Dynamic Web > Service Helpers, which shows how web services can be consumed from > IronPython in an easy-to-use manner. The sample can be downloaded from > http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=47( > IronPython-1.0.1-Samples-WebServices.zip) and details on what's provided > can be found at > http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title=Samples. > > > > Have fun! > > > > The IronPython Team > > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Thu Jan 11 22:57:36 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Thu, 11 Jan 2007 14:57:36 -0700 Subject: [IronPython] Dynamic Web Service Helpers Sample In-Reply-To: <5b0248170701101653n730d31f8yc571309358c10123@mail.gmail.com> References: <7346A825E148B049A9AD1D3ED46A2D910CC7FA0DAF@NA-EXMSG-C106.redmond.corp.microsoft.com> <5b0248170701101653n730d31f8yc571309358c10123@mail.gmail.com> Message-ID: Hey Seo :) >> RSS sample runs, others involving WSDL don't. I'm not sure why. Worth investigating. Have you uncovered anything in this regard? -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ygutfreund at draper.com Thu Jan 11 23:05:34 2007 From: ygutfreund at draper.com (Gutfreund, Yechezkal) Date: Thu, 11 Jan 2007 17:05:34 -0500 Subject: [IronPython] Loading XAML files In-Reply-To: Message-ID: <98B94F0758D7394CA057AE4898CBC85E02B3E761@exchbk1.draper.com> I am using Blend to create XAML files and testing out the design there. Then but all my code is done via Python using the Tutorials "avalon.py" module. It works fine. Except for one annoying glitch. true WPF Xaml files need to specify the class name: But for some reason the LoadXAML() call chokes on this: >>> w.Content = LoadXaml("WebWrapper.xaml") 'Class' attribute does not exist in XML namespace 'http://schemas.microsoft.com/winfx/2006/xaml' namespace. Line '6' Position '2'. at IronPython.Hosting.PythonEngine.ExecuteToConsole(String text, EngineModule engineModule, IDictionary`2 locals) at IronPython.Hosting.PythonEngine.ExecuteToConsole(String text) at IronPythonConsole.PythonCommandLine.DoOneInteractive() at IronPythonConsole.PythonCommandLine.b__6(Boolean& continueInteractionArgument) at IronPythonConsole.PythonCommandLine.TryInteractiveAction(InteractiveActi on interactiveAction, Boolean& continueInteraction) SystemError: 'Class' attribute does not exist in XML namespace 'http://schemas.microsoft.com/winfx/2006/xaml' namespace. Line '6' Position '2'. Is there a fix. I really like the ability to have simple test code and classes in the WPF project, but have the true implementation in IronPython. BTW, here is a wish list item. To be able to have direct support of IronPython scripting in Blend, so that I can single step and debug the scripts, and interactive try things out. They you would have a real Flash killer. Dr. Yechezkal Gutfreund -------------- next part -------------- An HTML attachment was scrubbed... URL: From garage_dba at hotmail.com Fri Jan 12 00:25:30 2007 From: garage_dba at hotmail.com (Bill64bits) Date: Thu, 11 Jan 2007 17:25:30 -0600 Subject: [IronPython] Dynamic Web Service Helpers Sample References: <7346A825E148B049A9AD1D3ED46A2D910CC7FA0DAF@NA-EXMSG-C106.redmond.corp.microsoft.com><5b0248170701101653n730d31f8yc571309358c10123@mail.gmail.com> Message-ID: I had to rename the math.py to wsmath.py due to path issues. Then it worked fine upon "import wsmath" inside ipy. ----- Original Message ----- From: M. David Peterson To: Discussion of IronPython Sent: Thursday, January 11, 2007 3:57 PM Subject: Re: [IronPython] Dynamic Web Service Helpers Sample Hey Seo :) >> RSS sample runs, others involving WSDL don't. I'm not sure why. Worth investigating. Have you uncovered anything in this regard? -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 ------------------------------------------------------------------------------ _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvm_cop at spamcop.net Fri Jan 12 04:10:21 2007 From: jvm_cop at spamcop.net (J. Merrill) Date: Thu, 11 Jan 2007 22:10:21 -0500 Subject: [IronPython] Loading XAML files In-Reply-To: <98B94F0758D7394CA057AE4898CBC85E02B3E761@exchbk1.draper.co m> References: <98B94F0758D7394CA057AE4898CBC85E02B3E761@exchbk1.draper.com> Message-ID: <7.0.1.0.2.20070111215605.07a936a0@wheresmymailserver.com> At 05:05 PM 1/11/2007, Gutfreund, Yechezkal wrote (in part) >I am using Blend to create XAML files and testing out the design there. Then but all my code is done via Python using the Tutorials "avalon.py" module. > >It works fine. Except for one annoying glitch. > >But for some reason the LoadXAML() call chokes on this: > > >>>> w.Content = LoadXaml("WebWrapper.xaml") >'Class' attribute does not exist in XML namespace 'http://schemas.microsoft.com/winfx/2006/xaml' namespace. Line '6' Position '2'. I know almost nothing about XAML, but that error seems to be coming not from anything related to IronPython but rather from some .Net XML parser. Have you attempted to confirm the validity of the file by loading using any other development tool? An XML validation tool should be able to determine the accuracy of the statement that there's no "Class" attribute in that namespace. (Is it possible that the attribute name is "class" not "Class" ?) J. Merrill / Analytical Software Corp -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbk.lists at gmail.com Fri Jan 12 05:01:55 2007 From: mbk.lists at gmail.com (Mike Krell) Date: Thu, 11 Jan 2007 21:01:55 -0700 Subject: [IronPython] Full forms editor with VS Express? Message-ID: Hey all, My understanding is that it's not possible to use the full IronPython integration with VS Express. Given that, what is the best way to use the full power of the forms editor from VS express but code the forms and the rest of the app in IronPython? I don't want to use any of the (mostly incomplete) alternate form editors that are freely available. Is WPF / XAML a help here? Mike From xmlhacker at gmail.com Fri Jan 12 06:53:33 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Thu, 11 Jan 2007 22:53:33 -0700 Subject: [IronPython] Dynamic Web Service Helpers Sample In-Reply-To: References: <7346A825E148B049A9AD1D3ED46A2D910CC7FA0DAF@NA-EXMSG-C106.redmond.corp.microsoft.com> <5b0248170701101653n730d31f8yc571309358c10123@mail.gmail.com> Message-ID: On 1/11/07, Bill64bits wrote: > > I had to rename the math.py to wsmath.py due to path issues. > Then it worked fine upon "import wsmath" inside ipy. > > Nice! Thanks for the tip! -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbk.lists at gmail.com Fri Jan 12 11:01:09 2007 From: mbk.lists at gmail.com (Mike Krell) Date: Fri, 12 Jan 2007 03:01:09 -0700 Subject: [IronPython] Full forms editor with VS Express? Message-ID: Hey all, My understanding is that it's not possible to use the full IronPython integration with VS Express. Given that, what is the best way to use the full power of the forms editor from VS express but code the forms and the rest of the app in IronPython? I don't want to use any of the (mostly incomplete) alternate form editors that are freely available. Is WPF / XAML a help here? Mike From fuzzyman at voidspace.org.uk Fri Jan 12 11:19:49 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 12 Jan 2007 10:19:49 +0000 Subject: [IronPython] Full forms editor with VS Express? In-Reply-To: References: Message-ID: <45A760C5.8030101@voidspace.org.uk> Mike Krell wrote: > Hey all, > > My understanding is that it's not possible to use the full IronPython > integration with VS Express. Given that, what is the best way to use > the full power of the forms editor from VS express but code the forms > and the rest of the app in IronPython? I don't want to use any of the > (mostly incomplete) alternate form editors that are freely available. > At Resolver we have the full version of Visual Studio, but we still use the forms editor to create C# code. We use it just to create the GUI layer (mainly for our dialogs), making sure that all the attributes are set to protected. Then we subclass in IronPython. Having all the dialog sources in C# makes sure we are never tempted to modify them by hand. :-) This works very well for us. Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > Is WPF / XAML a help here? > > Mike > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From mbk.lists at gmail.com Fri Jan 12 12:21:14 2007 From: mbk.lists at gmail.com (Mike Krell) Date: Fri, 12 Jan 2007 04:21:14 -0700 Subject: [IronPython] Full forms editor with VS Express? In-Reply-To: <45A760C5.8030101@voidspace.org.uk> References: <45A760C5.8030101@voidspace.org.uk> Message-ID: On 1/12/07, Michael Foord wrote: > At Resolver we have the full version of Visual Studio, but we still use > the forms editor to create C# code. > > We use it just to create the GUI layer (mainly for our dialogs), making > sure that all the attributes are set to protected. Then we subclass in > IronPython. I'm still getting used to Forms as well as IPy. Could you give a quick example or details about what the dividing line is, i.e., how much work does the IPy subclass take on? How much of the dialog event handlers is handled in IPy? Mike From bernd.viehmann at ascom-ac.de Fri Jan 12 12:47:02 2007 From: bernd.viehmann at ascom-ac.de (Bernd Viehmann) Date: Fri, 12 Jan 2007 12:47:02 +0100 Subject: [IronPython] Q: How to resize an System.Array ? Message-ID: <45A77536.9070808@ascom-ac.de> Hi, I have some problems with using >System.Array<-instances in ipy. I have found a way to create them, but not how to use the :-). Basically i want 2 use a MemoryStream in the following way ( kind of C#-way :-) ) : dataHeap = System.Array[System.Byte] dataHeap.Resize(dataHeap,4096) bytesRead = reader.Read(dataHeap, 0, PiceLength) But ipy does not understand me. I receive the message: dataHeap.Resize(dataHeap,4096) TypeError: no callable targets, if this is a generic method make sure specify the type parameters Any ideas who to use the mem-stream? Thanks much. Bernd From fuzzyman at voidspace.org.uk Fri Jan 12 13:51:42 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 12 Jan 2007 12:51:42 +0000 Subject: [IronPython] Full forms editor with VS Express? In-Reply-To: References: <45A760C5.8030101@voidspace.org.uk> Message-ID: <45A7845E.5020604@voidspace.org.uk> Mike Krell wrote: > On 1/12/07, Michael Foord wrote: > > >> At Resolver we have the full version of Visual Studio, but we still use >> the forms editor to create C# code. >> >> We use it just to create the GUI layer (mainly for our dialogs), making >> sure that all the attributes are set to protected. Then we subclass in >> IronPython. >> > > I'm still getting used to Forms as well as IPy. Could you give a > quick example or details about what the dividing line is, i.e., how > much work does the IPy subclass take on? How much of the dialog event > handlers is handled in IPy? > None. :-) We merely do the layout in the forms editor and make the components protected rather than private. *All* the logic is done with IronPython. Admittedly this works well for dialogs where you have no sub windows etc, but you could design these separately. Michael > Mike > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From ygutfreund at draper.com Fri Jan 12 14:21:54 2007 From: ygutfreund at draper.com (Gutfreund, Yechezkal) Date: Fri, 12 Jan 2007 08:21:54 -0500 Subject: [IronPython] Loading XAML files In-Reply-To: <7.0.1.0.2.20070111215605.07a936a0@wheresmymailserver.com> Message-ID: <98B94F0758D7394CA057AE4898CBC85E02B3EAC4@exchbk1.draper.com> All of that XAML code is generated by BLEND. Both Blend and VS-Studio understand that x:Class is a member of the namespace. But I am also not a WPF .NET guru. What I suspect is that when I use ipy, I am not using the same libraries that do XML and XAML loading as when I use Blend and VS-Studio. Ideas? ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill Sent: Thursday, January 11, 2007 10:10 PM To: Discussion of IronPython Subject: Re: [IronPython] Loading XAML files At 05:05 PM 1/11/2007, Gutfreund, Yechezkal wrote (in part) I am using Blend to create XAML files and testing out the design there. Then but all my code is done via Python using the Tutorials "avalon.py" module. It works fine. Except for one annoying glitch. But for some reason the LoadXAML() call chokes on this: >>> w.Content = LoadXaml("WebWrapper.xaml") 'Class' attribute does not exist in XML namespace ' http://schemas.microsoft.com/winfx/2006/xaml ' namespace. Line '6' Position '2'. I know almost nothing about XAML, but that error seems to be coming not from anything related to IronPython but rather from some .Net XML parser. Have you attempted to confirm the validity of the file by loading using any other development tool? An XML validation tool should be able to determine the accuracy of the statement that there's no "Class" attribute in that namespace. (Is it possible that the attribute name is "class" not "Class" ?) J. Merrill / Analytical Software Corp -------------- next part -------------- An HTML attachment was scrubbed... URL: From wierob at gmx.de Fri Jan 12 15:02:29 2007 From: wierob at gmx.de (wierob) Date: Fri, 12 Jan 2007 15:02:29 +0100 Subject: [IronPython] Dyamic Web Service and Security Message-ID: <45A794F5.4070905@gmx.de> Hi, How can I configure username/password and ssl (trusted server certificates) in a dynamic web service client? regards robert From sum.ergo.code at gmail.com Fri Jan 12 17:16:14 2007 From: sum.ergo.code at gmail.com (Patrick O'Brien) Date: Fri, 12 Jan 2007 10:16:14 -0600 Subject: [IronPython] Full forms editor with VS Express? In-Reply-To: <45A7845E.5020604@voidspace.org.uk> References: <45A760C5.8030101@voidspace.org.uk> <45A7845E.5020604@voidspace.org.uk> Message-ID: <1d39a8340701120816q13f34f03jdd213db873436367@mail.gmail.com> On 1/12/07, Michael Foord wrote: > > > We merely do the layout in the forms editor and make the components > protected rather than private. *All* the logic is done with IronPython. > > Admittedly this works well for dialogs where you have no sub windows > etc, but you could design these separately. > I know you are busy with the book, but even an extremely simple example of what you described would be a terrific blog post and addition to your tutorial series. I'll even buy you the beverage of your choice at Pycon as a "thank you". How does that sound for arm-twisting? :-) -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Louie http://www.pylouie.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From haiboluo at exchange.microsoft.com Fri Jan 12 17:50:28 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Fri, 12 Jan 2007 08:50:28 -0800 Subject: [IronPython] Q: How to resize an System.Array ? In-Reply-To: <45A77536.9070808@ascom-ac.de> References: <45A77536.9070808@ascom-ac.de> Message-ID: dateHeap is a type in your code snippet below. The following code works, but I am not 100% sure it is expected to see the exception thrown for the last line. Dino? >>> import System >>> t = System.Array[System.Byte] >>> a = t([1,2]) >>> System.Array.Resize[System.Byte](a, 10) System.Byte[](1, 2, 0, 0, 0, 0, 0, 0, 0, 0) >>> System.Array.Resize(a, 10) Traceback (most recent call last): File , line 0, in ##27 TypeError: no callable targets, if this is a generic method make sure specify the type parameters -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Bernd Viehmann Sent: Friday, January 12, 2007 3:47 AM To: users at lists.ironpython.com Subject: [IronPython] Q: How to resize an System.Array ? Hi, I have some problems with using >System.Array<-instances in ipy. I have found a way to create them, but not how to use the :-). Basically i want 2 use a MemoryStream in the following way ( kind of C#-way :-) ) : dataHeap = System.Array[System.Byte] dataHeap.Resize(dataHeap,4096) bytesRead = reader.Read(dataHeap, 0, PiceLength) But ipy does not understand me. I receive the message: dataHeap.Resize(dataHeap,4096) TypeError: no callable targets, if this is a generic method make sure specify the type parameters Any ideas who to use the mem-stream? Thanks much. Bernd _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From mbk.lists at gmail.com Fri Jan 12 18:36:53 2007 From: mbk.lists at gmail.com (Mike Krell) Date: Fri, 12 Jan 2007 10:36:53 -0700 Subject: [IronPython] Full forms editor with VS Express? In-Reply-To: <45A7845E.5020604@voidspace.org.uk> References: <45A760C5.8030101@voidspace.org.uk> <45A7845E.5020604@voidspace.org.uk> Message-ID: On 1/12/07, Michael Foord wrote: > > [How] much work does the IPy subclass take on? How much of the dialog event > > handlers is handled in IPy? > > > None. :-) I think you meant "All." :-) > We merely do the layout in the forms editor and make the components > protected rather than private. *All* the logic is done with IronPython. > > Admittedly this works well for dialogs where you have no sub windows > etc, but you could design these separately. OK, so if I understand you correctly, you don't even define event handlers from the forms manager. You just expose all the controls on the dialog by making them protected instead of private. This allows you to subclass the dialog from within IPy, and the IPy code defines and implements the event handlers. Is that right? Mike From fuzzyman at voidspace.org.uk Fri Jan 12 19:03:42 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 12 Jan 2007 18:03:42 +0000 Subject: [IronPython] Full forms editor with VS Express? In-Reply-To: References: <45A760C5.8030101@voidspace.org.uk> <45A7845E.5020604@voidspace.org.uk> Message-ID: <45A7CD7E.2050201@voidspace.org.uk> Mike Krell wrote: > On 1/12/07, Michael Foord wrote: > >>> [How] much work does the IPy subclass take on? How much of the dialog event >>> handlers is handled in IPy? >>> >>> >> None. :-) >> > > I think you meant "All." :-) > > >> We merely do the layout in the forms editor and make the components >> protected rather than private. *All* the logic is done with IronPython. >> >> Admittedly this works well for dialogs where you have no sub windows >> etc, but you could design these separately. >> > > OK, so if I understand you correctly, you don't even define event > handlers from the forms manager. You just expose all the controls on > the dialog by making them protected instead of private. This allows > you to subclass the dialog from within IPy, and the IPy code defines > and implements the event handlers. Is that right? > > Right in both cases. :-) Michael > Mike > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From haiboluo at exchange.microsoft.com Fri Jan 12 19:36:34 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Fri, 12 Jan 2007 10:36:34 -0800 Subject: [IronPython] Loading XAML files In-Reply-To: <98B94F0758D7394CA057AE4898CBC85E02B3EAC4@exchbk1.draper.com> References: <7.0.1.0.2.20070111215605.07a936a0@wheresmymailserver.com> <98B94F0758D7394CA057AE4898CBC85E02B3EAC4@exchbk1.draper.com> Message-ID: I know little about WPF. I found http://msdn2.microsoft.com/en-us/library/ms752309.aspx talking about x:Class attribute. Removing x:class line, I am able to load the UserControl. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Gutfreund, Yechezkal Sent: Friday, January 12, 2007 5:22 AM To: Discussion of IronPython Cc: Vlad Vinogradsky Subject: Re: [IronPython] Loading XAML files All of that XAML code is generated by BLEND. Both Blend and VS-Studio understand that x:Class is a member of the namespace. But I am also not a WPF .NET guru. What I suspect is that when I use ipy, I am not using the same libraries that do XML and XAML loading as when I use Blend and VS-Studio. Ideas? ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill Sent: Thursday, January 11, 2007 10:10 PM To: Discussion of IronPython Subject: Re: [IronPython] Loading XAML files At 05:05 PM 1/11/2007, Gutfreund, Yechezkal wrote (in part) I am using Blend to create XAML files and testing out the design there. Then but all my code is done via Python using the Tutorials "avalon.py" module. It works fine. Except for one annoying glitch. But for some reason the LoadXAML() call chokes on this: >>> w.Content = LoadXaml("WebWrapper.xaml") 'Class' attribute does not exist in XML namespace ' http://schemas.microsoft.com/winfx/2006/xaml' namespace. Line '6' Position '2'. I know almost nothing about XAML, but that error seems to be coming not from anything related to IronPython but rather from some .Net XML parser. Have you attempted to confirm the validity of the file by loading using any other development tool? An XML validation tool should be able to determine the accuracy of the statement that there's no "Class" attribute in that namespace. (Is it possible that the attribute name is "class" not "Class" ?) J. Merrill / Analytical Software Corp -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Fri Jan 12 19:42:33 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 12 Jan 2007 10:42:33 -0800 Subject: [IronPython] Q: How to resize an System.Array ? In-Reply-To: References: <45A77536.9070808@ascom-ac.de> Message-ID: <7AD436E4270DD54A94238001769C22275C6FC6F539@DF-GRTDANE-MSG.exchange.corp.microsoft.com> dataHeap = System.Array[System.Byte] is just remembering the array type, not creating the actual array instance. What I think you want is: import System dataHeap = System.Array.CreateInstance(System.Byte, 4096) # creates a byte array 4k long if you want to then resize the array: dataHeap = Array.Resize[System.Byte](dataHeap, newSize) # resizes the array to the new size Both of those seem to work. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Haibo Luo Sent: Friday, January 12, 2007 8:50 AM To: Discussion of IronPython Subject: Re: [IronPython] Q: How to resize an System.Array ? dateHeap is a type in your code snippet below. The following code works, but I am not 100% sure it is expected to see the exception thrown for the last line. Dino? >>> import System >>> t = System.Array[System.Byte] >>> a = t([1,2]) >>> System.Array.Resize[System.Byte](a, 10) System.Byte[](1, 2, 0, 0, 0, 0, 0, 0, 0, 0) >>> System.Array.Resize(a, 10) Traceback (most recent call last): File , line 0, in ##27 TypeError: no callable targets, if this is a generic method make sure specify the type parameters -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Bernd Viehmann Sent: Friday, January 12, 2007 3:47 AM To: users at lists.ironpython.com Subject: [IronPython] Q: How to resize an System.Array ? Hi, I have some problems with using >System.Array<-instances in ipy. I have found a way to create them, but not how to use the :-). Basically i want 2 use a MemoryStream in the following way ( kind of C#-way :-) ) : dataHeap = System.Array[System.Byte] dataHeap.Resize(dataHeap,4096) bytesRead = reader.Read(dataHeap, 0, PiceLength) But ipy does not understand me. I receive the message: dataHeap.Resize(dataHeap,4096) TypeError: no callable targets, if this is a generic method make sure specify the type parameters Any ideas who to use the mem-stream? Thanks much. Bernd _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From wierob at gmx.de Fri Jan 12 19:48:15 2007 From: wierob at gmx.de (wierob) Date: Fri, 12 Jan 2007 19:48:15 +0100 Subject: [IronPython] Java Web Service Message-ID: <45A7D7EF.90707@gmx.de> Hi I have a Java web service implemented as an EJB (J2EE 1.4), which exposes the following method. /** * Web service operation */ public String sayHello(final String arg) throws java.rmi.RemoteException { return "Hello " + arg + "!!!"; } It works fine with a Java client, but I can't call the method from IronPython. import clr clr.AddReference("DynamicWebServiceHelpers.dll") from DynamicWebServiceHelpers import WebService ws = WebService.Load(...) ws.sayHello("Du") The call to sayHello throws an exception TypeError: expected sayHello, got str So what's the mistake? regards robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From nytrokiss at gmail.com Fri Jan 12 20:32:33 2007 From: nytrokiss at gmail.com (James Matthews) Date: Fri, 12 Jan 2007 14:32:33 -0500 Subject: [IronPython] Ide Message-ID: <8a6b8e350701121132o5b2595b9p9bbec2b663e5714f@mail.gmail.com> Is there any good references and/or books on iron python as well as a good ide -- http://www.goldwatches.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Fri Jan 12 21:11:20 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Fri, 12 Jan 2007 12:11:20 -0800 Subject: [IronPython] Java Web Service Message-ID: It might be useful to post a wsdl which reproduces this. ________________________________ From: users-bounces at lists.ironpython.com on behalf of wierob Sent: Fri 1/12/2007 10:48 AM To: users at lists.ironpython.com Subject: [IronPython] Java Web Service Hi I have a Java web service implemented as an EJB (J2EE 1.4), which exposes the following method. /** * Web service operation */ public String sayHello(final String arg) throws java.rmi.RemoteException { return "Hello " + arg + "!!!"; } It works fine with a Java client, but I can't call the method from IronPython. import clr clr.AddReference("DynamicWebServiceHelpers.dll") from DynamicWebServiceHelpers import WebService ws = WebService.Load(...) ws.sayHello("Du") The call to sayHello throws an exception TypeError: expected sayHello, got str So what's the mistake? regards robert -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3742 bytes Desc: not available URL: From fuzzyman at voidspace.org.uk Fri Jan 12 21:22:00 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 12 Jan 2007 20:22:00 +0000 Subject: [IronPython] Ide In-Reply-To: <8a6b8e350701121132o5b2595b9p9bbec2b663e5714f@mail.gmail.com> References: <8a6b8e350701121132o5b2595b9p9bbec2b663e5714f@mail.gmail.com> Message-ID: <45A7EDE8.8090501@voidspace.org.uk> James Matthews wrote: > Is there any good references and/or books on iron python as well as a > good ide I'm currently using Wing, which whilst it doesn't have native IronPython support is one of the best Python IDEs. I'm working on a book, but I don't think there are any available currently which focus on IronPython. Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > > -- > http://www.goldwatches.com > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From fuzzyman at voidspace.org.uk Sat Jan 13 01:36:20 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 13 Jan 2007 00:36:20 +0000 Subject: [IronPython] Full forms editor with VS Express? In-Reply-To: <1d39a8340701120816q13f34f03jdd213db873436367@mail.gmail.com> References: <45A760C5.8030101@voidspace.org.uk> <45A7845E.5020604@voidspace.org.uk> <1d39a8340701120816q13f34f03jdd213db873436367@mail.gmail.com> Message-ID: <45A82984.1060506@voidspace.org.uk> Patrick O'Brien wrote: > On 1/12/07, *Michael Foord* > wrote: > > > We merely do the layout in the forms editor and make the components > protected rather than private. *All* the logic is done with > IronPython. > > Admittedly this works well for dialogs where you have no sub windows > etc, but you could design these separately. > > > I know you are busy with the book, but even an extremely simple > example of what you described would be a terrific blog post and > addition to your tutorial series. I'll even buy you the beverage of > your choice at Pycon as a "thank you". How does that sound for > arm-twisting? :-) Well... since my computer died and my editor just started mentioning deadlines it's going to be difficult. On the other hand, I want that beer. ;-) Michael http://www.voidspace.org.uk/python/articles.shtml > > -- > Patrick K. O'Brien > Orbtech http://www.orbtech.com > Schevo http://www.schevo.org > Louie http://www.pylouie.org > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From wierob at gmx.de Sat Jan 13 10:44:38 2007 From: wierob at gmx.de (wierob) Date: Sat, 13 Jan 2007 10:44:38 +0100 Subject: [IronPython] Java Web Service Message-ID: <45A8AA06.9010709@gmx.de> > > It might be useful to post a wsdl which reproduces this here you are: -------------- next part -------------- An HTML attachment was scrubbed... URL: From daftspaniel at gmail.com Sun Jan 14 22:25:25 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Sun, 14 Jan 2007 21:25:25 +0000 Subject: [IronPython] taylayout 00.00.15 released Message-ID: <20253b0c0701141325t4a201c56t4a0586cd2db7da1b@mail.gmail.com> TayLayout Release http://code.google.com/p/taylayout/downloads/list New This Release * Wordsearch generator sample (80% functional) * More controls supported (listbox, webbrowser) * More compound controls * Controls can now be right-aligned * Plenty of bug fixes TayLayout is a more sophisticated version of the flow layout - you can add controls to a panel or form and it takes care of positioning them. Controls are added in a Left to Right order until you specify that a new line is required. More info available at http://docs.google.com/View?docid=dd59dk39_2jh3xf9 Thanks, Davy Mitchell From nicolas.zielinski at transatel.com Mon Jan 15 10:36:48 2007 From: nicolas.zielinski at transatel.com (Nicolas Zielinski) Date: Mon, 15 Jan 2007 10:36:48 +0100 Subject: [IronPython] IronPython+Mono+DCOM ? Message-ID: <9AC4FE3392C56F4886FE8E7CA616B652586ECF@xchge.hq.transatel.com> Hello, I would like to know if it's possible to make a DCOM client using IronPython and Mono (under linux) or if there are known incompatibilites ? Thanks in advance. Regards, Nicolas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd.viehmann at ascom-ac.de Mon Jan 15 14:27:17 2007 From: bernd.viehmann at ascom-ac.de (Bernd Viehmann) Date: Mon, 15 Jan 2007 14:27:17 +0100 Subject: [IronPython] IronPython question on German newsgroup In-Reply-To: <7AD436E4270DD54A94238001769C2227597B607158@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <5b0248170701081929u1ac44f56x32ab3a60f7f29f44@mail.gmail.com> <7AD436E4270DD54A94238001769C2227597B607158@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <45AB8135.4070304@ascom-ac.de> Dino Viehland schrieb: > Thanks for staying on top of this feature request. I've gone ahead and opened work item #7159 for this. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo > Sent: Monday, January 08, 2007 7:29 PM > To: Discussion of IronPython > Subject: [IronPython] IronPython question on German newsgroup > > Someone who speaks German may want to reply to this: > http://groups.google.com/group/de.comp.lang.python/browse_thread/thread/33ab9d8fd0c978e7 > > If machine translation is any help, OP wants to convert string to > array of bytes. > > Okay, may I repeat my feature request to have clr.GetString and > clr.GetBytes? (Last sent Oct 2006.) > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > Hi, not necessary. I got already the answer by asking here. Thanks much for your help :-) regards Bernd From ygutfreund at draper.com Mon Jan 15 16:02:46 2007 From: ygutfreund at draper.com (Gutfreund, Yechezkal) Date: Mon, 15 Jan 2007 10:02:46 -0500 Subject: [IronPython] Loading XAML files In-Reply-To: Message-ID: <98B94F0758D7394CA057AE4898CBC85E02B7317F@exchbk1.draper.com> Yes, I mentioned in my first message that removing x:Class made it work. The problem is that every time I use Blend, or test the program in Blend or VS-Studio, blend will put it back in, and besides, VS-Studio and Blend both need it for default code-behinds. It is a pain to have to keep two parallel copies by hand. I can't see why the .LoadXAML() is does not do the same scheme checks that are begin done by Blend and VS-studio. That is why I am writing this list. Should I call it a bug? ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Haibo Luo Sent: Friday, January 12, 2007 1:37 PM To: Discussion of IronPython Subject: Re: [IronPython] Loading XAML files I know little about WPF. I found http://msdn2.microsoft.com/en-us/library/ms752309.aspx talking about x:Class attribute. Removing x:class line, I am able to load the UserControl. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Gutfreund, Yechezkal Sent: Friday, January 12, 2007 5:22 AM To: Discussion of IronPython Cc: Vlad Vinogradsky Subject: Re: [IronPython] Loading XAML files All of that XAML code is generated by BLEND. Both Blend and VS-Studio understand that x:Class is a member of the namespace. But I am also not a WPF .NET guru. What I suspect is that when I use ipy, I am not using the same libraries that do XML and XAML loading as when I use Blend and VS-Studio. Ideas? ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill Sent: Thursday, January 11, 2007 10:10 PM To: Discussion of IronPython Subject: Re: [IronPython] Loading XAML files At 05:05 PM 1/11/2007, Gutfreund, Yechezkal wrote (in part) I am using Blend to create XAML files and testing out the design there. Then but all my code is done via Python using the Tutorials "avalon.py" module. It works fine. Except for one annoying glitch. But for some reason the LoadXAML() call chokes on this: >>> w.Content = LoadXaml("WebWrapper.xaml") 'Class' attribute does not exist in XML namespace ' http://schemas.microsoft.com/winfx/2006/xaml ' namespace. Line '6' Position '2'. I know almost nothing about XAML, but that error seems to be coming not from anything related to IronPython but rather from some .Net XML parser. Have you attempted to confirm the validity of the file by loading using any other development tool? An XML validation tool should be able to determine the accuracy of the statement that there's no "Class" attribute in that namespace. (Is it possible that the attribute name is "class" not "Class" ?) J. Merrill / Analytical Software Corp -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael_sweeney at agilent.com Mon Jan 15 18:58:26 2007 From: michael_sweeney at agilent.com (michael_sweeney at agilent.com) Date: Mon, 15 Jan 2007 10:58:26 -0700 Subject: [IronPython] Calling Python objects from C#? Message-ID: <64B0479F895F194587EE70276364C5C601DA2FD0@wcosmb02.cos.agilent.com> Hi All, My apology if this has been asked before... I have searched for several examples and did not find what I was looking for. My question is what is the best way to interact with Python objects from within C#? I need to call functions, capture the return value and get/set attributes from within C#. I have tried several ways and ended up with this example for calling functions, but it generates an exception saying it does not know what "attr" is. Here is my example: File MyExample.py: class MyClass(object): def __init__(self): self.attr = 500.0 def DoWork(self): print "Attr = ", self.attr return self.attr File Program.cs: using System; using IronPython.Runtime; using IronPython.Runtime.Types; using IronPython.Runtime.Operations; using IronPython.Hosting; using IronPython.Modules; namespace IPyExample { class Program { static void Main(string[] args) { PythonEngine engine = new PythonEngine(); EngineModule module = engine.CreateModule("MyExample", true); try { engine.ExecuteFile("MyExample.py", module); } catch (Exception ex) { Console.WriteLine("Failed to execute Example.py file"); Console.WriteLine("Exception: {0}", ex.Message); return; } // Get the Python Class from the module's global list UserType ptype = module.Globals["MyClass"] as UserType; // Create an instance of the object object myclass = ptype.AllocateObject(); // Call the method - Using Ops.Invoke() Ops.Invoke(myclass, SymbolTable.StringToId("DoWork")); // Call the same method - Using UserType.Invoke() object rtnValue = ptype.Invoke(myclass, SymbolTable.StringToId("DoWork")); Console.WriteLine("DoWork return value = {0}\n", rtnValue); } } } Exception: C:\Documents and Settings\sweeneym\My Documents\Visual Studio 2005\Projects\ATF. IP\IPyExample\bin\Debug>IPYExample Attr = Unhandled Exception: System.MissingMemberException: attr at IronPython.Runtime.Types.UserType.GetAttr(ICallerContext context, Object self, SymbolId name) in C:\Development\Ir onPython-1.1\Src\IronPython\Runtime\Types\UserType.cs:line 370 at IronPython.Runtime.Operations.Ops.GetAttr(ICallerContext context, Object o, SymbolId name) in C:\Development\IronP ython-1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1644 at DoWork$f1##4(FunctionEnvironment4Dictionary , Object ) at IronPython.Runtime.Calls.CallTarget1.Invoke(Object arg0) at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) in C:\Development\IronPython-1.1\Src\ IronPython\Runtime\Calls\Function.Generated.cs:line 127 at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object[] args) in C:\Development\IronPython-1.1\Sr c\IronPython\Runtime\Calls\Function.Generated.cs:line 138 at IronPython.Runtime.Calls.PythonFunction.CallInstance(ICallerContext context, Object instance, Object[] args) in C: \Development\IronPython-1.1\Src\IronPython\Runtime\Calls\Function.cs:line 389 at IronPython.Runtime.Calls.Method.Call(ICallerContext context, Object[] args) in C:\Development\IronPython-1.1\Src\I ronPython\Runtime\Calls\Function.cs:line 972 at IronPython.Runtime.Operations.Ops.Call(Object func, Object[] args) in C:\Development\IronPython-1.1\Src\IronPython \Runtime\Operations\Ops.cs:line 1414 at IronPython.Runtime.Types.DynamicType.Invoke(Object target, SymbolId name, Object[] args) in C:\Development\IronPyt hon-1.1\Src\IronPython\Runtime\Types\DynamicType.cs:line 1010 at IronPython.Runtime.Operations.Ops.Invoke(Object target, SymbolId name, Object[] args) in C:\Development\IronPython -1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1760 at IPyExample.Program.Main(String[] args) in C:\Documents and Settings\sweeneym\My Documents\Visual Studio 2005\Proje cts\ATF.IP\IPyExample\Program.cs:line 35 ------------------------------------------------------------ Michael A. Sweeney email: michael_sweeney at agilent.com Agilent Technologies phone: (509) 921-4395 MS:3WU-222 fax: (509) 921-3991 24001 E. Mission Ave. Liberty Lake, WA 99019 USA ------------------------------------------------------------ From dinov at exchange.microsoft.com Mon Jan 15 20:45:45 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 15 Jan 2007 11:45:45 -0800 Subject: [IronPython] Calling Python objects from C#? In-Reply-To: <64B0479F895F194587EE70276364C5C601DA2FD0@wcosmb02.cos.agilent.com> References: <64B0479F895F194587EE70276364C5C601DA2FD0@wcosmb02.cos.agilent.com> Message-ID: <7AD436E4270DD54A94238001769C222762C9EF23DC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I think the problem is that AllocateObject is equivalent to calling mytype.__new__ which is not quite what you want - you want the equivalent of doing mytype () or mytype.__call__() I would change this to: // Get the Python Class from the module's global list object ptype = module.Globals["MyClass"]; // Create an instance of the object object myclass = Ops.Call(ptype); Not only is it more correct it gets rid of the direct dependency on UserType (for example your code wouldn't have worked w/ an old-style class or if a user had done MyClass = System.SomeTypeThatHasADoWorkMethod). >From there I think your Ops.Invoke calls should work (although I haven't tried to make sure). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com Sent: Monday, January 15, 2007 9:58 AM To: users at lists.ironpython.com Subject: [IronPython] Calling Python objects from C#? Hi All, My apology if this has been asked before... I have searched for several examples and did not find what I was looking for. My question is what is the best way to interact with Python objects from within C#? I need to call functions, capture the return value and get/set attributes from within C#. I have tried several ways and ended up with this example for calling functions, but it generates an exception saying it does not know what "attr" is. Here is my example: File MyExample.py: class MyClass(object): def __init__(self): self.attr = 500.0 def DoWork(self): print "Attr = ", self.attr return self.attr File Program.cs: using System; using IronPython.Runtime; using IronPython.Runtime.Types; using IronPython.Runtime.Operations; using IronPython.Hosting; using IronPython.Modules; namespace IPyExample { class Program { static void Main(string[] args) { PythonEngine engine = new PythonEngine(); EngineModule module = engine.CreateModule("MyExample", true); try { engine.ExecuteFile("MyExample.py", module); } catch (Exception ex) { Console.WriteLine("Failed to execute Example.py file"); Console.WriteLine("Exception: {0}", ex.Message); return; } // Get the Python Class from the module's global list UserType ptype = module.Globals["MyClass"] as UserType; // Create an instance of the object object myclass = ptype.AllocateObject(); // Call the method - Using Ops.Invoke() Ops.Invoke(myclass, SymbolTable.StringToId("DoWork")); // Call the same method - Using UserType.Invoke() object rtnValue = ptype.Invoke(myclass, SymbolTable.StringToId("DoWork")); Console.WriteLine("DoWork return value = {0}\n", rtnValue); } } } Exception: C:\Documents and Settings\sweeneym\My Documents\Visual Studio 2005\Projects\ATF. IP\IPyExample\bin\Debug>IPYExample Attr = Unhandled Exception: System.MissingMemberException: attr at IronPython.Runtime.Types.UserType.GetAttr(ICallerContext context, Object self, SymbolId name) in C:\Development\Ir onPython-1.1\Src\IronPython\Runtime\Types\UserType.cs:line 370 at IronPython.Runtime.Operations.Ops.GetAttr(ICallerContext context, Object o, SymbolId name) in C:\Development\IronP ython-1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1644 at DoWork$f1##4(FunctionEnvironment4Dictionary , Object ) at IronPython.Runtime.Calls.CallTarget1.Invoke(Object arg0) at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) in C:\Development\IronPython-1.1\Src\ IronPython\Runtime\Calls\Function.Generated.cs:line 127 at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object[] args) in C:\Development\IronPython-1.1\Sr c\IronPython\Runtime\Calls\Function.Generated.cs:line 138 at IronPython.Runtime.Calls.PythonFunction.CallInstance(ICallerContext context, Object instance, Object[] args) in C: \Development\IronPython-1.1\Src\IronPython\Runtime\Calls\Function.cs:line 389 at IronPython.Runtime.Calls.Method.Call(ICallerContext context, Object[] args) in C:\Development\IronPython-1.1\Src\I ronPython\Runtime\Calls\Function.cs:line 972 at IronPython.Runtime.Operations.Ops.Call(Object func, Object[] args) in C:\Development\IronPython-1.1\Src\IronPython \Runtime\Operations\Ops.cs:line 1414 at IronPython.Runtime.Types.DynamicType.Invoke(Object target, SymbolId name, Object[] args) in C:\Development\IronPyt hon-1.1\Src\IronPython\Runtime\Types\DynamicType.cs:line 1010 at IronPython.Runtime.Operations.Ops.Invoke(Object target, SymbolId name, Object[] args) in C:\Development\IronPython -1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1760 at IPyExample.Program.Main(String[] args) in C:\Documents and Settings\sweeneym\My Documents\Visual Studio 2005\Proje cts\ATF.IP\IPyExample\Program.cs:line 35 ------------------------------------------------------------ Michael A. Sweeney email: michael_sweeney at agilent.com Agilent Technologies phone: (509) 921-4395 MS:3WU-222 fax: (509) 921-3991 24001 E. Mission Ave. Liberty Lake, WA 99019 USA ------------------------------------------------------------ _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From michael_sweeney at agilent.com Mon Jan 15 21:54:44 2007 From: michael_sweeney at agilent.com (michael_sweeney at agilent.com) Date: Mon, 15 Jan 2007 13:54:44 -0700 Subject: [IronPython] Calling Python objects from C#? In-Reply-To: <7AD436E4270DD54A94238001769C222762C9EF23DC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <64B0479F895F194587EE70276364C5C601DA2FD0@wcosmb02.cos.agilent.com> <7AD436E4270DD54A94238001769C222762C9EF23DC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <64B0479F895F194587EE70276364C5C601DA300B@wcosmb02.cos.agilent.com> Thanks Dino, That is much simpler! Now for get/set of attributes values... I need an ICallerContext for the Ops.GetAttr() call. Is there a way to get this without calling 'object pmodule = module.Import("MyExample");'? static void Main(string[] args) { PythonEngine engine = new PythonEngine(); EngineModule module = engine.CreateModule("MyExample", true); try { engine.ExecuteFile("MyExample.py", module); } catch (Exception ex) { Console.WriteLine("Failed to execute Example.py file"); Console.WriteLine("Exception: {0}", ex.Message); return; } // Get the Python Class from the module's global list object ptype = module.Globals["MyClass"]; // Get Module Instance object pmodule = module.Import("MyExample"); // Create an instance of the object object pobj = Ops.Call(ptype); // Call the method - Using Ops.Invoke() object rtnValue = Ops.Invoke(pobj, SymbolTable.StringToId("DoWork")); Console.WriteLine("DoWork return value = {0}\n", rtnValue); // Perform a GetAttr on the object instance object attr = Ops.GetAttr((ICallerContext)pmodule, pobj, SymbolTable.StringToId("attr")); Console.WriteLine("attr = {0}, type = {}\n", attr); } Thanks in advance... Mike > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Monday, January 15, 2007 11:46 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Calling Python objects from C#? > > I think the problem is that AllocateObject is equivalent to calling > mytype.__new__ which is not quite what you want - you want the equivalent > of doing mytype () or mytype.__call__() > > I would change this to: > > // Get the Python Class from the module's global list > object ptype = module.Globals["MyClass"]; > > // Create an instance of the object > object myclass = Ops.Call(ptype); > > Not only is it more correct it gets rid of the direct dependency on > UserType (for example your code wouldn't have worked w/ an old-style class > or if a user had done MyClass = System.SomeTypeThatHasADoWorkMethod). > > >From there I think your Ops.Invoke calls should work (although I haven't > tried to make sure). > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com > Sent: Monday, January 15, 2007 9:58 AM > To: users at lists.ironpython.com > Subject: [IronPython] Calling Python objects from C#? > > Hi All, > > My apology if this has been asked before... I have searched for several > examples and did not find what I was looking for. > > My question is what is the best way to interact with Python objects from > within C#? I need to call functions, capture the return value and get/set > attributes from within C#. > > I have tried several ways and ended up with this example for calling > functions, but it generates an exception saying it does not know what > "attr" is. > > Here is my example: > > File MyExample.py: > > class MyClass(object): > def __init__(self): > self.attr = 500.0 > > def DoWork(self): > print "Attr = ", self.attr > return self.attr > > > File Program.cs: > > using System; > > using IronPython.Runtime; > using IronPython.Runtime.Types; > using IronPython.Runtime.Operations; > using IronPython.Hosting; > using IronPython.Modules; > > namespace IPyExample > { > class Program > { > static void Main(string[] args) > { > PythonEngine engine = new PythonEngine(); > EngineModule module = engine.CreateModule("MyExample", true); > > try > { > engine.ExecuteFile("MyExample.py", module); > } > catch (Exception ex) > { > Console.WriteLine("Failed to execute Example.py file"); > Console.WriteLine("Exception: {0}", ex.Message); > return; > } > > // Get the Python Class from the module's global list > UserType ptype = module.Globals["MyClass"] as UserType; > > // Create an instance of the object > object myclass = ptype.AllocateObject(); > > // Call the method - Using Ops.Invoke() > Ops.Invoke(myclass, SymbolTable.StringToId("DoWork")); > > // Call the same method - Using UserType.Invoke() > object rtnValue = ptype.Invoke(myclass, > SymbolTable.StringToId("DoWork")); > > Console.WriteLine("DoWork return value = {0}\n", rtnValue); > } > } > } > > > Exception: > > C:\Documents and Settings\sweeneym\My Documents\Visual Studio > 2005\Projects\ATF. > IP\IPyExample\bin\Debug>IPYExample > Attr = > Unhandled Exception: System.MissingMemberException: attr > at IronPython.Runtime.Types.UserType.GetAttr(ICallerContext context, > Object self, SymbolId name) in C:\Development\Ir > onPython-1.1\Src\IronPython\Runtime\Types\UserType.cs:line 370 > at IronPython.Runtime.Operations.Ops.GetAttr(ICallerContext context, > Object o, SymbolId name) in C:\Development\IronP > ython-1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1644 > at DoWork$f1##4(FunctionEnvironment4Dictionary , Object ) > at IronPython.Runtime.Calls.CallTarget1.Invoke(Object arg0) > at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, > Object arg0) in C:\Development\IronPython-1.1\Src\ > IronPython\Runtime\Calls\Function.Generated.cs:line 127 > at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, > Object[] args) in C:\Development\IronPython-1.1\Sr > c\IronPython\Runtime\Calls\Function.Generated.cs:line 138 > at IronPython.Runtime.Calls.PythonFunction.CallInstance(ICallerContext > context, Object instance, Object[] args) in C: > \Development\IronPython-1.1\Src\IronPython\Runtime\Calls\Function.cs:line > 389 > at IronPython.Runtime.Calls.Method.Call(ICallerContext context, > Object[] args) in C:\Development\IronPython-1.1\Src\I > ronPython\Runtime\Calls\Function.cs:line 972 > at IronPython.Runtime.Operations.Ops.Call(Object func, Object[] args) > in C:\Development\IronPython-1.1\Src\IronPython > \Runtime\Operations\Ops.cs:line 1414 > at IronPython.Runtime.Types.DynamicType.Invoke(Object target, SymbolId > name, Object[] args) in C:\Development\IronPyt > hon-1.1\Src\IronPython\Runtime\Types\DynamicType.cs:line 1010 > at IronPython.Runtime.Operations.Ops.Invoke(Object target, SymbolId > name, Object[] args) in C:\Development\IronPython > -1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1760 > at IPyExample.Program.Main(String[] args) in C:\Documents and > Settings\sweeneym\My Documents\Visual Studio 2005\Proje > cts\ATF.IP\IPyExample\Program.cs:line 35 > > > ------------------------------------------------------------ > Michael A. Sweeney email: michael_sweeney at agilent.com > Agilent Technologies phone: (509) 921-4395 > MS:3WU-222 fax: (509) 921-3991 > 24001 E. Mission Ave. > Liberty Lake, WA 99019 USA > ------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Mon Jan 15 22:07:56 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 15 Jan 2007 13:07:56 -0800 Subject: [IronPython] Calling Python objects from C#? In-Reply-To: <64B0479F895F194587EE70276364C5C601DA300B@wcosmb02.cos.agilent.com> References: <64B0479F895F194587EE70276364C5C601DA2FD0@wcosmb02.cos.agilent.com> <7AD436E4270DD54A94238001769C222762C9EF23DC@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <64B0479F895F194587EE70276364C5C601DA300B@wcosmb02.cos.agilent.com> Message-ID: <7AD436E4270DD54A94238001769C222762C9EF2451@DF-GRTDANE-MSG.exchange.corp.microsoft.com> For the context you should be able to use DefaultContext.Default. If you wanted members from .NET types to show up on types that are used natively in Python (e.g. string, int, etc...) you could use DefaultContext.DefaultCLS. If you wanted the lookup to reflect what had happened in the module (e.g. whether the user has done import clr or import ) then you'd want to pass the module instance as the context. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com Sent: Monday, January 15, 2007 12:55 PM To: users at lists.ironpython.com Subject: Re: [IronPython] Calling Python objects from C#? Thanks Dino, That is much simpler! Now for get/set of attributes values... I need an ICallerContext for the Ops.GetAttr() call. Is there a way to get this without calling 'object pmodule = module.Import("MyExample");'? static void Main(string[] args) { PythonEngine engine = new PythonEngine(); EngineModule module = engine.CreateModule("MyExample", true); try { engine.ExecuteFile("MyExample.py", module); } catch (Exception ex) { Console.WriteLine("Failed to execute Example.py file"); Console.WriteLine("Exception: {0}", ex.Message); return; } // Get the Python Class from the module's global list object ptype = module.Globals["MyClass"]; // Get Module Instance object pmodule = module.Import("MyExample"); // Create an instance of the object object pobj = Ops.Call(ptype); // Call the method - Using Ops.Invoke() object rtnValue = Ops.Invoke(pobj, SymbolTable.StringToId("DoWork")); Console.WriteLine("DoWork return value = {0}\n", rtnValue); // Perform a GetAttr on the object instance object attr = Ops.GetAttr((ICallerContext)pmodule, pobj, SymbolTable.StringToId("attr")); Console.WriteLine("attr = {0}, type = {}\n", attr); } Thanks in advance... Mike > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Monday, January 15, 2007 11:46 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Calling Python objects from C#? > > I think the problem is that AllocateObject is equivalent to calling > mytype.__new__ which is not quite what you want - you want the equivalent > of doing mytype () or mytype.__call__() > > I would change this to: > > // Get the Python Class from the module's global list > object ptype = module.Globals["MyClass"]; > > // Create an instance of the object > object myclass = Ops.Call(ptype); > > Not only is it more correct it gets rid of the direct dependency on > UserType (for example your code wouldn't have worked w/ an old-style class > or if a user had done MyClass = System.SomeTypeThatHasADoWorkMethod). > > >From there I think your Ops.Invoke calls should work (although I haven't > tried to make sure). > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com > Sent: Monday, January 15, 2007 9:58 AM > To: users at lists.ironpython.com > Subject: [IronPython] Calling Python objects from C#? > > Hi All, > > My apology if this has been asked before... I have searched for several > examples and did not find what I was looking for. > > My question is what is the best way to interact with Python objects from > within C#? I need to call functions, capture the return value and get/set > attributes from within C#. > > I have tried several ways and ended up with this example for calling > functions, but it generates an exception saying it does not know what > "attr" is. > > Here is my example: > > File MyExample.py: > > class MyClass(object): > def __init__(self): > self.attr = 500.0 > > def DoWork(self): > print "Attr = ", self.attr > return self.attr > > > File Program.cs: > > using System; > > using IronPython.Runtime; > using IronPython.Runtime.Types; > using IronPython.Runtime.Operations; > using IronPython.Hosting; > using IronPython.Modules; > > namespace IPyExample > { > class Program > { > static void Main(string[] args) > { > PythonEngine engine = new PythonEngine(); > EngineModule module = engine.CreateModule("MyExample", true); > > try > { > engine.ExecuteFile("MyExample.py", module); > } > catch (Exception ex) > { > Console.WriteLine("Failed to execute Example.py file"); > Console.WriteLine("Exception: {0}", ex.Message); > return; > } > > // Get the Python Class from the module's global list > UserType ptype = module.Globals["MyClass"] as UserType; > > // Create an instance of the object > object myclass = ptype.AllocateObject(); > > // Call the method - Using Ops.Invoke() > Ops.Invoke(myclass, SymbolTable.StringToId("DoWork")); > > // Call the same method - Using UserType.Invoke() > object rtnValue = ptype.Invoke(myclass, > SymbolTable.StringToId("DoWork")); > > Console.WriteLine("DoWork return value = {0}\n", rtnValue); > } > } > } > > > Exception: > > C:\Documents and Settings\sweeneym\My Documents\Visual Studio > 2005\Projects\ATF. > IP\IPyExample\bin\Debug>IPYExample > Attr = > Unhandled Exception: System.MissingMemberException: attr > at IronPython.Runtime.Types.UserType.GetAttr(ICallerContext context, > Object self, SymbolId name) in C:\Development\Ir > onPython-1.1\Src\IronPython\Runtime\Types\UserType.cs:line 370 > at IronPython.Runtime.Operations.Ops.GetAttr(ICallerContext context, > Object o, SymbolId name) in C:\Development\IronP > ython-1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1644 > at DoWork$f1##4(FunctionEnvironment4Dictionary , Object ) > at IronPython.Runtime.Calls.CallTarget1.Invoke(Object arg0) > at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, > Object arg0) in C:\Development\IronPython-1.1\Src\ > IronPython\Runtime\Calls\Function.Generated.cs:line 127 > at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, > Object[] args) in C:\Development\IronPython-1.1\Sr > c\IronPython\Runtime\Calls\Function.Generated.cs:line 138 > at IronPython.Runtime.Calls.PythonFunction.CallInstance(ICallerContext > context, Object instance, Object[] args) in C: > \Development\IronPython-1.1\Src\IronPython\Runtime\Calls\Function.cs:line > 389 > at IronPython.Runtime.Calls.Method.Call(ICallerContext context, > Object[] args) in C:\Development\IronPython-1.1\Src\I > ronPython\Runtime\Calls\Function.cs:line 972 > at IronPython.Runtime.Operations.Ops.Call(Object func, Object[] args) > in C:\Development\IronPython-1.1\Src\IronPython > \Runtime\Operations\Ops.cs:line 1414 > at IronPython.Runtime.Types.DynamicType.Invoke(Object target, SymbolId > name, Object[] args) in C:\Development\IronPyt > hon-1.1\Src\IronPython\Runtime\Types\DynamicType.cs:line 1010 > at IronPython.Runtime.Operations.Ops.Invoke(Object target, SymbolId > name, Object[] args) in C:\Development\IronPython > -1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1760 > at IPyExample.Program.Main(String[] args) in C:\Documents and > Settings\sweeneym\My Documents\Visual Studio 2005\Proje > cts\ATF.IP\IPyExample\Program.cs:line 35 > > > ------------------------------------------------------------ > Michael A. Sweeney email: michael_sweeney at agilent.com > Agilent Technologies phone: (509) 921-4395 > MS:3WU-222 fax: (509) 921-3991 > 24001 E. Mission Ave. > Liberty Lake, WA 99019 USA > ------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From michael_sweeney at agilent.com Mon Jan 15 22:24:52 2007 From: michael_sweeney at agilent.com (michael_sweeney at agilent.com) Date: Mon, 15 Jan 2007 14:24:52 -0700 Subject: [IronPython] Calling Python objects from C#? In-Reply-To: <7AD436E4270DD54A94238001769C222762C9EF2451@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <64B0479F895F194587EE70276364C5C601DA2FD0@wcosmb02.cos.agilent.com><7AD436E4270DD54A94238001769C222762C9EF23DC@DF-GRTDANE-MSG.exchange.corp.microsoft.com><64B0479F895F194587EE70276364C5C601DA300B@wcosmb02.cos.agilent.com> <7AD436E4270DD54A94238001769C222762C9EF2451@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <64B0479F895F194587EE70276364C5C601DA300F@wcosmb02.cos.agilent.com> I think the DefaultContext class is private to the IronPython.Runtime.Calls namespace. I was unable to access it from my applications .dll. >From the file DefaultContext.cs: namespace IronPython.Runtime.Calls { class DefaultContext : ICallerContext { public static DefaultContext Default = new DefaultContext(CallerContextAttributes.None); public static DefaultContext DefaultCLS = new DefaultContext(CallerContextAttributes.ShowCls); This is correct? Or, should the scope be "public class DefaultContext"? Mike > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Monday, January 15, 2007 1:08 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Calling Python objects from C#? > > For the context you should be able to use DefaultContext.Default. If you > wanted members from .NET types to show up on types that are used natively > in Python (e.g. string, int, etc...) you could use > DefaultContext.DefaultCLS. If you wanted the lookup to reflect what had > happened in the module (e.g. whether the user has done import clr or > import ) then you'd want to pass the module instance > as the context. > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com > Sent: Monday, January 15, 2007 12:55 PM > To: users at lists.ironpython.com > Subject: Re: [IronPython] Calling Python objects from C#? > > Thanks Dino, > > That is much simpler! Now for get/set of attributes values... > > I need an ICallerContext for the Ops.GetAttr() call. Is there a way to get > this without calling 'object pmodule = module.Import("MyExample");'? > > > static void Main(string[] args) > { > PythonEngine engine = new PythonEngine(); > EngineModule module = engine.CreateModule("MyExample", true); > > try > { > engine.ExecuteFile("MyExample.py", module); > } > catch (Exception ex) > { > Console.WriteLine("Failed to execute Example.py file"); > Console.WriteLine("Exception: {0}", ex.Message); > return; > } > > // Get the Python Class from the module's global list > object ptype = module.Globals["MyClass"]; > > // Get Module Instance > object pmodule = module.Import("MyExample"); > > // Create an instance of the object > object pobj = Ops.Call(ptype); > > // Call the method - Using Ops.Invoke() > object rtnValue = Ops.Invoke(pobj, > SymbolTable.StringToId("DoWork")); > Console.WriteLine("DoWork return value = {0}\n", rtnValue); > > // Perform a GetAttr on the object instance > object attr = Ops.GetAttr((ICallerContext)pmodule, > pobj, SymbolTable.StringToId("attr")); > Console.WriteLine("attr = {0}, type = {}\n", attr); > > } > > Thanks in advance... > > Mike > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > > Sent: Monday, January 15, 2007 11:46 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Calling Python objects from C#? > > > > I think the problem is that AllocateObject is equivalent to calling > > mytype.__new__ which is not quite what you want - you want the > equivalent > > of doing mytype () or mytype.__call__() > > > > I would change this to: > > > > // Get the Python Class from the module's global list > > object ptype = module.Globals["MyClass"]; > > > > // Create an instance of the object > > object myclass = Ops.Call(ptype); > > > > Not only is it more correct it gets rid of the direct dependency on > > UserType (for example your code wouldn't have worked w/ an old-style > class > > or if a user had done MyClass = System.SomeTypeThatHasADoWorkMethod). > > > > >From there I think your Ops.Invoke calls should work (although I > haven't > > tried to make sure). > > > > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com > > Sent: Monday, January 15, 2007 9:58 AM > > To: users at lists.ironpython.com > > Subject: [IronPython] Calling Python objects from C#? > > > > Hi All, > > > > My apology if this has been asked before... I have searched for several > > examples and did not find what I was looking for. > > > > My question is what is the best way to interact with Python objects from > > within C#? I need to call functions, capture the return value and > get/set > > attributes from within C#. > > > > I have tried several ways and ended up with this example for calling > > functions, but it generates an exception saying it does not know what > > "attr" is. > > > > Here is my example: > > > > File MyExample.py: > > > > class MyClass(object): > > def __init__(self): > > self.attr = 500.0 > > > > def DoWork(self): > > print "Attr = ", self.attr > > return self.attr > > > > > > File Program.cs: > > > > using System; > > > > using IronPython.Runtime; > > using IronPython.Runtime.Types; > > using IronPython.Runtime.Operations; > > using IronPython.Hosting; > > using IronPython.Modules; > > > > namespace IPyExample > > { > > class Program > > { > > static void Main(string[] args) > > { > > PythonEngine engine = new PythonEngine(); > > EngineModule module = engine.CreateModule("MyExample", > true); > > > > try > > { > > engine.ExecuteFile("MyExample.py", module); > > } > > catch (Exception ex) > > { > > Console.WriteLine("Failed to execute Example.py file"); > > Console.WriteLine("Exception: {0}", ex.Message); > > return; > > } > > > > // Get the Python Class from the module's global list > > UserType ptype = module.Globals["MyClass"] as UserType; > > > > // Create an instance of the object > > object myclass = ptype.AllocateObject(); > > > > // Call the method - Using Ops.Invoke() > > Ops.Invoke(myclass, SymbolTable.StringToId("DoWork")); > > > > // Call the same method - Using UserType.Invoke() > > object rtnValue = ptype.Invoke(myclass, > > SymbolTable.StringToId("DoWork")); > > > > Console.WriteLine("DoWork return value = {0}\n", rtnValue); > > } > > } > > } > > > > > > Exception: > > > > C:\Documents and Settings\sweeneym\My Documents\Visual Studio > > 2005\Projects\ATF. > > IP\IPyExample\bin\Debug>IPYExample > > Attr = > > Unhandled Exception: System.MissingMemberException: attr > > at IronPython.Runtime.Types.UserType.GetAttr(ICallerContext context, > > Object self, SymbolId name) in C:\Development\Ir > > onPython-1.1\Src\IronPython\Runtime\Types\UserType.cs:line 370 > > at IronPython.Runtime.Operations.Ops.GetAttr(ICallerContext context, > > Object o, SymbolId name) in C:\Development\IronP > > ython-1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1644 > > at DoWork$f1##4(FunctionEnvironment4Dictionary , Object ) > > at IronPython.Runtime.Calls.CallTarget1.Invoke(Object arg0) > > at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, > > Object arg0) in C:\Development\IronPython-1.1\Src\ > > IronPython\Runtime\Calls\Function.Generated.cs:line 127 > > at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, > > Object[] args) in C:\Development\IronPython-1.1\Sr > > c\IronPython\Runtime\Calls\Function.Generated.cs:line 138 > > at > IronPython.Runtime.Calls.PythonFunction.CallInstance(ICallerContext > > context, Object instance, Object[] args) in C: > > \Development\IronPython- > 1.1\Src\IronPython\Runtime\Calls\Function.cs:line > > 389 > > at IronPython.Runtime.Calls.Method.Call(ICallerContext context, > > Object[] args) in C:\Development\IronPython-1.1\Src\I > > ronPython\Runtime\Calls\Function.cs:line 972 > > at IronPython.Runtime.Operations.Ops.Call(Object func, Object[] args) > > in C:\Development\IronPython-1.1\Src\IronPython > > \Runtime\Operations\Ops.cs:line 1414 > > at IronPython.Runtime.Types.DynamicType.Invoke(Object target, > SymbolId > > name, Object[] args) in C:\Development\IronPyt > > hon-1.1\Src\IronPython\Runtime\Types\DynamicType.cs:line 1010 > > at IronPython.Runtime.Operations.Ops.Invoke(Object target, SymbolId > > name, Object[] args) in C:\Development\IronPython > > -1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1760 > > at IPyExample.Program.Main(String[] args) in C:\Documents and > > Settings\sweeneym\My Documents\Visual Studio 2005\Proje > > cts\ATF.IP\IPyExample\Program.cs:line 35 > > > > > > ------------------------------------------------------------ > > Michael A. Sweeney email: michael_sweeney at agilent.com > > Agilent Technologies phone: (509) 921-4395 > > MS:3WU-222 fax: (509) 921-3991 > > 24001 E. Mission Ave. > > Liberty Lake, WA 99019 USA > > ------------------------------------------------------------ > > > > _______________________________________________ > > users mailing list > > users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > > users mailing list > > users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Mon Jan 15 23:00:32 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 15 Jan 2007 14:00:32 -0800 Subject: [IronPython] Calling Python objects from C#? In-Reply-To: <64B0479F895F194587EE70276364C5C601DA300F@wcosmb02.cos.agilent.com> References: <64B0479F895F194587EE70276364C5C601DA2FD0@wcosmb02.cos.agilent.com><7AD436E4270DD54A94238001769C222762C9EF23DC@DF-GRTDANE-MSG.exchange.corp.microsoft.com><64B0479F895F194587EE70276364C5C601DA300B@wcosmb02.cos.agilent.com> <7AD436E4270DD54A94238001769C222762C9EF2451@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <64B0479F895F194587EE70276364C5C601DA300F@wcosmb02.cos.agilent.com> Message-ID: <7AD436E4270DD54A94238001769C222762C9EF24AE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Sorry, I didn't realize we never made that public... Now that I'm looking at it a little closer I'm surprised how hard it is to get an ICallerContext instance. I think the easiest way is: module.GetModuleScope(null); (where module is the EngineModule instance in your sample code). That will return an IModuleScope which implements ICallerContext and that scope should stay in-sync with the module's own scope. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com Sent: Monday, January 15, 2007 1:25 PM To: users at lists.ironpython.com Subject: Re: [IronPython] Calling Python objects from C#? I think the DefaultContext class is private to the IronPython.Runtime.Calls namespace. I was unable to access it from my applications .dll. >From the file DefaultContext.cs: namespace IronPython.Runtime.Calls { class DefaultContext : ICallerContext { public static DefaultContext Default = new DefaultContext(CallerContextAttributes.None); public static DefaultContext DefaultCLS = new DefaultContext(CallerContextAttributes.ShowCls); This is correct? Or, should the scope be "public class DefaultContext"? Mike > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Monday, January 15, 2007 1:08 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Calling Python objects from C#? > > For the context you should be able to use DefaultContext.Default. If you > wanted members from .NET types to show up on types that are used natively > in Python (e.g. string, int, etc...) you could use > DefaultContext.DefaultCLS. If you wanted the lookup to reflect what had > happened in the module (e.g. whether the user has done import clr or > import ) then you'd want to pass the module instance > as the context. > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com > Sent: Monday, January 15, 2007 12:55 PM > To: users at lists.ironpython.com > Subject: Re: [IronPython] Calling Python objects from C#? > > Thanks Dino, > > That is much simpler! Now for get/set of attributes values... > > I need an ICallerContext for the Ops.GetAttr() call. Is there a way to get > this without calling 'object pmodule = module.Import("MyExample");'? > > > static void Main(string[] args) > { > PythonEngine engine = new PythonEngine(); > EngineModule module = engine.CreateModule("MyExample", true); > > try > { > engine.ExecuteFile("MyExample.py", module); > } > catch (Exception ex) > { > Console.WriteLine("Failed to execute Example.py file"); > Console.WriteLine("Exception: {0}", ex.Message); > return; > } > > // Get the Python Class from the module's global list > object ptype = module.Globals["MyClass"]; > > // Get Module Instance > object pmodule = module.Import("MyExample"); > > // Create an instance of the object > object pobj = Ops.Call(ptype); > > // Call the method - Using Ops.Invoke() > object rtnValue = Ops.Invoke(pobj, > SymbolTable.StringToId("DoWork")); > Console.WriteLine("DoWork return value = {0}\n", rtnValue); > > // Perform a GetAttr on the object instance > object attr = Ops.GetAttr((ICallerContext)pmodule, > pobj, SymbolTable.StringToId("attr")); > Console.WriteLine("attr = {0}, type = {}\n", attr); > > } > > Thanks in advance... > > Mike > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > > Sent: Monday, January 15, 2007 11:46 AM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Calling Python objects from C#? > > > > I think the problem is that AllocateObject is equivalent to calling > > mytype.__new__ which is not quite what you want - you want the > equivalent > > of doing mytype () or mytype.__call__() > > > > I would change this to: > > > > // Get the Python Class from the module's global list > > object ptype = module.Globals["MyClass"]; > > > > // Create an instance of the object > > object myclass = Ops.Call(ptype); > > > > Not only is it more correct it gets rid of the direct dependency on > > UserType (for example your code wouldn't have worked w/ an old-style > class > > or if a user had done MyClass = System.SomeTypeThatHasADoWorkMethod). > > > > >From there I think your Ops.Invoke calls should work (although I > haven't > > tried to make sure). > > > > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com > > Sent: Monday, January 15, 2007 9:58 AM > > To: users at lists.ironpython.com > > Subject: [IronPython] Calling Python objects from C#? > > > > Hi All, > > > > My apology if this has been asked before... I have searched for several > > examples and did not find what I was looking for. > > > > My question is what is the best way to interact with Python objects from > > within C#? I need to call functions, capture the return value and > get/set > > attributes from within C#. > > > > I have tried several ways and ended up with this example for calling > > functions, but it generates an exception saying it does not know what > > "attr" is. > > > > Here is my example: > > > > File MyExample.py: > > > > class MyClass(object): > > def __init__(self): > > self.attr = 500.0 > > > > def DoWork(self): > > print "Attr = ", self.attr > > return self.attr > > > > > > File Program.cs: > > > > using System; > > > > using IronPython.Runtime; > > using IronPython.Runtime.Types; > > using IronPython.Runtime.Operations; > > using IronPython.Hosting; > > using IronPython.Modules; > > > > namespace IPyExample > > { > > class Program > > { > > static void Main(string[] args) > > { > > PythonEngine engine = new PythonEngine(); > > EngineModule module = engine.CreateModule("MyExample", > true); > > > > try > > { > > engine.ExecuteFile("MyExample.py", module); > > } > > catch (Exception ex) > > { > > Console.WriteLine("Failed to execute Example.py file"); > > Console.WriteLine("Exception: {0}", ex.Message); > > return; > > } > > > > // Get the Python Class from the module's global list > > UserType ptype = module.Globals["MyClass"] as UserType; > > > > // Create an instance of the object > > object myclass = ptype.AllocateObject(); > > > > // Call the method - Using Ops.Invoke() > > Ops.Invoke(myclass, SymbolTable.StringToId("DoWork")); > > > > // Call the same method - Using UserType.Invoke() > > object rtnValue = ptype.Invoke(myclass, > > SymbolTable.StringToId("DoWork")); > > > > Console.WriteLine("DoWork return value = {0}\n", rtnValue); > > } > > } > > } > > > > > > Exception: > > > > C:\Documents and Settings\sweeneym\My Documents\Visual Studio > > 2005\Projects\ATF. > > IP\IPyExample\bin\Debug>IPYExample > > Attr = > > Unhandled Exception: System.MissingMemberException: attr > > at IronPython.Runtime.Types.UserType.GetAttr(ICallerContext context, > > Object self, SymbolId name) in C:\Development\Ir > > onPython-1.1\Src\IronPython\Runtime\Types\UserType.cs:line 370 > > at IronPython.Runtime.Operations.Ops.GetAttr(ICallerContext context, > > Object o, SymbolId name) in C:\Development\IronP > > ython-1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1644 > > at DoWork$f1##4(FunctionEnvironment4Dictionary , Object ) > > at IronPython.Runtime.Calls.CallTarget1.Invoke(Object arg0) > > at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, > > Object arg0) in C:\Development\IronPython-1.1\Src\ > > IronPython\Runtime\Calls\Function.Generated.cs:line 127 > > at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, > > Object[] args) in C:\Development\IronPython-1.1\Sr > > c\IronPython\Runtime\Calls\Function.Generated.cs:line 138 > > at > IronPython.Runtime.Calls.PythonFunction.CallInstance(ICallerContext > > context, Object instance, Object[] args) in C: > > \Development\IronPython- > 1.1\Src\IronPython\Runtime\Calls\Function.cs:line > > 389 > > at IronPython.Runtime.Calls.Method.Call(ICallerContext context, > > Object[] args) in C:\Development\IronPython-1.1\Src\I > > ronPython\Runtime\Calls\Function.cs:line 972 > > at IronPython.Runtime.Operations.Ops.Call(Object func, Object[] args) > > in C:\Development\IronPython-1.1\Src\IronPython > > \Runtime\Operations\Ops.cs:line 1414 > > at IronPython.Runtime.Types.DynamicType.Invoke(Object target, > SymbolId > > name, Object[] args) in C:\Development\IronPyt > > hon-1.1\Src\IronPython\Runtime\Types\DynamicType.cs:line 1010 > > at IronPython.Runtime.Operations.Ops.Invoke(Object target, SymbolId > > name, Object[] args) in C:\Development\IronPython > > -1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1760 > > at IPyExample.Program.Main(String[] args) in C:\Documents and > > Settings\sweeneym\My Documents\Visual Studio 2005\Proje > > cts\ATF.IP\IPyExample\Program.cs:line 35 > > > > > > ------------------------------------------------------------ > > Michael A. Sweeney email: michael_sweeney at agilent.com > > Agilent Technologies phone: (509) 921-4395 > > MS:3WU-222 fax: (509) 921-3991 > > 24001 E. Mission Ave. > > Liberty Lake, WA 99019 USA > > ------------------------------------------------------------ > > > > _______________________________________________ > > users mailing list > > users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > > users mailing list > > users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From michael_sweeney at agilent.com Mon Jan 15 23:24:47 2007 From: michael_sweeney at agilent.com (michael_sweeney at agilent.com) Date: Mon, 15 Jan 2007 15:24:47 -0700 Subject: [IronPython] Calling Python objects from C#? In-Reply-To: <7AD436E4270DD54A94238001769C222762C9EF24AE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <64B0479F895F194587EE70276364C5C601DA2FD0@wcosmb02.cos.agilent.com><7AD436E4270DD54A94238001769C222762C9EF23DC@DF-GRTDANE-MSG.exchange.corp.microsoft.com><64B0479F895F194587EE70276364C5C601DA300B@wcosmb02.cos.agilent.com><7AD436E4270DD54A94238001769C222762C9EF2451@DF-GRTDANE-MSG.exchange.corp.microsoft.com><64B0479F895F194587EE70276364C5C601DA300F@wcosmb02.cos.agilent.com> <7AD436E4270DD54A94238001769C222762C9EF24AE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <64B0479F895F194587EE70276364C5C601DA3012@wcosmb02.cos.agilent.com> Thanks again... This really helps... > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Monday, January 15, 2007 2:01 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Calling Python objects from C#? > > Sorry, I didn't realize we never made that public... > > Now that I'm looking at it a little closer I'm surprised how hard it is to > get an ICallerContext instance. I think the easiest way is: > module.GetModuleScope(null); (where module is the EngineModule instance in > your sample code). That will return an IModuleScope which implements > ICallerContext and that scope should stay in-sync with the module's own > scope. > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com > Sent: Monday, January 15, 2007 1:25 PM > To: users at lists.ironpython.com > Subject: Re: [IronPython] Calling Python objects from C#? > > I think the DefaultContext class is private to the > IronPython.Runtime.Calls namespace. I was unable to access it from my > applications .dll. > > >From the file DefaultContext.cs: > > namespace IronPython.Runtime.Calls { > class DefaultContext : ICallerContext { > public static DefaultContext Default = new > DefaultContext(CallerContextAttributes.None); > public static DefaultContext DefaultCLS = new > DefaultContext(CallerContextAttributes.ShowCls); > > This is correct? Or, should the scope be "public class DefaultContext"? > > Mike > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > > Sent: Monday, January 15, 2007 1:08 PM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Calling Python objects from C#? > > > > For the context you should be able to use DefaultContext.Default. If > you > > wanted members from .NET types to show up on types that are used > natively > > in Python (e.g. string, int, etc...) you could use > > DefaultContext.DefaultCLS. If you wanted the lookup to reflect what had > > happened in the module (e.g. whether the user has done import clr or > > import ) then you'd want to pass the module > instance > > as the context. > > > > > > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto:users- > > bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com > > Sent: Monday, January 15, 2007 12:55 PM > > To: users at lists.ironpython.com > > Subject: Re: [IronPython] Calling Python objects from C#? > > > > Thanks Dino, > > > > That is much simpler! Now for get/set of attributes values... > > > > I need an ICallerContext for the Ops.GetAttr() call. Is there a way to > get > > this without calling 'object pmodule = module.Import("MyExample");'? > > > > > > static void Main(string[] args) > > { > > PythonEngine engine = new PythonEngine(); > > EngineModule module = engine.CreateModule("MyExample", > true); > > > > try > > { > > engine.ExecuteFile("MyExample.py", module); > > } > > catch (Exception ex) > > { > > Console.WriteLine("Failed to execute Example.py file"); > > Console.WriteLine("Exception: {0}", ex.Message); > > return; > > } > > > > // Get the Python Class from the module's global list > > object ptype = module.Globals["MyClass"]; > > > > // Get Module Instance > > object pmodule = module.Import("MyExample"); > > > > // Create an instance of the object > > object pobj = Ops.Call(ptype); > > > > // Call the method - Using Ops.Invoke() > > object rtnValue = Ops.Invoke(pobj, > > SymbolTable.StringToId("DoWork")); > > Console.WriteLine("DoWork return value = {0}\n", rtnValue); > > > > // Perform a GetAttr on the object instance > > object attr = Ops.GetAttr((ICallerContext)pmodule, > > pobj, SymbolTable.StringToId("attr")); > > Console.WriteLine("attr = {0}, type = {}\n", attr); > > > > } > > > > Thanks in advance... > > > > Mike > > > > > -----Original Message----- > > > From: users-bounces at lists.ironpython.com [mailto:users- > > > bounces at lists.ironpython.com] On Behalf Of Dino Viehland > > > Sent: Monday, January 15, 2007 11:46 AM > > > To: Discussion of IronPython > > > Subject: Re: [IronPython] Calling Python objects from C#? > > > > > > I think the problem is that AllocateObject is equivalent to calling > > > mytype.__new__ which is not quite what you want - you want the > > equivalent > > > of doing mytype () or mytype.__call__() > > > > > > I would change this to: > > > > > > // Get the Python Class from the module's global list > > > object ptype = module.Globals["MyClass"]; > > > > > > // Create an instance of the object > > > object myclass = Ops.Call(ptype); > > > > > > Not only is it more correct it gets rid of the direct dependency on > > > UserType (for example your code wouldn't have worked w/ an old-style > > class > > > or if a user had done MyClass = System.SomeTypeThatHasADoWorkMethod). > > > > > > >From there I think your Ops.Invoke calls should work (although I > > haven't > > > tried to make sure). > > > > > > > > > -----Original Message----- > > > From: users-bounces at lists.ironpython.com [mailto:users- > > > bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com > > > Sent: Monday, January 15, 2007 9:58 AM > > > To: users at lists.ironpython.com > > > Subject: [IronPython] Calling Python objects from C#? > > > > > > Hi All, > > > > > > My apology if this has been asked before... I have searched for > several > > > examples and did not find what I was looking for. > > > > > > My question is what is the best way to interact with Python objects > from > > > within C#? I need to call functions, capture the return value and > > get/set > > > attributes from within C#. > > > > > > I have tried several ways and ended up with this example for calling > > > functions, but it generates an exception saying it does not know what > > > "attr" is. > > > > > > Here is my example: > > > > > > File MyExample.py: > > > > > > class MyClass(object): > > > def __init__(self): > > > self.attr = 500.0 > > > > > > def DoWork(self): > > > print "Attr = ", self.attr > > > return self.attr > > > > > > > > > File Program.cs: > > > > > > using System; > > > > > > using IronPython.Runtime; > > > using IronPython.Runtime.Types; > > > using IronPython.Runtime.Operations; > > > using IronPython.Hosting; > > > using IronPython.Modules; > > > > > > namespace IPyExample > > > { > > > class Program > > > { > > > static void Main(string[] args) > > > { > > > PythonEngine engine = new PythonEngine(); > > > EngineModule module = engine.CreateModule("MyExample", > > true); > > > > > > try > > > { > > > engine.ExecuteFile("MyExample.py", module); > > > } > > > catch (Exception ex) > > > { > > > Console.WriteLine("Failed to execute Example.py > file"); > > > Console.WriteLine("Exception: {0}", ex.Message); > > > return; > > > } > > > > > > // Get the Python Class from the module's global list > > > UserType ptype = module.Globals["MyClass"] as UserType; > > > > > > // Create an instance of the object > > > object myclass = ptype.AllocateObject(); > > > > > > // Call the method - Using Ops.Invoke() > > > Ops.Invoke(myclass, SymbolTable.StringToId("DoWork")); > > > > > > // Call the same method - Using UserType.Invoke() > > > object rtnValue = ptype.Invoke(myclass, > > > SymbolTable.StringToId("DoWork")); > > > > > > Console.WriteLine("DoWork return value = {0}\n", > rtnValue); > > > } > > > } > > > } > > > > > > > > > Exception: > > > > > > C:\Documents and Settings\sweeneym\My Documents\Visual Studio > > > 2005\Projects\ATF. > > > IP\IPyExample\bin\Debug>IPYExample > > > Attr = > > > Unhandled Exception: System.MissingMemberException: attr > > > at IronPython.Runtime.Types.UserType.GetAttr(ICallerContext > context, > > > Object self, SymbolId name) in C:\Development\Ir > > > onPython-1.1\Src\IronPython\Runtime\Types\UserType.cs:line 370 > > > at IronPython.Runtime.Operations.Ops.GetAttr(ICallerContext > context, > > > Object o, SymbolId name) in C:\Development\IronP > > > ython-1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1644 > > > at DoWork$f1##4(FunctionEnvironment4Dictionary , Object ) > > > at IronPython.Runtime.Calls.CallTarget1.Invoke(Object arg0) > > > at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, > > > Object arg0) in C:\Development\IronPython-1.1\Src\ > > > IronPython\Runtime\Calls\Function.Generated.cs:line 127 > > > at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, > > > Object[] args) in C:\Development\IronPython-1.1\Sr > > > c\IronPython\Runtime\Calls\Function.Generated.cs:line 138 > > > at > > IronPython.Runtime.Calls.PythonFunction.CallInstance(ICallerContext > > > context, Object instance, Object[] args) in C: > > > \Development\IronPython- > > 1.1\Src\IronPython\Runtime\Calls\Function.cs:line > > > 389 > > > at IronPython.Runtime.Calls.Method.Call(ICallerContext context, > > > Object[] args) in C:\Development\IronPython-1.1\Src\I > > > ronPython\Runtime\Calls\Function.cs:line 972 > > > at IronPython.Runtime.Operations.Ops.Call(Object func, Object[] > args) > > > in C:\Development\IronPython-1.1\Src\IronPython > > > \Runtime\Operations\Ops.cs:line 1414 > > > at IronPython.Runtime.Types.DynamicType.Invoke(Object target, > > SymbolId > > > name, Object[] args) in C:\Development\IronPyt > > > hon-1.1\Src\IronPython\Runtime\Types\DynamicType.cs:line 1010 > > > at IronPython.Runtime.Operations.Ops.Invoke(Object target, SymbolId > > > name, Object[] args) in C:\Development\IronPython > > > -1.1\Src\IronPython\Runtime\Operations\Ops.cs:line 1760 > > > at IPyExample.Program.Main(String[] args) in C:\Documents and > > > Settings\sweeneym\My Documents\Visual Studio 2005\Proje > > > cts\ATF.IP\IPyExample\Program.cs:line 35 > > > > > > > > > ------------------------------------------------------------ > > > Michael A. Sweeney email: michael_sweeney at agilent.com > > > Agilent Technologies phone: (509) 921-4395 > > > MS:3WU-222 fax: (509) 921-3991 > > > 24001 E. Mission Ave. > > > Liberty Lake, WA 99019 USA > > > ------------------------------------------------------------ > > > > > > _______________________________________________ > > > users mailing list > > > users at lists.ironpython.com > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > > > users mailing list > > > users at lists.ironpython.com > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > > users mailing list > > users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > > users mailing list > > users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From xmlhacker at gmail.com Wed Jan 17 02:53:40 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Tue, 16 Jan 2007 18:53:40 -0700 Subject: [IronPython] Miguel de Icaza on IronPython: IronPython has really helped Mono become a better runtime. Message-ID: [NOTE: I didn't see any mention of this in the recent archives, though my apologies if this is a repeat sound-byte.] I was just catching up a bit on a few blogs, and ran across the following sound byte from Miguel de Icaza[1], Second Mini-Anecdote: Pretty much every new release of IronPython has > exposed limitations in our runtime, our class libraries or our compilers. > IronPython has really helped Mono become a better runtime. [1] : http://tirania.org/blog/archive/2007/Jan-11-1.html -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wmayfield at reliabledatainterchange.com Thu Jan 18 04:53:22 2007 From: wmayfield at reliabledatainterchange.com (Web Mayfield) Date: Wed, 17 Jan 2007 21:53:22 -0600 Subject: [IronPython] IronPython on Ubuntu Message-ID: Are there any instructions anywhere about how to get IronPython 1.0.1 running with Mono 1.1.13.6? Is IP 1.0.1 even compatible with Mono 1.1.13.6 or am I going to have to figure out how to upgrade Mono to a higher version? There probably is and I was just didn't find the right combination of search terms to find it. I'm on Mono 1.1.13.6 because that seems to be the highest version that I can find packaged for Ubuntu 6.06. I'm no Linux guy, so I'd like to stick to what shows up in Ubuntu's package manager if at all possible. I'm just trying to make sure that I don't write anything on Windows that won't also run on Mono. -- Web Mayfield From sh at defuze.org Thu Jan 18 09:19:31 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Thu, 18 Jan 2007 08:19:31 +0000 Subject: [IronPython] IronPython on Ubuntu In-Reply-To: References: Message-ID: <45AF2D93.8000506@defuze.org> Web Mayfield wrote: > Are there any instructions anywhere about how to get IronPython 1.0.1 running with Mono 1.1.13.6? Is IP 1.0.1 even compatible with Mono 1.1.13.6 or am I going to have to figure out how to upgrade Mono to a higher version? There probably is and I was just didn't find the right combination of search terms to find it. > > I'm on Mono 1.1.13.6 because that seems to be the highest version that I can find packaged for Ubuntu 6.06. I'm no Linux guy, so I'd like to stick to what shows up in Ubuntu's package manager if at all possible. I'm just trying to make sure that I don't write anything on Windows that won't also run on Mono. > IMO you should upgrade to Mono 1.2.x. Simply download the binary installer and launch it in your home directory somewhere. This won't be disruptive to the rest of your system and you will get all the latest Mono support. I run a Ubuntu-based distrib and that's what I've done. ftp://www.go-mono.com/archive/1.2.2.1/linux-installer/1/mono-1.2.2.1_1-installer.bin - Sylvain From sanxiyn at gmail.com Thu Jan 18 11:34:44 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 18 Jan 2007 19:34:44 +0900 Subject: [IronPython] IronPython on Ubuntu In-Reply-To: References: Message-ID: <5b0248170701180234ncf77fa2r4a131b33db986cdc@mail.gmail.com> 2007/1/18, Web Mayfield : > Are there any instructions anywhere about how to get IronPython 1.0.1 > running with Mono 1.1.13.6? It is not possible. Okay, it is possible, but is not worth the effort. Please upgrade. I perfectly understand your desire to stick to the provided packages, but Mono 1.1.13.x simply has too many runtime and library bugs to run IronPython 1.0.x. Any Mono versions in the 1.2.x series will do. -- Seo Sanghyeon From sh at defuze.org Thu Jan 18 16:56:23 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Thu, 18 Jan 2007 15:56:23 +0000 Subject: [IronPython] Potential issue with the 'in' construction? Message-ID: <45AF98A7.3080609@defuze.org> Hi folks, Say I have the following class: class Test(dict): def __getitem__(self, key): print "__gelitem__ called" return dict.__getitem__(self, key.title()) def __setitem__(self, key, value): print "__selitem__ called" dict.__setitem__(self, key.title(), value) def __delitem__(self, key): print "__delitem__ called" dict.__delitem__(self, key.title()) def __contains__(self, key): print "__contains__ called" return dict.__contains__(self, key.title()) def has_key(self, key): print "has_key called" return dict.__contains__(self, key.title()) Now say I have this code: if __name__ == "__main__": u = Test() u['simple'] = 'text' print u.keys() print 'simple' in u print u.__contains__('simple') print u.has_key('simple') print u['simple'] del u['simple'] I will get the following output: __selitem__ called ['Simple'] False __contains__ called True has_key called True __gelitem__ called text __delitem__ called As you can see all the overridden methods were correctly called except the __contains__ on 'in' construction. The same test with CPython: __selitem__ called ['Simple'] __contains__ called True __contains__ called True has_key called True __gelitem__ called text __delitem__ called In that case everything is as I expected. So could there be a problem on the way IP manages "in"? This looks like a minor bug but prevent me from running CherryPy 3 which uses the same type of Case Insensitive dict to handle easily HTTP headers. Thoughts on a workaround or fix? - Sylvain From sh at defuze.org Thu Jan 18 16:58:07 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Thu, 18 Jan 2007 15:58:07 +0000 Subject: [IronPython] Potential issue with the 'in' construction? In-Reply-To: <45AF98A7.3080609@defuze.org> References: <45AF98A7.3080609@defuze.org> Message-ID: <45AF990F.7000601@defuze.org> Forgot to say that I tested with the latest IPCE svn trunk build against mono 1.2 - Sylvain Sylvain Hellegouarch wrote: > Hi folks, > > Say I have the following class: > > class Test(dict): > def __getitem__(self, key): > print "__gelitem__ called" > return dict.__getitem__(self, key.title()) > > def __setitem__(self, key, value): > print "__selitem__ called" > dict.__setitem__(self, key.title(), value) > > def __delitem__(self, key): > print "__delitem__ called" > dict.__delitem__(self, key.title()) > > def __contains__(self, key): > print "__contains__ called" > return dict.__contains__(self, key.title()) > > def has_key(self, key): > print "has_key called" > return dict.__contains__(self, key.title()) > > Now say I have this code: > > if __name__ == "__main__": > u = Test() > u['simple'] = 'text' > print u.keys() > print 'simple' in u > print u.__contains__('simple') > print u.has_key('simple') > print u['simple'] > del u['simple'] > > I will get the following output: > > __selitem__ called > ['Simple'] > False > __contains__ called > True > has_key called > True > __gelitem__ called > text > __delitem__ called > > > As you can see all the overridden methods were correctly called except > the __contains__ on 'in' construction. > > The same test with CPython: > > __selitem__ called > ['Simple'] > __contains__ called > True > __contains__ called > True > has_key called > True > __gelitem__ called > text > __delitem__ called > > > In that case everything is as I expected. > > So could there be a problem on the way IP manages "in"? > > This looks like a minor bug but prevent me from running CherryPy 3 which > uses the same type of Case Insensitive dict to handle easily HTTP headers. > > Thoughts on a workaround or fix? > - Sylvain > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Thu Jan 18 17:51:01 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 18 Jan 2007 08:51:01 -0800 Subject: [IronPython] Potential issue with the 'in' construction? In-Reply-To: <45AF98A7.3080609@defuze.org> References: <45AF98A7.3080609@defuze.org> Message-ID: <7AD436E4270DD54A94238001769C222762C9EF2E6B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> This is a bug, thanks for reporting it. Ops.In() needs to check for IPythonContainer before checking for IDictionary to detect the overridden method. I've opened bug 7426 for this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7426). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch Sent: Thursday, January 18, 2007 7:56 AM To: Discussion of IronPython Subject: [IronPython] Potential issue with the 'in' construction? Hi folks, Say I have the following class: class Test(dict): def __getitem__(self, key): print "__gelitem__ called" return dict.__getitem__(self, key.title()) def __setitem__(self, key, value): print "__selitem__ called" dict.__setitem__(self, key.title(), value) def __delitem__(self, key): print "__delitem__ called" dict.__delitem__(self, key.title()) def __contains__(self, key): print "__contains__ called" return dict.__contains__(self, key.title()) def has_key(self, key): print "has_key called" return dict.__contains__(self, key.title()) Now say I have this code: if __name__ == "__main__": u = Test() u['simple'] = 'text' print u.keys() print 'simple' in u print u.__contains__('simple') print u.has_key('simple') print u['simple'] del u['simple'] I will get the following output: __selitem__ called ['Simple'] False __contains__ called True has_key called True __gelitem__ called text __delitem__ called As you can see all the overridden methods were correctly called except the __contains__ on 'in' construction. The same test with CPython: __selitem__ called ['Simple'] __contains__ called True __contains__ called True has_key called True __gelitem__ called text __delitem__ called In that case everything is as I expected. So could there be a problem on the way IP manages "in"? This looks like a minor bug but prevent me from running CherryPy 3 which uses the same type of Case Insensitive dict to handle easily HTTP headers. Thoughts on a workaround or fix? - Sylvain _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Fri Jan 19 07:47:51 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 19 Jan 2007 15:47:51 +0900 Subject: [IronPython] Socket's life after close() Message-ID: <5b0248170701182247n6276b8actd25f28ce90754af5@mail.gmail.com> Issue #1368 is closed, but its primary use case is still broken. Have you tested with original poster's test case, urllib.urlopen()? amecha commented on Jan 10 about this closed issue stating that it is still broken and I can confirm. (btw, shouldn't the original poster be able to re-open the bug?) Here is a simplifed test case since urllib.urlopen() calls hosts of other functions that simply obscures the root cause. The test assumes that echo service is enabled on the localhost. # test.py import socket s = socket.socket() s.connect(('127.0.0.1', 7)) s.send('test') f = s.makefile() s.close() print f.read(4) Python can read fine after socket close(), but IronPython complains. -- Seo Sanghyeon From sanxiyn at gmail.com Fri Jan 19 08:16:58 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 19 Jan 2007 16:16:58 +0900 Subject: [IronPython] Traceback line numbers in Mono (workaround) Message-ID: <5b0248170701182316n2e952d3bmeeea39526f389d39@mail.gmail.com> Hallo, alle Mono Nutzer, (or something like that) One of the most annoying things in using IronPython on Mono is that line numbers are missing in tracebacks. There is a workaround now! For full details see http://bugzilla.ximian.com/show_bug.cgi?id=80191 Summary: mono --debug ipy.exe -X:SaveAssemblies script.py This will display correct line numbers in traceback. You need both --debug and -X:SaveAssemblies. The issue is that Mono can't display line numbers from AssemblyBuilder built in memory, but only from Assembly loaded from disk. -- Seo Sanghyeon From haiboluo at exchange.microsoft.com Fri Jan 19 08:24:29 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Thu, 18 Jan 2007 23:24:29 -0800 Subject: [IronPython] Socket's life after close() In-Reply-To: <5b0248170701182247n6276b8actd25f28ce90754af5@mail.gmail.com> References: <5b0248170701182247n6276b8actd25f28ce90754af5@mail.gmail.com> Message-ID: This might be related to our lack of nt.dup(). I filed a new bug (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7451) to track this. Sorry, we missed the comment left by amecha in codeplex. If you see any bug has not been fixed, please do not hesitate to re-activate it or send email to this list. A temp solution is: do not close the socket even after calling makefile. Btw, with the current makefile, ~70% of test_socket.py pass. test_urllib.py and test_urllibnet.py pass with few-line change. Thanks for telling us know this. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Thursday, January 18, 2007 10:48 PM To: Discussion of IronPython Subject: [IronPython] Socket's life after close() Issue #1368 is closed, but its primary use case is still broken. Have you tested with original poster's test case, urllib.urlopen()? amecha commented on Jan 10 about this closed issue stating that it is still broken and I can confirm. (btw, shouldn't the original poster be able to re-open the bug?) Here is a simplifed test case since urllib.urlopen() calls hosts of other functions that simply obscures the root cause. The test assumes that echo service is enabled on the localhost. # test.py import socket s = socket.socket() s.connect(('127.0.0.1', 7)) s.send('test') f = s.makefile() s.close() print f.read(4) Python can read fine after socket close(), but IronPython complains. -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Sat Jan 20 18:32:45 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 20 Jan 2007 17:32:45 +0000 Subject: [IronPython] IronPython and Python 3 Message-ID: <45B2523D.8060304@voidspace.org.uk> Hello all, What is the IronPython team's intention with respect to Python 2.X and Python 3 ? IronPython currently uses Python 2.4 as its reference implementation, but now has some features from Python 2.5. Is it the intention to continue tracking the progress of Python 2.X ? When Python 3 arrives, will a separate branch of IronPython be created ? Will development then track both the progress of Python 2.X *and* Python 3.X ? (Even after Python 3.0 final has been released, Python 2.X will continue to be developed and supported for some time.) All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml From sanxiyn at gmail.com Sun Jan 21 14:50:32 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sun, 21 Jan 2007 22:50:32 +0900 Subject: [IronPython] re.sub at the start of the string Message-ID: <5b0248170701210550j4eb9f18eo2117613545ed74af@mail.gmail.com> import re print re.sub('^', 'x', 'abc') CPython prints xabc, IronPython prints just abc. For FePy users: you can use FEPY_OPTIONS=regex to avoid this bug for the time being. -- Seo Sanghyeon From sanxiyn at gmail.com Sun Jan 21 16:56:03 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 22 Jan 2007 00:56:03 +0900 Subject: [IronPython] Empty func_defaults Message-ID: <5b0248170701210756i4ebc16banfce0a18215186298@mail.gmail.com> def f(): pass print f.func_defaults CPython prints None, IronPython prints (). -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Sun Jan 21 17:07:04 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 21 Jan 2007 16:07:04 +0000 Subject: [IronPython] Empty func_defaults In-Reply-To: <5b0248170701210756i4ebc16banfce0a18215186298@mail.gmail.com> References: <5b0248170701210756i4ebc16banfce0a18215186298@mail.gmail.com> Message-ID: <45B38FA8.3000309@voidspace.org.uk> Sanghyeon Seo wrote: > def f(): pass > print f.func_defaults > > CPython prints None, IronPython prints (). > Lamentably the IronPython behaviour, whilst wrong, is better. :-) Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml From anthonybaxter at gmail.com Mon Jan 22 08:05:45 2007 From: anthonybaxter at gmail.com (Anthony Baxter) Date: Mon, 22 Jan 2007 18:05:45 +1100 Subject: [IronPython] IronPython and Python 3 In-Reply-To: <45B2523D.8060304@voidspace.org.uk> References: <45B2523D.8060304@voidspace.org.uk> Message-ID: On 1/21/07, Michael Foord wrote: > Hello all, > > What is the IronPython team's intention with respect to Python 2.X and > Python 3 ? Note that Py3K is still a work in progress. Py2.6 will attempt to support (through use of from __future__, &c) compatibility with 2.5 as well as (hopefully) a lot of 3.0-isms. From dinov at exchange.microsoft.com Mon Jan 22 23:07:07 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 22 Jan 2007 14:07:07 -0800 Subject: [IronPython] re.sub at the start of the string In-Reply-To: <5b0248170701210550j4eb9f18eo2117613545ed74af@mail.gmail.com> References: <5b0248170701210550j4eb9f18eo2117613545ed74af@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222762CA466F36@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks for the bug report Seo! I've filed bug #7531 for this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7531). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Sunday, January 21, 2007 5:51 AM To: Discussion of IronPython Subject: [IronPython] re.sub at the start of the string import re print re.sub('^', 'x', 'abc') CPython prints xabc, IronPython prints just abc. For FePy users: you can use FEPY_OPTIONS=regex to avoid this bug for the time being. -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Mon Jan 22 23:09:30 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 22 Jan 2007 14:09:30 -0800 Subject: [IronPython] Empty func_defaults In-Reply-To: <45B38FA8.3000309@voidspace.org.uk> References: <5b0248170701210756i4ebc16banfce0a18215186298@mail.gmail.com> <45B38FA8.3000309@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222762CA466F3B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> And lucky for us both of those evaluate to false which at least makes the situation somewhat reasonable unless someone checks for equality to None directly. Anyway, we should match the behavior. I've opened CodePlex bug #7532 for this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7532). Thanks for the report Seo! -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Sunday, January 21, 2007 8:07 AM To: Discussion of IronPython Subject: Re: [IronPython] Empty func_defaults Sanghyeon Seo wrote: > def f(): pass > print f.func_defaults > > CPython prints None, IronPython prints (). > Lamentably the IronPython behaviour, whilst wrong, is better. :-) Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From haiboluo at exchange.microsoft.com Tue Jan 23 01:13:04 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Mon, 22 Jan 2007 16:13:04 -0800 Subject: [IronPython] Feedback needed for bug fix: Import pre-compiled modules Message-ID: We recently checked in a fix for codeplex work item# 358 (Implement import of pre-compiled modules). If possible, please download the source, and try it with your scenarios to see whether it addresses your issue (since many of you voted for this item). Running ipy.exe with existing -X:SaveAssemlies switch saves all .py files to corresponding .exe files. For example, given 2 files, main.py, and lib.py # lib.py x = 10 # main.py import lib print lib.x "ipy.exe -X:SaveAssemblies main.py" will result in the creation of lib.exe and main.exe. Next time you run main.py (no switch necessary), "import lib" prefers loading lib.exe to lib.py, if neither ironpython.dll nor lib.py is newer than lib.exe. This is also supposed to enable the binary deployment: you can copy only exe's (with the package structure) along with ironpython binaries to run your IronPython app. A new switch "-X:NotImportCompiled" is provided to disable such pre-compiled module import. Just a reminder, you can always vote on bugs in codeplex. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Tue Jan 23 01:33:44 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 22 Jan 2007 16:33:44 -0800 Subject: [IronPython] Feedback needed for bug fix: Import pre-compiledmodules Message-ID: """ "import lib" prefers loading lib.exe to lib.py, if neither ironpython.dll nor lib.py is newer than lib.exe. """ So: If lib.py doesn't exist, and lib.exe does, it'll import the exe. If lib.py does exist, it'll load lib.exe if the .exe is newer. (Assuming in both cases that ironpython.dll is older than the exe.) If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? How does this impact the upgraded-ironpython scenario for third-party dlls, or do you recommend sending source code to recompile with? ________________________________ From: users-bounces at lists.ironpython.com on behalf of Haibo Luo Sent: Mon 1/22/2007 4:13 PM To: users at lists.ironpython.com Subject: [IronPython] Feedback needed for bug fix: Import pre-compiledmodules We recently checked in a fix for codeplex work item# 358 (Implement import of pre-compiled modules ). If possible, please download the source, and try it with your scenarios to see whether it addresses your issue (since many of you voted for this item). Running ipy.exe with existing -X:SaveAssemlies switch saves all .py files to corresponding .exe files. For example, given 2 files, main.py, and lib.py # lib.py x = 10 # main.py import lib print lib.x "ipy.exe -X:SaveAssemblies main.py" will result in the creation of lib.exe and main.exe. Next time you run main.py (no switch necessary), "import lib" prefers loading lib.exe to lib.py, if neither ironpython.dll nor lib.py is newer than lib.exe. This is also supposed to enable the binary deployment: you can copy only exe's (with the package structure) along with ironpython binaries to run your IronPython app. A new switch "-X:NotImportCompiled" is provided to disable such pre-compiled module import. Just a reminder, you can always vote on bugs in codeplex . Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 6337 bytes Desc: not available URL: From haiboluo at exchange.microsoft.com Tue Jan 23 01:44:39 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Mon, 22 Jan 2007 16:44:39 -0800 Subject: [IronPython] Feedback needed for bug fix: Import pre-compiledmodules In-Reply-To: References: Message-ID: If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >>> Yes the upgraded-ironpython scenario >>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer Sent: Monday, January 22, 2007 4:34 PM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix: Import pre-compiledmodules """ "import lib" prefers loading lib.exe to lib.py, if neither ironpython.dll nor lib.py is newer than lib.exe. """ So: If lib.py doesn't exist, and lib.exe does, it'll import the exe. If lib.py does exist, it'll load lib.exe if the .exe is newer. (Assuming in both cases that ironpython.dll is older than the exe.) If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? How does this impact the upgraded-ironpython scenario for third-party dlls, or do you recommend sending source code to recompile with? ________________________________ From: users-bounces at lists.ironpython.com on behalf of Haibo Luo Sent: Mon 1/22/2007 4:13 PM To: users at lists.ironpython.com Subject: [IronPython] Feedback needed for bug fix: Import pre-compiledmodules We recently checked in a fix for codeplex work item# 358 (Implement import of pre-compiled modules). If possible, please download the source, and try it with your scenarios to see whether it addresses your issue (since many of you voted for this item). Running ipy.exe with existing -X:SaveAssemlies switch saves all .py files to corresponding .exe files. For example, given 2 files, main.py, and lib.py # lib.py x = 10 # main.py import lib print lib.x "ipy.exe -X:SaveAssemblies main.py" will result in the creation of lib.exe and main.exe. Next time you run main.py (no switch necessary), "import lib" prefers loading lib.exe to lib.py, if neither ironpython.dll nor lib.py is newer than lib.exe. This is also supposed to enable the binary deployment: you can copy only exe's (with the package structure) along with ironpython binaries to run your IronPython app. A new switch "-X:NotImportCompiled" is provided to disable such pre-compiled module import. Just a reminder, you can always vote on bugs in codeplex. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Tue Jan 23 03:24:33 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 22 Jan 2007 18:24:33 -0800 Subject: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules Message-ID: the upgraded-ironpython scenario >>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). ________________________________ From: users-bounces at lists.ironpython.com on behalf of Haibo Luo Sent: Mon 1/22/2007 4:44 PM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >>> Yes the upgraded-ironpython scenario >>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer Sent: Monday, January 22, 2007 4:34 PM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix: Import pre-compiledmodules """ "import lib" prefers loading lib.exe to lib.py, if neither ironpython.dll nor lib.py is newer than lib.exe. """ So: If lib.py doesn't exist, and lib.exe does, it'll import the exe. If lib.py does exist, it'll load lib.exe if the .exe is newer. (Assuming in both cases that ironpython.dll is older than the exe.) If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? How does this impact the upgraded-ironpython scenario for third-party dlls, or do you recommend sending source code to recompile with? ________________________________ From: users-bounces at lists.ironpython.com on behalf of Haibo Luo Sent: Mon 1/22/2007 4:13 PM To: users at lists.ironpython.com Subject: [IronPython] Feedback needed for bug fix: Import pre-compiledmodules We recently checked in a fix for codeplex work item# 358 (Implement import of pre-compiled modules ). If possible, please download the source, and try it with your scenarios to see whether it addresses your issue (since many of you voted for this item). Running ipy.exe with existing -X:SaveAssemlies switch saves all .py files to corresponding .exe files. For example, given 2 files, main.py, and lib.py # lib.py x = 10 # main.py import lib print lib.x "ipy.exe -X:SaveAssemblies main.py" will result in the creation of lib.exe and main.exe. Next time you run main.py (no switch necessary), "import lib" prefers loading lib.exe to lib.py, if neither ironpython.dll nor lib.py is newer than lib.exe. This is also supposed to enable the binary deployment: you can copy only exe's (with the package structure) along with ironpython binaries to run your IronPython app. A new switch "-X:NotImportCompiled" is provided to disable such pre-compiled module import. Just a reminder, you can always vote on bugs in codeplex . Thanks! From nytrokiss at gmail.com Tue Jan 23 03:49:36 2007 From: nytrokiss at gmail.com (James Matthews) Date: Mon, 22 Jan 2007 21:49:36 -0500 Subject: [IronPython] re.sub at the start of the string In-Reply-To: <5b0248170701210550j4eb9f18eo2117613545ed74af@mail.gmail.com> References: <5b0248170701210550j4eb9f18eo2117613545ed74af@mail.gmail.com> Message-ID: <8a6b8e350701221849p2e38f085g90ecdf7502092d9b@mail.gmail.com> When is there going to be a 1. manual on Iron Python and 2 and IDE! On 1/21/07, Sanghyeon Seo wrote: > > import re > print re.sub('^', 'x', 'abc') > > CPython prints xabc, IronPython prints just abc. > > For FePy users: you can use FEPY_OPTIONS=regex to avoid this bug for > the time being. > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.goldwatches.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvm_cop at spamcop.net Tue Jan 23 05:02:51 2007 From: jvm_cop at spamcop.net (J. Merrill) Date: Mon, 22 Jan 2007 23:02:51 -0500 Subject: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules Message-ID: <7.0.1.0.2.20070122225903.0472a0c8@wheresmymailserver.com> Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? At 09:24 PM 1/22/2007, Keith J. Farmer wrote >the upgraded-ironpython scenario > >>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. > > >That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). > >Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). > > >________________________________ > >From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >Sent: Mon 1/22/2007 4:44 PM >To: Discussion of IronPython >Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > > > >If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? > >>>> Yes > >[snip] J. Merrill / Analytical Software Corp From haiboluo at exchange.microsoft.com Tue Jan 23 06:04:38 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Mon, 22 Jan 2007 21:04:38 -0800 Subject: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules In-Reply-To: <7.0.1.0.2.20070122225903.0472a0c8@wheresmymailserver.com> References: <7.0.1.0.2.20070122225903.0472a0c8@wheresmymailserver.com> Message-ID: Yes, the current implementation is not ideal. There are 3 ways to load assemblies in .NET: Load, LoadFrom, and LoadFile. - In order to use Load, the generated assemblies have to be strong named; which means the ironpython dlls has to be strong named too. - If an assembly with the same identity is already loaded, LoadFrom returns the loaded assembly even if a different path was specified (from http://msdn2.microsoft.com/en-us/library/1009fa28.aspx). This blocks loading different copies of __init__.exe. - The current implementation chose LoadFile, however it prevents us to call GetCustomAttribute on the loaded assembly for some reason. In the future, we will probably look into LoadFrom, and explore approaches to differentiate identities of __init__.exe (and other possible assemblies with same name), and check some kind of custom attribute. Ideally, we should try to keep the pre-compiled modules' back compatibility for minor version update. For now, the current setting should give you the least surprise: - you won't get MissingMethodException when IronPython.dll changed some APIs. - you will always see the updated behavior when .py source is updated. I will file a work item to track such upgraded-ironpython scenario. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill Sent: Monday, January 22, 2007 8:03 PM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? At 09:24 PM 1/22/2007, Keith J. Farmer wrote >the upgraded-ironpython scenario > >>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. > > >That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). > >Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). > > >________________________________ > >From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >Sent: Mon 1/22/2007 4:44 PM >To: Discussion of IronPython >Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > > > >If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? > >>>> Yes > >[snip] J. Merrill / Analytical Software Corp _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From kfarmer at thuban.org Tue Jan 23 06:38:48 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Mon, 22 Jan 2007 21:38:48 -0800 Subject: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules Message-ID: Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location. The situation I see is: Install IronPython. Install a binaries-only IP app. Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load. So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source). Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill Sent: Monday, January 22, 2007 8:03 PM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? At 09:24 PM 1/22/2007, Keith J. Farmer wrote >the upgraded-ironpython scenario > >>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. > > >That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). > >Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). > > >________________________________ > >From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >Sent: Mon 1/22/2007 4:44 PM >To: Discussion of IronPython >Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > > > >If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? > >>>> Yes > >[snip] J. Merrill / Analytical Software Corp _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From haiboluo at exchange.microsoft.com Tue Jan 23 07:49:25 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Mon, 22 Jan 2007 22:49:25 -0800 Subject: [IronPython] Loading XAML files In-Reply-To: <98B94F0758D7394CA057AE4898CBC85E02B7317F@exchbk1.draper.com> References: <98B94F0758D7394CA057AE4898CBC85E02B7317F@exchbk1.draper.com> Message-ID: Today the Blend team gave us a short demo about their product. I tried their internal beta2 build. Seems the issue has been addressed. With the coming beta2, you can choose "file->new item->Page" (within a project), uncheck "include code file". The generated xaml file will not have x:Class. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Gutfreund, Yechezkal Sent: Monday, January 15, 2007 7:03 AM To: Discussion of IronPython Subject: Re: [IronPython] Loading XAML files Yes, I mentioned in my first message that removing x:Class made it work. The problem is that every time I use Blend, or test the program in Blend or VS-Studio, blend will put it back in, and besides, VS-Studio and Blend both need it for default code-behinds. It is a pain to have to keep two parallel copies by hand. I can't see why the .LoadXAML() is does not do the same scheme checks that are begin done by Blend and VS-studio. That is why I am writing this list. Should I call it a bug? ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Haibo Luo Sent: Friday, January 12, 2007 1:37 PM To: Discussion of IronPython Subject: Re: [IronPython] Loading XAML files I know little about WPF. I found http://msdn2.microsoft.com/en-us/library/ms752309.aspx talking about x:Class attribute. Removing x:class line, I am able to load the UserControl. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Gutfreund, Yechezkal Sent: Friday, January 12, 2007 5:22 AM To: Discussion of IronPython Cc: Vlad Vinogradsky Subject: Re: [IronPython] Loading XAML files All of that XAML code is generated by BLEND. Both Blend and VS-Studio understand that x:Class is a member of the namespace. But I am also not a WPF .NET guru. What I suspect is that when I use ipy, I am not using the same libraries that do XML and XAML loading as when I use Blend and VS-Studio. Ideas? ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill Sent: Thursday, January 11, 2007 10:10 PM To: Discussion of IronPython Subject: Re: [IronPython] Loading XAML files At 05:05 PM 1/11/2007, Gutfreund, Yechezkal wrote (in part) I am using Blend to create XAML files and testing out the design there. Then but all my code is done via Python using the Tutorials "avalon.py" module. It works fine. Except for one annoying glitch. But for some reason the LoadXAML() call chokes on this: >>> w.Content = LoadXaml("WebWrapper.xaml") 'Class' attribute does not exist in XML namespace ' http://schemas.microsoft.com/winfx/2006/xaml' namespace. Line '6' Position '2'. I know almost nothing about XAML, but that error seems to be coming not from anything related to IronPython but rather from some .Net XML parser. Have you attempted to confirm the validity of the file by loading using any other development tool? An XML validation tool should be able to determine the accuracy of the statement that there's no "Class" attribute in that namespace. (Is it possible that the attribute name is "class" not "Class" ?) J. Merrill / Analytical Software Corp -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Tue Jan 23 08:25:31 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 23 Jan 2007 16:25:31 +0900 Subject: [IronPython] Problems with -X:SaveAssemblies Message-ID: <5b0248170701222325w2c05050iafc6c4681c76f5c4@mail.gmail.com> I found this while testing precompiled module feature, but it's the same with plain 1.1a1. I'm not sure whether this is IronPython problem. Can anyone confirm this on .NET, not Mono? How to reproduce: 1. Create x/__init__.py and y/__init__.py as empty files. 2. Create z.py with content "import x, y". 3. Run z.py with and without -X:SaveAssemblies. Later produces null point exception for me. -- Seo Sanghyeon From sanxiyn at gmail.com Tue Jan 23 12:49:10 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 23 Jan 2007 20:49:10 +0900 Subject: [IronPython] type.__call__ again Message-ID: <5b0248170701230349v13610df4qe9a489bfbcdb884c@mail.gmail.com> CPython >>> type.__call__(object) IronPython >>> type.__call__(object) Something's wrong... -- Seo Sanghyeon From jvm_cop at spamcop.net Tue Jan 23 16:22:09 2007 From: jvm_cop at spamcop.net (J. Merrill) Date: Tue, 23 Jan 2007 10:22:09 -0500 Subject: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules Message-ID: <7.0.1.0.2.20070123100956.07bb6ac0@wheresmymailserver.com> I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has to use the same centrally maintained copy of a DLL" the recipe for "DLL hell" that .Net is supposed to let us avoid? In the specific scenario you provide -- you update a DLL used by an existing EXE -- .Net is designed to keep using the old version of the DLL unless you either re-compile to re-build the EXE, or add an entry to the EXE's .config file that tells it that it's ok to use the newer one. (That only applies for DLLs in the GAC, as I understand it.) .Net isn't supposed to load app X that references DLL Y unless the "identity" of Y is the identity listed in the manifest for app X. Changing the identity of a DLL can be done by changing its version number; unfortunately, unless the DLL is installed in the GAC, you can't have two copies of the same DLL differing only in their version and have "the right one" (the one referenced by the EXE, or pointed to by the EXE's config file) load. Sigh. At 12:38 AM 1/23/2007, Keith J. Farmer wrote >Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location. > >The situation I see is: > >Install IronPython. >Install a binaries-only IP app. >Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load. > >So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source). > >Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs. > >-----Original Message----- >From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill >Sent: Monday, January 22, 2007 8:03 PM >To: Discussion of IronPython >Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > >Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? > >Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? > >At 09:24 PM 1/22/2007, Keith J. Farmer wrote >>the upgraded-ironpython scenario >> >>>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. >> >> >>That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). >> >>Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). >> >> >>________________________________ >> >>From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >>Sent: Mon 1/22/2007 4:44 PM >>To: Discussion of IronPython >>Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >> >> >> >>If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >> >>>>> Yes >> >>[snip] > > >J. Merrill / Analytical Software Corp > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com J. Merrill / Analytical Software Corp From haiboluo at exchange.microsoft.com Tue Jan 23 18:05:27 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Tue, 23 Jan 2007 09:05:27 -0800 Subject: [IronPython] Problems with -X:SaveAssemblies In-Reply-To: <5b0248170701222325w2c05050iafc6c4681c76f5c4@mail.gmail.com> References: <5b0248170701222325w2c05050iafc6c4681c76f5c4@mail.gmail.com> Message-ID: I did not see the repro in ironpython + .net. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Monday, January 22, 2007 11:26 PM To: Discussion of IronPython Subject: [IronPython] Problems with -X:SaveAssemblies I found this while testing precompiled module feature, but it's the same with plain 1.1a1. I'm not sure whether this is IronPython problem. Can anyone confirm this on .NET, not Mono? How to reproduce: 1. Create x/__init__.py and y/__init__.py as empty files. 2. Create z.py with content "import x, y". 3. Run z.py with and without -X:SaveAssemblies. Later produces null point exception for me. -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From kfarmer at thuban.org Tue Jan 23 20:00:55 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 23 Jan 2007 11:00:55 -0800 Subject: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules Message-ID: I could be wrong (I certainly have been in the past), but the current scheme seems to pre-empt the built-in mechanisms. There are several ways you can get a reference to an assembly -- file name, name space without strong name, name space and version, name space and public key, etc. This works well enough for most (not all) purposes. If you want .NET to load the most recent version of an assembly, you just need to ask for it. If you require a certain version, or culture, you can ask for those as well. Consider an addin approach, where the IronPython.dll is the addin rather than a compile-time reference. If you did that, then the exe could have a bootstrapper that merely asks for the runtime without specifying strong names. It loads IronPython, potentially obeying any of the standard redirection declarations in exe.config. The exe then casts the IP runtime to IIronPython_1_0_1, and starts calling methods. In versioning IronPython, if a breaking change needs to happen, we can use explicit interfaces: public int IIronPython_1_0_0.Add(int x, int y) { return x + y + 0.1; } public int IIronPython_1_0_1.Add(int x, int y) { return x + y; // bug fix } .. I'm just doing this off the top of my head at the moment, but I think it'd at least alleviate some of the problem. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill Sent: Tuesday, January 23, 2007 7:22 AM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has to use the same centrally maintained copy of a DLL" the recipe for "DLL hell" that .Net is supposed to let us avoid? In the specific scenario you provide -- you update a DLL used by an existing EXE -- .Net is designed to keep using the old version of the DLL unless you either re-compile to re-build the EXE, or add an entry to the EXE's .config file that tells it that it's ok to use the newer one. (That only applies for DLLs in the GAC, as I understand it.) .Net isn't supposed to load app X that references DLL Y unless the "identity" of Y is the identity listed in the manifest for app X. Changing the identity of a DLL can be done by changing its version number; unfortunately, unless the DLL is installed in the GAC, you can't have two copies of the same DLL differing only in their version and have "the right one" (the one referenced by the EXE, or pointed to by the EXE's config file) load. Sigh. At 12:38 AM 1/23/2007, Keith J. Farmer wrote >Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location. > >The situation I see is: > >Install IronPython. >Install a binaries-only IP app. >Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load. > >So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source). > >Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs. > >-----Original Message----- >From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill >Sent: Monday, January 22, 2007 8:03 PM >To: Discussion of IronPython >Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > >Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? > >Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? > >At 09:24 PM 1/22/2007, Keith J. Farmer wrote >>the upgraded-ironpython scenario >> >>>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. >> >> >>That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). >> >>Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). >> >> >>________________________________ >> >>From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >>Sent: Mon 1/22/2007 4:44 PM >>To: Discussion of IronPython >>Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >> >> >> >>If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >> >>>>> Yes >> >>[snip] > > >J. Merrill / Analytical Software Corp > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com J. Merrill / Analytical Software Corp _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From garage_dba at hotmail.com Tue Jan 23 20:33:27 2007 From: garage_dba at hotmail.com (Bill64bits) Date: Tue, 23 Jan 2007 13:33:27 -0600 Subject: [IronPython] Feedback neededfor bug fix:Import pre-compiledmodules References: Message-ID: When/If IronPython becomes stable won't IronPython.dll just disappear into the .NET runtime? ----- Original Message ----- From: Keith J. Farmer To: Discussion of IronPython Sent: Tuesday, January 23, 2007 1:00 PM Subject: Re: [IronPython] Feedback neededfor bug fix:Import pre-compiledmodules I could be wrong (I certainly have been in the past), but the current scheme seems to pre-empt the built-in mechanisms. There are several ways you can get a reference to an assembly -- file name, name space without strong name, name space and version, name space and public key, etc. This works well enough for most (not all) purposes. If you want .NET to load the most recent version of an assembly, you just need to ask for it. If you require a certain version, or culture, you can ask for those as well. Consider an addin approach, where the IronPython.dll is the addin rather than a compile-time reference. If you did that, then the exe could have a bootstrapper that merely asks for the runtime without specifying strong names. It loads IronPython, potentially obeying any of the standard redirection declarations in exe.config. The exe then casts the IP runtime to IIronPython_1_0_1, and starts calling methods. In versioning IronPython, if a breaking change needs to happen, we can use explicit interfaces: public int IIronPython_1_0_0.Add(int x, int y) { return x + y + 0.1; } public int IIronPython_1_0_1.Add(int x, int y) { return x + y; // bug fix } .. I'm just doing this off the top of my head at the moment, but I think it'd at least alleviate some of the problem. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill Sent: Tuesday, January 23, 2007 7:22 AM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has to use the same centrally maintained copy of a DLL" the recipe for "DLL hell" that .Net is supposed to let us avoid? In the specific scenario you provide -- you update a DLL used by an existing EXE -- .Net is designed to keep using the old version of the DLL unless you either re-compile to re-build the EXE, or add an entry to the EXE's .config file that tells it that it's ok to use the newer one. (That only applies for DLLs in the GAC, as I understand it.) .Net isn't supposed to load app X that references DLL Y unless the "identity" of Y is the identity listed in the manifest for app X. Changing the identity of a DLL can be done by changing its version number; unfortunately, unless the DLL is installed in the GAC, you can't have two copies of the same DLL differing only in their version and have "the right one" (the one referenced by the EXE, or pointed to by the EXE's config file) load. Sigh. At 12:38 AM 1/23/2007, Keith J. Farmer wrote >Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location. > >The situation I see is: > >Install IronPython. >Install a binaries-only IP app. >Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load. > >So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source). > >Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs. > >-----Original Message----- >From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill >Sent: Monday, January 22, 2007 8:03 PM >To: Discussion of IronPython >Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > >Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? > >Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? > >At 09:24 PM 1/22/2007, Keith J. Farmer wrote >>the upgraded-ironpython scenario >> >>>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. >> >> >>That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). >> >>Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). >> >> >>________________________________ >> >>From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >>Sent: Mon 1/22/2007 4:44 PM >>To: Discussion of IronPython >>Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >> >> >> >>If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >> >>>>> Yes >> >>[snip] > > >J. Merrill / Analytical Software Corp > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com J. Merrill / Analytical Software Corp _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Tue Jan 23 21:00:10 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 23 Jan 2007 12:00:10 -0800 Subject: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C222762CA467317@DF-GRTDANE-MSG.exchange.corp.microsoft.com> This should be solvable in a similar but slightly different way. We wouldn't want to require an extra argument (in this case the versioned IronPython engine) to be required for each call. Also I'm going to pick a slightly more generic example "DoOperation" instead of Add (because a bug fix to the semantics of Add would just change the body of Add and everything would be ok. A signature change is really more interesting). Static object DoOperation(object arg) { DoOperation_1_0_1(arg, null); } Static object DoOperation_1_0_1(object arg1, object arg2) { ... } In this case we could preserve the old DoOperation method and add the new DoOperation_1_0_1 method that anything in 1.0.1 or later would call. All code compiled against 1.0 would continue to call the old version and pass in a default value for the new argument that we added. The interesting thing here isn't can we come up with a scheme that enables us to fix bugs in the runtime from version to version. The real challenge is ensuring that we actually follow this pattern from version to version and verifying that old assemblies continue to run on newer versions of IronPython. That becomes an increasingly large test burden over time with an ever expanding test matrix as we ship each new version. Certainly within minor versions this is something we might be able to pull off with only a little difficulty but for example ensuring that v1.0 binaries work against v1.1 (or worse yet, v2.0) well be quite the challenge. One interesting question is why are people interested in this feature? Is it primarily for the improved performance that loading the cached DLL gives or is it for enabling the shipping of binary-only EXEs that run against arbitrary versions of IronPython.dll? It'd be interesting to see what most people want out of this feature to gauge how we should evolve this and the level of compatibility we should maintain between versions. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer Sent: Tuesday, January 23, 2007 11:01 AM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules I could be wrong (I certainly have been in the past), but the current scheme seems to pre-empt the built-in mechanisms. There are several ways you can get a reference to an assembly -- file name, name space without strong name, name space and version, name space and public key, etc. This works well enough for most (not all) purposes. If you want .NET to load the most recent version of an assembly, you just need to ask for it. If you require a certain version, or culture, you can ask for those as well. Consider an addin approach, where the IronPython.dll is the addin rather than a compile-time reference. If you did that, then the exe could have a bootstrapper that merely asks for the runtime without specifying strong names. It loads IronPython, potentially obeying any of the standard redirection declarations in exe.config. The exe then casts the IP runtime to IIronPython_1_0_1, and starts calling methods. In versioning IronPython, if a breaking change needs to happen, we can use explicit interfaces: public int IIronPython_1_0_0.Add(int x, int y) { return x + y + 0.1; } public int IIronPython_1_0_1.Add(int x, int y) { return x + y; // bug fix } .. I'm just doing this off the top of my head at the moment, but I think it'd at least alleviate some of the problem. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill Sent: Tuesday, January 23, 2007 7:22 AM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has to use the same centrally maintained copy of a DLL" the recipe for "DLL hell" that .Net is supposed to let us avoid? In the specific scenario you provide -- you update a DLL used by an existing EXE -- .Net is designed to keep using the old version of the DLL unless you either re-compile to re-build the EXE, or add an entry to the EXE's .config file that tells it that it's ok to use the newer one. (That only applies for DLLs in the GAC, as I understand it.) .Net isn't supposed to load app X that references DLL Y unless the "identity" of Y is the identity listed in the manifest for app X. Changing the identity of a DLL can be done by changing its version number; unfortunately, unless the DLL is installed in the GAC, you can't have two copies of the same DLL differing only in their version and have "the right one" (the one referenced by the EXE, or pointed to by the EXE's config file) load. Sigh. At 12:38 AM 1/23/2007, Keith J. Farmer wrote >Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location. > >The situation I see is: > >Install IronPython. >Install a binaries-only IP app. >Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load. > >So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source). > >Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs. > >-----Original Message----- >From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill >Sent: Monday, January 22, 2007 8:03 PM >To: Discussion of IronPython >Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > >Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? > >Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? > >At 09:24 PM 1/22/2007, Keith J. Farmer wrote >>the upgraded-ironpython scenario >> >>>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. >> >> >>That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). >> >>Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). >> >> >>________________________________ >> >>From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >>Sent: Mon 1/22/2007 4:44 PM >>To: Discussion of IronPython >>Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >> >> >> >>If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >> >>>>> Yes >> >>[snip] > > >J. Merrill / Analytical Software Corp > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com J. Merrill / Analytical Software Corp _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Tue Jan 23 21:00:37 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 23 Jan 2007 12:00:37 -0800 Subject: [IronPython] Problems with -X:SaveAssemblies In-Reply-To: References: <5b0248170701222325w2c05050iafc6c4681c76f5c4@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222762CA467319@DF-GRTDANE-MSG.exchange.corp.microsoft.com> It might be interesting to also run with -X:ExceptionDetail to see where the exception is coming from and report that back to the Mono team. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Haibo Luo Sent: Tuesday, January 23, 2007 9:05 AM To: Discussion of IronPython Subject: Re: [IronPython] Problems with -X:SaveAssemblies I did not see the repro in ironpython + .net. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Monday, January 22, 2007 11:26 PM To: Discussion of IronPython Subject: [IronPython] Problems with -X:SaveAssemblies I found this while testing precompiled module feature, but it's the same with plain 1.1a1. I'm not sure whether this is IronPython problem. Can anyone confirm this on .NET, not Mono? How to reproduce: 1. Create x/__init__.py and y/__init__.py as empty files. 2. Create z.py with content "import x, y". 3. Run z.py with and without -X:SaveAssemblies. Later produces null point exception for me. -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From kfarmer at thuban.org Tue Jan 23 21:03:17 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 23 Jan 2007 12:03:17 -0800 Subject: [IronPython] Feedbackneededfor bug fix:Import pre-compiledmodules Message-ID: If it did, I don't think we'd be getting the continuous updates. Thought some more on the commute. The are a couple problems, overall, when versioning. The basic problem I think is avoiding the dll explosion when maintaining side-by-side versions that are frequently updated. The explosion can happen either in the GAC or outside of it (ie, in binaries-only deployments). The GAC is less of an explosion. So, culture-wise, what can we do? I propose for the sake of hearing myself type that we maintain multiple a.b versions in the GAC, but only the latest of each (this follows what Microsoft has done, basically): IronPython 1.0.3.1234 IronPython 1.0.5.5678 replaces 1.0.3.x, bug fix. 1.0.3 apps can be expected to work correctly under 1.0.5. Correctly doesn't mean identically -- bug fixes *are* bug fixes. IronPython 1.1.0.9012 side-by-side with 1.0.x, API change. Assembly redirection or recompilation of exes can be expected. We limit the breaking API changes to infrequent drops. The second problem -- the actual dll hell -- is that in the current CLR, you cannot reference two different versions of the same (type.. assembly?). For example, you make a reference to version 2 of foo.dll, and a reference to bar.dll. Bar.dll makes a reference to the old version 1 foo.dll. Breakage occurs. The solution to that problem is different, and IMHO not something to solve independently of the rest of .NET. ________________________________ From: users-bounces at lists.ironpython.com on behalf of Bill64bits Sent: Tue 1/23/2007 11:33 AM To: Discussion of IronPython Subject: Re: [IronPython] Feedbackneededfor bug fix:Import pre-compiledmodules When/If IronPython becomes stable won't IronPython.dll just disappear into the .NET runtime? ----- Original Message ----- From: Keith J. Farmer To: Discussion of IronPython Sent: Tuesday, January 23, 2007 1:00 PM Subject: Re: [IronPython] Feedback neededfor bug fix:Import pre-compiledmodules I could be wrong (I certainly have been in the past), but the current scheme seems to pre-empt the built-in mechanisms. There are several ways you can get a reference to an assembly -- file name, name space without strong name, name space and version, name space and public key, etc. This works well enough for most (not all) purposes. If you want .NET to load the most recent version of an assembly, you just need to ask for it. If you require a certain version, or culture, you can ask for those as well. Consider an addin approach, where the IronPython.dll is the addin rather than a compile-time reference. If you did that, then the exe could have a bootstrapper that merely asks for the runtime without specifying strong names. It loads IronPython, potentially obeying any of the standard redirection declarations in exe.config. The exe then casts the IP runtime to IIronPython_1_0_1, and starts calling methods. In versioning IronPython, if a breaking change needs to happen, we can use explicit interfaces: public int IIronPython_1_0_0.Add(int x, int y) { return x + y + 0.1; } public int IIronPython_1_0_1.Add(int x, int y) { return x + y; // bug fix } .. I'm just doing this off the top of my head at the moment, but I think it'd at least alleviate some of the problem. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill Sent: Tuesday, January 23, 2007 7:22 AM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has to use the same centrally maintained copy of a DLL" the recipe for "DLL hell" that .Net is supposed to let us avoid? In the specific scenario you provide -- you update a DLL used by an existing EXE -- .Net is designed to keep using the old version of the DLL unless you either re-compile to re-build the EXE, or add an entry to the EXE's .config file that tells it that it's ok to use the newer one. (That only applies for DLLs in the GAC, as I understand it.) .Net isn't supposed to load app X that references DLL Y unless the "identity" of Y is the identity listed in the manifest for app X. Changing the identity of a DLL can be done by changing its version number; unfortunately, unless the DLL is installed in the GAC, you can't have two copies of the same DLL differing only in their version and have "the right one" (the one referenced by the EXE, or pointed to by the EXE's config file) load. Sigh. At 12:38 AM 1/23/2007, Keith J. Farmer wrote >Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location. > >The situation I see is: > >Install IronPython. >Install a binaries-only IP app. >Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load. > >So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source). > >Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs. > >-----Original Message----- >From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill >Sent: Monday, January 22, 2007 8:03 PM >To: Discussion of IronPython >Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > >Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? > >Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? > >At 09:24 PM 1/22/2007, Keith J. Farmer wrote >>the upgraded-ironpython scenario >> >>>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. >> >> >>That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). >> >>Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). >> >> >>________________________________ >> >>From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >>Sent: Mon 1/22/2007 4:44 PM >>To: Discussion of IronPython >>Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >> >> >> >>If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >> >>>>> Yes >> >>[snip] > > >J. Merrill / Analytical Software Corp > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com J. Merrill / Analytical Software Corp _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From kfarmer at thuban.org Tue Jan 23 21:18:15 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 23 Jan 2007 12:18:15 -0800 Subject: [IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules Message-ID: I was just latching myself onto the shipping-binaries-only blurb in the original email. :) My personal biases are against shipping source code, if for no other reason than it avoids the problems of office-chair programmers modifying code they don't actually understand. That, and the deployment tends to feel, well, cleaner. I don't think that -- as incredibly intelligent as she is -- we can expect my retired english teacher to understand how versioning works. She'll expect it to just work, modulo installing the latest IronPython, which may be newer than the exe. (Interesting feature to add to the exe -- option to include a way to automatically download and install the required version of IronPython...) ________________________________ From: users-bounces at lists.ironpython.com on behalf of Dino Viehland Sent: Tue 1/23/2007 12:00 PM To: Discussion of IronPython Subject: Re: [IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules One interesting question is why are people interested in this feature? Is it primarily for the improved performance that loading the cached DLL gives or is it for enabling the shipping of binary-only EXEs that run against arbitrary versions of IronPython.dll? It'd be interesting to see what most people want out of this feature to gauge how we should evolve this and the level of compatibility we should maintain between versions. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer Sent: Tuesday, January 23, 2007 11:01 AM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules I could be wrong (I certainly have been in the past), but the current scheme seems to pre-empt the built-in mechanisms. There are several ways you can get a reference to an assembly -- file name, name space without strong name, name space and version, name space and public key, etc. This works well enough for most (not all) purposes. If you want .NET to load the most recent version of an assembly, you just need to ask for it. If you require a certain version, or culture, you can ask for those as well. Consider an addin approach, where the IronPython.dll is the addin rather than a compile-time reference. If you did that, then the exe could have a bootstrapper that merely asks for the runtime without specifying strong names. It loads IronPython, potentially obeying any of the standard redirection declarations in exe.config. The exe then casts the IP runtime to IIronPython_1_0_1, and starts calling methods. In versioning IronPython, if a breaking change needs to happen, we can use explicit interfaces: public int IIronPython_1_0_0.Add(int x, int y) { return x + y + 0.1; } public int IIronPython_1_0_1.Add(int x, int y) { return x + y; // bug fix } .. I'm just doing this off the top of my head at the moment, but I think it'd at least alleviate some of the problem. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill Sent: Tuesday, January 23, 2007 7:22 AM To: Discussion of IronPython Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has to use the same centrally maintained copy of a DLL" the recipe for "DLL hell" that .Net is supposed to let us avoid? In the specific scenario you provide -- you update a DLL used by an existing EXE -- .Net is designed to keep using the old version of the DLL unless you either re-compile to re-build the EXE, or add an entry to the EXE's .config file that tells it that it's ok to use the newer one. (That only applies for DLLs in the GAC, as I understand it.) .Net isn't supposed to load app X that references DLL Y unless the "identity" of Y is the identity listed in the manifest for app X. Changing the identity of a DLL can be done by changing its version number; unfortunately, unless the DLL is installed in the GAC, you can't have two copies of the same DLL differing only in their version and have "the right one" (the one referenced by the EXE, or pointed to by the EXE's config file) load. Sigh. At 12:38 AM 1/23/2007, Keith J. Farmer wrote >Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location. > >The situation I see is: > >Install IronPython. >Install a binaries-only IP app. >Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load. > >So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source). > >Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs. > >-----Original Message----- >From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill >Sent: Monday, January 22, 2007 8:03 PM >To: Discussion of IronPython >Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > >Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? > >Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? > >At 09:24 PM 1/22/2007, Keith J. Farmer wrote >>the upgraded-ironpython scenario >> >>>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. >> >> >>That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). >> >>Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). >> >> >>________________________________ >> >>From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >>Sent: Mon 1/22/2007 4:44 PM >>To: Discussion of IronPython >>Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >> >> >> >>If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >> >>>>> Yes >> >>[snip] > > >J. Merrill / Analytical Software Corp > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com J. Merrill / Analytical Software Corp _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Wed Jan 24 00:17:09 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 23 Jan 2007 15:17:09 -0800 Subject: [IronPython] IronPython and Python 3 In-Reply-To: References: <45B2523D.8060304@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222762CA467457@DF-GRTDANE-MSG.exchange.corp.microsoft.com> We haven't had much in the ways of discussing supporting Py3k features yet and it might still be a little too early to do so. We have been following some of the changes and we'll probably start following the changes a little more closely. We also still have some catching up to do with v2.5 (1.1alpha has some improved support but is still missing a couple of features) as well. So no current plans yet but as that changes we'll be sure to let the community know. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Anthony Baxter Sent: Sunday, January 21, 2007 11:06 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython and Python 3 On 1/21/07, Michael Foord wrote: > Hello all, > > What is the IronPython team's intention with respect to Python 2.X and > Python 3 ? Note that Py3K is still a work in progress. Py2.6 will attempt to support (through use of from __future__, &c) compatibility with 2.5 as well as (hopefully) a lot of 3.0-isms. _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Wed Jan 24 00:24:46 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 23 Jan 2007 23:24:46 +0000 Subject: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules In-Reply-To: <7AD436E4270DD54A94238001769C222762CA467317@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222762CA467317@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <45B6993E.3060609@voidspace.org.uk> Dino Viehland wrote: > This should be solvable in a similar but slightly different way. We wouldn't want to require an extra argument (in this case the versioned IronPython engine) to be required for each call. Also I'm going to pick a slightly more generic example "DoOperation" instead of Add (because a bug fix to the semantics of Add would just change the body of Add and everything would be ok. A signature change is really more interesting). > > Static object DoOperation(object arg) { DoOperation_1_0_1(arg, null); } > Static object DoOperation_1_0_1(object arg1, object arg2) { ... } > > In this case we could preserve the old DoOperation method and add the new DoOperation_1_0_1 method that anything in 1.0.1 or later would call. All code compiled against 1.0 would continue to call the old version and pass in a default value for the new argument that we added. > > The interesting thing here isn't can we come up with a scheme that enables us to fix bugs in the runtime from version to version. The real challenge is ensuring that we actually follow this pattern from version to version and verifying that old assemblies continue to run on newer versions of IronPython. That becomes an increasingly large test burden over time with an ever expanding test matrix as we ship each new version. > > Certainly within minor versions this is something we might be able to pull off with only a little difficulty but for example ensuring that v1.0 binaries work against v1.1 (or worse yet, v2.0) well be quite the challenge. > > One interesting question is why are people interested in this feature? Is it primarily for the improved performance that loading the cached DLL gives or is it for enabling the shipping of binary-only EXEs that run against arbitrary versions of IronPython.dll? It'd be interesting to see what most people want out of this feature to gauge how we should evolve this and the level of compatibility we should maintain between versions. > > It is interesting to note that CPython makes no guarantees about binary compatibility between major version upgrades. It does guarantee compatibility between minor version changes. For people distributing applications it shouldn't be a problem, just recompile against the binary that you are distributing. Michael Foord http://www.voidspace.org.uk/python/articles.shtml > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer > Sent: Tuesday, January 23, 2007 11:01 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > > I could be wrong (I certainly have been in the past), but the current scheme seems to pre-empt the built-in mechanisms. > > There are several ways you can get a reference to an assembly -- file name, name space without strong name, name space and version, name space and public key, etc. This works well enough for most (not all) purposes. If you want .NET to load the most recent version of an assembly, you just need to ask for it. If you require a certain version, or culture, you can ask for those as well. > > Consider an addin approach, where the IronPython.dll is the addin rather than a compile-time reference. If you did that, then the exe could have a bootstrapper that merely asks for the runtime without specifying strong names. It loads IronPython, potentially obeying any of the standard redirection declarations in exe.config. The exe then casts the IP runtime to IIronPython_1_0_1, and starts calling methods. > > In versioning IronPython, if a breaking change needs to happen, we can use explicit interfaces: > > public int IIronPython_1_0_0.Add(int x, int y) { return x + y + 0.1; } > public int IIronPython_1_0_1.Add(int x, int y) { return x + y; // bug fix } > > .. I'm just doing this off the top of my head at the moment, but I think it'd at least alleviate some of the problem. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill > Sent: Tuesday, January 23, 2007 7:22 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > > I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has to use the same centrally maintained copy of a DLL" the recipe for "DLL hell" that .Net is supposed to let us avoid? In the specific scenario you provide -- you update a DLL used by an existing EXE -- .Net is designed to keep using the old version of the DLL unless you either re-compile to re-build the EXE, or add an entry to the EXE's .config file that tells it that it's ok to use the newer one. (That only applies for DLLs in the GAC, as I understand it.) > > .Net isn't supposed to load app X that references DLL Y unless the "identity" of Y is the identity listed in the manifest for app X. Changing the identity of a DLL can be done by changing its version number; unfortunately, unless the DLL is installed in the GAC, you can't have two copies of the same DLL differing only in their version and have "the right one" (the one referenced by the EXE, or pointed to by the EXE's config file) load. > > Sigh. > > At 12:38 AM 1/23/2007, Keith J. Farmer wrote > >> Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location. >> >> The situation I see is: >> >> Install IronPython. >> Install a binaries-only IP app. >> Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load. >> >> So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source). >> >> Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill >> Sent: Monday, January 22, 2007 8:03 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >> >> Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? >> >> Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? >> >> At 09:24 PM 1/22/2007, Keith J. Farmer wrote >> >>> the upgraded-ironpython scenario >>> >>> >>>>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. >>>>>> >>> That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). >>> >>> Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). >>> >>> >>> ________________________________ >>> >>> From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >>> Sent: Mon 1/22/2007 4:44 PM >>> To: Discussion of IronPython >>> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >>> >>> >>> >>> If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >>> >>> >>>>>> Yes >>>>>> >>> [snip] >>> >> J. Merrill / Analytical Software Corp >> >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > J. Merrill / Analytical Software Corp > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From fuzzyman at voidspace.org.uk Wed Jan 24 00:26:04 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 23 Jan 2007 23:26:04 +0000 Subject: [IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules In-Reply-To: References: Message-ID: <45B6998C.3040207@voidspace.org.uk> Keith J. Farmer wrote: > I was just latching myself onto the shipping-binaries-only blurb in the original email. :) > > My personal biases are against shipping source code, if for no other reason than it avoids the problems of office-chair programmers modifying code they don't actually understand. That, and the deployment tends to feel, well, cleaner. > > I don't think that -- as incredibly intelligent as she is -- we can expect my retired english teacher to understand how versioning works. She'll expect it to just work, modulo installing the latest IronPython, which may be newer than the exe. > > (Interesting feature to add to the exe -- option to include a way to automatically download and install the required version of IronPython...) > > Why not distribute the required dlls with your application ? Isn't it assumed that this is what most IronPython applications will do ? Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > > > ________________________________ > > From: users-bounces at lists.ironpython.com on behalf of Dino Viehland > Sent: Tue 1/23/2007 12:00 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules > > > > > One interesting question is why are people interested in this feature? Is it primarily for the improved performance that loading the cached DLL gives or is it for enabling the shipping of binary-only EXEs that run against arbitrary versions of IronPython.dll? It'd be interesting to see what most people want out of this feature to gauge how we should evolve this and the level of compatibility we should maintain between versions. > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer > Sent: Tuesday, January 23, 2007 11:01 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > > I could be wrong (I certainly have been in the past), but the current scheme seems to pre-empt the built-in mechanisms. > > There are several ways you can get a reference to an assembly -- file name, name space without strong name, name space and version, name space and public key, etc. This works well enough for most (not all) purposes. If you want .NET to load the most recent version of an assembly, you just need to ask for it. If you require a certain version, or culture, you can ask for those as well. > > Consider an addin approach, where the IronPython.dll is the addin rather than a compile-time reference. If you did that, then the exe could have a bootstrapper that merely asks for the runtime without specifying strong names. It loads IronPython, potentially obeying any of the standard redirection declarations in exe.config. The exe then casts the IP runtime to IIronPython_1_0_1, and starts calling methods. > > In versioning IronPython, if a breaking change needs to happen, we can use explicit interfaces: > > public int IIronPython_1_0_0.Add(int x, int y) { return x + y + 0.1; } > public int IIronPython_1_0_1.Add(int x, int y) { return x + y; // bug fix } > > .. I'm just doing this off the top of my head at the moment, but I think it'd at least alleviate some of the problem. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill > Sent: Tuesday, January 23, 2007 7:22 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > > I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has to use the same centrally maintained copy of a DLL" the recipe for "DLL hell" that .Net is supposed to let us avoid? In the specific scenario you provide -- you update a DLL used by an existing EXE -- .Net is designed to keep using the old version of the DLL unless you either re-compile to re-build the EXE, or add an entry to the EXE's .config file that tells it that it's ok to use the newer one. (That only applies for DLLs in the GAC, as I understand it.) > > .Net isn't supposed to load app X that references DLL Y unless the "identity" of Y is the identity listed in the manifest for app X. Changing the identity of a DLL can be done by changing its version number; unfortunately, unless the DLL is installed in the GAC, you can't have two copies of the same DLL differing only in their version and have "the right one" (the one referenced by the EXE, or pointed to by the EXE's config file) load. > > Sigh. > > At 12:38 AM 1/23/2007, Keith J. Farmer wrote > >> Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location. >> >> The situation I see is: >> >> Install IronPython. >> Install a binaries-only IP app. >> Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load. >> >> So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source). >> >> Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill >> Sent: Monday, January 22, 2007 8:03 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >> >> Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? >> >> Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? >> >> At 09:24 PM 1/22/2007, Keith J. Farmer wrote >> >>> the upgraded-ironpython scenario >>> >>> >>>>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. >>>>>> >>> That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). >>> >>> Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). >>> >>> >>> ________________________________ >>> >>> From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >>> Sent: Mon 1/22/2007 4:44 PM >>> To: Discussion of IronPython >>> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >>> >>> >>> >>> If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >>> >>> >>>>>> Yes >>>>>> >>> [snip] >>> >> J. Merrill / Analytical Software Corp >> >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > J. Merrill / Analytical Software Corp > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From fuzzyman at voidspace.org.uk Wed Jan 24 00:29:32 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 23 Jan 2007 23:29:32 +0000 Subject: [IronPython] IronPython and Python 3 In-Reply-To: <7AD436E4270DD54A94238001769C222762CA467457@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <45B2523D.8060304@voidspace.org.uk> <7AD436E4270DD54A94238001769C222762CA467457@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <45B69A5C.80802@voidspace.org.uk> Dino Viehland wrote: > We haven't had much in the ways of discussing supporting Py3k features yet and it might still be a little too early to do so. We have been following some of the changes and we'll probably start following the changes a little more closely. > > We also still have some catching up to do with v2.5 (1.1alpha has some improved support but is still missing a couple of features) as well. So no current plans yet but as that changes we'll be sure to let the community know. > Ok, great. So your only settled plans are to continue to support Python 2.X features (including 2.6 ones ?), but no decision yet on how to deal with Python 3. Michael Foord http://www.voidspace.org.uk/python/index.shtml > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Anthony Baxter > Sent: Sunday, January 21, 2007 11:06 PM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython and Python 3 > > On 1/21/07, Michael Foord wrote: > >> Hello all, >> >> What is the IronPython team's intention with respect to Python 2.X and >> Python 3 ? >> > > Note that Py3K is still a work in progress. Py2.6 will attempt to > support (through use of from __future__, &c) compatibility with 2.5 as > well as (hopefully) a lot of 3.0-isms. > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From nytrokiss at gmail.com Wed Jan 24 03:54:21 2007 From: nytrokiss at gmail.com (James Matthews) Date: Tue, 23 Jan 2007 21:54:21 -0500 Subject: [IronPython] IronPython and Python 3 In-Reply-To: <7AD436E4270DD54A94238001769C222762CA467457@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <45B2523D.8060304@voidspace.org.uk> <7AD436E4270DD54A94238001769C222762CA467457@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <8a6b8e350701231854n6d64c2cbl39fe8ca4e529d494@mail.gmail.com> Well i am sure that when python 3000 comes out iron python will be there with there version! On 1/23/07, Dino Viehland wrote: > > We haven't had much in the ways of discussing supporting Py3k features yet > and it might still be a little too early to do so. We have been following > some of the changes and we'll probably start following the changes a little > more closely. > > We also still have some catching up to do with v2.5 (1.1alpha has some > improved support but is still missing a couple of features) as well. So no > current plans yet but as that changes we'll be sure to let the community > know. > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Anthony Baxter > Sent: Sunday, January 21, 2007 11:06 PM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython and Python 3 > > On 1/21/07, Michael Foord wrote: > > Hello all, > > > > What is the IronPython team's intention with respect to Python 2.X and > > Python 3 ? > > Note that Py3K is still a work in progress. Py2.6 will attempt to > support (through use of from __future__, &c) compatibility with 2.5 as > well as (hopefully) a lot of 3.0-isms. > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.goldwatches.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Wed Jan 24 06:30:15 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 23 Jan 2007 21:30:15 -0800 Subject: [IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules Message-ID: It's not what I assumed. Most .NET applications in my experience don't package the framework when they're distributed. In fact, I tend to feel offended when I find an app has packaged the entire runtime it needs and included it in the install. Zope really annoyed me in this way, and don't get me started on the Starry Night updater -- it packages all of Java and that's not even for the main application. It means wasted space for me, as well as multiple versions lying about. It's a reinforcement of the old dll hell when people are hard at work trying to put it to rest. There should be a better means for cooperation between third party apps and the runtime as regards version. I don't make the claim that it's an easy problem to solve, but the solution shouldn't be at odds with the native support, nor should it put a burden on the end-user. My ideal, for example, would be to have IronPython-on-Windows included as a component via Microsoft Update, and serviced through those channels. This would mean, then, that IronPython apps would have to be safe against revisions. Perhaps under Vista. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Tuesday, January 23, 2007 3:26 PM To: Discussion of IronPython Subject: Re: [IronPython]Feedbackneeded for bug fix:Import pre-compiledmodules Keith J. Farmer wrote: > I was just latching myself onto the shipping-binaries-only blurb in the original email. :) > > My personal biases are against shipping source code, if for no other reason than it avoids the problems of office-chair programmers modifying code they don't actually understand. That, and the deployment tends to feel, well, cleaner. > > I don't think that -- as incredibly intelligent as she is -- we can expect my retired english teacher to understand how versioning works. She'll expect it to just work, modulo installing the latest IronPython, which may be newer than the exe. > > (Interesting feature to add to the exe -- option to include a way to automatically download and install the required version of IronPython...) > > Why not distribute the required dlls with your application ? Isn't it assumed that this is what most IronPython applications will do ? Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > > > ________________________________ > > From: users-bounces at lists.ironpython.com on behalf of Dino Viehland > Sent: Tue 1/23/2007 12:00 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules > > > > > One interesting question is why are people interested in this feature? Is it primarily for the improved performance that loading the cached DLL gives or is it for enabling the shipping of binary-only EXEs that run against arbitrary versions of IronPython.dll? It'd be interesting to see what most people want out of this feature to gauge how we should evolve this and the level of compatibility we should maintain between versions. > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer > Sent: Tuesday, January 23, 2007 11:01 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > > I could be wrong (I certainly have been in the past), but the current scheme seems to pre-empt the built-in mechanisms. > > There are several ways you can get a reference to an assembly -- file name, name space without strong name, name space and version, name space and public key, etc. This works well enough for most (not all) purposes. If you want .NET to load the most recent version of an assembly, you just need to ask for it. If you require a certain version, or culture, you can ask for those as well. > > Consider an addin approach, where the IronPython.dll is the addin rather than a compile-time reference. If you did that, then the exe could have a bootstrapper that merely asks for the runtime without specifying strong names. It loads IronPython, potentially obeying any of the standard redirection declarations in exe.config. The exe then casts the IP runtime to IIronPython_1_0_1, and starts calling methods. > > In versioning IronPython, if a breaking change needs to happen, we can use explicit interfaces: > > public int IIronPython_1_0_0.Add(int x, int y) { return x + y + 0.1; } > public int IIronPython_1_0_1.Add(int x, int y) { return x + y; // bug fix } > > .. I'm just doing this off the top of my head at the moment, but I think it'd at least alleviate some of the problem. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill > Sent: Tuesday, January 23, 2007 7:22 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules > > I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has to use the same centrally maintained copy of a DLL" the recipe for "DLL hell" that .Net is supposed to let us avoid? In the specific scenario you provide -- you update a DLL used by an existing EXE -- .Net is designed to keep using the old version of the DLL unless you either re-compile to re-build the EXE, or add an entry to the EXE's .config file that tells it that it's ok to use the newer one. (That only applies for DLLs in the GAC, as I understand it.) > > .Net isn't supposed to load app X that references DLL Y unless the "identity" of Y is the identity listed in the manifest for app X. Changing the identity of a DLL can be done by changing its version number; unfortunately, unless the DLL is installed in the GAC, you can't have two copies of the same DLL differing only in their version and have "the right one" (the one referenced by the EXE, or pointed to by the EXE's config file) load. > > Sigh. > > At 12:38 AM 1/23/2007, Keith J. Farmer wrote > >> Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location. >> >> The situation I see is: >> >> Install IronPython. >> Install a binaries-only IP app. >> Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load. >> >> So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source). >> >> Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill >> Sent: Monday, January 22, 2007 8:03 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >> >> Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? >> >> Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? >> >> At 09:24 PM 1/22/2007, Keith J. Farmer wrote >> >>> the upgraded-ironpython scenario >>> >>> >>>>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. >>>>>> >>> That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). >>> >>> Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). >>> >>> >>> ________________________________ >>> >>> From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >>> Sent: Mon 1/22/2007 4:44 PM >>> To: Discussion of IronPython >>> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >>> >>> >>> >>> If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >>> >>> >>>>>> Yes >>>>>> >>> [snip] >>> >> J. Merrill / Analytical Software Corp >> >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > J. Merrill / Analytical Software Corp > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Wed Jan 24 15:34:47 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 24 Jan 2007 14:34:47 +0000 Subject: [IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules In-Reply-To: References: Message-ID: <45B76E87.2000903@voidspace.org.uk> On Jan 24, 5:30 am, "Keith J. Farmer" wrote: > It's not what I assumed. Most .NET applications in my experience don't package the framework when they're distributed. In fact, I tend to feel offended when I find an app has packaged the entire runtime it needs and included it in the install. Zope really annoyed me in this way, and don't get me started on the Starry Night updater -- it packages all of Java and that's not even for the main application. It means wasted space for me, as well as multiple versions lying about. It's a reinforcement of the old dll hell when people are hard at work trying to put it to rest. > Distributing IronPython DLLs isn't quite analagous to distributing the 'whole framework'. Also, compiled executables have to have *some* dependency on the version of IronPython they were compiled for. Imagine if you have an executable compiled for IronPython 1.2 and the user has IronPython 1.1 in the GAC or somewhere else in their path. Surely *that's* DLL hell. Having a very strict dependency on version requires you to distribute the DLLs and recompile when you upgrade your Python version, *but* it reduces that kind of DLL hell. A globally installed IronPython is cool, having it a packaged part of the .NET framework is cooler - but won't that stop the kind of rapid development that the IronPython team have been doing ? After all they've been pushing out new versions every few weeks, which they couldn't really do if each version change had big ramifications for third party developers (us). Being only dependent on which version we choose to use, rather than whichever version the user has installed, seems like a better situation to me. > There should be a better means for cooperation between third party apps and the runtime as regards version. I don't make the claim that it's an easy problem to solve, but the solution shouldn't be at odds with the native support, nor should it put a burden on the end-user. > > My ideal, for example, would be to have IronPython-on-Windows included as a component via Microsoft Update, and serviced through those channels. This would mean, then, that IronPython apps would have to be safe against revisions. Perhaps under Vista. > Its finding a way to make apps safe against revisions that is difficult. If the only solution is for the IronPython team to keep backwards compatible with previous releases it might lead to the sources and the binaries growing a horrible amount of cruft. I don't see the downside of having to distribute DLLs with applications (and having a strong name dependency) in quite the same way you do, but if a solution can be found... great. Michael http://www.voidspace.org.uk/python/articles.shtml > > My ideal, for example, would be to have IronPython-on-Windows included as a component via Microsoft Update, and serviced through those channels. This would mean, then, that IronPython apps would have to be safe against revisions. Perhaps under Vista. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Tuesday, January 23, 2007 3:26 PM > To: Discussion of IronPython > Subject: Re: [IronPython]Feedbackneeded for bug fix:Import pre-compiledmodules > > Keith J. Farmer wrote: > >> I was just latching myself onto the shipping-binaries-only blurb in the original email. :) >> >> My personal biases are against shipping source code, if for no other reason than it avoids the problems of office-chair programmers modifying code they don't actually understand. That, and the deployment tends to feel, well, cleaner. >> >> I don't think that -- as incredibly intelligent as she is -- we can expect my retired english teacher to understand how versioning works. She'll expect it to just work, modulo installing the latest IronPython, which may be newer than the exe. >> >> (Interesting feature to add to the exe -- option to include a way to automatically download and install the required version of IronPython...) >> >> >> > Why not distribute the required dlls with your application ? Isn't it > assumed that this is what most IronPython applications will do ? > > Michael Foord > http://www.voidspace.org.uk/ironpython/index.shtml > > >> >> >> ________________________________ >> >> From: users-bounces at lists.ironpython.com on behalf of Dino Viehland >> Sent: Tue 1/23/2007 12:00 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules >> >> >> >> >> One interesting question is why are people interested in this feature? Is it primarily for the improved performance that loading the cached DLL gives or is it for enabling the shipping of binary-only EXEs that run against arbitrary versions of IronPython.dll? It'd be interesting to see what most people want out of this feature to gauge how we should evolve this and the level of compatibility we should maintain between versions. >> >> >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer >> Sent: Tuesday, January 23, 2007 11:01 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >> >> I could be wrong (I certainly have been in the past), but the current scheme seems to pre-empt the built-in mechanisms. >> >> There are several ways you can get a reference to an assembly -- file name, name space without strong name, name space and version, name space and public key, etc. This works well enough for most (not all) purposes. If you want .NET to load the most recent version of an assembly, you just need to ask for it. If you require a certain version, or culture, you can ask for those as well. >> >> Consider an addin approach, where the IronPython.dll is the addin rather than a compile-time reference. If you did that, then the exe could have a bootstrapper that merely asks for the runtime without specifying strong names. It loads IronPython, potentially obeying any of the standard redirection declarations in exe.config. The exe then casts the IP runtime to IIronPython_1_0_1, and starts calling methods. >> >> In versioning IronPython, if a breaking change needs to happen, we can use explicit interfaces: >> >> public int IIronPython_1_0_0.Add(int x, int y) { return x + y + 0.1; } >> public int IIronPython_1_0_1.Add(int x, int y) { return x + y; // bug fix } >> >> .. I'm just doing this off the top of my head at the moment, but I think it'd at least alleviate some of the problem. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill >> Sent: Tuesday, January 23, 2007 7:22 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >> >> I'm not arguing with you -- just playing devil's advocate. Isn't "everyone has to use the same centrally maintained copy of a DLL" the recipe for "DLL hell" that .Net is supposed to let us avoid? In the specific scenario you provide -- you update a DLL used by an existing EXE -- .Net is designed to keep using the old version of the DLL unless you either re-compile to re-build the EXE, or add an entry to the EXE's .config file that tells it that it's ok to use the newer one. (That only applies for DLLs in the GAC, as I understand it.) >> >> .Net isn't supposed to load app X that references DLL Y unless the "identity" of Y is the identity listed in the manifest for app X. Changing the identity of a DLL can be done by changing its version number; unfortunately, unless the DLL is installed in the GAC, you can't have two copies of the same DLL differing only in their version and have "the right one" (the one referenced by the EXE, or pointed to by the EXE's config file) load. >> >> Sigh. >> >> At 12:38 AM 1/23/2007, Keith J. Farmer wrote >> >> >>> Why do you assume the deployment will involve dropping IronPython in the application directory? Sure, you *could*, but it's unreasonable, I think, to force the end user to have Yet Another Copy of a dll when it could just reference the latest-and-greatest at a central location. >>> >>> The situation I see is: >>> >>> Install IronPython. >>> Install a binaries-only IP app. >>> Update IronPython to change a spelling error in a resource -- suddenly the app doesn't even load. >>> >>> So, for binaries-only, the situation's just plain broken. Granted, I'd wager that most Python is distributed with source (if not as source). >>> >>> Another alternative? Use explicit interfaces in the IronPython runtime to allow side-by-side versioning of the API. The exe's bootstrapper can load IronPython.dll without using the strong name, grab the runtime, cast to that interface and deal with versioning issues for some period of time before obsoletion. This would also allow developers to switch compatibility levels when testing their programs. >>> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill >>> Sent: Monday, January 22, 2007 8:03 PM >>> To: Discussion of IronPython >>> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >>> >>> Could IP just ignore the timestamp on ironpython.dll and let the .Net runtime figure out if there are any references to no-longer-present mechanisms within the binary? >>> >>> Keith, is it really the case that your clients without Python source are going to download new versions of IP and (this is important) put them in the directory with your software? That is, assuming that you put IP.DLL in the directory with the EXEs/DLLs you built, even if they're doing their own IP development elsewhere on the machine and updating it regularly, won't your executables use the old IP.DLL until you give them the new one (and presumably matching recompiled EXEs/DLLs)? >>> >>> At 09:24 PM 1/22/2007, Keith J. Farmer wrote >>> >>> >>>> the upgraded-ironpython scenario >>>> >>>> >>>> >>>>>>> I do not think this is supported. The pre-compiled module has much dependency on IronPython.dll. Some emitted calls in those modules could be changed (or removed) in the next version of IronPython.dll. >>>>>>> >>>>>>> >>>> That makes me itch... I understand runtime dependencies, but the binaries-only deployment scenario just dropped in value if they are completely invalidated because the runtime undergoes a minor rev (or is otherwise touched). >>>> >>>> Would it be possible for the runtime to query the assembly to determine if it's compatible or not? Some sort of poor man's static analysis (eg, a manifest of API dependencies could be generated when the assembly is stored to disk, and if the runtime doesn't find any in the list that match any breaking change from the producing version, it accepts it). >>>> >>>> >>>> ________________________________ >>>> >>>> From: users-bounces at lists.ironpython.com on behalf of Haibo Luo >>>> Sent: Mon 1/22/2007 4:44 PM >>>> To: Discussion of IronPython >>>> Subject: Re: [IronPython] Feedback needed for bug fix:Import pre-compiledmodules >>>> >>>> >>>> >>>> If ironpython.dll is newer than lib.exe, and lib.py does not exist, we should expect an exception? >>>> >>>> >>>> >>>>>>> Yes >>>>>>> >>>>>>> >>>> [snip] >>>> >>>> >>> J. Merrill / Analytical Software Corp >>> >>> >>> _______________________________________________ >>> users mailing list >>> users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> _______________________________________________ >>> users mailing list >>> users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >> J. Merrill / Analytical Software Corp >> >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> _______________________________________________ >> users mailing list >> users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From jvm_cop at spamcop.net Wed Jan 24 16:20:53 2007 From: jvm_cop at spamcop.net (J. Merrill) Date: Wed, 24 Jan 2007 10:20:53 -0500 Subject: [IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules Message-ID: <7.0.1.0.2.20070124094959.07aebcf8@wheresmymailserver.com> At 12:30 AM 1/24/2007, Keith J. Farmer wrote (in part) >There should be a better means for cooperation between third party apps and the runtime as regards version. I don't make the claim that it's an easy problem to solve, but the solution shouldn't be at odds with the native support, nor should it put a burden on the end-user. > >My ideal, for example, would be to have IronPython-on-Windows included as a component via Microsoft Update, and serviced through those channels. This would mean, then, that IronPython apps would have to be safe against revisions. Perhaps under Vista. If IronPython were installed in the GAC, new versions would lie side-by-side with old ones. A "publisher policy file" could be provided with the new version that tells the CLR that the new version is (supposed to be) 100% compatible with (some subset of existing) old versions, so that apps compiled against the older version will use the new version without needing to be recompiled. If the publisher policy file doesn't indicate complete compatibility, existing apps continue to use the version with which they were compiled. This prevents the "version N of DLL X was installed in system32, overwriting version M, because app B requires version N; this breaks app A that only works with version M of X" variant of DLL hell. If the developer (or user) of an app determines that the new version of IP will in fact work with the app without it being recompiled, she can put an instruction to load the newer DLL in the app.exe.config file. Similarly, if it turns out that the compatibility promised by the publisher policy file is not realized, the developer (or user) of the app can force the app to use the original version with which the app was compiled. This leaves the decision about whether to risk blindly using a new version without the component publisher's official sanction can be made by app developers (or users), and the decision can be changed easily (by modifying the app.exe.config file). This is the solution to DLL hell that .Net promises. It only works for apps compiled against components that are installed in the GAC. It works very well for professional component-builders (DevExpress, Infragistics, ComponentOne, etc) as they are able to deliver a new version along with an assertion that it is completely compatible (the publisher policy file) and all apps compiled against the old version will start using it. If they deliver a new version that they realize is not 100% compatible, they can indicate that as well -- existing apps will continue to work with the old version, newly built apps work with the new version, and the app developer (or user) can try out the new version with an existing app without recompiling and back out if there's trouble. This relatively wonderful scenario (at least compared to pre-.Net DLL hell) cannot be realized without the GAC, as it is only with components that are in the GAC (or in the framework itself) that different versions live "side by side" in a central location about which the CLR has full knowledge. If you develop a component and are unwilling to make the promises that are involved with GAC installation, the easiest and least-hellish solution is to put your component in the directory with the EXE (or in a subdirectory that the runtime will look in). This lets each app decide whether to continue to use the old version, or to use the new version without recompiling (risking a problem if the new version isn't completely compatible), and of course at any point the developers of the app can recompile with (and deliver) the new version. It is a sign of the relative immaturity of IronPython that its developers (correctly IMO) are not willing to do the extra work involved in installing in the GAC. Someday, IP will be in the GAC (or part of the framework). J. Merrill / Analytical Software Corp From dinov at exchange.microsoft.com Wed Jan 24 17:55:20 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 24 Jan 2007 08:55:20 -0800 Subject: [IronPython] type.__call__ again In-Reply-To: <5b0248170701230349v13610df4qe9a489bfbcdb884c@mail.gmail.com> References: <5b0248170701230349v13610df4qe9a489bfbcdb884c@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222762CA4675E7@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks for the bug report Seo. I've opened CodePlex bug #7594 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7594). It looks like the problem is that our type.__call__ is actually the type object it's self, CPython has a slot wrapper for __call__: >>> type.__call__ CPython has a slot wrapper for this: >>> type.__call__ We probably need to publish our own slot wrapper to make this work. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Tuesday, January 23, 2007 3:49 AM To: Discussion of IronPython Subject: [IronPython] type.__call__ again CPython >>> type.__call__(object) IronPython >>> type.__call__(object) Something's wrong... -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From kfarmer at thuban.org Wed Jan 24 21:41:02 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 24 Jan 2007 12:41:02 -0800 Subject: [IronPython] Feedbackneeded for bug fix:Import pre-compiledmodules Message-ID: I'd be perfectly happy to see it in the GAC, at this point. It would just have to coordinate updates without littering the GAC with weekly versions, even if it means the runtime dependency is actually handled at runtime instead of compile time. As for being part of the framework -- I hope not, at least not beyond parts of IP being elevated to the framework. Updates every other year would not be good for IP, which IMO should remain flexible enough to release on CPython's schedule in addition to its own. Thankfully, you don't have to be part of the framework to be part of the GAC. ________________________________ From: users-bounces at lists.ironpython.com on behalf of J. Merrill Sent: Wed 1/24/2007 7:20 AM It is a sign of the relative immaturity of IronPython that its developers (correctly IMO) are not willing to do the extra work involved in installing in the GAC. Someday, IP will be in the GAC (or part of the framework). J. Merrill / Analytical Software Corp From fuzzyman at voidspace.org.uk Sat Jan 27 00:03:18 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 26 Jan 2007 23:03:18 +0000 Subject: [IronPython] .NET Framework 2 and Windows Update Message-ID: <45BA88B6.1070109@voidspace.org.uk> Hello all, I recently acquired a new laptop, running Windows Media Center (based on XP). As part of the initial update, .NET 2.0 was installed (at least the runtime). Is this now standard practise for Windows update, has anyone else seen this ? If it is true that the .NET 2.0 runtime is now a 'standard' part of Windows, this is good news for IronPython. Of course I might have been hallucinating. :-) Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml From garage_dba at hotmail.com Sat Jan 27 01:15:14 2007 From: garage_dba at hotmail.com (Bill64bits) Date: Fri, 26 Jan 2007 18:15:14 -0600 Subject: [IronPython] .NET Framework 2 and Windows Update References: <45BA88B6.1070109@voidspace.org.uk> Message-ID: I read it is standard with Vista. That's only 90 million new pc's next year. That enough? I thought 3.0 would be on it, but guess not. As far as XP goes, maybe the OEM stuff now has 2.0 on it. What brand of laptop did you get? ----- Original Message ----- From: Michael Foord To: Discussion of IronPython Sent: Friday, January 26, 2007 5:03 PM Subject: [IronPython] .NET Framework 2 and Windows Update Hello all, I recently acquired a new laptop, running Windows Media Center (based on XP). As part of the initial update, .NET 2.0 was installed (at least the runtime). Is this now standard practise for Windows update, has anyone else seen this ? If it is true that the .NET 2.0 runtime is now a 'standard' part of Windows, this is good news for IronPython. Of course I might have been hallucinating. :-) Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sat Jan 27 01:18:18 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 27 Jan 2007 00:18:18 +0000 Subject: [IronPython] .NET Framework 2 and Windows Update In-Reply-To: References: <45BA88B6.1070109@voidspace.org.uk> Message-ID: <45BA9A4A.3030608@voidspace.org.uk> Bill64bits wrote: > I read it is standard with Vista. > That's only 90 million new pc's next year. That enough? > I thought 3.0 would be on it, but guess not. > > As far as XP goes, maybe the OEM stuff now has 2.0 on it. > What brand of laptop did you get? It's a Fujitsu Siemens Amilo. It wasn't an update to the 2.0 runtime that was pulled in by the Windows update, but the runtime itself. Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml > ----- Original Message ----- > *From:* Michael Foord > *To:* Discussion of IronPython > *Sent:* Friday, January 26, 2007 5:03 PM > *Subject:* [IronPython] .NET Framework 2 and Windows Update > > Hello all, > > I recently acquired a new laptop, running Windows Media Center > (based on > XP). > > As part of the initial update, .NET 2.0 was installed (at least the > runtime). > > Is this now standard practise for Windows update, has anyone else > seen > this ? > > If it is true that the .NET 2.0 runtime is now a 'standard' part of > Windows, this is good news for IronPython. Of course I might have > been > hallucinating. :-) > > Fuzzyman > http://www.voidspace.org.uk/ironpython/index.shtml > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From kfarmer at thuban.org Sat Jan 27 01:21:15 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Fri, 26 Jan 2007 16:21:15 -0800 Subject: [IronPython] .NET Framework 2 and Windows Update Message-ID: Actually, I think 3.0 is standard, but recall that 3.0 only extends 2.0's offerings -- you still need 2.0. I'd have to recheck my Vista boxen at home, but I recall I was able to create a quite-n-easy xaml page and display it (blank canvas with a button). Have you not been able to do the same? ________________________________ From: users-bounces at lists.ironpython.com on behalf of Bill64bits Sent: Fri 1/26/2007 4:15 PM To: Discussion of IronPython Subject: Re: [IronPython] .NET Framework 2 and Windows Update I read it is standard with Vista. That's only 90 million new pc's next year. That enough? I thought 3.0 would be on it, but guess not. As far as XP goes, maybe the OEM stuff now has 2.0 on it. What brand of laptop did you get? ----- Original Message ----- From: Michael Foord To: Discussion of IronPython Sent: Friday, January 26, 2007 5:03 PM Subject: [IronPython] .NET Framework 2 and Windows Update Hello all, I recently acquired a new laptop, running Windows Media Center (based on XP). As part of the initial update, .NET 2.0 was installed (at least the runtime). Is this now standard practise for Windows update, has anyone else seen this ? If it is true that the .NET 2.0 runtime is now a 'standard' part of Windows, this is good news for IronPython. Of course I might have been hallucinating. :-) Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From adam.hill at gmail.com Sat Jan 27 01:30:49 2007 From: adam.hill at gmail.com (Adam Hill) Date: Fri, 26 Jan 2007 18:30:49 -0600 Subject: [IronPython] .NET Framework 2 and Windows Update In-Reply-To: References: Message-ID: 3.0 *is* 2.0 3.0 == .NET 2.0 + WPF + WCF The big difference between the XP bits and the Vista bits are how WPF work with the DWM (on Vista) or the rendering mess that is GDI + XP :) From tim.joslyn at dilgenter.com Sat Jan 27 01:27:41 2007 From: tim.joslyn at dilgenter.com (Tim Joslyn) Date: Sat, 27 Jan 2007 00:27:41 -0000 Subject: [IronPython] unsubscribe References: Message-ID: <7BE0727108176D479E1FFDC5CBBB54A035BCF8@dilexc001.Dilgenter.INT> -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of users-request at lists.ironpython.com Sent: 26 January 2007 16:23 To: users at lists.ironpython.com Subject: users Digest, Vol 30, Issue 35 Send users mailing list submissions to users at lists.ironpython.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.ironpython.com/listinfo.cgi/users-ironpython.com or, via email, send a message with subject or body 'help' to users-request at lists.ironpython.com You can reach the person managing the list at users-owner at lists.ironpython.com When replying, please edit your Subject line so it is more specific than "Re: Contents of users digest..." Today's Topics: 1. .NET Framework 2 and Windows Update (Michael Foord) 2. Re: .NET Framework 2 and Windows Update (Bill64bits) 3. Re: .NET Framework 2 and Windows Update (Michael Foord) ---------------------------------------------------------------------- Message: 1 Date: Fri, 26 Jan 2007 23:03:18 +0000 From: Michael Foord Subject: [IronPython] .NET Framework 2 and Windows Update To: Discussion of IronPython Message-ID: <45BA88B6.1070109 at voidspace.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello all, I recently acquired a new laptop, running Windows Media Center (based on XP). As part of the initial update, .NET 2.0 was installed (at least the runtime). Is this now standard practise for Windows update, has anyone else seen this ? If it is true that the .NET 2.0 runtime is now a 'standard' part of Windows, this is good news for IronPython. Of course I might have been hallucinating. :-) Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml ------------------------------ Message: 2 Date: Fri, 26 Jan 2007 18:15:14 -0600 From: "Bill64bits" Subject: Re: [IronPython] .NET Framework 2 and Windows Update To: "Discussion of IronPython" Message-ID: Content-Type: text/plain; charset="iso-8859-1" I read it is standard with Vista. That's only 90 million new pc's next year. That enough? I thought 3.0 would be on it, but guess not. As far as XP goes, maybe the OEM stuff now has 2.0 on it. What brand of laptop did you get? ----- Original Message ----- From: Michael Foord To: Discussion of IronPython Sent: Friday, January 26, 2007 5:03 PM Subject: [IronPython] .NET Framework 2 and Windows Update Hello all, I recently acquired a new laptop, running Windows Media Center (based on XP). As part of the initial update, .NET 2.0 was installed (at least the runtime). Is this now standard practise for Windows update, has anyone else seen this ? If it is true that the .NET 2.0 runtime is now a 'standard' part of Windows, this is good news for IronPython. Of course I might have been hallucinating. :-) Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ironpython.com/pipermail/users-ironpython.com/attachments/2 0070126/dc6ca7dc/attachment-0001.html ------------------------------ Message: 3 Date: Sat, 27 Jan 2007 00:18:18 +0000 From: Michael Foord Subject: Re: [IronPython] .NET Framework 2 and Windows Update To: Discussion of IronPython Message-ID: <45BA9A4A.3030608 at voidspace.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Bill64bits wrote: > I read it is standard with Vista. > That's only 90 million new pc's next year. That enough? > I thought 3.0 would be on it, but guess not. > > As far as XP goes, maybe the OEM stuff now has 2.0 on it. > What brand of laptop did you get? It's a Fujitsu Siemens Amilo. It wasn't an update to the 2.0 runtime that was pulled in by the Windows update, but the runtime itself. Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml > ----- Original Message ----- > *From:* Michael Foord > *To:* Discussion of IronPython > *Sent:* Friday, January 26, 2007 5:03 PM > *Subject:* [IronPython] .NET Framework 2 and Windows Update > > Hello all, > > I recently acquired a new laptop, running Windows Media Center > (based on > XP). > > As part of the initial update, .NET 2.0 was installed (at least the > runtime). > > Is this now standard practise for Windows update, has anyone else > seen > this ? > > If it is true that the .NET 2.0 runtime is now a 'standard' part of > Windows, this is good news for IronPython. Of course I might have > been > hallucinating. :-) > > Fuzzyman > http://www.voidspace.org.uk/ironpython/index.shtml > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > ------------------------------ _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com End of users Digest, Vol 30, Issue 35 ************************************* This message has been scanned for viruses by BlackSpider MailControl providing total protection against email threats. For more information or to purchase BlackSpider for your organisation please call Dilgenter on 0870 350 0030. From kfarmer at thuban.org Sat Jan 27 08:43:33 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Fri, 26 Jan 2007 23:43:33 -0800 Subject: [IronPython] .NET Framework 2 and Windows Update Message-ID: Only in the unofficial sense. :) (I can *kinda* see why they'd call it 3.0, but only just kinda) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Adam Hill Sent: Friday, January 26, 2007 4:31 PM To: Discussion of IronPython Subject: Re: [IronPython] .NET Framework 2 and Windows Update 3.0 *is* 2.0 3.0 == .NET 2.0 + WPF + WCF The big difference between the XP bits and the Vista bits are how WPF work with the DWM (on Vista) or the rendering mess that is GDI + XP :) _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Sat Jan 27 15:20:11 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sat, 27 Jan 2007 23:20:11 +0900 Subject: [IronPython] os.access Message-ID: <5b0248170701270620x67a53285n2416f90e71afad30@mail.gmail.com> It would be nice to have a basic implementation of os.access in IronPython. As it is available for all of Windows/Unix/Macintosh in CPython, existing Python codes aiming to be portable don't shy away from using it. Especially, os.access(path, os.F_OK) seems to be widespread for checking existence of path, although I don't see why. Isn't it same as os.path.exists(path)? If you know how they differ, please enlighten me. Anyway, here are some usages of os.access in the wild: http://www.google.com/codesearch?q=os.access+F_OK CPython simply calls access() function of CRT to implement it on Windows: http://msdn2.microsoft.com/en-us/library/1w06ktdy(VS.80).aspx -- Seo Sanghyeon From sanxiyn at gmail.com Sat Jan 27 16:10:54 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sun, 28 Jan 2007 00:10:54 +0900 Subject: [IronPython] __builtins__ Message-ID: <5b0248170701270710s4a97d1c9tdc41702c76d8c107@mail.gmail.com> In CPython, __builtins__ is a module for the main script, but it is a dictionary for modules. This is quite confusing, and this behaviour is explicitly stated as an implementation detail. As far as I can tell, it is always a module in IronPython. http://docs.python.org/lib/module-builtin.html However, far too many existing CPython sources break beacuse of this on IronPython for my taste. The symptom is: TypeError: is not enumerable This is usually caused by well-intended codes as following: if 'sorted' not in __builtins__: def sorted(seq): seq = seq[:] seq.sort() return seq This lets one to keep compatibility with CPython versions before 2.4, while still using 2.4-introduced sorted() builtin. Here are some existing usages: http://www.google.com/codesearch?q=%22in+__builtins__%22 -- Seo Sanghyeon From sanxiyn at gmail.com Sat Jan 27 16:29:34 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sun, 28 Jan 2007 00:29:34 +0900 Subject: [IronPython] type.__call__ again In-Reply-To: <5b0248170701230349v13610df4qe9a489bfbcdb884c@mail.gmail.com> References: <5b0248170701230349v13610df4qe9a489bfbcdb884c@mail.gmail.com> Message-ID: <5b0248170701270729j7b73fa3ci95ea6d456e346d33@mail.gmail.com> 2007/1/23, Sanghyeon Seo : > CPython > >>> type.__call__(object) > > > IronPython > >>> type.__call__(object) > This affects Mako template library as well as SQLAlchemy database toolkit. Here is a usage in Mako: http://www.makotemplates.org/trac/browser/mako/trunk/lib/mako/parsetree.py?rev=181#L136 -- Seo Sanghyeon From jvm_cop at spamcop.net Sun Jan 28 04:16:23 2007 From: jvm_cop at spamcop.net (J. Merrill) Date: Sat, 27 Jan 2007 22:16:23 -0500 Subject: [IronPython] __builtins__ In-Reply-To: <5b0248170701270710s4a97d1c9tdc41702c76d8c107@mail.gmail.co m> References: <5b0248170701270710s4a97d1c9tdc41702c76d8c107@mail.gmail.com> Message-ID: <7.0.1.0.2.20070127221255.07bb1030@wheresmymailserver.com> Is it a typo that it says "...builtin__'> is not enumerable" (vs builtins)? Would a solution be to implement the enumerable mechanism (over the names of the attributes) for __builtins__ ? That would not be hard to do (I don't think) and would be unlikely to cause much trouble. At 10:10 AM 1/27/2007, Sanghyeon Seo wrote >In CPython, __builtins__ is a module for the main script, but it is a >dictionary for modules. This is quite confusing, and this behaviour is >explicitly stated as an implementation detail. As far as I can tell, >it is always a module in IronPython. > >http://docs.python.org/lib/module-builtin.html > >However, far too many existing CPython sources break beacuse of this >on IronPython for my taste. The symptom is: > >TypeError: is not enumerable > >This is usually caused by well-intended codes as following: > >if 'sorted' not in __builtins__: > def sorted(seq): > seq = seq[:] > seq.sort() > return seq > >This lets one to keep compatibility with CPython versions before 2.4, >while still using 2.4-introduced sorted() builtin. > >Here are some existing usages: >http://www.google.com/codesearch?q=%22in+__builtins__%22 J. Merrill / Analytical Software Corp From sanxiyn at gmail.com Sun Jan 28 07:00:35 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sun, 28 Jan 2007 15:00:35 +0900 Subject: [IronPython] __builtins__ In-Reply-To: <7.0.1.0.2.20070127221255.07bb1030@wheresmymailserver.com> References: <5b0248170701270710s4a97d1c9tdc41702c76d8c107@mail.gmail.com> <7.0.1.0.2.20070127221255.07bb1030@wheresmymailserver.com> Message-ID: <5b0248170701272200g4f0700ddr25822d66e7f8887@mail.gmail.com> 2007/1/28, J. Merrill : > Is it a typo that it says "...builtin__'> is not enumerable" (vs builtins)? No. __builtin__ is a module. __builtins__ is a special variable that may point to either a module or a module's dictionary. > Would a solution be to implement the enumerable mechanism (over the names of the attributes) for __builtins__ ? That would not be hard to do (I don't think) and would be unlikely to cause much trouble. The Right Thing would be make CPython's __builtins__ consistent, or remove it altogether. Either ways will cause compatibility trouble, so they are unlikely to happen I guess. Oh, perhaps I should bring this topic to Python 3000 list. My proposed solution is to let __builtins__ point to dictionary instead of module when module is imported. -- Seo Sanghyeon From erzengel-von-licht at cox.net Sun Jan 28 09:05:03 2007 From: erzengel-von-licht at cox.net (Erzengel des Lichtes) Date: Sun, 28 Jan 2007 00:05:03 -0800 Subject: [IronPython] Suspending, saving script execution? Message-ID: <003701c742b3$04038ff0$6701a8c0@cxm> I want to use IronPython in a game of mine, but not as the primary programming language (that's written in an amalgamation of C++, C++/CLI, and C#), instead as programmable behavior to allow users to program units and the AI. In order to accomplish this I need to be able to suspend a script without suspending the thread it resides in. For Example, say there is a function move that orders an object to move forward a certain amount of meters at default speed. There is also a turn function that orders the object to turn a certain amount to the left. I then get the following script from the user: def main(self): self.move(5) self.turn(90) if self.direction == Direction.East: self.turn(180) self.move(2) Now, the script is going to need to be suspended while it's moving 5 meters (it's not going to teleport) forward, then again while it's turning 90 degrees to the right, possibly again when it turns around, and finally once again while moving forward 2 meters. I can't block the script without suspending the thread/fiber, right? But with a large number of scriptable units, the system will not be able to cope with a thread/fiber per script. In addition, I need to be able to save the stack, any dynamic memory being used, and the instruction pointer, as well as the generated code. From what I can tell, IronPython and Cpython both provide "black boxes" that cannot be saved--IronPython providing dynamically generated managed code. I do not know of any way that I can save the code and all data from such an environment. What options would I really have to accomplish this? Is there any way to save/set the instruction pointer/stack frame through MSIL? Is there anything in IronPython's engine that might let me do this? Or perhaps I should just pull in IronPython's Parser and make my own compiler? Any other ideas? Thanks for any help, Erzengel des Lichtes Hikari no Daitenshi Archangel of Light From curt at hagenlocher.org Sun Jan 28 18:36:55 2007 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Sun, 28 Jan 2007 09:36:55 -0800 Subject: [IronPython] Suspending, saving script execution? In-Reply-To: <003701c742b3$04038ff0$6701a8c0@cxm> References: <003701c742b3$04038ff0$6701a8c0@cxm> Message-ID: On 1/28/07, Erzengel des Lichtes wrote: > > Now, the script is going to need to be suspended while it's moving 5 > meters > (it's not going to teleport) forward, then again while it's turning 90 > degrees to the right, possibly again when it turns around, and finally > once > again while moving forward 2 meters. > I can't block the script without suspending the thread/fiber, right? But > with a large number of scriptable units, the system will not be able to > cope > with a thread/fiber per script. This sounds like the sort of thing that Stackless Python[1] was invented for. This is a variation of CPython that -- by removing the dependency of Python code execution on the processor's stack -- allows execution of multiple objects without creating multiple threads. The game "EVE Online" uses Stackless Python for this purpose. I doubt you could accomplish something similar in IronPython simply because of how the CLR works. But the low-level hooks in CLR 2.0 that were created for SQL Server may allow something in that direction. 1: http://www.stackless.com 2: http://www.eve-online.com -- Curt Hagenlocher curt at hagenlocher.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvm_cop at spamcop.net Mon Jan 29 01:37:43 2007 From: jvm_cop at spamcop.net (J. Merrill) Date: Sun, 28 Jan 2007 19:37:43 -0500 Subject: [IronPython] os.access In-Reply-To: <5b0248170701270620x67a53285n2416f90e71afad30@mail.gmail.co m> References: <5b0248170701270620x67a53285n2416f90e71afad30@mail.gmail.com> Message-ID: <7.0.1.0.2.20070128193238.07b3c390@wheresmymailserver.com> The CRT (C-language runtime) is not available to .Net code (except through unmanaged code), so it's not as simple to do this as just P/Invoking that routine. Unfortunately the pointer in the page you mention below to the .Net equivalent doesn't point to the description of code that does the equivalent thing; it points to the definition of an enumeration that needs to be used in the implementation of a method equivalent to access(). At 09:20 AM 1/27/2007, Sanghyeon Seo wrote (in part) >It would be nice to have a basic implementation of os.access in IronPython. >[snip] >CPython simply calls access() function of CRT to implement it on Windows: >http://msdn2.microsoft.com/en-us/library/1w06ktdy(VS.80).aspx > >-- >Seo Sanghyeon J. Merrill / Analytical Software Corp From slide.o.mix at gmail.com Mon Jan 29 02:06:00 2007 From: slide.o.mix at gmail.com (Slide) Date: Sun, 28 Jan 2007 18:06:00 -0700 Subject: [IronPython] os.access In-Reply-To: <7.0.1.0.2.20070128193238.07b3c390@wheresmymailserver.com> References: <5b0248170701270620x67a53285n2416f90e71afad30@mail.gmail.com> <7.0.1.0.2.20070128193238.07b3c390@wheresmymailserver.com> Message-ID: On 1/28/07, J. Merrill wrote: > The CRT (C-language runtime) is not available to .Net code (except through unmanaged code), so it's not as simple to do this as just P/Invoking that routine. > > Unfortunately the pointer in the page you mention below to the .Net equivalent doesn't point to the description of code that does the equivalent thing; it points to the definition of an enumeration that needs to be used in the implementation of a method equivalent to access(). > > At 09:20 AM 1/27/2007, Sanghyeon Seo wrote (in part) > >It would be nice to have a basic implementation of os.access in IronPython. > >[snip] > >CPython simply calls access() function of CRT to implement it on Windows: > >http://msdn2.microsoft.com/en-us/library/1w06ktdy(VS.80).aspx > > > >-- > >Seo Sanghyeon > > After following through some of the links on the page for the access function, wouldn't the System.IO.FileInfo class with its .Exists, .IsReadOnly, etc members come the closest in functionality? I don't know how you would do write only, but if you figured that out, you could find out read and write as well. access also works on directories as well, so you might have to go with System.IO.FileSystemInfo, or check whether the item was a directory or file before checking the access. slide From Jonathan.Hogg at kbcaim.com Mon Jan 29 10:01:39 2007 From: Jonathan.Hogg at kbcaim.com (Hogg, Jonathan) Date: Mon, 29 Jan 2007 09:01:39 -0000 Subject: [IronPython] Suspending, saving script execution? Message-ID: <716052183E837C44BCAAFEBABBD8A3EF020AE761@london.kbcfp.com> Stackless Python is definitely the way to go, but if you needed to do this in IronPython/.NET, you can get a poor man's form of micro-threading with generators. Taking your example, you could re-write it like so: def main(self): yield move(5) yield turn(90) if self.direction == Direction.East: yield turn(180) yield move(2) where 'move' and 'turn' are type constructors - or factory functions or whatever - that return an object representing the action to be taken. Now you instantiate the generator to create your micro-thread, and call '.next()' on it to execute it up to the next yield. t1 = mytank.main() action = t1.next() The difference between this and full threading is that it's cooperative and that you have to write your own micro-thread scheduler. Presumably you'll have some kind of game-state/event engine that will keep track of what each of the actors is currently doing and when they become eligible for execution again (it's finished moving/turning), you would poke them to see what they want to do next. Main problem is that if a piece of user-generated logic is badly behaved (doesn't yield), then your game would hang. Jonathan ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: 28 January 2007 17:37 To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? On 1/28/07, Erzengel des Lichtes wrote: Now, the script is going to need to be suspended while it's moving 5 meters (it's not going to teleport) forward, then again while it's turning 90 degrees to the right, possibly again when it turns around, and finally once again while moving forward 2 meters. I can't block the script without suspending the thread/fiber, right? But with a large number of scriptable units, the system will not be able to cope with a thread/fiber per script. This sounds like the sort of thing that Stackless Python[1] was invented for. This is a variation of CPython that -- by removing the dependency of Python code execution on the processor's stack -- allows execution of multiple objects without creating multiple threads. The game "EVE Online" uses Stackless Python for this purpose. I doubt you could accomplish something similar in IronPython simply because of how the CLR works. But the low-level hooks in CLR 2.0 that were created for SQL Server may allow something in that direction. 1: http://www.stackless.com 2: http://www.eve-online.com -- Curt Hagenlocher curt at hagenlocher.org -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of KBC Alternative Investment Management Limited or its affiliates, or any funds or accounts managed or advised by any of the aforementioned entities (together referred to as "KBC AIM"). This message does not create any obligation, contractual or otherwise, on the part of KBC AIM. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC AIM would enter into a transaction, or prices at which similar transactions may be carried on KBC AIM's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. From dinov at exchange.microsoft.com Mon Jan 29 21:53:10 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 29 Jan 2007 12:53:10 -0800 Subject: [IronPython] __builtins__ In-Reply-To: <5b0248170701270710s4a97d1c9tdc41702c76d8c107@mail.gmail.com> References: <5b0248170701270710s4a97d1c9tdc41702c76d8c107@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222765BB6CE70E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks for reporting this bug. I've opened CodePlex bug #7766 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7766). There's some other weird behavior I was looking at for __builtins__ last week and maybe this will turn out to be related. Redefining __builtins__ at the console changes the behavior of import (e.g. import sys will fail if __builtins__ doesn't have __import__ defined on it) but this doesn't work at the module level. I'll need to dig deeper to see if there's some dependency of this being a dictionary or a module but it is interesting. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Saturday, January 27, 2007 7:11 AM To: Discussion of IronPython Subject: [IronPython] __builtins__ In CPython, __builtins__ is a module for the main script, but it is a dictionary for modules. This is quite confusing, and this behaviour is explicitly stated as an implementation detail. As far as I can tell, it is always a module in IronPython. http://docs.python.org/lib/module-builtin.html However, far too many existing CPython sources break beacuse of this on IronPython for my taste. The symptom is: TypeError: is not enumerable This is usually caused by well-intended codes as following: if 'sorted' not in __builtins__: def sorted(seq): seq = seq[:] seq.sort() return seq This lets one to keep compatibility with CPython versions before 2.4, while still using 2.4-introduced sorted() builtin. Here are some existing usages: http://www.google.com/codesearch?q=%22in+__builtins__%22 -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Mon Jan 29 22:48:21 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 29 Jan 2007 13:48:21 -0800 Subject: [IronPython] Suspending, saving script execution? In-Reply-To: <716052183E837C44BCAAFEBABBD8A3EF020AE761@london.kbcfp.com> References: <716052183E837C44BCAAFEBABBD8A3EF020AE761@london.kbcfp.com> Message-ID: <7AD436E4270DD54A94238001769C222765BB6CE77F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Presumably someone could also modify IronPython's CodeGen class to turn all methods into generators that yield at regular intervals. This would take a significant performance hit as all the locals would be hoisted into a FunctionEnvironmentDictionary and would still need the scheduler / virtual stack maintenance but be an interesting experiment. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Hogg, Jonathan Sent: Monday, January 29, 2007 1:02 AM To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? Stackless Python is definitely the way to go, but if you needed to do this in IronPython/.NET, you can get a poor man's form of micro-threading with generators. Taking your example, you could re-write it like so: def main(self): yield move(5) yield turn(90) if self.direction == Direction.East: yield turn(180) yield move(2) where 'move' and 'turn' are type constructors - or factory functions or whatever - that return an object representing the action to be taken. Now you instantiate the generator to create your micro-thread, and call '.next()' on it to execute it up to the next yield. t1 = mytank.main() action = t1.next() The difference between this and full threading is that it's cooperative and that you have to write your own micro-thread scheduler. Presumably you'll have some kind of game-state/event engine that will keep track of what each of the actors is currently doing and when they become eligible for execution again (it's finished moving/turning), you would poke them to see what they want to do next. Main problem is that if a piece of user-generated logic is badly behaved (doesn't yield), then your game would hang. Jonathan ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: 28 January 2007 17:37 To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? On 1/28/07, Erzengel des Lichtes wrote: Now, the script is going to need to be suspended while it's moving 5 meters (it's not going to teleport) forward, then again while it's turning 90 degrees to the right, possibly again when it turns around, and finally once again while moving forward 2 meters. I can't block the script without suspending the thread/fiber, right? But with a large number of scriptable units, the system will not be able to cope with a thread/fiber per script. This sounds like the sort of thing that Stackless Python[1] was invented for. This is a variation of CPython that -- by removing the dependency of Python code execution on the processor's stack -- allows execution of multiple objects without creating multiple threads. The game "EVE Online" uses Stackless Python for this purpose. I doubt you could accomplish something similar in IronPython simply because of how the CLR works. But the low-level hooks in CLR 2.0 that were created for SQL Server may allow something in that direction. 1: http://www.stackless.com 2: http://www.eve-online.com -- Curt Hagenlocher curt at hagenlocher.org -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of KBC Alternative Investment Management Limited or its affiliates, or any funds or accounts managed or advised by any of the aforementioned entities (together referred to as "KBC AIM"). This message does not create any obligation, contractual or otherwise, on the part of KBC AIM. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC AIM would enter into a transaction, or prices at which similar transactions may be carried on KBC AIM's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From erzengel-von-licht at cox.net Mon Jan 29 23:59:46 2007 From: erzengel-von-licht at cox.net (Erzengel des Lichtes) Date: Mon, 29 Jan 2007 14:59:46 -0800 Subject: [IronPython] Suspending, saving script execution? In-Reply-To: <7AD436E4270DD54A94238001769C222765BB6CE77F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <009401c743f9$2c0521c0$6701a8c0@cxm> Thanks for the responses, I've considered using yield, which is what drew me to Python in the first place, but I operate under the theory that the developer should make it as easy as possible for the user, not themselves. Which means I need to do the yielding automatically on the C# side. What I really want is to use the reflectance available in .net, but I don't need the script itself to be turned into MSIL. The script should be able to be suspended anywhere in the script so that I can save/load (and prevent hanging by interrupting a long script, then let it continue after other scripts have had a chance to run). On the other hand, all .net methods will be atomic. I don't really care much about the performance of the scripts as they're supposed to be very high level; everything performance critical is written in C++, and everything else (except AI and scene choreography) is in C# (the glue is in C++/CLI). Only AI, scene choreography, and user scripts are in python. More often than not, a python script will probably be in its suspended state, waiting for "move" or whatever to return. The script's performance isn't much of a concern when the script isn't actually doing anything most of the time. Up until now I've just been looking into completely replacing PythonEngine, just using Compiler.Parser, but I'll look into Compiler.Generation.CodeGen, as well. I just haven't become very familiar with the internals of IronPython so any pointers would be appreciated (at the moment, I'm just following execution in the debugger). Erzengel des Lichtes Hikari no Daitenshi Archangel of Light -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, January 29, 2007 1:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? Presumably someone could also modify IronPython's CodeGen class to turn all methods into generators that yield at regular intervals. This would take a significant performance hit as all the locals would be hoisted into a FunctionEnvironmentDictionary and would still need the scheduler / virtual stack maintenance but be an interesting experiment. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Hogg, Jonathan Sent: Monday, January 29, 2007 1:02 AM To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? Stackless Python is definitely the way to go, but if you needed to do this in IronPython/.NET, you can get a poor man's form of micro-threading with generators. Taking your example, you could re-write it like so: def main(self): yield move(5) yield turn(90) if self.direction == Direction.East: yield turn(180) yield move(2) where 'move' and 'turn' are type constructors - or factory functions or whatever - that return an object representing the action to be taken. Now you instantiate the generator to create your micro-thread, and call '.next()' on it to execute it up to the next yield. t1 = mytank.main() action = t1.next() The difference between this and full threading is that it's cooperative and that you have to write your own micro-thread scheduler. Presumably you'll have some kind of game-state/event engine that will keep track of what each of the actors is currently doing and when they become eligible for execution again (it's finished moving/turning), you would poke them to see what they want to do next. Main problem is that if a piece of user-generated logic is badly behaved (doesn't yield), then your game would hang. Jonathan ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: 28 January 2007 17:37 To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? On 1/28/07, Erzengel des Lichtes wrote: Now, the script is going to need to be suspended while it's moving 5 meters (it's not going to teleport) forward, then again while it's turning 90 degrees to the right, possibly again when it turns around, and finally once again while moving forward 2 meters. I can't block the script without suspending the thread/fiber, right? But with a large number of scriptable units, the system will not be able to cope with a thread/fiber per script. This sounds like the sort of thing that Stackless Python[1] was invented for. This is a variation of CPython that -- by removing the dependency of Python code execution on the processor's stack -- allows execution of multiple objects without creating multiple threads. The game "EVE Online" uses Stackless Python for this purpose. I doubt you could accomplish something similar in IronPython simply because of how the CLR works. But the low-level hooks in CLR 2.0 that were created for SQL Server may allow something in that direction. 1: http://www.stackless.com 2: http://www.eve-online.com -- Curt Hagenlocher curt at hagenlocher.org -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of KBC Alternative Investment Management Limited or its affiliates, or any funds or accounts managed or advised by any of the aforementioned entities (together referred to as "KBC AIM"). This message does not create any obligation, contractual or otherwise, on the part of KBC AIM. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC AIM would enter into a transaction, or prices at which similar transactions may be carried on KBC AIM's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From xmlhacker at gmail.com Tue Jan 30 02:56:38 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Mon, 29 Jan 2007 18:56:38 -0700 Subject: [IronPython] Suspending, saving script execution? In-Reply-To: <009401c743f9$2c0521c0$6701a8c0@cxm> References: <7AD436E4270DD54A94238001769C222765BB6CE77F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <009401c743f9$2c0521c0$6701a8c0@cxm> Message-ID: > so any pointers would be appreciated (at the moment, I'm just > following execution in the debugger). While not directly related to IronPython (or MSFT for that matter), this seems like a perfect use-case for Vista Smalltalk (non-MS implementation of Smalltalk and Lisp; see: VST Wiki). I've Cc'd the group mailing list [see: Group List; VST Group: Please see the inline message for proper context.] While not a perfect 1-to-1 comparison, [see: Example:1] showcases how one would go about editing the generated Lisp-code from a circle drawn in the visual drawing tool that is part of the VST XBAP application [see: VSB; requires IE7/.NET 3.0 libraries, though WPF/e will be providing a cross-browser/platform capability in the coming months, from what I understand.] It would seem to me that the combination of the message-based approach provided by Smalltalk, and the list-processing approach of Lisp, by breaking any given script into smaller pieces, and building agents to handle the sending/receiving/processing of each message would provide exactly what you would need to accomplish the task of suspending and resuming action as necessary. While I can't say for sure, it would seem to me that adding IronPython to the mix *should* be pretty straight forward: Adding both assemblies to your project, and using a dictionary for ease of storage/access/editing of various Smalltalk and/or Lisp scripts, you could use a pretty straight forward declarative script syntax that would hide any unnecessary complexity from the user. How practical this would be in terms of performance is a definite unknown at this state, but it at least seems to provide a reasonable expectation for performance if care was taken to build in a proper caching mechanism. VST Wiki: http://vistascript.net/ Group List: http://groups.google.ca/group/Vista-Smalltallk Example:1: http://vistasmalltalk.wordpress.com/2007/01/29/modifying-generated-lisp/ VSB: http://vistascript.net/vistascript/vsb/Vsb.xbap Peter Fisk's (VST creator) blog: http://vistasmalltalk.wordpress.com/ On 1/29/07, Erzengel des Lichtes wrote: > > Thanks for the responses, > > I've considered using yield, which is what drew me to Python in the first > place, but I operate under the theory that the developer should make it as > easy as possible for the user, not themselves. Which means I need to do > the > yielding automatically on the C# side. > > What I really want is to use the reflectance available in .net, but I > don't > need the script itself to be turned into MSIL. The script should be able > to > be suspended anywhere in the script so that I can save/load (and prevent > hanging by interrupting a long script, then let it continue after other > scripts have had a chance to run). On the other hand, all .net methods > will > be atomic. > I don't really care much about the performance of the scripts as they're > supposed to be very high level; everything performance critical is written > in C++, and everything else (except AI and scene choreography) is in C# > (the > glue is in C++/CLI). Only AI, scene choreography, and user scripts are in > python. More often than not, a python script will probably be in its > suspended state, waiting for "move" or whatever to return. The script's > performance isn't much of a concern when the script isn't actually doing > anything most of the time. > > Up until now I've just been looking into completely replacing > PythonEngine, > just using Compiler.Parser, but I'll look into Compiler.Generation.CodeGen > , > as well. I just haven't become very familiar with the internals of > IronPython so any pointers would be appreciated (at the moment, I'm just > following execution in the debugger). > > Erzengel des Lichtes > Hikari no Daitenshi > Archangel of Light > > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Monday, January 29, 2007 1:48 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Suspending, saving script execution? > > Presumably someone could also modify IronPython's CodeGen class to turn > all > methods into generators that yield at regular intervals. This would take > a > significant performance hit as all the locals would be hoisted into a > FunctionEnvironmentDictionary and would still need the scheduler / virtual > stack maintenance but be an interesting experiment. > > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Hogg, Jonathan > Sent: Monday, January 29, 2007 1:02 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Suspending, saving script execution? > > Stackless Python is definitely the way to go, but if you needed to do this > in IronPython/.NET, you can get a poor man's form of micro-threading with > generators. Taking your example, you could re-write it like so: > > def main(self): > yield move(5) > yield turn(90) > if self.direction == Direction.East: > yield turn(180) > yield move(2) > > where 'move' and 'turn' are type constructors - or factory functions or > whatever - that return an object representing the action to be taken. > Now you instantiate the generator to create your micro-thread, and call > '.next()' on it to execute it up to the next yield. > > t1 = mytank.main() > action = t1.next() > > The difference between this and full threading is that it's cooperative > and > that you have to write your own micro-thread scheduler. Presumably you'll > have some kind of game-state/event engine that will keep track of what > each > of the actors is currently doing and when they become eligible for > execution > again (it's finished moving/turning), you would poke them to see what they > want to do next. > > Main problem is that if a piece of user-generated logic is badly behaved > (doesn't yield), then your game would hang. > > Jonathan > > ________________________________ > > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher > Sent: 28 January 2007 17:37 > To: Discussion of IronPython > Subject: Re: [IronPython] Suspending, saving script execution? > > > On 1/28/07, Erzengel des Lichtes wrote: > > Now, the script is going to need to be suspended while it's moving > 5 > meters > (it's not going to teleport) forward, then again while it's > turning > 90 > degrees to the right, possibly again when it turns around, and > finally once > again while moving forward 2 meters. > I can't block the script without suspending the thread/fiber, > right? > But > with a large number of scriptable units, the system will not be > able > to cope > with a thread/fiber per script. > > > This sounds like the sort of thing that Stackless Python[1] was invented > for. This is a variation of CPython that -- by removing the dependency of > Python code execution on the processor's stack -- allows execution of > multiple objects without creating multiple threads. The game "EVE Online" > uses Stackless Python for this purpose. > > I doubt you could accomplish something similar in IronPython simply > because > of how the CLR works. But the low-level hooks in CLR 2.0 that were > created > for SQL Server may allow something in that direction. > > 1: http://www.stackless.com > 2: http://www.eve-online.com > > -- > Curt Hagenlocher > curt at hagenlocher.org > > -- > This message may contain confidential, proprietary, or legally privileged > information. No confidentiality or privilege is waived by any transmission > to an unintended recipient. If you are not an intended recipient, please > notify the sender and delete this message immediately. Any views expressed > in this message are those of the sender, not those of KBC Alternative > Investment Management Limited or its affiliates, or any funds or accounts > managed or advised by any of the aforementioned entities (together > referred > to as "KBC AIM"). > > This message does not create any obligation, contractual or otherwise, on > the part of KBC AIM. It is not an offer (or solicitation of an offer) of, > or > a recommendation to buy or sell, any financial product. Any prices or > other > values included in this message are indicative only, and do not > necessarily > represent current market prices, prices at which KBC AIM would enter into > a > transaction, or prices at which similar transactions may be carried on KBC > AIM's own books. The information contained in this message is provided "as > is", without representations or warranties, express or implied, of any > kind. > Past performance is not indicative of future returns. > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ygutfreund at draper.com Tue Jan 30 15:13:34 2007 From: ygutfreund at draper.com (Gutfreund, Yechezkal) Date: Tue, 30 Jan 2007 09:13:34 -0500 Subject: [IronPython] Suspending, saving script execution? In-Reply-To: References: <7AD436E4270DD54A94238001769C222765BB6CE77F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <009401c743f9$2c0521c0$6701a8c0@cxm> Message-ID: <98B94F0758D7394CA057AE4898CBC85E02E11646@exchbk1.draper.com> Hmm.. Shades of Smalltalk-72 (not 80, which compiled methods, but rather -72 which parsed and executed method calls as messages on receipt). It was rejected for performance reasons in Smalltalk-76, which went too far towards the C# strictly bound, and a compromise was found in -80. BTW, Ousterout made a strong case for this sort of paradigm in TCL and distributed TCL. I like the paradigm for a lot of things that I do, but I realize it's limitation for other scenarios. ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of M. David Peterson Sent: Monday, January 29, 2007 8:57 PM To: Discussion of IronPython Cc: Vista-Smalltallk at googlegroups.com Subject: Re: [IronPython] Suspending, saving script execution? so any pointers would be appreciated (at the moment, I'm just following execution in the debugger). While not directly related to IronPython (or MSFT for that matter), this seems like a perfect use-case for Vista Smalltalk (non-MS implementation of Smalltalk and Lisp; see: VST Wiki). I've Cc'd the group mailing list [see: Group List; VST Group: Please see the inline message for proper context.] While not a perfect 1-to-1 comparison, [see: Example:1] showcases how one would go about editing the generated Lisp-code from a circle drawn in the visual drawing tool that is part of the VST XBAP application [see: VSB; requires IE7/.NET 3.0 libraries, though WPF/e will be providing a cross-browser/platform capability in the coming months, from what I understand.] It would seem to me that the combination of the message-based approach provided by Smalltalk, and the list-processing approach of Lisp, by breaking any given script into smaller pieces, and building agents to handle the sending/receiving/processing of each message would provide exactly what you would need to accomplish the task of suspending and resuming action as necessary. While I can't say for sure, it would seem to me that adding IronPython to the mix *should* be pretty straight forward: Adding both assemblies to your project, and using a dictionary for ease of storage/access/editing of various Smalltalk and/or Lisp scripts, you could use a pretty straight forward declarative script syntax that would hide any unnecessary complexity from the user. How practical this would be in terms of performance is a definite unknown at this state, but it at least seems to provide a reasonable expectation for performance if care was taken to build in a proper caching mechanism. VST Wiki: http://vistascript.net/ Group List: http://groups.google.ca/group/Vista-Smalltallk Example:1: http://vistasmalltalk.wordpress.com/2007/01/29/modifying-generated-lisp/ VSB: http://vistascript.net/vistascript/vsb/Vsb.xbap Peter Fisk's (VST creator) blog: http://vistasmalltalk.wordpress.com/ On 1/29/07, Erzengel des Lichtes < erzengel-von-licht at cox.net > wrote: Thanks for the responses, I've considered using yield, which is what drew me to Python in the first place, but I operate under the theory that the developer should make it as easy as possible for the user, not themselves. Which means I need to do the yielding automatically on the C# side. What I really want is to use the reflectance available in .net, but I don't need the script itself to be turned into MSIL. The script should be able to be suspended anywhere in the script so that I can save/load (and prevent hanging by interrupting a long script, then let it continue after other scripts have had a chance to run). On the other hand, all .net methods will be atomic. I don't really care much about the performance of the scripts as they're supposed to be very high level; everything performance critical is written in C++, and everything else (except AI and scene choreography) is in C# (the glue is in C++/CLI). Only AI, scene choreography, and user scripts are in python. More often than not, a python script will probably be in its suspended state, waiting for "move" or whatever to return. The script's performance isn't much of a concern when the script isn't actually doing anything most of the time. Up until now I've just been looking into completely replacing PythonEngine, just using Compiler.Parser, but I'll look into Compiler.Generation.CodeGen, as well. I just haven't become very familiar with the internals of IronPython so any pointers would be appreciated (at the moment, I'm just following execution in the debugger). Erzengel des Lichtes Hikari no Daitenshi Archangel of Light -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, January 29, 2007 1:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? Presumably someone could also modify IronPython's CodeGen class to turn all methods into generators that yield at regular intervals. This would take a significant performance hit as all the locals would be hoisted into a FunctionEnvironmentDictionary and would still need the scheduler / virtual stack maintenance but be an interesting experiment. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Hogg, Jonathan Sent: Monday, January 29, 2007 1:02 AM To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? Stackless Python is definitely the way to go, but if you needed to do this in IronPython/.NET, you can get a poor man's form of micro-threading with generators. Taking your example, you could re-write it like so: def main(self): yield move(5) yield turn(90) if self.direction == Direction.East: yield turn(180) yield move(2) where 'move' and 'turn' are type constructors - or factory functions or whatever - that return an object representing the action to be taken. Now you instantiate the generator to create your micro-thread, and call '.next()' on it to execute it up to the next yield. t1 = mytank.main() action = t1.next() The difference between this and full threading is that it's cooperative and that you have to write your own micro-thread scheduler. Presumably you'll have some kind of game-state/event engine that will keep track of what each of the actors is currently doing and when they become eligible for execution again (it's finished moving/turning), you would poke them to see what they want to do next. Main problem is that if a piece of user-generated logic is badly behaved (doesn't yield), then your game would hang. Jonathan ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: 28 January 2007 17:37 To: Discussion of IronPython Subject: Re: [IronPython] Suspending, saving script execution? On 1/28/07, Erzengel des Lichtes < erzengel-von-licht at cox.net > wrote: Now, the script is going to need to be suspended while it's moving 5 meters (it's not going to teleport) forward, then again while it's turning 90 degrees to the right, possibly again when it turns around, and finally once again while moving forward 2 meters. I can't block the script without suspending the thread/fiber, right? But with a large number of scriptable units, the system will not be able to cope with a thread/fiber per script. This sounds like the sort of thing that Stackless Python[1] was invented for. This is a variation of CPython that -- by removing the dependency of Python code execution on the processor's stack -- allows execution of multiple objects without creating multiple threads. The game "EVE Online" uses Stackless Python for this purpose. I doubt you could accomplish something similar in IronPython simply because of how the CLR works. But the low-level hooks in CLR 2.0 that were created for SQL Server may allow something in that direction. 1: http://www.stackless.com 2: http://www.eve-online.com -- Curt Hagenlocher curt at hagenlocher.org -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of KBC Alternative Investment Management Limited or its affiliates, or any funds or accounts managed or advised by any of the aforementioned entities (together referred to as "KBC AIM"). This message does not create any obligation, contractual or otherwise, on the part of KBC AIM. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC AIM would enter into a transaction, or prices at which similar transactions may be carried on KBC AIM's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Wed Jan 31 04:59:08 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Tue, 30 Jan 2007 20:59:08 -0700 Subject: [IronPython] Suspending, saving script execution? In-Reply-To: <98B94F0758D7394CA057AE4898CBC85E02E11646@exchbk1.draper.com> References: <7AD436E4270DD54A94238001769C222765BB6CE77F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <009401c743f9$2c0521c0$6701a8c0@cxm> <98B94F0758D7394CA057AE4898CBC85E02E11646@exchbk1.draper.com> Message-ID: You know, I have heard so many good and wonderful things about TCL, yet no very little to nothing about it. Seems obviouis I need to change that... Thanks for the info/history lesson -- need to dig deeper into this topic, as well, though to be honest, its not surprising to me to see proof that, yet again, what's old is new, and what's new, old. As per a comment I recently left to a post from Rick Jelliffe (oh yes, of Wikigate *FAME* ;)) regarding Schematron and "Cagle's Law of Contant Complexity"[ http://www.oreillynet.com/xml/blog/2007/01/cagles_law_of_constant_complex.html ], Though not specifically brought to the surface, much like Occam's Razor [ > http://en.wikipedia.org/wiki/Occam's_Razor], > > In short, when given two equally valid explanations for a phenomenon, one > should embrace the less complicated formulation. > > Which I believe is *EXACTLY* what Schematron represents. > > As a side, but related note, isn't funny how it's the first technology > that tends to be the most correct as solving the problem at hand, though no > one is really quite sure how to use it properly, or maybe better said, what > to use it for. The second attempt is filled with so many ideas on how to > make the first version better, though without any better understanding of > what it will be used for, and as such seems to so overshoot the mark that a > third time is required to fix all the problems of the second, before finally > realizing that it was the first that was most correct in the first place. > "You mean John McCarthy, Guy Steele, and Alan Kay were right this whole time!" DAMN IT!, if that doesn't just blow the last 20 years of so-called "computer language progress"! Guess it's time to crack open the "history" books again to see what's in store for us next... "Python, Haskell, and (compiled!) Javascript? What the... " ;) :D On 1/30/07, Gutfreund, Yechezkal wrote: > > Hmm.. Shades of Smalltalk-72 (not 80, which compiled methods, but rather > -72 which parsed and executed method calls as messages on receipt). It was > rejected for performance reasons in Smalltalk-76, which went too far towards > the C# strictly bound, and a compromise was found in -80. > > BTW, Ousterout made a strong case for this sort of paradigm in TCL and > distributed TCL. > > I like the paradigm for a lot of things that I do, but I realize it's > limitation for other scenarios. > > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Wed Jan 31 05:00:08 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Tue, 30 Jan 2007 21:00:08 -0700 Subject: [IronPython] Suspending, saving script execution? In-Reply-To: References: <7AD436E4270DD54A94238001769C222765BB6CE77F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <009401c743f9$2c0521c0$6701a8c0@cxm> <98B94F0758D7394CA057AE4898CBC85E02E11646@exchbk1.draper.com> Message-ID: s/no/know s/obviouis/obvious I'll just stop there and hope you can forgive me for the rest... ;) On 1/30/07, M. David Peterson wrote: > > You know, I have heard so many good and wonderful things about TCL, yet no > very little to nothing about it. > > Seems obviouis I need to change that... > > Thanks for the info/history lesson -- need to dig deeper into this topic, > as well, though to be honest, its not surprising to me to see proof that, > yet again, what's old is new, and what's new, old. > > As per a comment I recently left to a post from Rick Jelliffe (oh yes, of > Wikigate *FAME* ;)) regarding Schematron and "Cagle's Law of Contant > Complexity"[http://www.oreillynet.com/xml/blog/2007/01/cagles_law_of_constant_complex.html > ], > > Though not specifically brought to the surface, much like Occam's Razor [ > > http://en.wikipedia.org/wiki/Occam's_Razor], > > > > In short, when given two equally valid explanations for a phenomenon, > > one should embrace the less complicated formulation. > > > > Which I believe is *EXACTLY* what Schematron represents. > > > > As a side, but related note, isn't funny how it's the first technology > > that tends to be the most correct as solving the problem at hand, though no > > one is really quite sure how to use it properly, or maybe better said, what > > to use it for. The second attempt is filled with so many ideas on how to > > make the first version better, though without any better understanding of > > what it will be used for, and as such seems to so overshoot the mark that a > > third time is required to fix all the problems of the second, before finally > > realizing that it was the first that was most correct in the first place. > > > > "You mean John McCarthy, Guy Steele, and Alan Kay were right this whole > time!" > > DAMN IT!, if that doesn't just blow the last 20 years of so-called > "computer language progress"! Guess it's time to crack open the "history" > books again to see what's in store for us next... > > "Python, Haskell, and (compiled!) Javascript? What the... " ;) :D > > On 1/30/07, Gutfreund, Yechezkal < ygutfreund at draper.com> wrote: > > > > Hmm.. Shades of Smalltalk-72 (not 80, which compiled methods, but > > rather -72 which parsed and executed method calls as messages on receipt). > > It was rejected for performance reasons in Smalltalk-76, which went too far > > towards the C# strictly bound, and a compromise was found in -80. > > > > BTW, Ousterout made a strong case for this sort of paradigm in TCL and > > distributed TCL. > > > > I like the paradigm for a lot of things that I do, but I realize it's > > limitation for other scenarios. > > > > > -- > /M:D > > M. David Peterson > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Wed Jan 31 05:02:31 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Tue, 30 Jan 2007 21:02:31 -0700 Subject: [IronPython] Suspending, saving script execution? In-Reply-To: References: <7AD436E4270DD54A94238001769C222765BB6CE77F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <009401c743f9$2c0521c0$6701a8c0@cxm> Message-ID: On 1/29/07, M. David Peterson wrote: > > > so any pointers would be appreciated (at the moment, I'm just > > following execution in the debugger). > > > While not directly related to IronPython (or MSFT for that matter), this > seems like a perfect use-case for Vista Smalltalk (non-MS implementation of > Smalltalk and Lisp; see: VST Wiki). I've Cc'd the group mailing list [see: > Group List; VST Group: Please see the inline message for proper context.] > Peter Fisk's follow-up from earlier today > http://groups.google.ca/group/Vista-Smalltallk/msg/261580807ae6a486?dmode=source&hl=en -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 -------------- next part -------------- An HTML attachment was scrubbed... URL: