Dino Viehland a écrit :
> I haven't seen anything like this before... But I have a couple of questions:
> Are the keys always strings when it repros? And is the dictionary always
> created using the {} syntax?
the keys are always strings, and the dict is instantiated only once,
with the {} syn
Dino Viehland a écrit :
> Thanks for the bug report. I've opened this as CodePlex bug #2290. I've
> tentatively opened this as a 1.01 bug so let us know if this is blocking you.
No emergency, thanks, I have a workaround!
Congrat. for quick answer!
Stan.
>
> One workaround is to do:
>
> 'ab
Thanks for the bug report. I've opened this as CodePlex bug #2290. I've
tentatively opened this as a 1.01 bug so let us know if this is blocking you.
One workaround is to do:
'abc'.encode(sys.getdefaultencoding())
Which will work on both CPython & IronPython.
You could also pass None in on I
I haven't seen anything like this before... But I have a couple of questions:
Are the keys always strings when it repros? And is the dictionary always
created using the {} syntax?
I ask because we have a lot of different dictionary implementations, or there
could be a bug where we have differ
By the way, the environment in which the bug shows up is
single-threaded, so I do not suspect any concurrent access problem.
Stan.
Stanislas Pinte a écrit :
> Hello,
>
> We are just seeing a very strange bug in the following code:
>
> myDictionnary = {}
> .
> for key in myDictionnary.keys():
>
Hello,
We are just seeing a very strange bug in the following code:
myDictionnary = {}
..
for key in myDictionnary.keys():
assert myDictionnary.has_key(key) --> throw AssertionError
this is fixed by the following change:
for key, value in myDictionnary.iteritems():
...
Ever seen this?
Too
more info on what 2.4 should be:
> encode( [encoding[,errors]])
> Return an encoded version of the string. Default encoding is the current
> default string encoding. errors may be given to set a different error
> handling scheme. The default for errors is 'strict', meaning that encodin
Hello,
[sim-ironpython]> python
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> "a".encode()
'a'
>>> ^Z
[sim-ironpython]> ironpython/ipy.exe
IronPython 1.0.60816 on .NET 2.0.50727.42
Copyrigh
Well, I'm back.
Catching up... Done.
Mark's changes from this mail is now merged:
http://lists.ironpython.com/pipermail/users-ironpython.com/2006-August/003052.html
And available here:
http://sparcs.kaist.ac.kr/~tinuviel/fepy/lib/pyexpat.py
With a test:
http://sparcs.kaist.ac.kr/~tinuviel/fepy/
Leaking memory with IronPython.Compiler.Options.GenerateDynamicMethods
= false isn’t really a big issue: ClrDebuggingEnabled = true already
starts to leak memory (at least that’s what the comment says).
Is there any complete documentation about
what actions cause memory leaks? By follow
You can use engine.Globals["name"] = value
Martin
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Cosby
Sent: Thursday, August 17, 2006 5:34 PM
To: IronPython Users
Subject: [IronPython] PythonEngine.SetVariable
At one point, PythonEngine.SetVariable
Without looking at the IP source, can we be confident that the same IL is
produced when a DynamicMethod is created as when AssemblyBuilder is used? Do
the test cases get run with both settings of Options.GenerateDynamicMethods?
One of the most frustrating debugging problems is when code fails w
12 matches
Mail list logo
