Ahh, well if it's ASP.NET it's all multi-threaded because you're probably handling more than one request at a time.
From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Pablo Dalmazzo Sent: Thursday, October 14, 2010 4:49 AM To: IronPython Mailing list Subject: Re: [IronPython] expected behavior of the module copy with .net objects thanks for the reply Dino, If I get any additional info about it, I'll post it. In one application (which triggered the error you mentioned it) Im using an asp.net timer. That runs in another thread, right? Greetings, Pablo ________________________________ From: di...@microsoft.com To: users@lists.ironpython.com Date: Wed, 13 Oct 2010 19:47:04 +0000 Subject: Re: [IronPython] expected behavior of the module copy with .net objects I think as of now copy is certainly not suitable for all .NET objects. For starters not all .NET objects are serializable/copyable. There should probably be some effort to close the gaps where it makes sense. For example something which implements ICloneable could have a __copy__ method added to it. This is similar to how we add a __reduce_ex__ method for things which implement ISerializable. But if something doesn't implement either of these interfaces then there's no standard way for us to copy these objects. If you have specific object types which you know you need to copy I would suggest registering the type with copy_reg. That should at least give you a solution for your specific scenarios. You also mentioned the null reference exception ("object reference not set to object instance..."). That sounds like a bug - I would guess you're running in a multi-threaded environment? If you could get a repro of this that'd be great as it looks like it could be an issue w/ our dictionary implementation not being thread safe. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Pablo Dalmazzo Sent: Wednesday, October 13, 2010 11:51 AM To: IronPython Mailing list Subject: [IronPython] expected behavior of the module copy with .net objects Hi guys, Sorry for being annoying about this but I just want to know where I'm standing at :) It would seem to me the copy module has some problems copying .net objects in general. I was wondering if I'm pretending too much for that module and it will never fully copy objects instantiated from .net classes, or it's a goal for it to do it someday, or I just happened to find a couple of errors, or Im not using it rightly for what it was meant to be. I dont know 5% of what you know so it's an honest question :) Aside there are a couple of errors I cant reproduce, and that it didnt copy System.DBNull , now I see it loses property values when copying a System.Data.SqlConnection object, properties such as "DataSource", "DataBase", etc. they get empty strings after being copied. Just in case I tried with the original version of the module/file copy. I guess you have thousands of things to check but I just want to know, it's the module supposed to copy any object instantiated from .net classes or it's only supposed to fully work only for custom made classes? Greetings, Pablo Dalmazzo P.S: sorry about insisting again with this but I've also added another example where it seems to fail :) _______________________________________________ Users mailing list Users@lists.ironpython.com<mailto:Users@lists.ironpython.com> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
