Hello guys,we've found a bug in the copy module, but the real problem is we
cant reproduce it. Sometimes when we try to deepcopy an object of a custom
object relation mapping type, we get this errorname types is not definedLine
55: for t in (type(None),int,long,float,bool,str,tuple),
On 12/10/2010 15:29, Pablo Dalmazzo wrote:
Hello guys,
we've found a bug in the copy module, but the real problem is we cant
reproduce it.
Sometimes when we try to deepcopy an object of a custom object
relation mapping type, we get this error
name types is not defined
Line 55:
for t in
Hi Michael,
yes, sorry, it's line 102. I have added a couple of lines to fix the
problem with the module copy not copying System.DBNull types before, it
looked like they worked with that problem. (and I erased the
commentaries of the module) But this seems to be another problem.
I
Hi,
I'm running the pyc.py IronPython compiler. In the GenerateExe method, there
is a call to GetMethod(InitializeModule). This method was available in
IP 2.6 but seems to have disappeared in IP 2.7.
I used GetMethods() to confirm that in IP 2.6 we have:
Int32*
It should still be there at least I still see it in the sources. It's not
defined for Silverlight builds (I'm not sure if that's a change or not). One
thing to be careful of is that 2.6 and 2.7 do have different .NET assembly
versions so they will be treated as different types. In other
Thanks Dino,
OK, after installing my IP 2.7, the only IP .dll's are in c:\program
files\ironpython 2.7\Silverlight\bin\*.dll. Are these the Silverlight
builds you mentioned? If so, how would I get the standard builds?
I noticed that in my 2.6 installation, the dll's are in c:\program
I just got another error, no idea what triggered it but just reporting it
anyway, it happened when copying another object with data from a sql server
table.
line 191
return memo[d]
object reference not set to object instance (sort of, Im translating it from
spanish where it says Referencia
Ahh, yes, in 2.7 we switched to installing the binaries into the GAC so they
won't be in C:\Program Files anymore. Instead they should be in
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\IronPython\...
Also, are you using the 2.7 PYC w/ 2.7 or are you using the 2.6 PYC? I'm not
sure it'll make
Jeff wrote:
Can this be changed, Dino? It's a couple MB on disk and no difference to the
installer to have them in both places.
Yep, it should be easy to change. I'll take a look later this week at doing
that.
___
Users mailing list
Cool. Seems to work fine w/ the DLL's from GAC_MSIL\IronP\.. the method
shows up and the .exe seems to build just fine.
I'm using a version of pyc.py based on the 2.7 pyc.py. I've modified it so
that can build all of the standard library source modules needed into the
application dll, so that
On Tue, Oct 12, 2010 at 12:30 PM, Ken MacDonald drken...@gmail.com wrote:
Cool. Seems to work fine w/ the DLL's from GAC_MSIL\IronP\.. the method
shows up and the .exe seems to build just fine.
I'm using a version of pyc.py based on the 2.7 pyc.py. I've modified it so
that can build all
Random crazy thought: can you use ilmerge to pull all of those into
one .exe? Horribly bloated, I'm sure, but possibly useful for
distribution.
- Jeff
I was just happy to be able to get all of the source code into DLLs, which
meant 1) not having to install IP on customer systems where we
12 matches
Mail list logo
