From kaspertsw at msn.com Thu Feb 1 23:49:02 2007 From: kaspertsw at msn.com (Kasper Tanggaard) Date: Thu, 01 Feb 2007 23:49:02 +0100 Subject: [IronPython] Events Message-ID: Hello all, This is my first post, and I'm not that used to mailinglists, so I do apologize if it goes wrong :). I'm using IronPython as scripting in my application, and I already love it! I would like for my users to write methods which they can hook up as events to the controls already in the application. This works fine, but what if the user messes up? I would like to be able to remove user assigned events from within the application, since I've seen that done with other scripting components back in the good old Delphi days. Is this possible with IronPython? If not, is it possible to do with a piece of Python code which the user can execute if something goes wrong? I hope someone can help me here :) Kind regards, Kasper _________________________________________________________________ F? 250 MB gratis lagerplads p? MSN Hotmail: http://www.hotmail.com From michael.foord at resolversystems.com Fri Feb 2 15:13:13 2007 From: michael.foord at resolversystems.com (Michael Foord) Date: Fri, 02 Feb 2007 14:13:13 +0000 Subject: [IronPython] Events In-Reply-To: References: Message-ID: <45C346F9.8020609@resolversystems.com> Kasper Tanggaard wrote: > Hello all, > > This is my first post, and I'm not that used to mailinglists, so I do > apologize if it goes wrong :). I'm using IronPython as scripting in my > application, and I already love it! I would like for my users to write > methods which they can hook up as events to the controls already in > the application. This works fine, but what if the user messes up? I > would like to be able to remove user assigned events from within the > application, since I've seen that done with other scripting components > back in the good old Delphi days. Is this possible with IronPython? If > not, is it possible to do with a piece of Python code which the user > can execute if something goes wrong? I hope someone can help me here :) Hello Kasper, In IronPython events are added using '+=' : def onClick(sender, event): print 'clicked' button.Click += onClick To remove it you do: button.Click -= onClick Perhaps you could create your own interface for adding to events, which keeps track of everything added and allows you to remove them easily ? I'm not sure if event handlers are simply collections, there may be a away of examining them to see what is in there. I hope this is helpful. Michael http://www.voidspace.org.uk/python/articles.shtml > > Kind regards, > > Kasper > > _________________________________________________________________ > F? 250 MB gratis lagerplads p? MSN Hotmail: http://www.hotmail.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.411 / Virus Database: 268.17.19/663 - Release Date: 01/02/2007 > > -- Michael Foord Resolver Systems michael.foord 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. VAT No. GB 893 5643 79 From dinov at exchange.microsoft.com Fri Feb 2 21:41:29 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 2 Feb 2007 12:41:29 -0800 Subject: [IronPython] Events In-Reply-To: <45C346F9.8020609@resolversystems.com> References: <45C346F9.8020609@resolversystems.com> Message-ID: <7AD436E4270DD54A94238001769C222765EC12B1AE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> One thing I'll point out is we have no direct support for this in IronPython today. But our events are all dispatched using an EventDispatcher class (see ReflectedMembers.cs, EventDispatcher is an inner class of ReflectedEvent). This class registers a single event against the underlying .NET event and when the event is fired the dispatcher dispatches to all of the registered handlers. At this point in the code it would be possible to add a try/catch and remove the current dispatcher if it threw. We'd obviously have to think about this before making it a language feature but if you wanted to customize your version of IronPython to handle this it should be fairly trivial. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, February 02, 2007 6:13 AM To: Discussion of IronPython Subject: Re: [IronPython] Events Kasper Tanggaard wrote: > Hello all, > > This is my first post, and I'm not that used to mailinglists, so I do > apologize if it goes wrong :). I'm using IronPython as scripting in my > application, and I already love it! I would like for my users to write > methods which they can hook up as events to the controls already in > the application. This works fine, but what if the user messes up? I > would like to be able to remove user assigned events from within the > application, since I've seen that done with other scripting components > back in the good old Delphi days. Is this possible with IronPython? If > not, is it possible to do with a piece of Python code which the user > can execute if something goes wrong? I hope someone can help me here :) Hello Kasper, In IronPython events are added using '+=' : def onClick(sender, event): print 'clicked' button.Click += onClick To remove it you do: button.Click -= onClick Perhaps you could create your own interface for adding to events, which keeps track of everything added and allows you to remove them easily ? I'm not sure if event handlers are simply collections, there may be a away of examining them to see what is in there. I hope this is helpful. Michael http://www.voidspace.org.uk/python/articles.shtml > > Kind regards, > > Kasper > > _________________________________________________________________ > F? 250 MB gratis lagerplads p? MSN Hotmail: http://www.hotmail.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.411 / Virus Database: 268.17.19/663 - Release Date: 01/02/2007 > > -- Michael Foord Resolver Systems michael.foord 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. VAT No. GB 893 5643 79 _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From textdirected at gmail.com Sat Feb 3 05:54:26 2007 From: textdirected at gmail.com (HEMMI, Shigeru) Date: Sat, 3 Feb 2007 13:54:26 +0900 Subject: [IronPython] BUG? IOError: Could not find file Message-ID: Hello, IronPython Team, On my MAC OS X (Panther) + mono + IronPython, I encounterd a bug for the program. class TESTINGwrite(file): def __init__(self, fname): file.__init__(self,fname,"w",1) def writesomething(self): self.write("Hi there\n") if __name__=='__main__': x = TESTINGwrite("testing_TMP.txt") x.writesomething() x.close() In IronPython, this code generats errer(see below), while CPython runs properly. I am guessing this is a bug. $ ipy IOErrorCouldNoFindFile.py Traceback (most recent call last): File IOErrorCouldNoFindFile, line unknown, in Initialize File mscorlib, line unknown, in .ctor File mscorlib, line unknown, in .ctor IOError: Could not find file "testing_TMP.txt". regards, From daftspaniel at gmail.com Mon Feb 5 14:14:42 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Mon, 5 Feb 2007 13:14:42 +0000 Subject: [IronPython] New IronPython Section In-Reply-To: <7.0.1.0.2.20061230010531.077bcd78@wheresmymailserver.com> References: <20061217212555.VLNO26699.aamtaout03-winn.ispmail.ntl.com@192.168.1.100> <4585B692.3040605@voidspace.org.uk> <20253b0c0612171339pdb283d8ld7c31f60401ef4fb@mail.gmail.com> <1d39a8340612291934p50b7558bg41a909420fb8cb54@mail.gmail.com> <7.0.1.0.2.20061230010531.077bcd78@wheresmymailserver.com> Message-ID: <20253b0c0702050514xba9c405lab1c1c6a3adb06e3@mail.gmail.com> On 12/30/06, J. Merrill wrote: > I too cannot get DNS to recognize www.latedecember.com .... Finally my website is back on line but the domain is .co.uk now. http://www.latedecember.co.uk/sites/personal/davy/ RSS for IronPython section is now : http://www.latedecember.co.uk/sites/personal/davy/IronPython_index.xml Cheers, Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Mood News - BBC News Headlines Auto-Classified as Good, Bad or Neutral. http://www.latedecember.co.uk/sites/moodnews/ From sh at defuze.org Mon Feb 5 14:15:48 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Mon, 05 Feb 2007 13:15:48 +0000 Subject: [IronPython] ANN: bridge 0.2.4 Message-ID: <45C72E04.3070407@defuze.org> Hi all, I am pleased to announce the release of bridge 0.2.4, a general purpose XML library for Python and IronPython. == Overview == bridge is very simple and light. It basically let you load an XML document via a set of different parsers (xml.dom, expat, Amara, lxml, System.Xml and ElementTree) and creates a tree of Elements and Attributes before releasing the parser resources. This means that once the document is loaded it is independent from the underlying parser. bridge then provides a straightforward interface to navigate through the tree and manipulate it. bridge does not try to replace underlying XML engines but offer a common API so that your applications are less dependent of those engines. bridge offers a couple of other goodies however to play with the tree of elements (see the documentation). == What's new? == This release is an important milestone for bridge: * added expat parser (seems to be the fatest parser bridge has) * many namespace issues fixed with the default parser * added incremental parsing with dispatching based on rules during the parsing of bridge Elements * added path lookup support (not XPath) * slightly increased the API of a few helps functions == TODO == Potentially the IronPython implementation is not as up-to-date as the other parsers. All parsers will generate the same bridge structure. The only minor difference at the present time is coming from the lxml parser which does not preserve processing instructions and comments before the root element. bridge cannot therefore access them. Add more unit tests. == Download == * easy_install -U bridge * Tarballs http://www.defuze.org/oss/bridge/ * svn co https://svn.defuze.org/oss/bridge/ == Documentation == Wiki: http://trac.defuze.org/wiki/bridge Have fun, -- Sylvain Hellegouarch http://www.defuze.org From Jochen.Langer at al-lighting.com Mon Feb 5 16:48:23 2007 From: Jochen.Langer at al-lighting.com (Langer, Jochen ALRT/EEG2 *) Date: Mon, 5 Feb 2007 16:48:23 +0100 Subject: [IronPython] How to force ipy-engine to reload imported modules ? Message-ID: > We use IronPython-engine embedded in a C# application. The engine > executes Python-scripts that are located in several directories with > ExecuteFile(). The scripts import modules that are located in > subfolders of folder of the respective script. > > Doing so the following problem occurs: > > 1. Executing ScriptA in DirectoryA imports Modules that are located in > subdrectories of DirectoryA - still everything is fine > > 2. Executing ScriptB in DirectoryB does not import modules if a module > with the same name had been imported during the previous call to > ExecuteFile("DirectoryA\ScriptA"). The previously imported modules > (belonging to ScriptA) are used instead. > > As a workaround we create a new engine prior to each execution and > dispose it afterwards. > But this is not the preferred implementation - I'd rather like to have > one static engine-object that can be used multiple times. (putting all > scripts into the same folder or using different module-names is not an > option due to maintainance and reuse) > > Any suggestions how the ipy-engine can be forced to reload modules > upon each call to ExecuteFile() ? > > regards, > > > Jochen -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Feb 5 17:53:22 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 05 Feb 2007 16:53:22 +0000 Subject: [IronPython] How to force ipy-engine to reload imported modules ? In-Reply-To: References: Message-ID: <45C76102.2070000@voidspace.org.uk> Langer, Jochen ALRT/EEG2 * wrote: > > We use IronPython-engine embedded in a C# application. The engine > executes Python-scripts that are located in several directories with > ExecuteFile(). The scripts import modules that are located in > subfolders of folder of the respective script. > > Doing so the following problem occurs: > > 1. Executing ScriptA in DirectoryA imports Modules that are located in > subdrectories of DirectoryA - still everything is fine > > 2. Executing ScriptB in DirectoryB does not import modules if a module > with the same name had been imported during the previous call to > ExecuteFile("DirectoryA\ScriptA"). The previously imported modules > (belonging to ScriptA) are used instead. > > As a workaround we create a new engine prior to each execution and > dispose it afterwards. > But this is not the preferred implementation - I'd rather like to have > one static engine-object that can be used multiple times. (putting all > scripts into the same folder or using different module-names is not an > option due to maintainance and reuse) > > Any suggestions how the ipy-engine can be forced to reload modules > upon each call to ExecuteFile() ? > Reusing previously imported modules (recognised by name) is a feature not a bug. :-) I'm not sure what the best approach from 'outside' the engine is, but there are a couple of Python tricks to get this to work as you expect. Imported modules are stored in 'sys.modules' (a dictionary - keyed by the module name). Deleting entires from here will cause them to be reloaded next time you import. If you make your top level directory a package you can import using absolute references. E.g. if you have your main application libraries in a directory called main and then two subdirectories called 'a' and 'b' and you want to import modules from both a and b. Add empty '__init__.py' files to directories a and b and then import using : from Main.a import module from Main.b import module The entries in sys.modules will then be 'Main.a.module' and 'Main.b.module'; which don't clash. I HTH. I'm sure there are alternative approaches from the C# sharp. All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > regards, > > > Jochen > > ------------------------------------------------------------------------ > > _______________________________________________ > 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.411 / Virus Database: 268.17.25/669 - Release Date: 04/02/2007 > > From dinov at exchange.microsoft.com Mon Feb 5 20:38:27 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 5 Feb 2007 11:38:27 -0800 Subject: [IronPython] How to force ipy-engine to reload imported modules ? In-Reply-To: <45C76102.2070000@voidspace.org.uk> References: <45C76102.2070000@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222765EC12B5D2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I think the package solution that Michael proposes here is the best one. It's good both for getting the behavior right from C# (you do nothing in C# and let the package infrastructure work for you) and for being a consistent host within the broader Python perspective. This way you're not re-inventing the wheel and instead just doing things the "right way". -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, February 05, 2007 8:53 AM To: Discussion of IronPython Subject: Re: [IronPython] How to force ipy-engine to reload imported modules ? Langer, Jochen ALRT/EEG2 * wrote: > > We use IronPython-engine embedded in a C# application. The engine > executes Python-scripts that are located in several directories with > ExecuteFile(). The scripts import modules that are located in > subfolders of folder of the respective script. > > Doing so the following problem occurs: > > 1. Executing ScriptA in DirectoryA imports Modules that are located in > subdrectories of DirectoryA - still everything is fine > > 2. Executing ScriptB in DirectoryB does not import modules if a module > with the same name had been imported during the previous call to > ExecuteFile("DirectoryA\ScriptA"). The previously imported modules > (belonging to ScriptA) are used instead. > > As a workaround we create a new engine prior to each execution and > dispose it afterwards. > But this is not the preferred implementation - I'd rather like to have > one static engine-object that can be used multiple times. (putting all > scripts into the same folder or using different module-names is not an > option due to maintainance and reuse) > > Any suggestions how the ipy-engine can be forced to reload modules > upon each call to ExecuteFile() ? > Reusing previously imported modules (recognised by name) is a feature not a bug. :-) I'm not sure what the best approach from 'outside' the engine is, but there are a couple of Python tricks to get this to work as you expect. Imported modules are stored in 'sys.modules' (a dictionary - keyed by the module name). Deleting entires from here will cause them to be reloaded next time you import. If you make your top level directory a package you can import using absolute references. E.g. if you have your main application libraries in a directory called main and then two subdirectories called 'a' and 'b' and you want to import modules from both a and b. Add empty '__init__.py' files to directories a and b and then import using : from Main.a import module from Main.b import module The entries in sys.modules will then be 'Main.a.module' and 'Main.b.module'; which don't clash. I HTH. I'm sure there are alternative approaches from the C# sharp. All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > regards, > > > Jochen > > ------------------------------------------------------------------------ > > _______________________________________________ > 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.411 / Virus Database: 268.17.25/669 - Release Date: 04/02/2007 > > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Wed Feb 7 03:33:04 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 7 Feb 2007 11:33:04 +0900 Subject: [IronPython] IronPython book in Japan? Message-ID: <5b0248170702061833v4a529a0cy3ff08d0b5a1816da@mail.gmail.com> http://www.amazon.co.jp/gp/product/4774130427 ??Python??????? Django,TurboGears,Twisted,IronPython ???? (???) Software Design ??? (??) ????? Latest Python Explorer: through coverage of Django, TurboGears, Twisted, IronPython (Large Print) Edited by editors of Software Design Published by Technical Reviews(?) It is said to be 184 pages and priced at 1869 JPY, which would be roughly 15.5 USD. Does anyone have more information on this book? -- Seo Sanghyeon From sanxiyn at gmail.com Wed Feb 7 03:35:49 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 7 Feb 2007 11:35:49 +0900 Subject: [IronPython] IronPython book in Japan? In-Reply-To: <5b0248170702061833v4a529a0cy3ff08d0b5a1816da@mail.gmail.com> References: <5b0248170702061833v4a529a0cy3ff08d0b5a1816da@mail.gmail.com> Message-ID: <5b0248170702061835l5bab0303qbc215f3e29e7072@mail.gmail.com> 2007/2/7, Sanghyeon Seo : > Latest Python Explorer: through coverage of Django, TurboGears, > Twisted, IronPython (Large Print) Oops, "large print" seems to be about book size, not font size. -- Seo Sanghyeon From redmoon17 at gmail.com Wed Feb 7 04:37:18 2007 From: redmoon17 at gmail.com (Kevin Chu) Date: Wed, 7 Feb 2007 11:37:18 +0800 Subject: [IronPython] IronPython book in Japan? In-Reply-To: <5b0248170702061835l5bab0303qbc215f3e29e7072@mail.gmail.com> References: <5b0248170702061833v4a529a0cy3ff08d0b5a1816da@mail.gmail.com> <5b0248170702061835l5bab0303qbc215f3e29e7072@mail.gmail.com> Message-ID: <41d7f4a90702061937t503f9f59i8ccd97ddf9d7ff77@mail.gmail.com> It is not monograph for IronPython, I think. However my friends and I are writing a book for IronPython in China. I am be assigned to introduce IPCE, hope you can give me a hand when I have any problems. On 2/7/07, Sanghyeon Seo wrote: > 2007/2/7, Sanghyeon Seo : > > Latest Python Explorer: through coverage of Django, TurboGears, > > Twisted, IronPython (Large Print) > > Oops, "large print" seems to be about book size, not font size. > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Once in a Redmoon From sanxiyn at gmail.com Wed Feb 7 06:52:28 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 7 Feb 2007 14:52:28 +0900 Subject: [IronPython] Pickle-Serialization integration Message-ID: <5b0248170702062152r50455a6ci764ad7bc921f6984@mail.gmail.com> Python has pickle, and .NET has System.Runtime.Serialization, and they do roughly the same thing. So one should be able to pickle any .NET objects that is serializable. As Python's pickle has a mechanism to register custom hooks, I wrote hooks to delegate pickling of .NET objects to System.Runtime.Serialization. It works fine! This is how it looks like: from System import DateTime import pickle import fepy.pickle fepy.pickle.register(DateTime) obj = DateTime.Now string = pickle.dumps(obj) newobj = pickle.loads(string) assert obj == newobj Does it make to sense to do the reverse? That is, making picklable Python objects serializable by, I guess, implementing ISerializable? I have no idea how to go about that. Any suggestions welcome. -- Seo Sanghyeon From redmoon17 at gmail.com Wed Feb 7 13:10:34 2007 From: redmoon17 at gmail.com (Kevin Chu) Date: Wed, 7 Feb 2007 20:10:34 +0800 Subject: [IronPython] IPCE be included into Mono 1.2.3 Message-ID: <41d7f4a90702070410t5f362e00t92595a84db2e5360@mail.gmail.com> In this release, we are now shipping the IronPython Community Edition (IPCE) from Seo Sanghyeon. IPCE includes a number of preconfigured libraries with IronPython to improve your IronPython developing experience. source:http://www.go-mono.com/archive/1.2.3/ -- Once in a Redmoon From sanxiyn at gmail.com Thu Feb 8 03:13:48 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 8 Feb 2007 11:13:48 +0900 Subject: [IronPython] os.access In-Reply-To: <5b0248170701270620x67a53285n2416f90e71afad30@mail.gmail.com> References: <5b0248170701270620x67a53285n2416f90e71afad30@mail.gmail.com> Message-ID: <5b0248170702071813w2a34414cof784d1bf730b2f81@mail.gmail.com> 2007/1/27, Sanghyeon Seo : > It would be nice to have a basic implementation of os.access in IronPython. This seems to have slipped out of the radar. I filed CodePlex issue #8073 myself. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8073 -- Seo Sanghyeon From jvm_cop at spamcop.net Thu Feb 8 17:07:51 2007 From: jvm_cop at spamcop.net (J. Merrill) Date: Thu, 08 Feb 2007 11:07:51 -0500 Subject: [IronPython] Pickle-Serialization integration In-Reply-To: <5b0248170702062152r50455a6ci764ad7bc921f6984@mail.gmail.co m> References: <5b0248170702062152r50455a6ci764ad7bc921f6984@mail.gmail.com> Message-ID: <7.0.1.0.2.20070208110535.07c50e10@wheresmymailserver.com> You could implement ISerializable on Python objects by pickling the object (using the regular Python pickle mechanism) and using the resulting string as the serialized value (perhaps with some kind of sanity-test header and/or trailer). Unserializing would then require unpickling the serialized string. At 12:52 AM 2/7/2007, Sanghyeon Seo wrote >Python has pickle, and .NET has System.Runtime.Serialization, and they >do roughly the same thing. > >So one should be able to pickle any .NET objects that is serializable. > >As Python's pickle has a mechanism to register custom hooks, I wrote >hooks to delegate pickling of .NET objects to >System.Runtime.Serialization. It works fine! > >This is how it looks like: > >from System import DateTime >import pickle >import fepy.pickle >fepy.pickle.register(DateTime) > >obj = DateTime.Now >string = pickle.dumps(obj) >newobj = pickle.loads(string) >assert obj == newobj > >Does it make to sense to do the reverse? That is, making picklable >Python objects serializable by, I guess, implementing ISerializable? I >have no idea how to go about that. Any suggestions welcome. > >-- >Seo Sanghyeon J. Merrill / Analytical Software Corp From tjenkins at devis.com Thu Feb 8 17:43:09 2007 From: tjenkins at devis.com (Tom Jenkins) Date: Thu, 08 Feb 2007 11:43:09 -0500 Subject: [IronPython] Can IronPython help Message-ID: <45CB531D.50604@devis.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, We have a requirement to integrate a 3rd party product into our system. This 3rd party product is written in C#. Its engine is available through a set of dlls. Our system does not run on .NET; its a zope app. What we would like to do is put up a web service in front of the 3rd party product that our system talks to. The web service would import and use the dlls to run the engine. Can we use IronPython to write the web service? Is this a feasible scenario? Or do we have to go with a C# implementation? Thanks in advance. - -- Tom Jenkins Senior Systems Analyst Devis - http://www.devis.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFy1MdN0FsrlkIeqcRAswMAKC63r8Jx+NBMMC8PFJWQ/rii+tRBgCePevw 8ZeguMHcd2Eco5NJV3/YNtI= =a4Pn -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: tjenkins.vcf Type: text/x-vcard Size: 158 bytes Desc: not available URL: From dinov at exchange.microsoft.com Thu Feb 8 18:16:58 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 8 Feb 2007 09:16:58 -0800 Subject: [IronPython] os.access In-Reply-To: <5b0248170702071813w2a34414cof784d1bf730b2f81@mail.gmail.com> References: <5b0248170701270620x67a53285n2416f90e71afad30@mail.gmail.com> <5b0248170702071813w2a34414cof784d1bf730b2f81@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222766B4654D70@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks Seo! Sorry we missed this. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Wednesday, February 07, 2007 6:14 PM To: Discussion of IronPython Subject: Re: [IronPython] os.access 2007/1/27, Sanghyeon Seo : > It would be nice to have a basic implementation of os.access in IronPython. This seems to have slipped out of the radar. I filed CodePlex issue #8073 myself. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8073 -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jvm_cop at spamcop.net Thu Feb 8 19:51:28 2007 From: jvm_cop at spamcop.net (J. Merrill) Date: Thu, 08 Feb 2007 13:51:28 -0500 Subject: [IronPython] Can IronPython help In-Reply-To: <45CB531D.50604@devis.com> References: <45CB531D.50604@devis.com> Message-ID: <7.0.1.0.2.20070208134304.079cb9f8@wheresmymailserver.com> Yes, you could write the web service with IronPython -- but a web service might not be an appropriate way to provide the 3rd-party product's API. For example, if you're expected to create objects of particular types declared in the API and call methods on those objects, you would need to figure out how to maintain the "state" associated with those objects. Only if the API is not particularly object-oriented, or if it's particularly stateless, would a web service be a desirable way to provide the interface. Is the product available for .Net 1.1 or only for .Net 2? I ask because there is a "call .Net from (not-Iron) Python" mechanism that's well tested for .Net 1.1, but the .Net 2 version has not been provided in "usable by normal people" form yet. (Some people with strong .Net 2 skills have made it work for them, but none AFAIK have made what they did available. The .Net 2 version in its unfinished state is available in the svn repository.) http://pythonnet.sourceforge.net/ Good luck. At 11:43 AM 2/8/2007, Tom Jenkins wrote >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Hello all, >We have a requirement to integrate a 3rd party product into our system. > This 3rd party product is written in C#. Its engine is available >through a set of dlls. > >Our system does not run on .NET; its a zope app. > >What we would like to do is put up a web service in front of the 3rd >party product that our system talks to. The web service would import >and use the dlls to run the engine. > >Can we use IronPython to write the web service? Is this a feasible >scenario? Or do we have to go with a C# implementation? > >Thanks in advance. > >- -- >Tom Jenkins >Senior Systems Analyst >Devis - http://www.devis.com J. Merrill / Analytical Software Corp From njriley at uiuc.edu Sat Feb 10 09:37:51 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Sat, 10 Feb 2007 02:37:51 -0600 Subject: [IronPython] Any way to get IronPython on Mono to have a usable command line? Message-ID: <20070210083751.GB66450@uiuc.edu> Hi, I'm trying to run IronPython on Mono. I've got IPCE installed as included with Mono 1.2.3 on both Windows and Linux, but both versions are behaving strangely compared with ipy.exe on the Microsoft runtime (how do you refer to it anyway?) On Windows I get doubled characters as I type and ^@ inserted when I press the control key, and on Linux I get command-line history but the delete key and other usual keys like ^U don't work, just inserting ^?, ^U, etc. instead. Is there an alternate way I can run it so I can at least delete, and preferably get history too? Thanks, -- Nicholas Riley | From kfarmer at thuban.org Sat Feb 10 09:46:00 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Sat, 10 Feb 2007 00:46:00 -0800 Subject: [IronPython] Any way to get IronPython on Mono to have a usablecommand line? Message-ID: I added notes to this effect on Bugzilla a day or two ago. It's practically unusable. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Nicholas Riley Sent: Saturday, February 10, 2007 12:38 AM To: users at lists.ironpython.com Subject: [IronPython] Any way to get IronPython on Mono to have a usablecommand line? Hi, I'm trying to run IronPython on Mono. I've got IPCE installed as included with Mono 1.2.3 on both Windows and Linux, but both versions are behaving strangely compared with ipy.exe on the Microsoft runtime (how do you refer to it anyway?) On Windows I get doubled characters as I type and ^@ inserted when I press the control key, and on Linux I get command-line history but the delete key and other usual keys like ^U don't work, just inserting ^?, ^U, etc. instead. Is there an alternate way I can run it so I can at least delete, and preferably get history too? Thanks, -- Nicholas Riley | _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From storm.openmail at gmail.com Mon Feb 12 16:17:36 2007 From: storm.openmail at gmail.com (kak kak) Date: Mon, 12 Feb 2007 16:17:36 +0100 Subject: [IronPython] Generated Code in the Iron Python Source Message-ID: Hia, I've recently started to peek around in the source code for IronPython and couldn't help but notice that some of the source code in the parser has comments about being autogenerated (i.e the Tokenizer class) I assume you have been using a tool similar to *ANTLR*, I'm just curious about the what tools you have been using to autogenerate this code and are they publicly available? BR Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Mon Feb 12 18:10:59 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 12 Feb 2007 09:10:59 -0800 Subject: [IronPython] Generated Code in the Iron Python Source In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C222766B46555E5@DF-GRTDANE-MSG.exchange.corp.microsoft.com> We auto-generate the code via Python script files. The source code for the generation ships w/ IronPython and is in Src\Scripts\generate.py and individual scripts (generate_*.py). If you're looking for the code that handles a specific block you can grep/findstr for that block's region name minus the "Generated" part that's automatically included at the beginning. Some of the scripts merely auto-generate based upon a pre-set table of one form or another (most of them). Other scripts reflect into the current running Python interpreter and generate based upon what they see there (e.g. exceptions). Finally some use Reflection to look at the types in the currently running interpreter and generate code based upon that (e.g. walker). Using IronPython to generate these lets us use the most appropriate one at the time (although it makes things difficult if you've broken the interpreter so badly the scripts don't run anymore J). Finally the scripts support checking the current source code and validating that there are no inconsistencies between what's on disk and what will be output. You can run any generate_*.py w/ a "checkonly" option on the command line and it will return 0 if all generated files match. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of kak kak Sent: Monday, February 12, 2007 7:18 AM To: users at lists.ironpython.com Subject: [IronPython] Generated Code in the Iron Python Source Hia, I've recently started to peek around in the source code for IronPython and couldn't help but notice that some of the source code in the parser has comments about being autogenerated (i.e the Tokenizer class) I assume you have been using a tool similar to ANTLR, I'm just curious about the what tools you have been using to autogenerate this code and are they publicly available? BR Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.moore at centrify.com Mon Feb 12 23:19:01 2007 From: paul.moore at centrify.com (Paul Moore) Date: Mon, 12 Feb 2007 14:19:01 -0800 Subject: [IronPython] standard modules Message-ID: which standard modules exist in IP? For example can I do 'import random' or must I use the the CLR equivalents -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Feb 12 23:22:34 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 12 Feb 2007 22:22:34 +0000 Subject: [IronPython] standard modules In-Reply-To: References: Message-ID: <45D0E8AA.2000208@voidspace.org.uk> Paul Moore wrote: > which standard modules exist in IP? > For example can I do 'import random' or must I use the the CLR equivalents You can use most of the Python standard library, but it must be on the path (it doesn't come with the Microsoft IronPython distribution). Make sure you have Python 2.4 installed. You can then either use the IRONPYTHONPATH environment variable and set it to the location of the Python standard library, manually add the path in site.py *or* manually add the path in your own code. 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 > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.411 / Virus Database: 268.17.36/681 - Release Date: 11/02/2007 > > From anilmrn at yahoo.com Tue Feb 13 01:13:10 2007 From: anilmrn at yahoo.com (anilmrn at yahoo.com) Date: 12 Feb 2007 16:13:10 -0800 Subject: [IronPython] Join Anil M on Yahoo! Messenger! Message-ID: <20070213001311.02CEF48002@diego.dreamhost.com> Anil M wants to talk with you using the new Yahoo! Messenger: Accept the invitation by clicking this link: http://invite.msg.yahoo.com/invite?op=accept&intl=us&sig=WhTFu2ujI_6s5sZosDgdoWId0ImbtGK2gpyfwaKWj_v_DxHsDdXGPD.FOVNvahHKjBJ4RV721zY4Yt_APt7uMxAHnfP0VixnOMGY8_ZAPk_lfo_h1XqcC9ohlp5Y With Yahoo! Messenger, you get: Free worldwide PC-to-PC calls.* All you need are speakers and a microphone (or a headset). If no one's there, leave a voicemail! IM Windows Live™ Messenger friends too. Add your Windows Live friends to your Yahoo! contact list. See when they're online and IM them anytime. Stealth settings keep you in control. Now you can get in touch on your time, by controlling who sees when you're online. So what are you waiting for? It's free. Get Yahoo! Messenger and start connecting how you want, when you want. * Emergency 911 calling services not available on Yahoo! Messenger. Please inform others who use your Yahoo! Messenger they must dial 911 through traditional phone lines or cell carriers. By using Yahoo! Messenger you agree to not use PC-to-PC calling in countries where prohibited. The above features apply to the Windows version of Yahoo! Messenger. -------------- next part -------------- An HTML attachment was scrubbed... URL: From njriley at uiuc.edu Tue Feb 13 09:44:30 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Tue, 13 Feb 2007 02:44:30 -0600 Subject: [IronPython] Better source code access? Message-ID: <20070213084430.GA92208@uiuc.edu> Hi, I found some messages in the archives from back in October regarding access for non-contributors to CodePlex's Team Foundation Server. Has there been any progress on this? I've been trying to figure out how some code in IronPython evolved and the lack of an easily browseable interface (diffs? commit messages?) is a real impediment. If there's no other choice I could download the zip files for each revision, check them in somewhere else and make the repository available for public browsing. It would help if you mention on the front page of the wiki (under "Get the Sources") that Team Explorer cannot be used by all users - it would have saved me a lot of time knowing that! Thanks, -- Nicholas Riley | From sanxiyn at gmail.com Tue Feb 13 16:29:53 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 14 Feb 2007 00:29:53 +0900 Subject: [IronPython] standard modules In-Reply-To: References: Message-ID: <5b0248170702130729g4ead3e72m9a1ea0f950b0dedd@mail.gmail.com> 2007/2/13, Paul Moore : > which standard modules exist in IP? > For example can I do 'import random' or must I use the the CLR equivalents You can import random just fine. -- Seo Sanghyeon From Martin.Maly at microsoft.com Tue Feb 13 17:45:10 2007 From: Martin.Maly at microsoft.com (Martin Maly) Date: Tue, 13 Feb 2007 08:45:10 -0800 Subject: [IronPython] Better source code access? In-Reply-To: <20070213084430.GA92208@uiuc.edu> References: <20070213084430.GA92208@uiuc.edu> Message-ID: We did talk to the CodePlex team and it turns out that they consciously impose this limitation. Only the members of the Contributor/Developer group have access to the server via the Team Explorer. Since we talked to them last, we haven't heard any update on this so I presume this limitation has not gone away and probably won't in the foreseeable future. Please accept our apologies, Martin -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Nicholas Riley Sent: Tuesday, February 13, 2007 12:45 AM To: users at lists.ironpython.com Subject: [IronPython] Better source code access? Hi, I found some messages in the archives from back in October regarding access for non-contributors to CodePlex's Team Foundation Server. Has there been any progress on this? I've been trying to figure out how some code in IronPython evolved and the lack of an easily browseable interface (diffs? commit messages?) is a real impediment. If there's no other choice I could download the zip files for each revision, check them in somewhere else and make the repository available for public browsing. It would help if you mention on the front page of the wiki (under "Get the Sources") that Team Explorer cannot be used by all users - it would have saved me a lot of time knowing that! Thanks, -- Nicholas Riley | _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From njriley at uiuc.edu Wed Feb 14 05:36:32 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Tue, 13 Feb 2007 22:36:32 -0600 Subject: [IronPython] Better source code access? In-Reply-To: References: <20070213084430.GA92208@uiuc.edu> Message-ID: <20070214043632.GA1974@uiuc.edu> On Tue, Feb 13, 2007 at 08:45:10AM -0800, Martin Maly wrote: > We did talk to the CodePlex team and it turns out that they > consciously impose this limitation. Only the members of the > Contributor/Developer group have access to the server via the Team > Explorer. Since we talked to them last, we haven't heard any update > on this so I presume this limitation has not gone away and probably > won't in the foreseeable future. Thanks for checking. > If there's no other choice I could download the zip files for each > revision, check them in somewhere else and make the repository > available for public browsing. I imported the data into Mercurial. Note that I didn't account for the branching in the repo that happened at some point, but this still should be a lot more useful than the browser on the CodePlex site. -- Nicholas Riley | From davidjensen at usa.net Wed Feb 14 15:06:25 2007 From: davidjensen at usa.net (David Jensen) Date: Wed, 14 Feb 2007 09:06:25 -0500 Subject: [IronPython] iron python on pocket pc Message-ID: <237LBNoFZ9002S14.1171461985@cmsweb14.cms.usa.net> Does ironpython work on pocket pc? If so, which versions does it run on? I would assume it would be .net 2.0 which would be mobile 5 or, possibly, 2003 David Jensen David Jensen Apartment 412 414 West 120th Street New York, New York 10027 212-866-7094 646-245-2654 (cell) 206-984-4900 (fax to email) davidjensen at usa.net From simon.dahlbacka at gmail.com Wed Feb 14 15:20:37 2007 From: simon.dahlbacka at gmail.com (Simon Dahlbacka) Date: Wed, 14 Feb 2007 16:20:37 +0200 Subject: [IronPython] iron python on pocket pc In-Reply-To: <237LBNoFZ9002S14.1171461985@cmsweb14.cms.usa.net> References: <237LBNoFZ9002S14.1171461985@cmsweb14.cms.usa.net> Message-ID: <57124720702140620h251206cdq9ceb782409900e5b@mail.gmail.com> AFAIK, no, since it needs stuff like Reflection Emit that is not available but in the full .NET 2.0 On 2/14/07, David Jensen wrote: > > Does ironpython work on pocket pc? If so, which versions does it run on? I > would assume it would be .net 2.0 which would be mobile 5 or, possibly, > 2003 > > David Jensen > > > David Jensen > Apartment 412 > 414 West 120th Street > New York, New York 10027 > 212-866-7094 > 646-245-2654 (cell) > 206-984-4900 (fax to email) > davidjensen at usa.net > > > > _______________________________________________ > 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 ygutfreund at draper.com Wed Feb 14 16:14:46 2007 From: ygutfreund at draper.com (Gutfreund, Yechezkal) Date: Wed, 14 Feb 2007 10:14:46 -0500 Subject: [IronPython] iron python on pocket pc References: <237LBNoFZ9002S14.1171461985@cmsweb14.cms.usa.net> <57124720702140620h251206cdq9ceb782409900e5b@mail.gmail.com> Message-ID: <98B94F0758D7394CA057AE4898CBC85E02890D9A@exchbk1.draper.com> Consider getting an OQO Model 2, or an SONY VIA UX-280 (they are only slightly larger than a PDA, but run full VISTA). ________________________________ From: users-bounces at lists.ironpython.com on behalf of Simon Dahlbacka Sent: Wed 2/14/2007 9:20 AM To: Discussion of IronPython Subject: Re: [IronPython] iron python on pocket pc AFAIK, no, since it needs stuff like Reflection Emit that is not available but in the full .NET 2.0 On 2/14/07, David Jensen < davidjensen at usa.net > wrote: Does ironpython work on pocket pc? If so, which versions does it run on? I would assume it would be .net 2.0 which would be mobile 5 or, possibly, 2003 David Jensen David Jensen Apartment 412 414 West 120th Street New York, New York 10027 212-866-7094 646-245-2654 (cell) 206-984-4900 (fax to email) davidjensen at usa.net _______________________________________________ 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 giles.thomas at resolversystems.com Wed Feb 14 16:16:57 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Wed, 14 Feb 2007 15:16:57 +0000 Subject: [IronPython] Bug in handling of keyword arguments for __call__ Message-ID: <45D327E9.6050207@resolversystems.com> Hi, It looks like there's a problem with calling a callable object using the "**" dictionary-unpacking syntax for keyword arguments. Here's a minimal repro. In CPython: ------------------------ Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class F(object): ... def __call__(self, *args, **kwargs): ... print args, kwargs ... >>> f = F() >>> f(*(1,), **{'a' : 23}) (1,) {'a': 23} >>> ------------------------ In IP 1.0.1 (also checked against 1.1 alpha): --------------------- IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> class F(object): ... def __call__(self, *args, **kwargs): ... print args, kwargs ... >>> f = F() >>> f(*(1,), **{'a' : 23}) Traceback (most recent call last): File , line 0, in ##23 Exception: this object is not callable with keyword parameters --------------------- Regards, Giles -- Giles Thomas giles.thomas at resolversystems.com +44 (0) 20 7253 6372 Resolver Systems Ltd 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From dinov at exchange.microsoft.com Wed Feb 14 18:07:54 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 14 Feb 2007 09:07:54 -0800 Subject: [IronPython] Bug in handling of keyword arguments for __call__ In-Reply-To: <45D327E9.6050207@resolversystems.com> References: <45D327E9.6050207@resolversystems.com> Message-ID: <7AD436E4270DD54A94238001769C2227689FBD2C77@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks for the bug report. I've opened bug #8246 to track this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8246). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Giles Thomas Sent: Wednesday, February 14, 2007 7:17 AM To: Discussion of IronPython Subject: [IronPython] Bug in handling of keyword arguments for __call__ Hi, It looks like there's a problem with calling a callable object using the "**" dictionary-unpacking syntax for keyword arguments. Here's a minimal repro. In CPython: ------------------------ Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class F(object): ... def __call__(self, *args, **kwargs): ... print args, kwargs ... >>> f = F() >>> f(*(1,), **{'a' : 23}) (1,) {'a': 23} >>> ------------------------ In IP 1.0.1 (also checked against 1.1 alpha): --------------------- IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> class F(object): ... def __call__(self, *args, **kwargs): ... print args, kwargs ... >>> f = F() >>> f(*(1,), **{'a' : 23}) Traceback (most recent call last): File , line 0, in ##23 Exception: this object is not callable with keyword parameters --------------------- Regards, Giles -- Giles Thomas giles.thomas at resolversystems.com +44 (0) 20 7253 6372 Resolver Systems Ltd 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From giles.thomas at resolversystems.com Wed Feb 14 19:11:41 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Wed, 14 Feb 2007 18:11:41 +0000 Subject: [IronPython] Bug in handling of keyword arguments for __call__ In-Reply-To: <7AD436E4270DD54A94238001769C2227689FBD2C77@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <45D327E9.6050207@resolversystems.com> <7AD436E4270DD54A94238001769C2227689FBD2C77@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <45D350DD.7000703@resolversystems.com> Many thanks, Dino. This might be of use when debugging: ---- IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> class F(object): ... def __call__(self, *args, **kwargs): ... print "F.__call__(%s, %s)" % (args, kwargs) ... >>> print F.__call__ >>> ---- Dino Viehland wrote: > Thanks for the bug report. I've opened bug #8246 to track this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8246). > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Giles Thomas > Sent: Wednesday, February 14, 2007 7:17 AM > To: Discussion of IronPython > Subject: [IronPython] Bug in handling of keyword arguments for __call__ > > Hi, > > It looks like there's a problem with calling a callable object using the > "**" dictionary-unpacking syntax for keyword arguments. Here's a > minimal repro. > > In CPython: > > ------------------------ > Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on > win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> class F(object): > ... def __call__(self, *args, **kwargs): > ... print args, kwargs > ... > >>> f = F() > >>> f(*(1,), **{'a' : 23}) > (1,) {'a': 23} > >>> > ------------------------ > > In IP 1.0.1 (also checked against 1.1 alpha): > > --------------------- > IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> class F(object): > ... def __call__(self, *args, **kwargs): > ... print args, kwargs > ... > >>> f = F() > >>> f(*(1,), **{'a' : 23}) > Traceback (most recent call last): > File , line 0, in ##23 > Exception: this object is not callable with keyword parameters > --------------------- > > > Regards, > > Giles > > -- > Giles Thomas > giles.thomas at resolversystems.com > +44 (0) 20 7253 6372 > > Resolver Systems Ltd > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 > Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > > _______________________________________________ > users mailing list > users 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 > -- Giles Thomas giles.thomas at resolversystems.com +44 (0) 20 7253 6372 Resolver Systems Ltd 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From szport at gmail.com Wed Feb 14 19:53:34 2007 From: szport at gmail.com (Andrew) Date: Wed, 14 Feb 2007 21:53:34 +0300 Subject: [IronPython] Bug in handling of keyword arguments for __call__ In-Reply-To: <45D350DD.7000703@resolversystems.com> References: <45D327E9.6050207@resolversystems.com> <7AD436E4270DD54A94238001769C2227689FBD2C77@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <45D350DD.7000703@resolversystems.com> Message-ID: It seems that this refers to Item # 7594: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7594 2007/2/14, Giles Thomas : > > Many thanks, Dino. This might be of use when debugging: > > ---- > IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> class F(object): > ... def __call__(self, *args, **kwargs): > ... print "F.__call__(%s, %s)" % (args, kwargs) > ... > >>> print F.__call__ > > >>> > ---- > > > > > Dino Viehland wrote: > > Thanks for the bug report. I've opened bug #8246 to track this ( > http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8246). > > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Giles Thomas > > Sent: Wednesday, February 14, 2007 7:17 AM > > To: Discussion of IronPython > > Subject: [IronPython] Bug in handling of keyword arguments for __call__ > > > > Hi, > > > > It looks like there's a problem with calling a callable object using the > > "**" dictionary-unpacking syntax for keyword arguments. Here's a > > minimal repro. > > > > In CPython: > > > > ------------------------ > > Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on > > win32 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> class F(object): > > ... def __call__(self, *args, **kwargs): > > ... print args, kwargs > > ... > > >>> f = F() > > >>> f(*(1,), **{'a' : 23}) > > (1,) {'a': 23} > > >>> > > ------------------------ > > > > In IP 1.0.1 (also checked against 1.1 alpha): > > > > --------------------- > > IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> class F(object): > > ... def __call__(self, *args, **kwargs): > > ... print args, kwargs > > ... > > >>> f = F() > > >>> f(*(1,), **{'a' : 23}) > > Traceback (most recent call last): > > File , line 0, in ##23 > > Exception: this object is not callable with keyword parameters > > --------------------- > > > > > > Regards, > > > > Giles > > > > -- > > Giles Thomas > > giles.thomas at resolversystems.com > > +44 (0) 20 7253 6372 > > > > Resolver Systems Ltd > > 17a Clerkenwell Road, London EC1M 5RD, UK > > VAT No.: GB 893 5643 79 > > Registered in England and Wales as company number 5467329. > > Registered address: 843 Finchley Road, London NW11 8NA, UK > > > > _______________________________________________ > > users mailing list > > users 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 > > > > -- > Giles Thomas > giles.thomas at resolversystems.com > +44 (0) 20 7253 6372 > > Resolver Systems Ltd > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 > Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > > _______________________________________________ > users mailing list > users 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 Wed Feb 14 20:15:05 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 14 Feb 2007 11:15:05 -0800 Subject: [IronPython] Bug in handling of keyword arguments for __call__ In-Reply-To: References: <45D327E9.6050207@resolversystems.com> <7AD436E4270DD54A94238001769C2227689FBD2C77@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <45D350DD.7000703@resolversystems.com> Message-ID: <7AD436E4270DD54A94238001769C2227689FBD2D5E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> They're certainly very similar but I'm not entirely certain if they're the same (although they may be). In the other bug type.__call__ is a type object which isn't right. If we were picking up type.__call__ instead of F.__call__ then I'd expect a different exception (as type.__call__ is a type, and types are callable w/ kw-args). I won't be certain until I look at it closer but I would expect that we're looking up the wrong thing when we do the call on f but I'm not sure where we'd be getting the wrong thing from. The good news is both of these are fixed in some internal (post v1.1) builds but the bad news is those aren't on CodePlex yet. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Andrew Sent: Wednesday, February 14, 2007 10:54 AM To: Discussion of IronPython Subject: Re: [IronPython] Bug in handling of keyword arguments for __call__ It seems that this refers to Item # 7594: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7594 2007/2/14, Giles Thomas >: Many thanks, Dino. This might be of use when debugging: ---- IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> class F(object): ... def __call__(self, *args, **kwargs): ... print "F.__call__(%s, %s)" % (args, kwargs) ... >>> print F.__call__ >>> ---- Dino Viehland wrote: > Thanks for the bug report. I've opened bug #8246 to track this ( http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8246). > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Giles Thomas > Sent: Wednesday, February 14, 2007 7:17 AM > To: Discussion of IronPython > Subject: [IronPython] Bug in handling of keyword arguments for __call__ > > Hi, > > It looks like there's a problem with calling a callable object using the > "**" dictionary-unpacking syntax for keyword arguments. Here's a > minimal repro. > > In CPython: > > ------------------------ > Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on > win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> class F(object): > ... def __call__(self, *args, **kwargs): > ... print args, kwargs > ... > >>> f = F() > >>> f(*(1,), **{'a' : 23}) > (1,) {'a': 23} > >>> > ------------------------ > > In IP 1.0.1 (also checked against 1.1 alpha): > > --------------------- > IronPython 1.0 (1.0.61005.1977 ) on .NET 2.0.50727.42 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> class F(object): > ... def __call__(self, *args, **kwargs): > ... print args, kwargs > ... > >>> f = F() > >>> f(*(1,), **{'a' : 23}) > Traceback (most recent call last): > File , line 0, in ##23 > Exception: this object is not callable with keyword parameters > --------------------- > > > Regards, > > Giles > > -- > Giles Thomas > giles.thomas at resolversystems.com > +44 (0) 20 7253 6372 > > Resolver Systems Ltd > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 > Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > > _______________________________________________ > users mailing list > users 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 > -- Giles Thomas giles.thomas at resolversystems.com +44 (0) 20 7253 6372 Resolver Systems Ltd 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.chadwick at gmail.com Thu Feb 15 04:43:36 2007 From: steve.chadwick at gmail.com (Steve Chadwick) Date: Wed, 14 Feb 2007 20:43:36 -0700 Subject: [IronPython] Looping in IronPython - should it be linear? In-Reply-To: <5b0248170702130729g4ead3e72m9a1ea0f950b0dedd@mail.gmail.com> References: <5b0248170702130729g4ead3e72m9a1ea0f950b0dedd@mail.gmail.com> Message-ID: <000501c750b3$79e04f20$0200a8c0@SteveChadwick> All, I am new to IP, and I have a silly post. I am sure that someone might be able to help me understand what is happening here (I am truly impressed with the technical depth of this forum). In trying to learn the language, one of the things I do is just run a quick looping experiment and measure the time it takes to execute N iterations. Up to this point, I have always gotten a trend that is linear, which makes sense. However, the below graph isn't linear, and I am puzzled as to why. The graph seems to suggest that the distribution has an exponential component to it. I have tested this on a couple of windows systems and this wasn't a fluke. Granted, the version of IP that I am using isn't the latest/greatest, but regardless of versioning, I am trying to understand the mechanism. Thanks for any thoughts, and my apologies if this turns out to be a silly post. Sincerely, Steve Chadwick -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Outlook.jpg Type: image/jpeg Size: 24797 bytes Desc: not available URL: From njriley at uiuc.edu Thu Feb 15 07:54:10 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu, 15 Feb 2007 00:54:10 -0600 Subject: [IronPython] Errors compiling IronPython with Mono Message-ID: <20070215065410.GA15326@uiuc.edu> Hi, I'm trying to compile IronPython with Mono, using the IPCE build script. With Mono 1.2.3 I get: IronPython/Modules/Builtin.cs(40,37): error CS0103: The name `Ops' does not exist in the context of `IronPython.Modules.Builtin' [... repeats many times ...] IronPython/Runtime/Operations/ComplexOps.cs(502,41): error CS0246: The type or namespace name `OpsReflectedField`2' could not be found. Are you missing a using directive or an assembly reference? IronPython/Runtime/Operations/ComplexOps.cs(503,41): error CS0246: The type or namespace name `OpsReflectedField`2' could not be found. Are you missing a using directive or an assembly reference? IronPython/Runtime/Operations/Ops.cs(62,125): error CS0246: The type or namespace name `MethodInfo' could not be found. Are you missing a using directive or an assembly reference? It seems that the last error is at the root of the problem - IronPython is using methods of MethodInfo that were only recently implemented in Mono (e.g. GetGenericArguments). I upgraded to SVN Mono, but now I get a different set of errors: IronPython/CodeDom/Compiler.cs(35,19): error CS0534: `IronPython.CodeDom.PythonGenerator' does not implement inherited abstract member `System.CodeDom.Compiler.CodeGenerator.CreateEscapedIdentifier(string)' IronPython/CodeDom/Compiler.cs(35,19): error CS0534: `IronPython.CodeDom.PythonGenerator' does not implement inherited abstract member `System.CodeDom.Compiler.CodeGenerator.CreateValidIdentifier(string)' IronPython/CodeDom/Compiler.cs(35,19): error CS0534: `IronPython.CodeDom.PythonGenerator' does not implement inherited abstract member `System.CodeDom.Compiler.CodeGenerator.GetTypeOutput(System.CodeDom.CodeTypeReference)' IronPython/CodeDom/Compiler.cs(35,19): error CS0534: `IronPython.CodeDom.PythonGenerator' does not implement inherited abstract member `System.CodeDom.Compiler.CodeGenerator.IsValidIdentifier(string)' IronPython/CodeDom/Compiler.cs(35,19): error CS0534: `IronPython.CodeDom.PythonGenerator' does not implement inherited abstract member `System.CodeDom.Compiler.CodeGenerator.Supports(System.CodeDom.Compiler.GeneratorSupport)' I am not terribly familiar with C# but it seems that these methods are defined in Generator.cs. Is this a problem with the Mono compiler not seeing the rest of this class, or ...? I would think that because IPCE uses IronPython 1.1a1 and comes with Mono it should be possible to compile it with that version, so maybe I am doing something wrong? Thanks, -- Nicholas Riley | From wierob at gmx.de Thu Feb 15 09:37:05 2007 From: wierob at gmx.de (Robert Wierschke) Date: Thu, 15 Feb 2007 09:37:05 +0100 Subject: [IronPython] Looping in IronPython - should it be linear? In-Reply-To: <000501c750b3$79e04f20$0200a8c0@SteveChadwick> References: <5b0248170702130729g4ead3e72m9a1ea0f950b0dedd@mail.gmail.com> <000501c750b3$79e04f20$0200a8c0@SteveChadwick> Message-ID: <20070215083705.225080@gmx.net> Please post the code of your loop. Do you instantiate objectn in your loop? I guess the memory management / garbage collection is responsible for the additional required time. Also the code runs in the .NET VM and the VM might do other things as well (JIT compilation, ...). -------- Original-Nachricht -------- Datum: Wed, 14 Feb 2007 20:43:36 -0700 Von: "Steve Chadwick" An: "\'Discussion of IronPython\'" CC: Betreff: [IronPython] Looping in IronPython - should it be linear? > All, > I am new to IP, and I have a silly post. I am sure that someone > might be able to help me understand what is happening here (I am truly > impressed with the technical depth of this forum). In trying to learn the > language, one of the things I do is just run a quick looping experiment > and > measure the time it takes to execute N iterations. Up to this point, I > have > always gotten a trend that is linear, which makes sense. > However, the below graph isn't linear, and I am puzzled as to why. > The graph seems to suggest that the distribution has an exponential > component to it. I have tested this on a couple of windows systems and > this > wasn't a fluke. Granted, the version of IP that I am using isn't the > latest/greatest, but regardless of versioning, I am trying to understand > the > mechanism. Thanks for any thoughts, and my apologies if this turns out to > be a silly post. > > Sincerely, > > Steve Chadwick > > > > -- 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 stan at ertmssolutions.com Thu Feb 15 09:38:56 2007 From: stan at ertmssolutions.com (Stanislas Pinte) Date: Thu, 15 Feb 2007 09:38:56 +0100 Subject: [IronPython] Looping in IronPython - should it be linear? In-Reply-To: <20070215083705.225080@gmx.net> References: <5b0248170702130729g4ead3e72m9a1ea0f950b0dedd@mail.gmail.com> <000501c750b3$79e04f20$0200a8c0@SteveChadwick> <20070215083705.225080@gmx.net> Message-ID: <45D41C20.6070604@ertmssolutions.com> Hello, I have had issues recently with a simulation framework, using simpy and IP, that is giving an out of memory error after +- 15 minutes... Repeatedly. If the looping code is costing anything non-linear, it is a serious issue ;-) Stan. Robert Wierschke a ?crit : > Please post the code of your loop. > > Do you instantiate objectn in your loop? I guess the memory management / garbage collection is responsible for the additional required time. > > Also the code runs in the .NET VM and the VM might do other things as well (JIT compilation, ...). > > > -------- Original-Nachricht -------- > Datum: Wed, 14 Feb 2007 20:43:36 -0700 > Von: "Steve Chadwick" > An: "\'Discussion of IronPython\'" > CC: > Betreff: [IronPython] Looping in IronPython - should it be linear? > >> All, >> I am new to IP, and I have a silly post. I am sure that someone >> might be able to help me understand what is happening here (I am truly >> impressed with the technical depth of this forum). In trying to learn the >> language, one of the things I do is just run a quick looping experiment >> and >> measure the time it takes to execute N iterations. Up to this point, I >> have >> always gotten a trend that is linear, which makes sense. >> However, the below graph isn't linear, and I am puzzled as to why. >> The graph seems to suggest that the distribution has an exponential >> component to it. I have tested this on a couple of windows systems and >> this >> wasn't a fluke. Granted, the version of IP that I am using isn't the >> latest/greatest, but regardless of versioning, I am trying to understand >> the >> mechanism. Thanks for any thoughts, and my apologies if this turns out to >> be a silly post. >> >> Sincerely, >> >> Steve Chadwick >> >> >> >> > -- ----------------------------------------------------------------- Stanislas Pinte e-mail: stan at ertmssolutions.com ERTMS Solutions http://www.ertmssolutions.com Rue de l'Autonomie, 1 Tel: + 322 - 522.06.63 1070 Bruxelles Fax: + 322 - 522.09.30 ----------------------------------------------------------------- Skype (http://www.skype.com) id: stanpinte ----------------------------------------------------------------- From giles.thomas at resolversystems.com Thu Feb 15 11:42:40 2007 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Thu, 15 Feb 2007 10:42:40 +0000 Subject: [IronPython] Bug in handling of keyword arguments for __call__ In-Reply-To: <7AD436E4270DD54A94238001769C2227689FBD2D5E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <45D327E9.6050207@resolversystems.com> <7AD436E4270DD54A94238001769C2227689FBD2C77@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <45D350DD.7000703@resolversystems.com> <7AD436E4270DD54A94238001769C2227689FBD2D5E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <45D43920.108@resolversystems.com> Excellent - thanks, Dino. We have workarounds for our specific uses in the meantime. Regards, Giles Dino Viehland wrote: > > They're certainly very similar but I'm not entirely certain if they're > the same (although they may be). In the other bug type.__call__ is a > type object which isn't right. If we were picking up type.__call__ > instead of F.__call__ then I'd expect a different exception (as > type.__call__ is a type, and types are callable w/ kw-args). I won't > be certain until I look at it closer but I would expect that we're > looking up the wrong thing when we do the call on f but I'm not sure > where we'd be getting the wrong thing from. > > The good news is both of these are fixed in some internal (post v1.1) > builds but the bad news is those aren't on CodePlex yet. > > > > *From:* users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Andrew > *Sent:* Wednesday, February 14, 2007 10:54 AM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Bug in handling of keyword arguments for > __call__ > > > > It seems that this refers to Item # 7594: > http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7594 > > 2007/2/14, Giles Thomas >: > > Many thanks, Dino. This might be of use when debugging: > > ---- > IronPython 1.0 (1.0.61005.1977) on .NET 2.0.50727.42 > Copyright (c) Microsoft Corporation. All rights reserved. > >>> class F(object): > ... def __call__(self, *args, **kwargs): > ... print "F.__call__(%s, %s)" % (args, kwargs) > ... > >>> print F.__call__ > > >>> > ---- > > > > > Dino Viehland wrote: > > Thanks for the bug report. I've opened bug #8246 to track this ( > http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8246). > > > > -----Original Message----- > > From: users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com > ] On Behalf Of Giles Thomas > > Sent: Wednesday, February 14, 2007 7:17 AM > > To: Discussion of IronPython > > Subject: [IronPython] Bug in handling of keyword arguments for __call__ > > > > Hi, > > > > It looks like there's a problem with calling a callable object using the > > "**" dictionary-unpacking syntax for keyword arguments. Here's a > > minimal repro. > > > > In CPython: > > > > ------------------------ > > Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on > > win32 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> class F(object): > > ... def __call__(self, *args, **kwargs): > > ... print args, kwargs > > ... > > >>> f = F() > > >>> f(*(1,), **{'a' : 23}) > > (1,) {'a': 23} > > >>> > > ------------------------ > > > > In IP 1.0.1 (also checked against 1.1 alpha): > > > > --------------------- > > IronPython 1.0 (1.0.61005.1977 ) on .NET 2.0.50727.42 > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> class F(object): > > ... def __call__(self, *args, **kwargs): > > ... print args, kwargs > > ... > > >>> f = F() > > >>> f(*(1,), **{'a' : 23}) > > Traceback (most recent call last): > > File , line 0, in ##23 > > Exception: this object is not callable with keyword parameters > > --------------------- > > > > > > Regards, > > > > Giles > > > > -- > > Giles Thomas > > giles.thomas at resolversystems.com > > > +44 (0) 20 7253 6372 > > > > Resolver Systems Ltd > > 17a Clerkenwell Road, London EC1M 5RD, UK > > VAT No.: GB 893 5643 79 > > Registered in England and Wales as company number 5467329. > > Registered address: 843 Finchley Road, London NW11 8NA, UK > > > > _______________________________________________ > > users mailing list > > users 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 > > > > -- > Giles Thomas > giles.thomas at resolversystems.com > +44 (0) 20 7253 6372 > > Resolver Systems Ltd > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 > Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > > _______________________________________________ > users mailing list > users 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 > -- Giles Thomas giles.thomas at resolversystems.com +44 (0) 20 7253 6372 Resolver Systems Ltd 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.chadwick at gmail.com Thu Feb 15 14:11:35 2007 From: steve.chadwick at gmail.com (Steve Chadwick) Date: Thu, 15 Feb 2007 06:11:35 -0700 Subject: [IronPython] Looping in IronPython - should it be linear? In-Reply-To: <20070215083705.225080@gmx.net> References: <5b0248170702130729g4ead3e72m9a1ea0f950b0dedd@mail.gmail.com><000501c750b3$79e04f20$0200a8c0@SteveChadwick> <20070215083705.225080@gmx.net> Message-ID: <008401c75102$d2f4ee00$0200a8c0@SteveChadwick> Sorry - here is the code that I am using to generate the loop time. def RunExperiment1(self, loopInterationValue): #counting up print "Exp 1: Counting Up, the loop value is ", str(loopInterationValue), "\n" for i in range(0, self.m_ExpRuns): outer_loop = 5 # Start block of interest start_time = time.time() for j in range(0,outer_loop): for k in range(0, loopInterationValue): 1 #empty loop end_time = time.time() mean = (end_time - start_time)/(outer_loop*1.0) # End block of interest # Write output via the base class (assign to mod variables) self.m_Mean = mean self.m_label_desc = "Loop_Counting_Up" self.m_LabelValue = loopInterationValue self.write_results() #via base class -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Robert Wierschke Sent: Thursday, February 15, 2007 1:37 AM To: Discussion of IronPython Subject: Re: [IronPython] Looping in IronPython - should it be linear? Please post the code of your loop. Do you instantiate objectn in your loop? I guess the memory management / garbage collection is responsible for the additional required time. Also the code runs in the .NET VM and the VM might do other things as well (JIT compilation, ...). -------- Original-Nachricht -------- Datum: Wed, 14 Feb 2007 20:43:36 -0700 Von: "Steve Chadwick" An: "\'Discussion of IronPython\'" CC: Betreff: [IronPython] Looping in IronPython - should it be linear? > All, > I am new to IP, and I have a silly post. I am sure that > someone might be able to help me understand what is happening here (I > am truly impressed with the technical depth of this forum). In trying > to learn the language, one of the things I do is just run a quick > looping experiment and measure the time it takes to execute N > iterations. Up to this point, I have always gotten a trend that is > linear, which makes sense. > However, the below graph isn't linear, and I am puzzled as to why. > The graph seems to suggest that the distribution has an exponential > component to it. I have tested this on a couple of windows systems > and this wasn't a fluke. Granted, the version of IP that I am using > isn't the latest/greatest, but regardless of versioning, I am trying > to understand the mechanism. Thanks for any thoughts, and my > apologies if this turns out to be a silly post. > > Sincerely, > > Steve Chadwick > > > > -- 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 dfugate at microsoft.com Thu Feb 15 18:34:33 2007 From: dfugate at microsoft.com (Dave Fugate) Date: Thu, 15 Feb 2007 09:34:33 -0800 Subject: [IronPython] Looping in IronPython - should it be linear? In-Reply-To: <008401c75102$d2f4ee00$0200a8c0@SteveChadwick> References: <5b0248170702130729g4ead3e72m9a1ea0f950b0dedd@mail.gmail.com><000501c750b3$79e04f20$0200a8c0@SteveChadwick> <20070215083705.225080@gmx.net> <008401c75102$d2f4ee00$0200a8c0@SteveChadwick> Message-ID: <7346A825E148B049A9AD1D3ED46A2D910CCD6043EC@NA-EXMSG-C106.redmond.corp.microsoft.com> Try replacing "range" with "xrange" and I think your performance results will change a bit (depending on the size of loopIterationValue of course). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Steve Chadwick Sent: Thursday, February 15, 2007 5:12 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Looping in IronPython - should it be linear? Sorry - here is the code that I am using to generate the loop time. def RunExperiment1(self, loopInterationValue): #counting up print "Exp 1: Counting Up, the loop value is ", str(loopInterationValue), "\n" for i in range(0, self.m_ExpRuns): outer_loop = 5 # Start block of interest start_time = time.time() for j in range(0,outer_loop): for k in range(0, loopInterationValue): 1 #empty loop end_time = time.time() mean = (end_time - start_time)/(outer_loop*1.0) # End block of interest # Write output via the base class (assign to mod variables) self.m_Mean = mean self.m_label_desc = "Loop_Counting_Up" self.m_LabelValue = loopInterationValue self.write_results() #via base class -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Robert Wierschke Sent: Thursday, February 15, 2007 1:37 AM To: Discussion of IronPython Subject: Re: [IronPython] Looping in IronPython - should it be linear? Please post the code of your loop. Do you instantiate objectn in your loop? I guess the memory management / garbage collection is responsible for the additional required time. Also the code runs in the .NET VM and the VM might do other things as well (JIT compilation, ...). -------- Original-Nachricht -------- Datum: Wed, 14 Feb 2007 20:43:36 -0700 Von: "Steve Chadwick" An: "\'Discussion of IronPython\'" CC: Betreff: [IronPython] Looping in IronPython - should it be linear? > All, > I am new to IP, and I have a silly post. I am sure that > someone might be able to help me understand what is happening here (I > am truly impressed with the technical depth of this forum). In trying > to learn the language, one of the things I do is just run a quick > looping experiment and measure the time it takes to execute N > iterations. Up to this point, I have always gotten a trend that is > linear, which makes sense. > However, the below graph isn't linear, and I am puzzled as to why. > The graph seems to suggest that the distribution has an exponential > component to it. I have tested this on a couple of windows systems > and this wasn't a fluke. Granted, the version of IP that I am using > isn't the latest/greatest, but regardless of versioning, I am trying > to understand the mechanism. Thanks for any thoughts, and my > apologies if this turns out to be a silly post. > > Sincerely, > > Steve Chadwick > > > > -- 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 _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From xmlhacker at gmail.com Fri Feb 16 22:17:46 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Fri, 16 Feb 2007 14:17:46 -0700 Subject: [IronPython] Errors compiling IronPython with Mono In-Reply-To: <20070215065410.GA15326@uiuc.edu> References: <20070215065410.GA15326@uiuc.edu> Message-ID: Not sure if this is the same issue (I had this same problem a few days ago attempting to build IPCE as well), but part of the 1.2.3.1 release from this morning includes, - Fix IronPython 1.1 alpha 1 Compilation (80749). More @ http://www.go-mono.com/archive/1.2.3.1/ On 2/14/07, Nicholas Riley wrote: > > Hi, > > I'm trying to compile IronPython with Mono, using the IPCE build > script. With Mono 1.2.3 I get: > > IronPython/Modules/Builtin.cs(40,37): error CS0103: The name `Ops' does > not exist in the context of `IronPython.Modules.Builtin' > [... repeats many times ...] > IronPython/Runtime/Operations/ComplexOps.cs(502,41): error CS0246: The > type or namespace name `OpsReflectedField`2' could not be found. Are you > missing a using directive or an assembly reference? > IronPython/Runtime/Operations/ComplexOps.cs(503,41): error CS0246: The > type or namespace name `OpsReflectedField`2' could not be found. Are you > missing a using directive or an assembly reference? > IronPython/Runtime/Operations/Ops.cs(62,125): error CS0246: The type or > namespace name `MethodInfo' could not be found. Are you missing a using > directive or an assembly reference? > > It seems that the last error is at the root of the problem - > IronPython is using methods of MethodInfo that were only recently > implemented in Mono (e.g. GetGenericArguments). I upgraded to SVN > Mono, but now I get a different set of errors: > > IronPython/CodeDom/Compiler.cs(35,19): error CS0534: > `IronPython.CodeDom.PythonGenerator' does not implement inherited abstract > member > `System.CodeDom.Compiler.CodeGenerator.CreateEscapedIdentifier(string)' > IronPython/CodeDom/Compiler.cs(35,19): error CS0534: > `IronPython.CodeDom.PythonGenerator' does not implement inherited abstract > member `System.CodeDom.Compiler.CodeGenerator.CreateValidIdentifier(string)' > IronPython/CodeDom/Compiler.cs(35,19): error CS0534: > `IronPython.CodeDom.PythonGenerator' does not implement inherited abstract > member `System.CodeDom.Compiler.CodeGenerator.GetTypeOutput( > System.CodeDom.CodeTypeReference)' > IronPython/CodeDom/Compiler.cs(35,19): error CS0534: > `IronPython.CodeDom.PythonGenerator' does not implement inherited abstract > member `System.CodeDom.Compiler.CodeGenerator.IsValidIdentifier(string)' > IronPython/CodeDom/Compiler.cs(35,19): error CS0534: > `IronPython.CodeDom.PythonGenerator' does not implement inherited abstract > member `System.CodeDom.Compiler.CodeGenerator.Supports( > System.CodeDom.Compiler.GeneratorSupport)' > > I am not terribly familiar with C# but it seems that these methods are > defined in Generator.cs. Is this a problem with the Mono compiler not > seeing the rest of this class, or ...? > > I would think that because IPCE uses IronPython 1.1a1 and comes with > Mono it should be possible to compile it with that version, so maybe I > am doing something wrong? > > Thanks, > > -- > Nicholas Riley | > _______________________________________________ > 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 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erzengel-von-licht at cox.net Sat Feb 17 11:04:18 2007 From: erzengel-von-licht at cox.net (Erzengel des Lichtes) Date: Sat, 17 Feb 2007 02:04:18 -0800 Subject: [IronPython] Method invocation when assigned to instance differs from default assignment? Message-ID: <000901c7527a$fcfe23f0$6601a8c0@cxm> I encountered an interesting quirk in Python; I want to know what it's about so that I can understand the expected behavior of a python interpriter. It occurs in both CPython and IronPython, so I presume it is the intended behavior. Note that I haven't worked with Python very long, and have mostly used simple scripting that is used to control the game I'm working on, so this may be well known already, but I found it strange. Anyway, I noticed when you did the following, the class would make a default assignment that was referanced in instances: (This isn't the quirk I'm talking about, it leads to it.) class MyClass: i = 5 Test = MyClass() Test2 = MyClass() def PrintTests(Message): print Message print "Test 1: " + str(Test.i) print "Test 2: " + str(Test2.i) PrintTests("Initial") Test.i = 2 PrintTests("Instance Change") MyClass.i = 4 PrintTests("Class Change") Test3 = MyClass() print "Test 3: " + str(Test3.i) Prints out: Initial Test 1: 5 Test 2: 5 Instance Change Test 1: 2 Test 2: 5 Class Change Test 1: 2 Test 2: 4 Test 3: 4 As you can see, changing the variable on the class type changes it on all unchanged instances and new instances. Now, I did this: class MyClass: pass def Method(): print "hello" Test = MyClass() Test.Func1 = Method Test.Func1() MyClass.Func2 = Method Test.Func2() Func1 prints out Hello, but Func2 says "TypeError: Method() takes exactly 0 arguments (1 given)". Why does Func1 work? Shouldn't it be passing in Test, and so providing more arguments than Method wants? Why does it only do this with Func2? Why would assigning a function to an instance variable cause this behavior to be different from a class variable? Is there any way to have the Func1 behavior, while being able to assign the change to all unchanged instances and new instances like I can with other variables? It's not something I really need to do, but I need to know Python's behavior in order to ensure I reproduce it correctly (My co-workers could get around any issues, but this is intended for the end user to have available as well, and having it act differently from CPython, IronPython, and others would be a Bad ThingT). Thanks for any info, Erzengel des Lichtes Hikari no Daitenshi Archangel of Light From njriley at uiuc.edu Sat Feb 17 11:38:44 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Sat, 17 Feb 2007 04:38:44 -0600 Subject: [IronPython] Method invocation when assigned to instance differs from default assignment? In-Reply-To: <000901c7527a$fcfe23f0$6601a8c0@cxm> References: <000901c7527a$fcfe23f0$6601a8c0@cxm> Message-ID: <20070217103844.GA45855@uiuc.edu> On Sat, Feb 17, 2007 at 02:04:18AM -0800, Erzengel des Lichtes wrote: > As you can see, changing the variable on the class type changes it on all > unchanged instances and new instances. This isn't quite correct - Python isn't actually going through and changing every instance. Attribute lookup ordinarily works on an instance by first looking for a value in the instance, then in the class, then in superclasses if any. > Now, I did this: > class MyClass: > pass > def Method(): > print "hello" > Test = MyClass() > Test.Func1 = Method > Test.Func1() > MyClass.Func2 = Method > Test.Func2() > > Func1 prints out Hello, but Func2 says "TypeError: Method() takes exactly 0 > arguments (1 given)". > > Why does Func1 work? Shouldn't it be passing in Test, and so providing more > arguments than Method wants? Why does it only do this with Func2? Why would > assigning a function to an instance variable cause this behavior to be > different from a class variable? You've discovered the difference between bound and unbound methods. You can see it if you examine a method when it's accessed via a class and its instance: >>> class C(object): ... def meth(self): return 5 ... >>> inst = C() >>> C.meth >>> inst.meth > >>> C.meth() Traceback (most recent call last): TypeError: meth() takes exactly 1 argument (0 given) >>> C.meth(inst) 5 >>> inst.meth() 5 Unbound methods require you specify the instance as an argument, typically named 'self'; bound methods have an instance already bound to 'self', hence the name. When you define a method on a class, what actually gets stored in the class is a "method descriptor" which dispenses either a bound or unbound method based on the object (instance or class, respectively) whose attribute is being looked up. There's some more information on how lookup works (in CPython, so the internals aren't quite valid for IronPython, but the behavior is the same) in PEP 252: > Is there any way to have the Func1 behavior, while being able to assign the > change to all unchanged instances and new instances like I can with other > variables? It's not something I really need to do, but I need to know > Python's behavior in order to ensure I reproduce it correctly (My co-workers > could get around any issues, but this is intended for the end user to have > available as well, and having it act differently from CPython, IronPython, > and others would be a Bad ThingT). I'd suggest, having recently been involved in a project which had to account for all the different ways you can modify Python's method dispatch, that you just figure out the features of Python that you need, and make sure they work. Don't go exploring or you might lose a week :-) You might better spend your time learning a bit about Python idioms; for example, in your code: print "Test 1: " + str(Test.i) would be more simply (and efficiently) written as: print "Test 1:', Test.i You might also look at PEP 8 for some hints on naming and so forth: -- Nicholas Riley | From njriley at uiuc.edu Sat Feb 17 11:40:00 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Sat, 17 Feb 2007 04:40:00 -0600 Subject: [IronPython] Errors compiling IronPython with Mono In-Reply-To: References: <20070215065410.GA15326@uiuc.edu> Message-ID: <20070217104000.GB45855@uiuc.edu> On Fri, Feb 16, 2007 at 02:17:46PM -0700, M. David Peterson wrote: > Not sure if this is the same issue (I had this same problem a few days ago > attempting to build IPCE as well), but part of the 1.2.3.1 release from this > morning includes, > > > - Fix IronPython 1.1 alpha 1 Compilation (80749). > > More @ http://www.go-mono.com/archive/1.2.3.1/ Yup, it's the same issue. Thanks, it works wonderfully now. -- Nicholas Riley | From erzengel-von-licht at cox.net Sat Feb 17 20:50:57 2007 From: erzengel-von-licht at cox.net (Erzengel des Lichtes) Date: Sat, 17 Feb 2007 11:50:57 -0800 Subject: [IronPython] Method invocation when assigned to instancediffers from default assignment? In-Reply-To: <20070217103844.GA45855@uiuc.edu> References: <000901c7527a$fcfe23f0$6601a8c0@cxm> <20070217103844.GA45855@uiuc.edu> Message-ID: <001101c752cc$f114b2a0$6601a8c0@cxm> -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Nicholas Riley Sent: Saturday, February 17, 2007 2:39 AM To: Discussion of IronPython Subject: Re: [IronPython] Method invocation when assigned to instancediffers from default assignment? You've discovered the difference between bound and unbound methods. You can see it if you examine a method when it's accessed via a class and its instance: >>> class C(object): ... def meth(self): return 5 ... >>> inst = C() >>> C.meth >>> inst.meth > >>> C.meth() Traceback (most recent call last): TypeError: meth() takes exactly 1 argument (0 given) >>> C.meth(inst) 5 >>> inst.meth() 5 Unbound methods require you specify the instance as an argument, typically named 'self'; bound methods have an instance already bound to 'self', hence the name. When you define a method on a class, what actually gets stored in the class is a "method descriptor" which dispenses either a bound or unbound method based on the object (instance or class, respectively) whose attribute is being looked up. There's some more information on how lookup works (in CPython, so the internals aren't quite valid for IronPython, but the behavior is the same) in PEP 252: --Reply-- OK, looking into my original code, Test.Func1 was a Function, Test.Func2 was a Bound Method, and MyClass.Func2 was an unbound method. My question then is: Why is Test.Func1 not a bound method? From xmlhacker at gmail.com Sat Feb 17 21:08:10 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sat, 17 Feb 2007 13:08:10 -0700 Subject: [IronPython] Errors compiling IronPython with Mono In-Reply-To: <20070217104000.GB45855@uiuc.edu> References: <20070215065410.GA15326@uiuc.edu> <20070217104000.GB45855@uiuc.edu> Message-ID: On 2/17/07, Nicholas Riley wrote: > > > Yup, it's the same issue. Thanks, it works wonderfully now. Sweet! Thanks for the info! -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From njriley at uiuc.edu Sat Feb 17 21:40:55 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Sat, 17 Feb 2007 14:40:55 -0600 Subject: [IronPython] Method invocation when assigned to instancediffers from default assignment? In-Reply-To: <001101c752cc$f114b2a0$6601a8c0@cxm> References: <000901c7527a$fcfe23f0$6601a8c0@cxm> <20070217103844.GA45855@uiuc.edu> <001101c752cc$f114b2a0$6601a8c0@cxm> Message-ID: <20070217204055.GA50453@uiuc.edu> On Sat, Feb 17, 2007 at 11:50:57AM -0800, Erzengel des Lichtes wrote: > OK, looking into my original code, Test.Func1 was a Function, Test.Func2 was > a Bound Method, and MyClass.Func2 was an unbound method. > My question then is: Why is Test.Func1 not a bound method? Bound methods are only created if the method is defined on the class, then accessed through an instance. If the method is defined on the instance, there's no need to bind it to an instance because it is already instance-specific. I hope that makes sense. -- Nicholas Riley | From drew at astro.pas.rochester.edu Sat Feb 17 22:06:59 2007 From: drew at astro.pas.rochester.edu (drew moore) Date: Sat, 17 Feb 2007 16:06:59 -0500 Subject: [IronPython] Method invocation when assigned to instancediffers from default assignment? In-Reply-To: <001101c752cc$f114b2a0$6601a8c0@cxm> References: <000901c7527a$fcfe23f0$6601a8c0@cxm> <20070217103844.GA45855@uiuc.edu> <001101c752cc$f114b2a0$6601a8c0@cxm> Message-ID: <45D76E73.2070802@astro.pas.rochester.edu> > OK, looking into my original code, Test.Func1 was a Function, Test.Func2 was > a Bound Method, and MyClass.Func2 was an unbound method. > My question then is: Why is Test.Func1 not a bound method? > This isn't really an IronPython question but... After you use Python for a while, you'll realize that such behavior would be very bad. An instance might want to simply cache a function for usage later. If just putting the function into the instance dictionary changed its signature, that would be a Bad Thing. Being able to add methods to a class at runtime for ALL instances to use -- well, that is a Good Thing. If you want to override the behavior of the class in specific instances, you probably want those instances to be subclasses instead. If you want to change that behavior *at runtime*, you can dynamically change an instance's class:: inst.__class__ = SomeOtherClass What are you trying to do that is leading you to desire this behavior? Your question might not seem so silly (sorry) if we can see the problem you are trying to solve. I'm sure that once you see the "Pythonic" way to do it, you'll like it better. >>> class spam : pass ... >>> def eggs(self) : print self ... >>> spam.eggs = eggs >>> spam.eggs is eggs False >>> eggs >>> spam.eggs >>> s = spam() >>> s.eggs is eggs False >>> s.eggs > >>> s.eggs = eggs >>> s.eggs is eggs True >>> s.eggs >>> s.__class__ >>> class OldSpam(spam) : ... def eggs(self) : ... print 42 ... >>> os = OldSpam() >>> os.eggs() 42 >>> s.eggs() Traceback (most recent call last): File "", line 1, in TypeError: eggs() takes exactly 1 argument (0 given) >>> del s.eggs >>> s.eggs() <__main__.spam instance at 0x00A4EAA8> >>> s.__class__ = OldSpam >>> s.eggs() 42 >>> Hope this helps. cheers Drew From erzengel-von-licht at cox.net Sun Feb 18 10:42:36 2007 From: erzengel-von-licht at cox.net (Erzengel des Lichtes) Date: Sun, 18 Feb 2007 01:42:36 -0800 Subject: [IronPython] Method invocation when assigned to instancediffers from default assignment? In-Reply-To: <45D76E73.2070802@astro.pas.rochester.edu> References: <000901c7527a$fcfe23f0$6601a8c0@cxm> <20070217103844.GA45855@uiuc.edu><001101c752cc$f114b2a0$6601a8c0@cxm> <45D76E73.2070802@astro.pas.rochester.edu> Message-ID: <002101c75341$1f2fe280$6601a8c0@cxm> -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of drew moore Sent: Saturday, February 17, 2007 1:07 PM To: Discussion of IronPython Subject: Re: [IronPython] Method invocation when assigned to instancediffers from default assignment? Your question might not seem so silly (sorry) if we can see the problem you are trying to solve. --Reply-- I'm not actually trying to solve a problem, just understand a behavior. Because I'm replacing portions of IronPython to allow me to interrupt a script at any point (and save local variables and the instruction pointer), I have to reimplement code. Originally I had classes running the code under the class scope on every instance (I thought it was like C# where class assignments are basically added to all constructors); then it was noticed that in instances where the class code ran a function this was a variation in the behavior of IronPython /w Fibers vs. Interuptable IronPython. I realized my mistake, fixed it, and the unit test case included not only assigning variables and running functions (which was used in the python scripts we've already made), but assigning functions--both to the class and the instance. Again it had a variation (Our Interruptable didn't see the extra variable, IronPython complained), as I was assuming that any assignment of a function would assign the function type instead of a bound/unbound method on class types. After all, changing a variable on the class only changed the referance, not the type. This lead to the E-mail, as I didn't understand what exactly was going on here. It seems to be somewhat inconsistent. So I don't actually have a problem needing a solution, just a "Why is it that way?" sort of question. At the moment, I'm having difficulty visualizing a real world scenario where this capability would be useful; it just happened to be a part of the testing scenarios to ensure consistent behavior. If it were like an event, would it not be preferable to be able to have a "default event" that can be overriden with an "instance event"? Otherwise, why have instance functions at all? Thanks for info, Erzengel des Lichtes Hikari no Daitenshi Archangel of Light From konstl at aaart.de Sun Feb 18 14:27:47 2007 From: konstl at aaart.de (kls) Date: Sun, 18 Feb 2007 14:27:47 +0100 Subject: [IronPython] Using a Python-Module from other Languages over .NET? Message-ID: <45D85453.9020506@aaart.de> Hi, i have a litle question: Is it possibel to compile a Python-Module with IronPython with all dependencies to a .Net-Module with can used from other Languages like VB over .NET? Thx for the answers From fuzzyman at voidspace.org.uk Sun Feb 18 14:35:30 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 18 Feb 2007 13:35:30 +0000 Subject: [IronPython] Using a Python-Module from other Languages over .NET? In-Reply-To: <45D85453.9020506@aaart.de> References: <45D85453.9020506@aaart.de> Message-ID: <45D85622.1080608@voidspace.org.uk> kls wrote: > Hi, > > i have a litle question: Is it possibel to compile a Python-Module with > IronPython with all dependencies to a .Net-Module with can used from > other Languages like VB over .NET? > > Not directly I'm afraid. The .NET garbage collector doesn't collect classes, so for memory efficiency reasons (? - only ?) IronPython re-uses a single (?) class definition internally. That means that IronPython classes can't be consumed directly from other languages. You can create stub wrapper classes in C# / VB.NET which call into the engine and use your classes. This is quite simple and somewhere on this list someone posted an example. Using the System.Reflection API it should be possible to automate creating these stub classes. I haven't had time to explore this myself, but it would be very interesting. All the best, Michael Foord http://www.voidspace.org.uk/ironpython/ > Thx for the answers > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From drew at astro.pas.rochester.edu Sun Feb 18 17:24:54 2007 From: drew at astro.pas.rochester.edu (drew moore) Date: Sun, 18 Feb 2007 11:24:54 -0500 Subject: [IronPython] Method invocation when assigned to instancediffers from default assignment? In-Reply-To: <002101c75341$1f2fe280$6601a8c0@cxm> References: <000901c7527a$fcfe23f0$6601a8c0@cxm> <20070217103844.GA45855@uiuc.edu><001101c752cc$f114b2a0$6601a8c0@cxm> <45D76E73.2070802@astro.pas.rochester.edu> <002101c75341$1f2fe280$6601a8c0@cxm> Message-ID: <45D87DD6.8010502@astro.pas.rochester.edu> Erzengel des Lichtes wrote: > > > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of drew moore > Sent: Saturday, February 17, 2007 1:07 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Method invocation when assigned to instancediffers > from default assignment? > > Your question might not seem so silly (sorry) if we can see the problem you > are trying to solve. > > --Reply-- > I'm not actually trying to solve a problem, just understand a behavior. > Wow! you're not the typical Python newbie! I don't know much about Fibers and Interruptible IronPython, but it sounds very interesting. Here's a simple scenario I can think of where instances might have callable attributes that don't need (or want) self automatically put in as the first argument:: class Logger(object) : def __init__(self, writer=None) : if writer == None : import sys self.writer = sys.stdout else: self.writer = writer def Log(self, message) : self.writer(message) cheers Drew From drew at astro.pas.rochester.edu Sun Feb 18 17:41:53 2007 From: drew at astro.pas.rochester.edu (drew moore) Date: Sun, 18 Feb 2007 11:41:53 -0500 Subject: [IronPython] Method invocation when assigned to instancediffers from default assignment? In-Reply-To: <45D87DD6.8010502@astro.pas.rochester.edu> References: <000901c7527a$fcfe23f0$6601a8c0@cxm> <20070217103844.GA45855@uiuc.edu><001101c752cc$f114b2a0$6601a8c0@cxm> <45D76E73.2070802@astro.pas.rochester.edu> <002101c75341$1f2fe280$6601a8c0@cxm> <45D87DD6.8010502@astro.pas.rochester.edu> Message-ID: <45D881D1.6010306@astro.pas.rochester.edu> oops. self.writer = sys.stdout.write but you get the idea From Jeff at ingenio.com Mon Feb 19 08:45:25 2007 From: Jeff at ingenio.com (Jeff Brown) Date: Sun, 18 Feb 2007 23:45:25 -0800 Subject: [IronPython] popen should not open new windows. Message-ID: When calling a process using nt.popen*, the ProcessInfo has the CreateNoWindow option set to false. This is fine ordinarily when working from the command prompt since it seems the current window will get recycled. However, when executing within the context of an NT Service or GUI process what happens is that a new window pops up whenever popen launches a process. This is very distracting. I ended up cooking up this workaround: # The built-in popen causes windows to pop up whenever a process # runs since it doesn't set the CreateNoWindow option of the ProcessInfo. *sigh* def QuietPOpen(executable, arguments): processStartInfo = ProcessStartInfo(executable, arguments) processStartInfo.UseShellExecute = False processStartInfo.CreateNoWindow = True processStartInfo.RedirectStandardOutput = True process = Process.Start(processStartInfo) return file(process.StandardOutput.BaseStream, "r") Jeff. From Jeff at ingenio.com Mon Feb 19 10:00:11 2007 From: Jeff at ingenio.com (Jeff Brown) Date: Mon, 19 Feb 2007 01:00:11 -0800 Subject: [IronPython] Feature request: Make assembly loading strategy configurable. Message-ID: Iron Python installs a rather dragonic AssemblyResolve hook. It uses Assembly.LoadFile to try to load an Assembly from the path when resolution fails. I would prefer if Assembly.LoadFrom were provided at least as an option, if not just made the standard behavior (once again). The problem in my case is that Iron Python is linking to an application that installs its own AssemblyResolve hook based on LoadFrom. Because LoadFrom and LoadFile Assemblies are tracked separately it happens that two copies of the same Assembly are loaded but they have incompatible types so the application blows up. What's more, there may actually be several identical copies of the same assembly floating around the search path. This is because the application consists of an assortment of plugin folders with locally copied (rather than shared) binaries. Here's my current workaround. Ugly huh? import System; System.AppDomain.CurrentDomain.remove_AssemblyResolve(System.Delegate.Cr eateDelegate(System.ResolveEventHandler, clr, "CurrentDomain_AssemblyResolve")) def AssemblyResolveWithLoadFrom(sender, e): try: return System.Reflection.Assembly.LoadFrom(e.Name + ".dll") except: return None System.AppDomain.CurrentDomain.add_AssemblyResolve(AssemblyResolveWithLo adFrom) Jeff. From miguel at novell.com Mon Feb 19 21:56:08 2007 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 19 Feb 2007 15:56:08 -0500 Subject: [IronPython] Any way to get IronPython on Mono to have a usable command line? In-Reply-To: <20070210083751.GB66450@uiuc.edu> References: <20070210083751.GB66450@uiuc.edu> Message-ID: <1171918568.4507.8.camel@erandi.dom> Hello, > Is there an alternate way I can run it so I can at least delete, and > preferably get history too? Try using one of the enhanced console options: mono ipy.exe -X:TabCompletion or: mono ipy.exe -X:ColorfulConsole Miguel From fuzzyman at voidspace.org.uk Mon Feb 19 22:51:44 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 19 Feb 2007 21:51:44 +0000 Subject: [IronPython] IronPython & Windows Forms Example: Tabbed Image Viewer Message-ID: <45DA1BF0.2060307@voidspace.org.uk> Hello all, Just a quick heads up. http://www.voidspace.org.uk/python/weblog/arch_d7_2007_02_17.shtml#e641 To support our talk on Developing with IronPython & Windows Forms, at PyCon, Andrzej and I (along with the help of our esteemed colleague Christian Muirhead) have created an example application. The result : * Tabbed Image Viewer: http://code.google.com/p/tabbedimages/ Visit my blog for some more details, or just download and have a play. Fuzzyman http://www.voidspace.org.uk/ironpython/index.shtml From dinov at exchange.microsoft.com Tue Feb 20 00:43:22 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 19 Feb 2007 15:43:22 -0800 Subject: [IronPython] popen should not open new windows. In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C222768A0133FA1@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks for the bug report! I've opened CodePlex bug #8361 to track & fix the issue (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8361). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Brown Sent: Sunday, February 18, 2007 11:45 PM To: users at lists.ironpython.com Subject: [IronPython] popen should not open new windows. When calling a process using nt.popen*, the ProcessInfo has the CreateNoWindow option set to false. This is fine ordinarily when working from the command prompt since it seems the current window will get recycled. However, when executing within the context of an NT Service or GUI process what happens is that a new window pops up whenever popen launches a process. This is very distracting. I ended up cooking up this workaround: # The built-in popen causes windows to pop up whenever a process # runs since it doesn't set the CreateNoWindow option of the ProcessInfo. *sigh* def QuietPOpen(executable, arguments): processStartInfo = ProcessStartInfo(executable, arguments) processStartInfo.UseShellExecute = False processStartInfo.CreateNoWindow = True processStartInfo.RedirectStandardOutput = True process = Process.Start(processStartInfo) return file(process.StandardOutput.BaseStream, "r") Jeff. _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Tue Feb 20 00:51:56 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 19 Feb 2007 15:51:56 -0800 Subject: [IronPython] Feature request: Make assembly loading strategy configurable. In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C222768A0133FAA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks for the suggestion. I've opened a bug to track this but I don't expect any immediate resolution here (the bug is http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8362). The problem here is that we're trying to get several different scenarios working correctly with our current assembly resolve logic: 1. Assemblies with references to other assemblies 2. Assemblies that exist outside of the AppDomain base path 3. Re-loading of non-strongly signed assemblies #1 requires either LoadFrom or LoadFile + Assembly Resolve Hooking so that we can get all the assemblies loaded #2 LoadFrom will work fine for the initial assembly but I believe it breaks on any dependencies #3 Requires LoadFile. We might be able to add a command line switch that causes the resolve event to be disabled for the process. The unfortunate effect of that is it's a big switch and might break code that expects to be able to load assemblies using our already established mechanism. If you own the process though and everything that gets loaded into it this might work. I realize you already have a workaround but would this one be better for you? Longer term we might be able to smarten this up (although it's really already too smart :) ) and provide a LoadFrom API that disables this (I'm thinking having a thread-static which our assembly resolve checks and skips providing resolution if you called our LoadFrom API). For the even longer term I believe we have told the CLR team about the issues we've encountered and we're hoping they deliver something that works better in the future :). That's really far off though... -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Brown Sent: Monday, February 19, 2007 1:00 AM To: users at lists.ironpython.com Subject: [IronPython] Feature request: Make assembly loading strategy configurable. Iron Python installs a rather dragonic AssemblyResolve hook. It uses Assembly.LoadFile to try to load an Assembly from the path when resolution fails. I would prefer if Assembly.LoadFrom were provided at least as an option, if not just made the standard behavior (once again). The problem in my case is that Iron Python is linking to an application that installs its own AssemblyResolve hook based on LoadFrom. Because LoadFrom and LoadFile Assemblies are tracked separately it happens that two copies of the same Assembly are loaded but they have incompatible types so the application blows up. What's more, there may actually be several identical copies of the same assembly floating around the search path. This is because the application consists of an assortment of plugin folders with locally copied (rather than shared) binaries. Here's my current workaround. Ugly huh? import System; System.AppDomain.CurrentDomain.remove_AssemblyResolve(System.Delegate.Cr eateDelegate(System.ResolveEventHandler, clr, "CurrentDomain_AssemblyResolve")) def AssemblyResolveWithLoadFrom(sender, e): try: return System.Reflection.Assembly.LoadFrom(e.Name + ".dll") except: return None System.AppDomain.CurrentDomain.add_AssemblyResolve(AssemblyResolveWithLo adFrom) Jeff. _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Tue Feb 20 04:45:18 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 19 Feb 2007 19:45:18 -0800 Subject: [IronPython] Using a Python-Module from other Languages over .NET? In-Reply-To: <45D85622.1080608@voidspace.org.uk> References: <45D85453.9020506@aaart.de> <45D85622.1080608@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222768A01340AA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> In addition to the memory efficiency we get correctness in supporting re-assignment to __class__. All of the types derived from one built-in type share the same in-memory layout. Therefore __class__ can be assigned arbitrarily between them changing the underlying dynamic type - just like CPython. The one other way to interop would be via interfaces. This has different pros and cons but is worth considering depending on what you're doing. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Sunday, February 18, 2007 5:36 AM To: Discussion of IronPython Subject: Re: [IronPython] Using a Python-Module from other Languages over .NET? kls wrote: > Hi, > > i have a litle question: Is it possibel to compile a Python-Module with > IronPython with all dependencies to a .Net-Module with can used from > other Languages like VB over .NET? > > Not directly I'm afraid. The .NET garbage collector doesn't collect classes, so for memory efficiency reasons (? - only ?) IronPython re-uses a single (?) class definition internally. That means that IronPython classes can't be consumed directly from other languages. You can create stub wrapper classes in C# / VB.NET which call into the engine and use your classes. This is quite simple and somewhere on this list someone posted an example. Using the System.Reflection API it should be possible to automate creating these stub classes. I haven't had time to explore this myself, but it would be very interesting. All the best, Michael Foord http://www.voidspace.org.uk/ironpython/ > Thx for the answers > _______________________________________________ > 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 sanxiyn at gmail.com Tue Feb 20 12:54:56 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 20 Feb 2007 20:54:56 +0900 Subject: [IronPython] CodePlex downloader Message-ID: <5b0248170702200354w6219f56bg2409a144b251a474@mail.gmail.com> I did a minimal fix to my CodePlex downloader, in order to cope with changed Source Code tab layout and new CodePlex URL scheme. https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/util/codeplex.py Usage: mkdir ProjectName # download the latest source code to the created directory (this is the first time only) python codeplex.py ProjectName The last line will scrap HTML and download new versions when available. This can be used to track the latest changes from Microsoft team, by those who don't have direct access to the source code repository. I have used this script since June 2006 to track IronPython and Phalanger. -- Seo Sanghyeon From sanxiyn at gmail.com Tue Feb 20 13:01:55 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 20 Feb 2007 21:01:55 +0900 Subject: [IronPython] Better source code access? In-Reply-To: References: <20070213084430.GA92208@uiuc.edu> Message-ID: <5b0248170702200401u79d8137dr138b1f19f363c53f@mail.gmail.com> 2007/2/14, Martin Maly : We did talk to the CodePlex team and it turns out that they consciously impose this limitation. Only the members of the Contributor/Developer group have access to the server via the Team Explorer. Since we talked to them last, we haven't heard any update on this so I presume this limitation has not gone away and probably won't in the foreseeable future. Is this really the case? Today I found this page: http://www.codeplex.com/IronPython/Project/ProjectRoles.aspx Is it not possible to modify this table? e.g. granting "Source Code/Access Source Control Server" permission to "Logged-In" role...? Or is this page just good-looking static table? -- Seo Sanghyeon From njriley at uiuc.edu Tue Feb 20 13:24:40 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Tue, 20 Feb 2007 06:24:40 -0600 Subject: [IronPython] CodePlex downloader In-Reply-To: <5b0248170702200354w6219f56bg2409a144b251a474@mail.gmail.com> References: <5b0248170702200354w6219f56bg2409a144b251a474@mail.gmail.com> Message-ID: <20070220122440.GA71376@uiuc.edu> On Tue, Feb 20, 2007 at 08:54:56PM +0900, Sanghyeon Seo wrote: > This can be used to track the latest changes from Microsoft team, by > those who don't have direct access to the source code repository. I > have used this script since June 2006 to track IronPython and > Phalanger. Aiee, I wish I had known about this before I wrote similar code last week. It's not particularly polished, but if it can help anyone else, here it is: commits.py parses revision info into a CSV file "commits.csv". On the first pass you will need to download all the HTML pages and supply them as arguments; on subsequent passes you can run it with no arguments and it'll grab the changes assuming they all fit on the first page of revisions. scrape.py downloads the revision zip files from the CSV file if they aren't already present. import.py imports the zip files and metadata into a Mercurial repository. If you just want to track IronPython it is probably easier just to use/clone my repository, which is (still) at: -- Nicholas Riley | From Martin.Maly at microsoft.com Tue Feb 20 18:23:28 2007 From: Martin.Maly at microsoft.com (Martin Maly) Date: Tue, 20 Feb 2007 09:23:28 -0800 Subject: [IronPython] Better source code access? In-Reply-To: <5b0248170702200401u79d8137dr138b1f19f363c53f@mail.gmail.com> References: <20070213084430.GA92208@uiuc.edu> <5b0248170702200401u79d8137dr138b1f19f363c53f@mail.gmail.com> Message-ID: Unfortunately, the table _is_ static :( M. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Tuesday, February 20, 2007 4:02 AM To: Discussion of IronPython Subject: Re: [IronPython] Better source code access? 2007/2/14, Martin Maly : We did talk to the CodePlex team and it turns out that they consciously impose this limitation. Only the members of the Contributor/Developer group have access to the server via the Team Explorer. Since we talked to them last, we haven't heard any update on this so I presume this limitation has not gone away and probably won't in the foreseeable future. Is this really the case? Today I found this page: http://www.codeplex.com/IronPython/Project/ProjectRoles.aspx Is it not possible to modify this table? e.g. granting "Source Code/Access Source Control Server" permission to "Logged-In" role...? Or is this page just good-looking static table? -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From konstl at aaart.de Tue Feb 20 20:20:39 2007 From: konstl at aaart.de (kls) Date: Tue, 20 Feb 2007 20:20:39 +0100 Subject: [IronPython] Using a Python-Module from other Languages over .NET? In-Reply-To: <7AD436E4270DD54A94238001769C222768A01340AA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <45D85453.9020506@aaart.de> <45D85622.1080608@voidspace.org.uk> <7AD436E4270DD54A94238001769C222768A01340AA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <45DB4A07.6030004@aaart.de> Thanks for the answers, but the solving writing interface classes in c# vb.net and so on, is to much complex for me at the moment because i can only python. Maybe when my module is complete finished and some .net-coders would like to use it, i will try that. > In addition to the memory efficiency we get correctness in supporting re-assignment to __class__. All of the types derived from one built-in type share the same in-memory layout. Therefore __class__ can be assigned arbitrarily between them changing the underlying dynamic type - just like CPython. > > The one other way to interop would be via interfaces. This has different pros and cons but is worth considering depending on what you're doing. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Sunday, February 18, 2007 5:36 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Using a Python-Module from other Languages over .NET? > > kls wrote: > >> Hi, >> >> i have a litle question: Is it possibel to compile a Python-Module with >> IronPython with all dependencies to a .Net-Module with can used from >> other Languages like VB over .NET? >> >> >> > Not directly I'm afraid. > > The .NET garbage collector doesn't collect classes, so for memory > efficiency reasons (? - only ?) IronPython re-uses a single (?) class > definition internally. > > That means that IronPython classes can't be consumed directly from other > languages. > > You can create stub wrapper classes in C# / VB.NET which call into the > engine and use your classes. This is quite simple and somewhere on this > list someone posted an example. > > Using the System.Reflection API it should be possible to automate > creating these stub classes. I haven't had time to explore this myself, > but it would be very interesting. > > All the best, > > Michael Foord > http://www.voidspace.org.uk/ironpython/ > > > > >> Thx for the answers >> _______________________________________________ >> 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 Jeff at ingenio.com Tue Feb 20 22:03:47 2007 From: Jeff at ingenio.com (Jeff Brown) Date: Tue, 20 Feb 2007 13:03:47 -0800 Subject: [IronPython] popen should not open new windows. Message-ID: Excellent, thank you. =) Jeff. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, February 19, 2007 3:43 PM To: Discussion of IronPython Subject: Re: [IronPython] popen should not open new windows. Thanks for the bug report! I've opened CodePlex bug #8361 to track & fix the issue (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8361). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Brown Sent: Sunday, February 18, 2007 11:45 PM To: users at lists.ironpython.com Subject: [IronPython] popen should not open new windows. When calling a process using nt.popen*, the ProcessInfo has the CreateNoWindow option set to false. This is fine ordinarily when working from the command prompt since it seems the current window will get recycled. However, when executing within the context of an NT Service or GUI process what happens is that a new window pops up whenever popen launches a process. This is very distracting. I ended up cooking up this workaround: # The built-in popen causes windows to pop up whenever a process # runs since it doesn't set the CreateNoWindow option of the ProcessInfo. *sigh* def QuietPOpen(executable, arguments): processStartInfo = ProcessStartInfo(executable, arguments) processStartInfo.UseShellExecute = False processStartInfo.CreateNoWindow = True processStartInfo.RedirectStandardOutput = True process = Process.Start(processStartInfo) return file(process.StandardOutput.BaseStream, "r") Jeff. _______________________________________________ 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 Jeff at ingenio.com Tue Feb 20 22:03:35 2007 From: Jeff at ingenio.com (Jeff Brown) Date: Tue, 20 Feb 2007 13:03:35 -0800 Subject: [IronPython] Feature request: Make assembly loadingstrategy configurable. Message-ID: Yes, it would be much better if I could disable the built-in AssemblyResolve hook. From my perspective it would be better if the script could do it dynamically at runtime. Say, clr.EnableAssemblyResolveHook = False or clr.AssemblyResolveMode = AssemblyResolveMode.LoadFromPath / Custom / etc... if there were several It's unfortunate that the CLR assembly loading model doesn't allow extending the assembly resolution path beyond the app-base folder. Oh well. I won't hold my breath. So it's clear that Iron Python requires an AssemblyResolve hook to present the illusion of a coherent sys.path. But LoadFile is bad news. It breaks compositionality of Iron Python with respect to assembly resolution. OTOH, LoadFrom with an Assembly Resolve hook will satisfy case #1 and #2 below. I'm just not convinced of the merit of case #3. With case #3 there are a couple of problems. The issue of reloading assemblies is very challenging given that assemblies cannot truly be unloaded. The issue of loading an assembly and its dependencies from a _specific_ non-standard location is also difficult and should really be dealt with directly by adding references to specific files rather than by means of Assembly Resolve (because we might load those dependencies from the wrong places if we're given a choice on the path). Most of the time LoadFile just creates problems because the user isn't interested in loading the Assembly from that _specific_ location but rather just happens to know that a satisfactory copy exists there. I believe the cases where LoadFile must be used are quite limited. They require careful attention to details when loading dependencies and when resolving names. The average user is just not likely to encounter this situation. Indeed many programs make assumptions about the uniqueness of type names that would fail otherwise. So I argue that the AssemblyResolve hook be changed to use LoadFrom but that the AddReferenceToFile and AddReferenceToFileAndPath methods remain as they are with LoadFile. The latter should be considered advanced usage. The preferred option would be for the user to extend sys.path and then use AddReference. We could draw attention to this process by introducing an AddReferencePath method that internally would just extend sys.path (or perhaps some private assembly reference path *shrug*). Alternately, the AddReference* methods could be changed to accept an optional "pathHint" argument to be included in the sys.path. (yuck) As for legitimate Assembly re-loading cases, perhaps there some other API support that could help. I don't know. Thanks for your consideration, Jeff. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, February 19, 2007 3:52 PM To: Discussion of IronPython Subject: Re: [IronPython] Feature request: Make assembly loadingstrategy configurable. Thanks for the suggestion. I've opened a bug to track this but I don't expect any immediate resolution here (the bug is http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8362). The problem here is that we're trying to get several different scenarios working correctly with our current assembly resolve logic: 1. Assemblies with references to other assemblies 2. Assemblies that exist outside of the AppDomain base path 3. Re-loading of non-strongly signed assemblies #1 requires either LoadFrom or LoadFile + Assembly Resolve Hooking so that we can get all the assemblies loaded #2 LoadFrom will work fine for the initial assembly but I believe it breaks on any dependencies #3 Requires LoadFile. We might be able to add a command line switch that causes the resolve event to be disabled for the process. The unfortunate effect of that is it's a big switch and might break code that expects to be able to load assemblies using our already established mechanism. If you own the process though and everything that gets loaded into it this might work. I realize you already have a workaround but would this one be better for you? Longer term we might be able to smarten this up (although it's really already too smart :) ) and provide a LoadFrom API that disables this (I'm thinking having a thread-static which our assembly resolve checks and skips providing resolution if you called our LoadFrom API). For the even longer term I believe we have told the CLR team about the issues we've encountered and we're hoping they deliver something that works better in the future :). That's really far off though... -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Brown Sent: Monday, February 19, 2007 1:00 AM To: users at lists.ironpython.com Subject: [IronPython] Feature request: Make assembly loading strategy configurable. Iron Python installs a rather dragonic AssemblyResolve hook. It uses Assembly.LoadFile to try to load an Assembly from the path when resolution fails. I would prefer if Assembly.LoadFrom were provided at least as an option, if not just made the standard behavior (once again). The problem in my case is that Iron Python is linking to an application that installs its own AssemblyResolve hook based on LoadFrom. Because LoadFrom and LoadFile Assemblies are tracked separately it happens that two copies of the same Assembly are loaded but they have incompatible types so the application blows up. What's more, there may actually be several identical copies of the same assembly floating around the search path. This is because the application consists of an assortment of plugin folders with locally copied (rather than shared) binaries. Here's my current workaround. Ugly huh? import System; System.AppDomain.CurrentDomain.remove_AssemblyResolve(System.Delegate.Cr eateDelegate(System.ResolveEventHandler, clr, "CurrentDomain_AssemblyResolve")) def AssemblyResolveWithLoadFrom(sender, e): try: return System.Reflection.Assembly.LoadFrom(e.Name + ".dll") except: return None System.AppDomain.CurrentDomain.add_AssemblyResolve(AssemblyResolveWithLo adFrom) Jeff. _______________________________________________ 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 erzengel-von-licht at cox.net Wed Feb 21 01:56:49 2007 From: erzengel-von-licht at cox.net (Erzengel des Lichtes) Date: Tue, 20 Feb 2007 16:56:49 -0800 Subject: [IronPython] Method invocation when assigned to instancediffers from default assignment? In-Reply-To: <45D87DD6.8010502@astro.pas.rochester.edu> References: <000901c7527a$fcfe23f0$6601a8c0@cxm> <20070217103844.GA45855@uiuc.edu><001101c752cc$f114b2a0$6601a8c0@cxm> <45D76E73.2070802@astro.pas.rochester.edu><002101c75341$1f2fe280$6601a8c0@cxm> <45D87DD6.8010502@astro.pas.rochester.edu> Message-ID: <001f01c75553$2b7da6d0$6601a8c0@cxm> -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of drew moore Sent: Sunday, February 18, 2007 8:25 AM To: Discussion of IronPython Subject: Re: [IronPython] Method invocation when assigned to instancediffers from default assignment? Wow! you're not the typical Python newbie! --Reply-- Indeed. The entire team is relatively new to Python, or any high level scripting language for that matter. All the programmers, like me, are more used to the complex languages like C/C++, C#, and Java. We reviewed several scripting languages we could embed, and decided to use Python. Now I need to catch up on Python as I modify the interpriter. -----Original Message----- I don't know much about Fibers and Interruptible IronPython, but it sounds very interesting. --Reply-- It's not surprising you don't know about "Interruptible IronPython" (working name), as it is propriatary at the moment (It's also nowhere near finished). I mentioned it tangentially when I started working on it, in the e-mail "Suspending, saving script execution?". Basically Interruptible replaces MSIL with an interpriter that allows the application to suspend a script wherever it wants (after so many commands, so many milliseconds, and/or manually) so that the thread can continue its execution. It is also serializable, so the data and instruction pointer can be saved and reloaded exactly where it was. IronPython /w Fibers is the method we used in our prototype. IronPython was left entirely unmodified. The only difference from what one usually does is that the hosting application puts each script into its own fiber (http://msdn2.microsoft.com/en-us/library/aa450744.aspx), which is basically a manual thread. The application then pauses the fiber whenever a function takes time (multiple frames) to finish. I knew this was a poor solution when I chose it (no saving/loading, a hard limit to the number of scripts that can be run at a time, malformed scripts can block execution, etc), but we needed to get a prototype done and the limitations were acceptable within the prototype. But that's why I, a Python 'n00b' am modifying IronPython. -----Original Message----- Here's a simple scenario I can think of where instances might have callable attributes that don't need (or want) self automatically put in as the first argument: --Reply-- But see, wouldn't it be nice, in your example, to do this: import sys class Logger(object) : writer = sys.stdout.write def __init__(self, writer=None) : if writer is not None : self.writer = writer def Log(self, message) : self.writer(message) Temp = Logger() OtherTemp = Logger() ErrorLog = Logger(sys.stderr.write) #At a later point in time... messageCount = 0 def myLogger(message): global messageCount messageCount += 1 sys.stdout.write("<" + str(messageCount) + ">" + message) Logger.writer = myLogger Temp.Log("SomeMessage") OtherTemp.Log("SomeMessage") ErrorLog.Log("SomeError") As neither Temp nor TempOther have their own instanced function, Log would have to fallback on the class function, which is now different, just like any other class variable. But we can't do that as a function attached to a class is considered an unbound method. This inconsistency is what has me confused about the utility of this ability. From xmlhacker at gmail.com Wed Feb 21 02:11:40 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Tue, 20 Feb 2007 18:11:40 -0700 Subject: [IronPython] Ruby, RoR, IronPython, Dynamic, Static, and the Power of Two Too Message-ID: For those with interest, I've referenced IronPython fairly extensively in a recent post to my blog @ http://dev.aol.com/ which attempts to make sense of the difference between static and dynamic languages, the importance of both, and why embracing sometimes first requires one to let go, http://dev.aol.com/blog/mdavidpeterson/2007/02/20/ror-and-the-dotnet-platform_let-go-to-embrace -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.dahlbacka at gmail.com Wed Feb 21 08:16:44 2007 From: simon.dahlbacka at gmail.com (Simon Dahlbacka) Date: Wed, 21 Feb 2007 09:16:44 +0200 Subject: [IronPython] Method invocation when assigned to instancediffers from default assignment? In-Reply-To: <001f01c75553$2b7da6d0$6601a8c0@cxm> References: <000901c7527a$fcfe23f0$6601a8c0@cxm> <20070217103844.GA45855@uiuc.edu> <001101c752cc$f114b2a0$6601a8c0@cxm> <45D76E73.2070802@astro.pas.rochester.edu> <002101c75341$1f2fe280$6601a8c0@cxm> <45D87DD6.8010502@astro.pas.rochester.edu> <001f01c75553$2b7da6d0$6601a8c0@cxm> Message-ID: <57124720702202316j75c400e2hf03e177393f4aa7a@mail.gmail.com> > > -----Original Message----- > Here's a simple scenario I can think of where instances might have > callable > attributes that don't need (or want) self automatically put in as the > first > argument: > --Reply-- > But see, wouldn't it be nice, in your example, to do this: > > import sys > class Logger(object) : > writer = sys.stdout.write > def __init__(self, writer=None) : > if writer is not None : > self.writer = writer > def Log(self, message) : > self.writer(message) > > Temp = Logger() > OtherTemp = Logger() > ErrorLog = Logger(sys.stderr.write) > #At a later point in time... > messageCount = 0 > def myLogger(message): > global messageCount > messageCount += 1 > sys.stdout.write("<" + str(messageCount) + ">" + message) > Logger.writer = myLogger > Temp.Log("SomeMessage") > OtherTemp.Log("SomeMessage") > ErrorLog.Log("SomeError") > > As neither Temp nor TempOther have their own instanced function, Log would > have to fallback on the class function, which is now different, just like > any other class variable. But we can't do that as a function attached to a > class is considered an unbound method. > This inconsistency is what has me confused about the utility of this > ability. FWIW, if you want to add a new instance method to an already instantiated class, in python you can do import new Temp.writer = new.instancemethod(myLogger, Temp, Logger) (Haven't tried it IronPython though..) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Wed Feb 21 23:45:14 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 21 Feb 2007 14:45:14 -0800 Subject: [IronPython] IronPython 1.1 Beta 1 Released Message-ID: <7AD436E4270DD54A94238001769C222768A0134780@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Hello IronPython Community, We have just released IronPython 1.1 Beta 1. This release primarily focuses on adding the remaining new functionality for the 1.1 release (array module, importing pre-compiled modules) along with many new bug fixes. Also included but previously available with 1.1 Alpha 1 are the new XML Doc comment integration with the help system, the SHA, MD5, and select modules. The remaining of the 1.1 cycle will focus on bug fixes. You can download the release from: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=1944 We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: J. Merrill, Coleyc, JoeSox, Michael Foord, Seo Sanghyeon, and Sylvain Hellegouarch. More complete list of changes and bug fixes: ============================================ Support importing pre-compiled modules produced when running in -X:SaveAssemblies mode Enable inheritance of static op_Implicit implicit conversion operators on .NET types Fixed tracebacks when catching exceptions in the method that threw them and a few other fixes here Bugfix: 4859 datetime.date.__str__ broken Bugfix: 4870 datetime.datetime.isoformat does not report microseconds Bugfix: 5148 datetime.time(..., None).tzname() returns '' instead of None Bugfix: Bugfix: 5146 datetime.time(...).isoformat() does not work Bugfix: 4860 datetime.datetime.* only accurate to 1000 microseconds Bugfix: 3850 datetime.datetime(...) allows negative microsecond parameter Bugfix: 5147 datetime.time(..., None).utcoffset() returns 0 instead of None Bugfix: 5145 datetime.time.resolution is the wrong type Bugfix: 5143 datetime.time(...) allows parameters < time.min and > time.max Bugfix: 5139 datetime.timedelta and datetime.time objects should work correctly in boolean contexts Bugfix: 5133 datetime.timedelta.* does not normalize negative parameters and return values Bugfix: 5132 datetime.timedelta(...) constructor does not round off floating point parameters correctly Bugfix: 4871 datetime.timedelta.__init__ does not accept the 4 optional keyword parameters Bugfix: 4868 datetime.datetime.timetuple returns an incorrect value Bugfix: 4867 datetime.datetime.tzname returns incorrect value if tzinfo member is None Bugfix: 4866 datetime.datetime.resolution is of the wrong type Bugfix: 4865 datetime.datetime.__cmp__ broken for datetime.datetime.max Bugfix: 4864 datetime.datetime.max has the wrong value for the microsecond member Bugfix: 4863 datetime.datetime.__init__(...) defaults the hour keyword param to 1 (should be 0) Bugfix: 4861 datetime.timedelta + datetime.datetime throws a TypeError Bugfix: 3990 datetime.timedelta member attributes out of range Bugfix: 5149 datetime.timdelta(...) does not add fractional microseconds correctly Bugfix: 5136 datetime.timedelta.min(imum), datetime.timedelta.max(imum), and datetime.timedelta.resolution all have incorrect values Bugfix: 5135 datetime.timedelta.min and datetime.timedelta.max are missing Bugfix: 4858 datetime.date.__reduce__ broken Bugfix 7426: in operator doesn't check for overloaded __contains__ on dictionary Implemented array module From fuzzyman at voidspace.org.uk Thu Feb 22 01:55:43 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 22 Feb 2007 00:55:43 +0000 Subject: [IronPython] IronPython 1.1 Beta 1 Released In-Reply-To: <7AD436E4270DD54A94238001769C222768A0134780@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222768A0134780@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <45DCEA0F.1050208@voidspace.org.uk> Dino Viehland wrote:. Great - well done and thank you. Michael Foord > We have just released IronPython 1.1 Beta 1. This release primarily focuses on adding the remaining new functionality for the 1.1 release (array module, importing pre-compiled modules) along with many new bug fixes. Also included but previously available with 1.1 Alpha 1 are the new XML Doc comment integration with the help system, the SHA, MD5, and select modules. The remaining of the 1.1 cycle will focus on bug fixes. > You can download the release from: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=1944 > > We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: J. Merrill, Coleyc, JoeSox, Michael Foord, Seo Sanghyeon, and Sylvain Hellegouarch. > > More complete list of changes and bug fixes: > ============================================ > Support importing pre-compiled modules produced when running in -X:SaveAssemblies mode > Enable inheritance of static op_Implicit implicit conversion operators on .NET types > Fixed tracebacks when catching exceptions in the method that threw them and a few other fixes here > Bugfix: 4859 datetime.date.__str__ broken > Bugfix: 4870 datetime.datetime.isoformat does not report microseconds > Bugfix: 5148 datetime.time(..., None).tzname() returns '' instead of None > Bugfix: Bugfix: 5146 datetime.time(...).isoformat() does not work > Bugfix: 4860 datetime.datetime.* only accurate to 1000 microseconds > Bugfix: 3850 datetime.datetime(...) allows negative microsecond parameter > Bugfix: 5147 datetime.time(..., None).utcoffset() returns 0 instead of None > Bugfix: 5145 datetime.time.resolution is the wrong type > Bugfix: 5143 datetime.time(...) allows parameters < time.min and > time.max > Bugfix: 5139 datetime.timedelta and datetime.time objects should work correctly in boolean contexts > Bugfix: 5133 datetime.timedelta.* does not normalize negative parameters and return values > Bugfix: 5132 datetime.timedelta(...) constructor does not round off floating point parameters correctly > Bugfix: 4871 datetime.timedelta.__init__ does not accept the 4 optional keyword parameters > Bugfix: 4868 datetime.datetime.timetuple returns an incorrect value > Bugfix: 4867 datetime.datetime.tzname returns incorrect value if tzinfo member is None > Bugfix: 4866 datetime.datetime.resolution is of the wrong type > Bugfix: 4865 datetime.datetime.__cmp__ broken for datetime.datetime.max > Bugfix: 4864 datetime.datetime.max has the wrong value for the microsecond member > Bugfix: 4863 datetime.datetime.__init__(...) defaults the hour keyword param to 1 (should be 0) > Bugfix: 4861 datetime.timedelta + datetime.datetime throws a TypeError > Bugfix: 3990 datetime.timedelta member attributes out of range > Bugfix: 5149 datetime.timdelta(...) does not add fractional microseconds correctly > Bugfix: 5136 datetime.timedelta.min(imum), datetime.timedelta.max(imum), and datetime.timedelta.resolution all have incorrect values > Bugfix: 5135 datetime.timedelta.min and datetime.timedelta.max are missing > Bugfix: 4858 datetime.date.__reduce__ broken > Bugfix 7426: in operator doesn't check for overloaded __contains__ on dictionary > Implemented array module > > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From joesox at gmail.com Thu Feb 22 07:15:24 2007 From: joesox at gmail.com (JoeSox) Date: Wed, 21 Feb 2007 22:15:24 -0800 Subject: [IronPython] array.fromfile Message-ID: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> IronPython Team, Thanks for the thanks. The array.cs is a great addition to IronPython. I just completed some testing with my ConceptNet C# library, which was using its own array.py to get things done. Testing with the IP array, I am getting an exception thrown ("file not large enough") performing a .fromfile on a unicode file (I think it is a unicode. It is a .mdf file from MIT's montylingua). I am guessing this is the problem since it is not a str file. Does this sound correct? The fileptr and length are the same values being passed (stepping thru a Python run and an IronPython run) array_ptr = array('L') array_ptr.fromfile(file_ptr,length) file_ptr {} object {IronPython.Runtime.PythonFile} length 260759 object {int} Thanks again, Joe On 2/21/07, Dino Viehland wrote: > Hello IronPython Community, > > We have just released IronPython 1.1 Beta 1. This release primarily focuses on adding the remaining new functionality for the 1.1 release (array module, importing pre-compiled modules) along with many new bug fixes. Also included but previously available with 1.1 Alpha 1 are the new XML Doc comment integration with the help system, the SHA, MD5, and select modules. The remaining of the 1.1 cycle will focus on bug fixes. > You can download the release from: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=1944 > > We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: J. Merrill, Coleyc, JoeSox, Michael Foord, Seo Sanghyeon, and Sylvain Hellegouarch. > > More complete list of changes and bug fixes: > ============================================ ... > Implemented array module From jvm_cop at spamcop.net Thu Feb 22 17:19:12 2007 From: jvm_cop at spamcop.net (J. Merrill) Date: Thu, 22 Feb 2007 11:19:12 -0500 Subject: [IronPython] array.fromfile In-Reply-To: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.co m> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> Message-ID: <7.0.1.0.2.20070222111009.05bca6a8@wheresmymailserver.com> Where did you get the value for the variable? How large is the file (in bytes)? What is the encoding of the file? You might need to read the file into a unicode string (assuming that you need some unicode characters) in order to deal with the file's encoding. I assume that fromfile's parameter is supposed to be the number of (logical) characters in the file (that is, the number of items to end up in the array). If the file is encoded with UTF-8, it likely is quite a bit smaller than 2-bytes-per-character; if the program is expecting a two-bytes-per-character file, it would whine unless the file is [at least] 2*length bytes.) At 01:15 AM 2/22/2007, JoeSox wrote >IronPython Team, > >Thanks for the thanks. The array.cs is a great addition to IronPython. >I just completed some testing with my ConceptNet C# library, which was >using its own array.py to get things done. > >Testing with the IP array, I am getting an exception thrown ("file not >large enough") performing a .fromfile on a unicode file (I think it is >a unicode. It is a .mdf file from MIT's montylingua). > >I am guessing this is the problem since it is not a str file. Does >this sound correct? > >The fileptr and length are the same values being passed (stepping thru >a Python run and an IronPython run) > >array_ptr = array('L') >array_ptr.fromfile(file_ptr,length) > >file_ptr {Documents\Python >Projects\conceptnet2.1\montylingua\FASTLEXICON_3.MDF', mode 'rb' at >0x0337843A>} object {IronPython.Runtime.PythonFile} > >length 260759 object {int} > >Thanks again, >Joe >[snip] J. Merrill / Analytical Software Corp From dinov at exchange.microsoft.com Thu Feb 22 17:59:06 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 22 Feb 2007 08:59:06 -0800 Subject: [IronPython] array.fromfile In-Reply-To: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Depending on how similar your array.py was to CPython's built-in array the problem here may be that our long data type is 8 bytes instead of 4 like on CPython. The documentation defines the "minimum" size and we use the native sizes for the similar .NET types. Try switching to using 'I' for the type instead. You could also check the itemsize on array.py's array and see if that's the case or not. ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of JoeSox [joesox at gmail.com] Sent: Wednesday, February 21, 2007 10:15 PM To: Discussion of IronPython Subject: [IronPython] array.fromfile IronPython Team, Thanks for the thanks. The array.cs is a great addition to IronPython. I just completed some testing with my ConceptNet C# library, which was using its own array.py to get things done. Testing with the IP array, I am getting an exception thrown ("file not large enough") performing a .fromfile on a unicode file (I think it is a unicode. It is a .mdf file from MIT's montylingua). I am guessing this is the problem since it is not a str file. Does this sound correct? The fileptr and length are the same values being passed (stepping thru a Python run and an IronPython run) array_ptr = array('L') array_ptr.fromfile(file_ptr,length) file_ptr {} object {IronPython.Runtime.PythonFile} length 260759 object {int} Thanks again, Joe On 2/21/07, Dino Viehland wrote: > Hello IronPython Community, > > We have just released IronPython 1.1 Beta 1. This release primarily focuses on adding the remaining new functionality for the 1.1 release (array module, importing pre-compiled modules) along with many new bug fixes. Also included but previously available with 1.1 Alpha 1 are the new XML Doc comment integration with the help system, the SHA, MD5, and select modules. The remaining of the 1.1 cycle will focus on bug fixes. > You can download the release from: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=1944 > > We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: J. Merrill, Coleyc, JoeSox, Michael Foord, Seo Sanghyeon, and Sylvain Hellegouarch. > > More complete list of changes and bug fixes: > ============================================ ... > Implemented array module _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From joesox at gmail.com Fri Feb 23 02:25:19 2007 From: joesox at gmail.com (JoeSox) Date: Thu, 22 Feb 2007 17:25:19 -0800 Subject: [IronPython] array.fromfile In-Reply-To: <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <785694cd0702221725w2069366dmc2b5fe3d2a208bf8@mail.gmail.com> Ok, I found out that the length value of 260759 appears to be pulled from a file that holds that value. So it is the same nomatter what the environment is. Now, here is the logic that my array.py file was using: self.itemsize = self._descriptor[1] """I think _descriptor[1] = typecode L, which in this case would be 4 bytes def fromfile(self, f, n): """Read n objects from the file object f and append them to the end of the array. Also called as read.""" if not isinstance(f, file): raise TypeError("arg1 must be open file") for i in range(n): item = f.read(self.itemsize) if len(item) < self.itemsize: raise EOFError("not enough items in file") self.fromstring(item) The full array.py may be found at http://codespeak.net/svn/pypy/dist/pypy/module/array/app_array.py -------------------------------- IronPython's: [PythonName("fromfile")] public void FromFile(PythonFile f, int n) { int bytesNeeded = n * ItemSize; string bytes = f.Read(bytesNeeded); if (bytes.Length < bytesNeeded) throw Ops.EofError("file not large enough"); FromString(bytes); } ---- I maybe incorrect but it seems that the 4 vs 8 bytes is an issue for me. Using 1.1B, I can not use my array.py because it uses IP's first when 'import array' is called. Sorry, I can't think of a suggested fix right now as I have ran out of time to look at this more today. I am sort of confused why IP uses n * ItemSize. Thanks, Joe On 2/22/07, Dino Viehland wrote: > Depending on how similar your array.py was to CPython's built-in array the problem here may be that our long data type is 8 bytes instead of 4 like on CPython. The documentation defines the "minimum" size and we use the native sizes for the similar .NET types. > > Try switching to using 'I' for the type instead. You could also check the itemsize on array.py's array and see if that's the case or not. > From davidf at sjsoft.com Fri Feb 23 09:12:34 2007 From: davidf at sjsoft.com (David Fraser) Date: Fri, 23 Feb 2007 10:12:34 +0200 Subject: [IronPython] Better source code access? In-Reply-To: <20070214043632.GA1974@uiuc.edu> References: <20070213084430.GA92208@uiuc.edu> <20070214043632.GA1974@uiuc.edu> Message-ID: <45DEA1F2.4070403@sjsoft.com> Nicholas Riley wrote: > On Tue, Feb 13, 2007 at 08:45:10AM -0800, Martin Maly wrote: > >> We did talk to the CodePlex team and it turns out that they >> consciously impose this limitation. Only the members of the >> Contributor/Developer group have access to the server via the Team >> Explorer. Since we talked to them last, we haven't heard any update >> on this so I presume this limitation has not gone away and probably >> won't in the foreseeable future. >> > > Thanks for checking. > > >> If there's no other choice I could download the zip files for each >> revision, check them in somewhere else and make the repository >> available for public browsing. >> > > I imported the data into Mercurial. > > > > Note that I didn't account for the branching in the repo that happened > at some point, but this still should be a lot more useful than the > browser on the CodePlex site. This is great - I tried but failed to extract the repository a while ago - did you reconstruct this from the zip files or how did you do it? Do you have a means of automating this so that it keeps up to date, or is that done already? :-) Cheers David From dinov at exchange.microsoft.com Fri Feb 23 18:58:32 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 23 Feb 2007 09:58:32 -0800 Subject: [IronPython] array.fromfile In-Reply-To: <785694cd0702221725w2069366dmc2b5fe3d2a208bf8@mail.gmail.com> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <785694cd0702221725w2069366dmc2b5fe3d2a208bf8@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C22276A3AC4E223@DF-GRTDANE-MSG.exchange.corp.microsoft.com> We're basically doing the same thing that the array.py is doing - the difference truly is just the item size. Python is implicitly doing the check by calling range(n) and doing the size check on each read. We're reading everything in at once and doing the same basic size check just doing it before intsead of at each read. They should both be equivalent though. Is there an issue w/ switching to using the I type for the array instead of the L type? If that seems too cumbersome we could consider changing the default size of L to match CPython (I suspect this means 4 bytes on a 32-bit platform and 8 bytes on 64-bit but I don't have a 64-bit install of CPython). ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of JoeSox [joesox at gmail.com] Sent: Thursday, February 22, 2007 5:25 PM To: Discussion of IronPython Subject: Re: [IronPython] array.fromfile Ok, I found out that the length value of 260759 appears to be pulled from a file that holds that value. So it is the same nomatter what the environment is. Now, here is the logic that my array.py file was using: self.itemsize = self._descriptor[1] """I think _descriptor[1] = typecode L, which in this case would be 4 bytes def fromfile(self, f, n): """Read n objects from the file object f and append them to the end of the array. Also called as read.""" if not isinstance(f, file): raise TypeError("arg1 must be open file") for i in range(n): item = f.read(self.itemsize) if len(item) < self.itemsize: raise EOFError("not enough items in file") self.fromstring(item) The full array.py may be found at http://codespeak.net/svn/pypy/dist/pypy/module/array/app_array.py -------------------------------- IronPython's: [PythonName("fromfile")] public void FromFile(PythonFile f, int n) { int bytesNeeded = n * ItemSize; string bytes = f.Read(bytesNeeded); if (bytes.Length < bytesNeeded) throw Ops.EofError("file not large enough"); FromString(bytes); } ---- I maybe incorrect but it seems that the 4 vs 8 bytes is an issue for me. Using 1.1B, I can not use my array.py because it uses IP's first when 'import array' is called. Sorry, I can't think of a suggested fix right now as I have ran out of time to look at this more today. I am sort of confused why IP uses n * ItemSize. Thanks, Joe On 2/22/07, Dino Viehland wrote: > Depending on how similar your array.py was to CPython's built-in array the problem here may be that our long data type is 8 bytes instead of 4 like on CPython. The documentation defines the "minimum" size and we use the native sizes for the similar .NET types. > > Try switching to using 'I' for the type instead. You could also check the itemsize on array.py's array and see if that's the case or not. > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sh at defuze.org Fri Feb 23 19:42:00 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Fri, 23 Feb 2007 18:42:00 +0000 Subject: [IronPython] Atom Publishing Protocol via IronPython Message-ID: <45DF3578.1030407@defuze.org> Hi folks, I have just started an article on how to use amplee [1] as a Python implementation of the Atom Publishing Protocol via IronPython. http://trac.defuze.org/wiki/AmpleeIronPython The article only provides an example via Mono for now but will soon be extended to explain how to deploy on Windows via IIS. If you fancy trying but find some issues please do let me know. - Sylvain [1] http://trac.defuze.org/wiki/amplee From joesox at gmail.com Fri Feb 23 22:14:29 2007 From: joesox at gmail.com (JoeSox) Date: Fri, 23 Feb 2007 13:14:29 -0800 Subject: [IronPython] array.fromfile In-Reply-To: <7AD436E4270DD54A94238001769C22276A3AC4E223@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702221725w2069366dmc2b5fe3d2a208bf8@mail.gmail.com> <7AD436E4270DD54A94238001769C22276A3AC4E223@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <785694cd0702231314p70a0c5a8jd6bca8d857018073@mail.gmail.com> On 2/23/07, Dino Viehland wrote: > We're basically doing the same thing that the array.py is doing - the difference truly is just the item size. Python is implicitly doing the check by calling range(n) and doing the size check on each read. We're reading everything in at once and doing the same basic size check just doing it before intsead of at each read. They should both be equivalent though. > > Is there an issue w/ switching to using the I type for the array instead of the L type? I tried this but was unsuccessful. It still results in the same exception being thrown. If I am understanding everything, the only typecode that uses 8 bytes is floating point 'd'. > If that seems too cumbersome we could consider changing the default size of L to match CPython (I suspect this means 4 bytes on a 32-bit platform and 8 bytes on 64-bit but I don't have a 64-bit install of CPython). > This is an interesting solution and I wish others onlist that use array could test also to provide additional feedback. If I had more time I could try to test with a rebuild of 1.1B and get back to you. I am not sure if I would be modifying correctly though, at this point I just quickly glanced at how you guys constructed the typecodes. I wouldn't think that modeling CPython's 4 bytes would be a bad thing, if an IP goal is to enable user modules to work both in IP and CPython. I think this is why many of us like IP because you can have something in CPython and easily use it in a .NET platform, or IP to CPython. I true cross-platform module would be my goal. Thanks, Joe From textdirected at gmail.com Sat Feb 24 01:49:06 2007 From: textdirected at gmail.com (HEMMI, Shigeru) Date: Sat, 24 Feb 2007 09:49:06 +0900 Subject: [IronPython] BUG? IOError: Could not find file In-Reply-To: References: Message-ID: Dear IronPython team, Such a coding pattern which inherits from 'file' class is my personal favourite. I believe this bug is a bug even in Windows within .NET. I hope IPy team to fix this bug in near future. Thanks in advance. 2007/2/3, HEMMI, Shigeru : > Hello, IronPython Team, > > On my MAC OS X (Panther) + mono + IronPython, I encounterd a bug for > the program. > > class TESTINGwrite(file): > def __init__(self, fname): > file.__init__(self,fname,"w",1) > def writesomething(self): > self.write("Hi there\n") > > if __name__=='__main__': > x = TESTINGwrite("testing_TMP.txt") > x.writesomething() > x.close() > > In IronPython, this code generats errer(see below), while CPython runs properly. > I am guessing this is a bug. > > $ ipy IOErrorCouldNoFindFile.py > Traceback (most recent call last): > File IOErrorCouldNoFindFile, line unknown, in Initialize > File mscorlib, line unknown, in .ctor > File mscorlib, line unknown, in .ctor > IOError: Could not find file "testing_TMP.txt". > > regards, > From jvm_cop at spamcop.net Sat Feb 24 15:39:57 2007 From: jvm_cop at spamcop.net (J. Merrill) Date: Sat, 24 Feb 2007 09:39:57 -0500 Subject: [IronPython] array.fromfile In-Reply-To: <785694cd0702231314p70a0c5a8jd6bca8d857018073@mail.gmail.co m> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702221725w2069366dmc2b5fe3d2a208bf8@mail.gmail.com> <7AD436E4270DD54A94238001769C22276A3AC4E223@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702231314p70a0c5a8jd6bca8d857018073@mail.gmail.com> Message-ID: <7.0.1.0.2.20070224093727.074ac290@wheresmymailserver.com> At 04:14 PM 2/23/2007, JoeSox wrote (in part) >On 2/23/07, Dino Viehland wrote: >> Is there an issue w/ switching to using the I type for the array instead of the L type? > >I tried this but was unsuccessful. It still results in the same >exception being thrown. If I am understanding everything, the only >typecode that uses 8 bytes is floating point 'd'. The file's size in bytes must be (at least) the number of values being read times the size of each value. If you are giving the file size in bytes as the length of the array, that will not work. What information do you have about the format of the file? Are the values supposed to be 4-byte integers? If so, you should divide the file size in bytes by 4 and use the I type, and look at the data to see if it makes any sense. Good luck J. Merrill / Analytical Software Corp From joesox at gmail.com Sat Feb 24 19:54:49 2007 From: joesox at gmail.com (JoeSox) Date: Sat, 24 Feb 2007 10:54:49 -0800 Subject: [IronPython] array.fromfile In-Reply-To: <7.0.1.0.2.20070224093727.074ac290@wheresmymailserver.com> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702221725w2069366dmc2b5fe3d2a208bf8@mail.gmail.com> <7AD436E4270DD54A94238001769C22276A3AC4E223@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702231314p70a0c5a8jd6bca8d857018073@mail.gmail.com> <7.0.1.0.2.20070224093727.074ac290@wheresmymailserver.com> Message-ID: <785694cd0702241054x5990fc03m2cfca31ba7d13634@mail.gmail.com> On 2/24/07, J. Merrill wrote: > The file's size in bytes must be (at least) the number of values being read times the size of each value. If you are giving the file size in bytes as the length of the array, that will not work. > One of the challenges here is that this exception is being thrown from someone else's natural language processing tool written in Python. I would like to use this tool with IronPython for development in a .NET environment. I have been stepping thru the CPython runs and it appears to me that the natural language processing tool is using '260759' as the length value for the .fromfile, and does not result in an exception. > What information do you have about the format of the file? The actual file size is 1044480 bytes. If I open it in notepad and click 'Save As' it wants to save it as an ANSI. A sample of the characters display in notepad as such: "            " * - 2 6 9 = @ C H L O R U Z ^ a d g j m p s w z } ? ? ? ? ? ' ? ? ? (c) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?       & * 3 @ G M R U Z a e i m o s w |  ? ? ? ? " ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?      # & - 4 8 = E J M S \ b f l o u z  ? ? ? ' " ? ? ? ? ?" These are packed lexicon datafiles. > Are the values supposed to be 4-byte integers? Yes, the natural language processing tool's module for loading these datafiles use 'L' which is 4 bytes. > If so, you should divide the file size in bytes by 4 and use the I type, and look at the data to see if it makes any sense. > I really don't wish to modify the natural language processing tool module any more that I already have. Is it really necessary for IronPython to change the "minimum" sizes of the array types? (and hopefully this is my problem, I guess I will need to modify array.cs to truly find out) Thanks, Joe From joesox at gmail.com Sat Feb 24 20:30:09 2007 From: joesox at gmail.com (JoeSox) Date: Sat, 24 Feb 2007 11:30:09 -0800 Subject: [IronPython] array.fromfile In-Reply-To: <785694cd0702241054x5990fc03m2cfca31ba7d13634@mail.gmail.com> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702221725w2069366dmc2b5fe3d2a208bf8@mail.gmail.com> <7AD436E4270DD54A94238001769C22276A3AC4E223@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702231314p70a0c5a8jd6bca8d857018073@mail.gmail.com> <7.0.1.0.2.20070224093727.074ac290@wheresmymailserver.com> <785694cd0702241054x5990fc03m2cfca31ba7d13634@mail.gmail.com> Message-ID: <785694cd0702241130s16714010o3ae2ef8a68ecab70@mail.gmail.com> On 2/24/07, JoeSox wrote: > I really don't wish to modify the natural language processing tool > module any more that I already have. Is it really necessary for > IronPython to change the "minimum" sizes of the array types? (and > hopefully this is my problem, I guess I will need to modify array.cs > to truly find out) Well, I changed the typecode's in array.cs to resemble CPython's but it seems ArrayData class can not handle the change. I haven't examined the ArrayData in detail. Maybe I need to change 'L' to UInt64. Here are my results for anyone interested: ----array.cs changes: case 'c': data = new ArrayData(); break; case 'b': data = new ArrayData(); break; case 'B': data = new ArrayData(); break; case 'u': data = new ArrayData(); break; case 'h': data = new ArrayData(); break; case 'H': data = new ArrayData(); break; case 'i': data = new ArrayData(); break; case 'I': data = new ArrayData(); break; case 'l': data = new ArrayData(); break; case 'L': data = new ArrayData(); break; case 'f': data = new ArrayData(); break; case 'd': data = new ArrayData(); break; ---exception: System.OverflowException was caught Message="couldn't convert to " Source="IronPython" StackTrace: at IronPython.Modules.ArrayModule.PythonArray.ArrayData`1.GetValue(Object value) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 566 at IronPython.Modules.ArrayModule.PythonArray.ArrayData`1.Append(Object value) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 579 at IronPython.Modules.ArrayModule.PythonArray.FromStream(Stream ms) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 542 at IronPython.Modules.ArrayModule.PythonArray.FromString(String s) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 216 at IronPython.Modules.ArrayModule.PythonArray.FromFile(PythonFile f, Int32 n) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 204 at FromFile##120(Object , Object , Object ) at IronPython.Runtime.Calls.CallTarget3.Invoke(Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallable3.CallInstance(ICallerContext context, Object arg0, Object arg1, Object arg2) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\FastCallable.Generated.cs:line 654 at IronPython.Runtime.Calls.BoundBuiltinFunction.Call(ICallerContext context, Object arg0, Object arg1) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\BuiltinFunction.Generated.cs:line 82 at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func, Object arg0, Object arg1) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.Generated.cs:line 92 at CNUMontyLexiconFast.array_fromfile$f343(FunctionEnvironment32Dictionary $env, Object self, Object file_ptr, Object array_ptr, Object length, Object java_p, Object java_code, Object endian_order) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\CNU\CNUtils2Demo\CNUtils2Demo\bin\Debug\CNUMontyLexiconFast.py:line 255 at CNUMontyLexiconFast.array_fromfile$f343(FunctionEnvironment32Dictionary , Object[] ) at IronPython.Runtime.Calls.FunctionN.Call(ICallerContext context, Object[] args) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.cs:line 721 at IronPython.Runtime.Calls.FastCallable.Call(Object[] args) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\FastCallable.cs:line 113 at IronPython.Runtime.Calls.PythonFunction.Call(ICallerContext context, Object[] args, String[] kwNames) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.cs:line 430 at IronPython.Runtime.Operations.Ops.Call(ICallerContext context, Object func, Object[] args, String[] names) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.cs:line 1428 at IronPython.Runtime.Calls.Method.Call(ICallerContext context, Object[] args, String[] names) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.cs:line 996 at IronPython.Runtime.Operations.Ops.Call(ICallerContext context, Object func, Object[] args, String[] names) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.cs:line 1428 at CNUMontyLexiconFast.load_fastlexicon$f332(FunctionEnvironment32Dictionary $env, Object self) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\CNU\CNUtils2Demo\CNUtils2Demo\bin\Debug\CNUMontyLexiconFast.py:line 101 at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.Generated.cs:line 127 at IronPython.Runtime.Calls.PythonFunction.CallInstance(ICallerContext context, Object arg0) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.Generated.cs:line 48 at IronPython.Runtime.Calls.Method.Call(ICallerContext context) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.Generated.cs:line 522 at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.Generated.cs:line 78 at CNUMontyLexiconFast.__init__$f330(FunctionEnvironment32Dictionary $env, Object self) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\CNU\CNUtils2Demo\CNUtils2Demo\bin\Debug\CNUMontyLexiconFast.py:line 37 (snipped) -- Thanks, Joe From dinov at exchange.microsoft.com Sat Feb 24 21:25:09 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Sat, 24 Feb 2007 12:25:09 -0800 Subject: [IronPython] array.fromfile In-Reply-To: <785694cd0702241130s16714010o3ae2ef8a68ecab70@mail.gmail.com> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702221725w2069366dmc2b5fe3d2a208bf8@mail.gmail.com> <7AD436E4270DD54A94238001769C22276A3AC4E223@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702231314p70a0c5a8jd6bca8d857018073@mail.gmail.com> <7.0.1.0.2.20070224093727.074ac290@wheresmymailserver.com> <785694cd0702241054x5990fc03m2cfca31ba7d13634@mail.gmail.com>, <785694cd0702241130s16714010o3ae2ef8a68ecab70@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C22276A3AC4E228@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Unfortunately there are several switch statements that will need to be updated. They are in CreateData (generic type), ToStream (cast), FromStream (call Read?Int32). If you update all 3 you should be consistent then. If I had to take a guess here I would think maybe there's an earlier read from an array that's driving the # of elements to be read later. I'm not opposed to changing the sizes of these to match CPython but I suspect we can never make the sizes 100% compatible across all architectures on all platforms. Technically this IS a bug in the module you're using - it shouldn't expect the sizes to be fixed. We can make these 4 byte values but I suspect we'll have differences on x64. We can make them platform dependent but not all platforms have the same definitions for the size of "long". In particular I believe Windows defines this as being 4 bytes and most other platforms choose 8 bytes. Based upon that investigating I'll update the sizes so we can be more compatible. But I'd love to hear if updating all 3 fixes your problem. ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of JoeSox [joesox at gmail.com] Sent: Saturday, February 24, 2007 11:30 AM To: Discussion of IronPython Subject: Re: [IronPython] array.fromfile On 2/24/07, JoeSox wrote: > I really don't wish to modify the natural language processing tool > module any more that I already have. Is it really necessary for > IronPython to change the "minimum" sizes of the array types? (and > hopefully this is my problem, I guess I will need to modify array.cs > to truly find out) Well, I changed the typecode's in array.cs to resemble CPython's but it seems ArrayData class can not handle the change. I haven't examined the ArrayData in detail. Maybe I need to change 'L' to UInt64. Here are my results for anyone interested: ----array.cs changes: case 'c': data = new ArrayData(); break; case 'b': data = new ArrayData(); break; case 'B': data = new ArrayData(); break; case 'u': data = new ArrayData(); break; case 'h': data = new ArrayData(); break; case 'H': data = new ArrayData(); break; case 'i': data = new ArrayData(); break; case 'I': data = new ArrayData(); break; case 'l': data = new ArrayData(); break; case 'L': data = new ArrayData(); break; case 'f': data = new ArrayData(); break; case 'd': data = new ArrayData(); break; ---exception: System.OverflowException was caught Message="couldn't convert to " Source="IronPython" StackTrace: at IronPython.Modules.ArrayModule.PythonArray.ArrayData`1.GetValue(Object value) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 566 at IronPython.Modules.ArrayModule.PythonArray.ArrayData`1.Append(Object value) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 579 at IronPython.Modules.ArrayModule.PythonArray.FromStream(Stream ms) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 542 at IronPython.Modules.ArrayModule.PythonArray.FromString(String s) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 216 at IronPython.Modules.ArrayModule.PythonArray.FromFile(PythonFile f, Int32 n) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 204 at FromFile##120(Object , Object , Object ) at IronPython.Runtime.Calls.CallTarget3.Invoke(Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallable3.CallInstance(ICallerContext context, Object arg0, Object arg1, Object arg2) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\FastCallable.Generated.cs:line 654 at IronPython.Runtime.Calls.BoundBuiltinFunction.Call(ICallerContext context, Object arg0, Object arg1) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\BuiltinFunction.Generated.cs:line 82 at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func, Object arg0, Object arg1) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.Generated.cs:line 92 at CNUMontyLexiconFast.array_fromfile$f343(FunctionEnvironment32Dictionary $env, Object self, Object file_ptr, Object array_ptr, Object length, Object java_p, Object java_code, Object endian_order) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\CNU\CNUtils2Demo\CNUtils2Demo\bin\Debug\CNUMontyLexiconFast.py:line 255 at CNUMontyLexiconFast.array_fromfile$f343(FunctionEnvironment32Dictionary , Object[] ) at IronPython.Runtime.Calls.FunctionN.Call(ICallerContext context, Object[] args) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.cs:line 721 at IronPython.Runtime.Calls.FastCallable.Call(Object[] args) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\FastCallable.cs:line 113 at IronPython.Runtime.Calls.PythonFunction.Call(ICallerContext context, Object[] args, String[] kwNames) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.cs:line 430 at IronPython.Runtime.Operations.Ops.Call(ICallerContext context, Object func, Object[] args, String[] names) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.cs:line 1428 at IronPython.Runtime.Calls.Method.Call(ICallerContext context, Object[] args, String[] names) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.cs:line 996 at IronPython.Runtime.Operations.Ops.Call(ICallerContext context, Object func, Object[] args, String[] names) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.cs:line 1428 at CNUMontyLexiconFast.load_fastlexicon$f332(FunctionEnvironment32Dictionary $env, Object self) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\CNU\CNUtils2Demo\CNUtils2Demo\bin\Debug\CNUMontyLexiconFast.py:line 101 at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.Generated.cs:line 127 at IronPython.Runtime.Calls.PythonFunction.CallInstance(ICallerContext context, Object arg0) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.Generated.cs:line 48 at IronPython.Runtime.Calls.Method.Call(ICallerContext context) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.Generated.cs:line 522 at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.Generated.cs:line 78 at CNUMontyLexiconFast.__init__$f330(FunctionEnvironment32Dictionary $env, Object self) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\CNU\CNUtils2Demo\CNUtils2Demo\bin\Debug\CNUMontyLexiconFast.py:line 37 (snipped) -- Thanks, Joe _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Sat Feb 24 21:49:15 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Sat, 24 Feb 2007 12:49:15 -0800 Subject: [IronPython] array.fromfile In-Reply-To: <7AD436E4270DD54A94238001769C22276A3AC4E228@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702221725w2069366dmc2b5fe3d2a208bf8@mail.gmail.com> <7AD436E4270DD54A94238001769C22276A3AC4E223@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702231314p70a0c5a8jd6bca8d857018073@mail.gmail.com> <7.0.1.0.2.20070224093727.074ac290@wheresmymailserver.com> <785694cd0702241054x5990fc03m2cfca31ba7d13634@mail.gmail.com>, <785694cd0702241130s16714010o3ae2ef8a68ecab70@mail.gmail.com>, <7AD436E4270DD54A94238001769C22276A3AC4E228@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <7AD436E4270DD54A94238001769C22276A3AC4E22A@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Ok, L/l are always 32-bits on CPython on Windows at least, so we'll match that behavior. I also noticed an additional bug where we aren't returning BigInt's from these so we'll fix that too. ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland [dinov at exchange.microsoft.com] Sent: Saturday, February 24, 2007 12:25 PM To: Discussion of IronPython Subject: Re: [IronPython] array.fromfile Unfortunately there are several switch statements that will need to be updated. They are in CreateData (generic type), ToStream (cast), FromStream (call Read?Int32). If you update all 3 you should be consistent then. If I had to take a guess here I would think maybe there's an earlier read from an array that's driving the # of elements to be read later. I'm not opposed to changing the sizes of these to match CPython but I suspect we can never make the sizes 100% compatible across all architectures on all platforms. Technically this IS a bug in the module you're using - it shouldn't expect the sizes to be fixed. We can make these 4 byte values but I suspect we'll have differences on x64. We can make them platform dependent but not all platforms have the same definitions for the size of "long". In particular I believe Windows defines this as being 4 bytes and most other platforms choose 8 bytes. Based upon that investigating I'll update the sizes so we can be more compatible. But I'd love to hear if updating all 3 fixes your problem. ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of JoeSox [joesox at gmail.com] Sent: Saturday, February 24, 2007 11:30 AM To: Discussion of IronPython Subject: Re: [IronPython] array.fromfile On 2/24/07, JoeSox wrote: > I really don't wish to modify the natural language processing tool > module any more that I already have. Is it really necessary for > IronPython to change the "minimum" sizes of the array types? (and > hopefully this is my problem, I guess I will need to modify array.cs > to truly find out) Well, I changed the typecode's in array.cs to resemble CPython's but it seems ArrayData class can not handle the change. I haven't examined the ArrayData in detail. Maybe I need to change 'L' to UInt64. Here are my results for anyone interested: ----array.cs changes: case 'c': data = new ArrayData(); break; case 'b': data = new ArrayData(); break; case 'B': data = new ArrayData(); break; case 'u': data = new ArrayData(); break; case 'h': data = new ArrayData(); break; case 'H': data = new ArrayData(); break; case 'i': data = new ArrayData(); break; case 'I': data = new ArrayData(); break; case 'l': data = new ArrayData(); break; case 'L': data = new ArrayData(); break; case 'f': data = new ArrayData(); break; case 'd': data = new ArrayData(); break; ---exception: System.OverflowException was caught Message="couldn't convert to " Source="IronPython" StackTrace: at IronPython.Modules.ArrayModule.PythonArray.ArrayData`1.GetValue(Object value) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 566 at IronPython.Modules.ArrayModule.PythonArray.ArrayData`1.Append(Object value) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 579 at IronPython.Modules.ArrayModule.PythonArray.FromStream(Stream ms) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 542 at IronPython.Modules.ArrayModule.PythonArray.FromString(String s) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 216 at IronPython.Modules.ArrayModule.PythonArray.FromFile(PythonFile f, Int32 n) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Modules\array.cs:line 204 at FromFile##120(Object , Object , Object ) at IronPython.Runtime.Calls.CallTarget3.Invoke(Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallable3.CallInstance(ICallerContext context, Object arg0, Object arg1, Object arg2) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\FastCallable.Generated.cs:line 654 at IronPython.Runtime.Calls.BoundBuiltinFunction.Call(ICallerContext context, Object arg0, Object arg1) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\BuiltinFunction.Generated.cs:line 82 at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func, Object arg0, Object arg1) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.Generated.cs:line 92 at CNUMontyLexiconFast.array_fromfile$f343(FunctionEnvironment32Dictionary $env, Object self, Object file_ptr, Object array_ptr, Object length, Object java_p, Object java_code, Object endian_order) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\CNU\CNUtils2Demo\CNUtils2Demo\bin\Debug\CNUMontyLexiconFast.py:line 255 at CNUMontyLexiconFast.array_fromfile$f343(FunctionEnvironment32Dictionary , Object[] ) at IronPython.Runtime.Calls.FunctionN.Call(ICallerContext context, Object[] args) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.cs:line 721 at IronPython.Runtime.Calls.FastCallable.Call(Object[] args) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\FastCallable.cs:line 113 at IronPython.Runtime.Calls.PythonFunction.Call(ICallerContext context, Object[] args, String[] kwNames) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.cs:line 430 at IronPython.Runtime.Operations.Ops.Call(ICallerContext context, Object func, Object[] args, String[] names) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.cs:line 1428 at IronPython.Runtime.Calls.Method.Call(ICallerContext context, Object[] args, String[] names) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.cs:line 996 at IronPython.Runtime.Operations.Ops.Call(ICallerContext context, Object func, Object[] args, String[] names) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.cs:line 1428 at CNUMontyLexiconFast.load_fastlexicon$f332(FunctionEnvironment32Dictionary $env, Object self) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\CNU\CNUtils2Demo\CNUtils2Demo\bin\Debug\CNUMontyLexiconFast.py:line 101 at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.Generated.cs:line 127 at IronPython.Runtime.Calls.PythonFunction.CallInstance(ICallerContext context, Object arg0) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.Generated.cs:line 48 at IronPython.Runtime.Calls.Method.Call(ICallerContext context) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Calls\Function.Generated.cs:line 522 at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\IronPython-1.1B1\Src\IronPython\Runtime\Operations\Ops.Generated.cs:line 78 at CNUMontyLexiconFast.__init__$f330(FunctionEnvironment32Dictionary $env, Object self) in C:\Documents and Settings\Joseph\My Documents\Visual Studio 2005\Projects\CNU\CNUtils2Demo\CNUtils2Demo\bin\Debug\CNUMontyLexiconFast.py:line 37 (snipped) -- Thanks, Joe _______________________________________________ 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 alex at moreati.org.uk Mon Feb 26 02:35:35 2007 From: alex at moreati.org.uk (Alex Willmer) Date: Mon, 26 Feb 2007 01:35:35 +0000 Subject: [IronPython] Using CLR bound COM interfaces Message-ID: <1172453735.13896.37.camel@martha> Hello, I've been attempting with IronPython, to access the CLR binding to ArcObjects[1], a COM based Geographic Information System (GIS) library. I come at this from a CPython background, so my knowledge of COM & .NET are lacking. I'm trying to understand how interfaces (IFoobar) are dealt with in IronPython. A C# example I'm attempting to transcribe contains the following lines: if (!((objectWorkspace is IWorkspace) || (objectWorkspace is IFeatureDataset))) { throw(new Exception(....)); } My assumption was that isinstance() would replace 'is', but the following would indicate otherwise. From the .NET 2.0 docs[2] the System.Uri class inherits from ISerializable >>> import System >>> import System.Runtime.Serialization >>> x = System.Uri('http://example.net') >>> isinstance(x, System.Uri) True >>> isinstance(x, System.Runtime.Serialization.ISerializable) False How should I test a particular object implements an interface? My second query is based on the following C#: IGeometryDefEdit geometryDefEdit = (IGeometryDefEdit) geometryDef; // Assign Geometry Definition geometryDefEdit.GeometryType_2 = geometryType; geometryDefEdit.GridCount_2 = 1; geometryDefEdit.set_GridSize(0, 0.5); geometryDefEdit.AvgNumPoints_2 = 2; geometryDefEdit.HasM_2 = false; geometryDefEdit.HasZ_2 = true; I understand that to transcribe this is I should forget the assignment/cast and replace geometryDefEdit.Method(args) with IGeometryDefEdit.MethodName(geometryDef, args). Is this correct? Many thanks. Alex Willmer [1] http://edndoc.esri.com/arcobjects/9.1/ [2] http://msdn2.microsoft.com/en-us/library/system.uri.aspx From Shri.Borde at microsoft.com Mon Feb 26 20:59:55 2007 From: Shri.Borde at microsoft.com (Shri Borde) Date: Mon, 26 Feb 2007 11:59:55 -0800 Subject: [IronPython] Using CLR bound COM interfaces In-Reply-To: <1172453735.13896.37.camel@martha> References: <1172453735.13896.37.camel@martha> Message-ID: <50B69702CA6E6D4E849D30CD4989AB8E6939B90B53@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Using isinstance should be the right way to check if an object is an interface. However, this does not currently work. http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=8121 tracks this issue. The (admittedly ugly) workaround that is also mentioned in the bug is: >>> import clr >>> import System >>> isinstance(1, System.IFormattable) # Should return True False >>> clr.GetClrType(System.IFormattable).IsAssignableFrom(clr.GetClrType(type(1))) # Workaround True For your second question, the answer depends on the actual type (not the statically declared C# type) of "geometryDef". If it implements IGeometryDefEdit explicitly, you do need to use "IGeometryDefEdit.MethodName(geometryDef, args)". Else, you can just use "geometryDef. MethodName(args)". The following bugs are related. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=4538 http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=1506 -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Alex Willmer Sent: Sunday, February 25, 2007 5:36 PM To: users at lists.ironpython.com Subject: [IronPython] Using CLR bound COM interfaces Hello, I've been attempting with IronPython, to access the CLR binding to ArcObjects[1], a COM based Geographic Information System (GIS) library. I come at this from a CPython background, so my knowledge of COM & .NET are lacking. I'm trying to understand how interfaces (IFoobar) are dealt with in IronPython. A C# example I'm attempting to transcribe contains the following lines: if (!((objectWorkspace is IWorkspace) || (objectWorkspace is IFeatureDataset))) { throw(new Exception(....)); } My assumption was that isinstance() would replace 'is', but the following would indicate otherwise. From the .NET 2.0 docs[2] the System.Uri class inherits from ISerializable >>> import System >>> import System.Runtime.Serialization >>> x = System.Uri('http://example.net') >>> isinstance(x, System.Uri) True >>> isinstance(x, System.Runtime.Serialization.ISerializable) False How should I test a particular object implements an interface? My second query is based on the following C#: IGeometryDefEdit geometryDefEdit = (IGeometryDefEdit) geometryDef; // Assign Geometry Definition geometryDefEdit.GeometryType_2 = geometryType; geometryDefEdit.GridCount_2 = 1; geometryDefEdit.set_GridSize(0, 0.5); geometryDefEdit.AvgNumPoints_2 = 2; geometryDefEdit.HasM_2 = false; geometryDefEdit.HasZ_2 = true; I understand that to transcribe this is I should forget the assignment/cast and replace geometryDefEdit.Method(args) with IGeometryDefEdit.MethodName(geometryDef, args). Is this correct? Many thanks. Alex Willmer [1] http://edndoc.esri.com/arcobjects/9.1/ [2] http://msdn2.microsoft.com/en-us/library/system.uri.aspx _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jojoba12 at hotmail.com Mon Feb 26 21:46:35 2007 From: jojoba12 at hotmail.com (jojoba) Date: Mon, 26 Feb 2007 12:46:35 -0800 Subject: [IronPython] how do you use ironpython 1.1 in visual studio 2005 Message-ID: <1172522795.467923.300730@q2g2000cwa.googlegroups.com> does anyone know how to use ironpython 1.1 in visual studio 2005!?!?!?! From austuff at gmail.com Tue Feb 27 00:39:57 2007 From: austuff at gmail.com (aus stuff) Date: Tue, 27 Feb 2007 09:09:57 +0930 Subject: [IronPython] how do you use ironpython 1.1 in visual studio 2005 In-Reply-To: <1172522795.467923.300730@q2g2000cwa.googlegroups.com> References: <1172522795.467923.300730@q2g2000cwa.googlegroups.com> Message-ID: <7d1760310702261539r29d93b0ds95164c888e111e75@mail.gmail.com> This was good heads up for me http://blogs.msdn.com/533273.aspx Regards On 2/27/07, jojoba wrote: > > does anyone know how to use ironpython 1.1 in visual studio 2005!?!?!?! > > _______________________________________________ > 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 joesox at gmail.com Tue Feb 27 06:59:13 2007 From: joesox at gmail.com (JoeSox) Date: Mon, 26 Feb 2007 21:59:13 -0800 Subject: [IronPython] array.fromfile In-Reply-To: <7AD436E4270DD54A94238001769C22276A3AC4E228@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702221725w2069366dmc2b5fe3d2a208bf8@mail.gmail.com> <7AD436E4270DD54A94238001769C22276A3AC4E223@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702231314p70a0c5a8jd6bca8d857018073@mail.gmail.com> <7.0.1.0.2.20070224093727.074ac290@wheresmymailserver.com> <785694cd0702241054x5990fc03m2cfca31ba7d13634@mail.gmail.com> <785694cd0702241130s16714010o3ae2ef8a68ecab70@mail.gmail.com> <7AD436E4270DD54A94238001769C22276A3AC4E228@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <785694cd0702262159s6d4ed5bp3b823e557a2a95cb@mail.gmail.com> Outstanding news! It worked. I finally had some extra time to change the other two methods to match my modifications to CreateData and it worked like a charm. Pretty cool. I think this is the best way to go, so not too many people get broken. Thanks, JoeSox On 2/24/07, Dino Viehland wrote: > Unfortunately there are several switch statements that will need to be updated. They are in CreateData (generic type), ToStream (cast), FromStream (call Read?Int32). If you update all 3 you should be consistent then. > > If I had to take a guess here I would think maybe there's an earlier read from an array that's driving the # of elements to be read later. > > I'm not opposed to changing the sizes of these to match CPython but I suspect we can never make the sizes 100% compatible across all architectures on all platforms. Technically this IS a bug in the module you're using - it shouldn't expect the sizes to be fixed. We can make these 4 byte values but I suspect we'll have differences on x64. We can make them platform dependent but not all platforms have the same definitions for the size of "long". In particular I believe Windows defines this as being 4 bytes and most other platforms choose 8 bytes. Based upon that investigating I'll update the sizes so we can be more compatible. But I'd love to hear if updating all 3 fixes your problem. > ________________________________________ From dinov at exchange.microsoft.com Tue Feb 27 20:47:27 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 27 Feb 2007 11:47:27 -0800 Subject: [IronPython] array.fromfile In-Reply-To: <785694cd0702262159s6d4ed5bp3b823e557a2a95cb@mail.gmail.com> References: <785694cd0702212215m236cd1f6lf273277096dcaae8@mail.gmail.com> <7AD436E4270DD54A94238001769C222769DB4F653E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702221725w2069366dmc2b5fe3d2a208bf8@mail.gmail.com> <7AD436E4270DD54A94238001769C22276A3AC4E223@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702231314p70a0c5a8jd6bca8d857018073@mail.gmail.com> <7.0.1.0.2.20070224093727.074ac290@wheresmymailserver.com> <785694cd0702241054x5990fc03m2cfca31ba7d13634@mail.gmail.com> <785694cd0702241130s16714010o3ae2ef8a68ecab70@mail.gmail.com> <7AD436E4270DD54A94238001769C22276A3AC4E228@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <785694cd0702262159s6d4ed5bp3b823e557a2a95cb@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C22276A3A8E0F2E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Cool, thanks for spending the time to try this out. I'll check-in the change in the next couple of days and it'll be 4 bytes in the next release. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of JoeSox Sent: Monday, February 26, 2007 9:59 PM To: Discussion of IronPython Subject: Re: [IronPython] array.fromfile Outstanding news! It worked. I finally had some extra time to change the other two methods to match my modifications to CreateData and it worked like a charm. Pretty cool. I think this is the best way to go, so not too many people get broken. Thanks, JoeSox On 2/24/07, Dino Viehland wrote: > Unfortunately there are several switch statements that will need to be updated. They are in CreateData (generic type), ToStream (cast), FromStream (call Read?Int32). If you update all 3 you should be consistent then. > > If I had to take a guess here I would think maybe there's an earlier read from an array that's driving the # of elements to be read later. > > I'm not opposed to changing the sizes of these to match CPython but I suspect we can never make the sizes 100% compatible across all architectures on all platforms. Technically this IS a bug in the module you're using - it shouldn't expect the sizes to be fixed. We can make these 4 byte values but I suspect we'll have differences on x64. We can make them platform dependent but not all platforms have the same definitions for the size of "long". In particular I believe Windows defines this as being 4 bytes and most other platforms choose 8 bytes. Based upon that investigating I'll update the sizes so we can be more compatible. But I'd love to hear if updating all 3 fixes your problem. > ________________________________________ _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com